IT/IT소식2009. 1. 26. 00:34

개 요
컴퓨터를 효과적으로 활용하기 위해서 하드웨어뿐만 아니라 정교한 소프트웨어가 필요
 하다. 이에 따라 우수한 프로그램을 개발하여 업무의 효율성을 높이고, 궁극적으로 국
 가발전에 이바지하기 위해서 컴퓨터에 관한 전문적인 지식과 기술을 갖춘 사람을 양성
 할 목적으로 제정됨.

 
영문명칭
Engineer Information Processing
변천과정  
 
1974년 정보처리기사 1급으로 신설되어 1999년 정보처리기사로 변경됨. 
 
수행직무  
 
- 컴퓨터 시스템을 통한 프로그램 개발 및 전산시스템을 분석하고,
   전산 업무의 타당성검토, 정보시스템분석, 시스템설계등 정보처리 전반에
   관한 업무수행 
 
취득방법  
 
① 시 행 처 : 한국산업인력공단
② 관련학과 : 대학 및 전문대학의 전자, 컴퓨터, 전산 계열학과 (컴퓨터공학과, 전산
               공학과, 전자계산공학과, 전산학과, 소프트웨어공학과 등) 및 동국대, 
               숭실대, 광운대, 한남대 부설 전자계산원.
③ 시험과목 
  - 필기 
   1. 데이터베이스
   2. 전자계산기구조
   3. 운영체제
   4. 소프트웨어공학
   5. 데이터통신
  - 실기 : 정보처리 실무
④ 검정방법
  - 필기 : 객관식 4지 택일형, 과목당 20문항(과목당 30분)
  - 실기 : 필답형(3시간)
⑤ 합격기준 
  - 필기 : 100점을 만점으로 하여 과목당 40점 이상, 전과목 평균 60점 이상.
  - 실기 : 100점을 만점으로 하여 60점 이상. 
 
진로 및 전망  
 
- 기업체 전산실, 소프트웨어 개발업체, SI(system integrated)업체 (정보통신, 시스템
   구축회사 등)정부기관, 언론기관, 교육 및 연구기관, 금융기관, 보험업, 병원 등 컴
   퓨터 시스템을 개발 및 운용하거나, 데이터 통신을 이용하여 정보처리를 시행하는 업
   체에서 활동하고 있다. 품질검사 전문기관 기술인력과 감리원 자격을 취득하여 감리
   전문회사의 감리원으로 진출할 수 있다. 3년 이상의 실무경력이 있는 자는 측량분야
   수치지도제작업의 정보처리 담당자로 진출가능하고, 정보통신부의 별정우체국 사무
   장, 사무주임, 사무보조 등 사무원으로 진출할 수 있다.
 - 정보화사회로 이행함에 따라 지식과 정보의 양이 증대되어 작업량과 업무량이 급속
   하게 증가했다. 또한 각종 업무의 전산화 요구가 더욱 증대되어 사회 전문분야로
   컴퓨터 사용이 보편화되면서 컴퓨터산업은 급속도로 확대되었다. 컴퓨터산업의
   확대는 곧 이 분야의 전문인력에 대한 수요 증가로 이어졌다. 따라서 컴퓨터 관련
   자격증에 대한 관심도 증가하고 있어 최근 응시자수와 합격자수가 증가하고 있는
   추세이다. 또한 취업, 입학시 가산점을 주거나 병역특례 등 혜택이 있어 실생활에
   널리 통용되고 인정받을 수 있다. (학점인정 30학점, 공무원 임용시험시 7급은 3%,
   9 급은 3% 가산특 전이 있다.) 
 
검정수수료  
  필기 : 18000원
실기 : 21000원

 
실시 기관명  
 
한국산업인력공단 
 
기관주소  
   www.hrdkorea.or.kr  

종목별 검정현황

종목명

년도

원서접수인원

최종응시인원

최종합격인원

합격율

정보처리기사 2007 215,190 158,148 30,315 19.2%
정보처리기사 2006 216,403 156,055 66,597 42.7%
정보처리기사 2005 221,210 163,535 58,133 35.5%
정보처리기사 2004 200,732 147,720 54,152 36.7%
정보처리기사 2003 154,652 114,988 45,744 39.8%
정보처리기사 2002 116,299 87,805 34,379 39.2%
정보처리기사 2001 102,008 73,783 21,114 28.6%
정보처리기사 1977-2000 580,523 447,319 85,942 19.2%
정보처리기사 1,807,017 1,349,353 396,376 32.613%
Posted by 사나에
Sunny/지쏘니는 누구?2009. 1. 19. 09:33
http://user.chol.com/~ilovehrl/mbti/mbti1.html 
MBTI 테스트 결과

 

▩ ENFP 스파크형 ▩

따뜻하고 정열적이고 활기에 넘치며 재능이 많고 상상력이 풍부하다.
온정적이고 창의적이며 항상 새로운 가능성을 찾고 시도한 형이다. 문제 해결에 재빠르고 관심이 있는 일은 무엇이든지
수행해내는 능력과 열성이 있다. 다른 사람들에게 관심을 쏟으며 사람들을 잘 다루고 뛰어난 통찰력으로 도움을 준다.
상담, 교육, 과학, 저널리스트, 광고, 판매, 성직, 작가 등의 분야에서 뛰어난 재능을 보인다. 반복되는 일상적인 일을
참지 못하고 열성이 나지 않는다. 또한 한가지 일을 끝내기도 전에 몇 가지 다른 일을 또 벌리는 경향을 가지고 있다.
통찰력과 창의력이 요구되지 않는 일에는 흥미를 느끼지 못하고 열성을 불러일으키지 못한다.

▒ 일반적인 특성 ▒

  • 감정이 얼굴에 잘 들어 난다
  • 새로운 시도를 좋아한다
  • 계획하기보다는 그때그때 일을 처리하는 편이다
  • 새로운 사람 만나기를 좋아한다
  • 감동을 잘하고 눈물도 잘 흘린다
  • 돈 개념이 희박하다. 돈을 모으기 힘들 수 있다
  • 감정의 기복이 심하다
  • 경쟁의식이 없다
  • 상대방의 말에 민감하나 기분이 나쁘지 않은 척 한다
  • 내면에 열정을 지녔다
  • 위기 대처능력이 뛰어난다
  • 사람을 기쁘게 해주는 타고난 능력이 있다
  • 행사나 일을 잘 주선한다
  • 놀다가도 몰입이 안되고 지금 무엇하고 있는 건가? 라는 생각이 들 때가 있다
  • 멋 내는 것을 좋아한다
  • 양보를 잘하고 싸움을 할려면 심장부터 뛴다
  • 단순암기에 약하다
  • 인생을 즐겁게 살려고 한다
  • 선생님이 마음에 들면 하기 싫은 과목도 잘한다
  • 하기 싫은 것에 대한 인내력이 부족하다
  • 좋아하는 사람과 싫어하는 사람의 구별이 심하다
  • 반복적인 일상을 힘들어 한다
  • 분위기를 잘 띄운 후에 자기는 빠진다

    ▒ 개발해야할 점 ▒

  • 감정의 기복을 이겨내기 위해서 꾸준한 운동이 필요
  • 좋아하는 일만 하기보다 우선순위에 맞추어서 하는 것이 필요
  • 상대방의 말에 대해서 객관화 작업이 필요
  • 규칙적이고 체계적일 필요가 있다
  • 현실에 충실해야 한다
  • 인내심을 길러야 한다




  • Posted by 사나에
    개발 이야기/Visual C#2008. 12. 19. 23:50
    출처 : http://code.msdn.microsoft.com/csharpfuture

    C# 4.0이 나왔네요.



    New features in C# 4.0

    Mads Torgersen, C# Language PM

    December 08

    Contents

    Introduction. 1

    Dynamic Lookup. 3

    Named and Optional Arguments. 6

    Features for COM interop. 8

    Variance. 9

    Relationship with Visual Basic. 11

    Resources. 11

     

    Introduction

    It is now close to a year since Microsoft Visual C# 3.0 shipped as part of Visual Studio 2008. In the VS Managed Languages team we are hard at work on creating the next version of the language (with the unsurprising working title of C# 4.0), and this document is a first public description of the planned language features as we currently see them.

    Please be advised that all this is in early stages of production and is subject to change. Part of the reason for sharing our plans in public so early is precisely to get the kind of feedback that will cause us to improve the final product before it rolls out.

    Simultaneously with the publication of this whitepaper, a first public CTP (community technology preview) of Visual Studio 2010 is going out as a Virtual PC image for everyone to try. Please use it to play and experiment with the features, and let us know of any thoughts you have. We ask for your understanding and patience working with very early bits, where especially new or newly implemented features do not have the quality or stability of a final product. The aim of the CTP is not to give you a productive work environment but to give you the best possible impression of what we are working on for the next release.

    The CTP contains a number of walkthroughs, some of which highlight the new language features of C# 4.0. Those are excellent for getting a hands-on guided tour through the details of some common scenarios for the features. You may consider this whitepaper a companion document to these walkthroughs, complementing them with a focus on the overall language features and how they work, as opposed to the specifics of the concrete scenarios.

    C# 4.0

    The major theme for C# 4.0 is dynamic programming. Increasingly, objects are “dynamic” in the sense that their structure and behavior is not captured by a static type, or at least not one that the compiler knows about when compiling your program. Some examples include

    a.       objects from dynamic programming languages, such as Python or Ruby

    b.      COM objects accessed through IDispatch

    c.       ordinary .NET types accessed through reflection

    d.      objects with changing structure, such as HTML DOM objects

    While C# remains a statically typed language, we aim to vastly improve the interaction with such objects.

    A secondary theme is co-evolution with Visual Basic. Going forward we will aim to maintain the individual character of each language, but at the same time important new features should be introduced in both languages at the same time. They should be differentiated more by style and feel than by feature set.

    The new features in C# 4.0 fall into four groups:

    Dynamic lookup

    Dynamic lookup allows you to write method, operator and indexer calls, property and field accesses, and even object invocations which bypass the C# static type checking and instead gets resolved at runtime.

    Named and optional parameters

    Parameters in C# can now be specified as optional by providing a default value for them in a member declaration. When the member is invoked, optional arguments can be omitted. Furthermore, any argument can be passed by parameter name instead of position.

    COM specific interop features

    Dynamic lookup as well as named and optional parameters both help making programming against COM less painful than today. On top of that, however, we are adding a number of other small features that further improve the interop experience.

    Variance

    It used to be that an IEnumerable<string> wasn’t an IEnumerable<object>. Now it is – C# embraces type safe “co-and contravariance” and common BCL types are updated to take advantage of that.

    Dynamic Lookup

    Dynamic lookup allows you a unified approach to invoking things dynamically. With dynamic lookup, when you have an object in your hand you do not need to worry about whether it comes from COM, IronPython, the HTML DOM or reflection; you just apply operations to it and leave it to the runtime to figure out what exactly those operations mean for that particular object.

    This affords you enormous flexibility, and can greatly simplify your code, but it does come with a significant drawback: Static typing is not maintained for these operations. A dynamic object is assumed at compile time to support any operation, and only at runtime will you get an error if it wasn’t so. Oftentimes this will be no loss, because the object wouldn’t have a static type anyway, in other cases it is a tradeoff between brevity and safety. In order to facilitate this tradeoff, it is a design goal of C# to allow you to opt in or opt out of dynamic behavior on every single call.

    The dynamic type

    C# 4.0 introduces a new static type called dynamic. When you have an object of type dynamic you can “do things to it” that are resolved only at runtime:

    dynamic d = GetDynamicObject(…);
    d.M(7);

    The C# compiler allows you to call a method with any name and any arguments on d because it is of type dynamic. At runtime the actual object that d refers to will be examined to determine what it means to “call M with an int” on it.

    The type dynamic can be thought of as a special version of the type object, which signals that the object can be used dynamically. It is easy to opt in or out of dynamic behavior: any object can be implicitly converted to dynamic, “suspending belief” until runtime. Conversely, there is an “assignment conversion” from dynamic to any other type, which allows implicit conversion in assignment-like constructs:

    dynamic d = 7; // implicit conversion
    int i = d; // assignment conversion

    Dynamic operations

    Not only method calls, but also field and property accesses, indexer and operator calls and even delegate invocations can be dispatched dynamically:

    dynamic d = GetDynamicObject(…);
    d.M(7); // calling methods
    d.f = d.P; // getting and settings fields and properties
    d[“one”] = d[“two”]; // getting and setting thorugh indexers
    int i = d + 3; // calling operators
    string s = d(5,7); // invoking as a delegate

    The role of the C# compiler here is simply to package up the necessary information about “what is being done to d”, so that the runtime can pick it up and determine what the exact meaning of it is given an actual object d. Think of it as deferring part of the compiler’s job to runtime.

    The result of any dynamic operation is itself of type dynamic.

    Runtime lookup

    At runtime a dynamic operation is dispatched according to the nature of its target object d:

    COM objects

    If d is a COM object, the operation is dispatched dynamically through COM IDispatch. This allows calling to COM types that don’t have a Primary Interop Assembly (PIA), and relying on COM features that don’t have a counterpart in C#, such as indexed properties and default properties.

    Dynamic objects

    If d implements the interface IDynamicObject d itself is asked to perform the operation. Thus by implementing IDynamicObject a type can completely redefine the meaning of dynamic operations. This is used intensively by dynamic languages such as IronPython and IronRuby to implement their own dynamic object models. It will also be used by APIs, e.g. by the HTML DOM to allow direct access to the object’s properties using property syntax.

    Plain objects

    Otherwise d is a standard .NET object, and the operation will be dispatched using reflection on its type and a C# “runtime binder” which implements C#’s lookup and overload resolution semantics at runtime. This is essentially a part of the C# compiler running as a runtime component to “finish the work” on dynamic operations that was deferred by the static compiler.

    Example

    Assume the following code:

    dynamic d1 = new Foo();
    dynamic d2 = new Bar();
    string s;

    d1.M(s, d2, 3, null);

    Because the receiver of the call to M is dynamic, the C# compiler does not try to resolve the meaning of the call. Instead it stashes away information for the runtime about the call. This information (often referred to as the “payload”) is essentially equivalent to:

    “Perform an instance method call of M with the following arguments:

    1.       a string

    2.       a dynamic

    3.       a literal int 3

    4.       a literal object null

    At runtime, assume that the actual type Foo of d1 is not a COM type and does not implement IDynamicObject. In this case the C# runtime binder picks up to finish the overload resolution job based on runtime type information, proceeding as follows:

    1.       Reflection is used to obtain the actual runtime types of the two objects, d1 and d2, that did not have a static type (or rather had the static type dynamic). The result is Foo for d1 and Bar for d2.

    2.       Method lookup and overload resolution is performed on the type Foo with the call M(string,Bar,3,null) using ordinary C# semantics.

    3.       If the method is found it is invoked; otherwise a runtime exception is thrown.

    Overload resolution with dynamic arguments

    Even if the receiver of a method call is of a static type, overload resolution can still happen at runtime. This can happen if one or more of the arguments have the type dynamic:

    Foo foo = new Foo();
    dynamic d = new Bar();

    var result = foo.M(d);

    The C# runtime binder will choose between the statically known overloads of M on Foo, based on the runtime type of d, namely Bar. The result is again of type dynamic.

    The Dynamic Language Runtime

    An important component in the underlying implementation of dynamic lookup is the Dynamic Language Runtime (DLR), which is a new API in .NET 4.0.

    The DLR provides most of the infrastructure behind not only C# dynamic lookup but also the implementation of several dynamic programming languages on .NET, such as IronPython and IronRuby. Through this common infrastructure a high degree of interoperability is ensured, but just as importantly the DLR provides excellent caching mechanisms which serve to greatly enhance the efficiency of runtime dispatch.

    To the user of dynamic lookup in C#, the DLR is invisible except for the improved efficiency. However, if you want to implement your own dynamically dispatched objects, the IDynamicObject interface allows you to interoperate with the DLR and plug in your own behavior. This is a rather advanced task, which requires you to understand a good deal more about the inner workings of the DLR. For API writers, however, it can definitely be worth the trouble in order to vastly improve the usability of e.g. a library representing an inherently dynamic domain.

    Open issues

    There are a few limitations and things that might work differently than you would expect.

    ·         The DLR allows objects to be created from objects that represent classes. However, the current implementation of C# doesn’t have syntax to support this.

    ·         Dynamic lookup will not be able to find extension methods. Whether extension methods apply or not depends on the static context of the call (i.e. which using clauses occur), and this context information is not currently kept as part of the payload.

    ·         Anonymous functions (i.e. lambda expressions) cannot appear as arguments to a dynamic method call. The compiler cannot bind (i.e. “understand”) an anonymous function without knowing what type it is converted to.

    One consequence of these limitations is that you cannot easily use LINQ queries over dynamic objects:

    dynamic collection = …;

    var result = collection.Select(e => e + 5);

    If the Select method is an extension method, dynamic lookup will not find it. Even if it is an instance method, the above does not compile, because a lambda expression cannot be passed as an argument to a dynamic operation.

    There are no plans to address these limitations in C# 4.0.

    Named and Optional Arguments

    Named and optional parameters are really two distinct features, but are often useful together. Optional parameters allow you to omit arguments to member invocations, whereas named arguments is a way to provide an argument using the name of the corresponding parameter instead of relying on its position in the parameter list.

    Some APIs, most notably COM interfaces such as the Office automation APIs, are written specifically with named and optional parameters in mind. Up until now it has been very painful to call into these APIs from C#, with sometimes as many as thirty arguments having to be explicitly passed, most of which have reasonable default values and could be omitted.

    Even in APIs for .NET however you sometimes find yourself compelled to write many overloads of a method with different combinations of parameters, in order to provide maximum usability to the callers. Optional parameters are a useful alternative for these situations.

    Optional parameters

    A parameter is declared optional simply by providing a default value for it:

    public void M(int x, int y = 5, int z = 7);

    Here y and z are optional parameters and can be omitted in calls:

    M(1, 2, 3); // ordinary call of M
    M(1, 2); // omitting z – equivalent to M(1, 2, 7)
    M(1); // omitting both y and z – equivalent to M(1, 5, 7)

    Named and optional arguments

    C# 4.0 does not permit you to omit arguments between commas as in M(1,,3). This could lead to highly unreadable comma-counting code. Instead any argument can be passed by name. Thus if you want to omit only y from a call of M you can write:

    M(1, z: 3); // passing z by name

    or

    M(x: 1, z: 3); // passing both x and z by name

    or even

    M(z: 3, x: 1); // reversing the order of arguments

    All forms are equivalent, except that arguments are always evaluated in the order they appear, so in the last example the 3 is evaluated before the 1.

    Optional and named arguments can be used not only with methods but also with indexers and constructors.

    Overload resolution

    Named and optional arguments affect overload resolution, but the changes are relatively simple:

    A signature is applicable if all its parameters are either optional or have exactly one corresponding argument (by name or position) in the call which is convertible to the parameter type.

    Betterness rules on conversions are only applied for arguments that are explicitly given – omitted optional arguments are ignored for betterness purposes.

    If two signatures are equally good, one that does not omit optional parameters is preferred.

    M(string s, int i = 1);
    M(object o);
    M(int i, string s = “Hello”);
    M(int i);

    M(5);

    Given these overloads, we can see the working of the rules above. M(string,int) is not applicable because 5 doesn’t convert to string. M(int,string) is applicable because its second parameter is optional, and so, obviously are M(object) and M(int).

    M(int,string) and M(int) are both better than M(object) because the conversion from 5 to int is better than the conversion from 5 to object.

    Finally M(int) is better than M(int,string) because no optional arguments are omitted.

    Thus the method that gets called is M(int).

    Features for COM interop

    Dynamic lookup as well as named and optional parameters greatly improve the experience of interoperating with COM APIs such as the Office Automation APIs. In order to remove even more of the speed bumps, a couple of small COM-specific features are also added to C# 4.0.

    Dynamic import

    Many COM methods accept and return variant types, which are represented in the PIAs as object. In the vast majority of cases, a programmer calling these methods already knows the static type of a returned object from context, but explicitly has to perform a cast on the returned value to make use of that knowledge. These casts are so common that they constitute a major nuisance.

    In order to facilitate a smoother experience, you can now choose to import these COM APIs in such a way that variants are instead represented using the type dynamic. In other words, from your point of view, COM signatures now have occurrences of dynamic instead of object in them.

    This means that you can easily access members directly off a returned object, or you can assign it to a strongly typed local variable without having to cast. To illustrate, you can now say

    excel.Cells[1, 1].Value = "Hello";

    instead of

    ((Excel.Range)excel.Cells[1, 1]).Value2 = "Hello";

    and

    Excel.Range range = excel.Cells[1, 1];

    instead of

    Excel.Range range = (Excel.Range)excel.Cells[1, 1];

    Compiling without PIAs

    Primary Interop Assemblies are large .NET assemblies generated from COM interfaces to facilitate strongly typed interoperability. They provide great support at design time, where your experience of the interop is as good as if the types where really defined in .NET. However, at runtime these large assemblies can easily bloat your program, and also cause versioning issues because they are distributed independently of your application.

    The no-PIA feature allows you to continue to use PIAs at design time without having them around at runtime. Instead, the C# compiler will bake the small part of the PIA that a program actually uses directly into its assembly. At runtime the PIA does not have to be loaded.

    Omitting ref

    Because of a different programming model, many COM APIs contain a lot of reference parameters. Contrary to refs in C#, these are typically not meant to mutate a passed-in argument for the subsequent benefit of the caller, but are simply another way of passing value parameters.

    It therefore seems unreasonable that a C# programmer should have to create temporary variables for all such ref parameters and pass these by reference. Instead, specifically for COM methods, the C# compiler will allow you to pass arguments by value to such a method, and will automatically generate temporary variables to hold the passed-in values, subsequently discarding these when the call returns. In this way the caller sees value semantics, and will not experience any side effects, but the called method still gets a reference.

    Open issues

    A few COM interface features still are not surfaced in C#. Most notably these include indexed properties and default properties. As mentioned above these will be respected if you access COM dynamically, but statically typed C# code will still not recognize them.

    There are currently no plans to address these remaining speed bumps in C# 4.0.

    Variance

    An aspect of generics that often comes across as surprising is that the following is illegal:

    IList<string> strings = new List<string>();
    IList<object> objects = strings;

    The second assignment is disallowed because strings does not have the same element type as objects. There is a perfectly good reason for this. If it were allowed you could write:

    objects[0] = 5;
    string s = strings[0];

    Allowing an int to be inserted into a list of strings and subsequently extracted as a string. This would be a breach of type safety.

    However, there are certain interfaces where the above cannot occur, notably where there is no way to insert an object into the collection. Such an interface is IEnumerable<T>. If instead you say:

    IEnumerable<object> objects = strings;

    There is no way we can put the wrong kind of thing into strings through objects, because objects doesn’t have a method that takes an element in. Variance is about allowing assignments such as this in cases where it is safe. The result is that a lot of situations that were previously surprising now just work.

    Covariance

    In .NET 4.0 the IEnumerable<T> interface will be declared in the following way:

    public interface IEnumerable<out T> : IEnumerable
    {
                 IEnumerator<T> GetEnumerator();
    }

    public interface IEnumerator<out T> : IEnumerator
    {
                 bool MoveNext();
                 T Current { get; }
    }

    The “out” in these declarations signifies that the T can only occur in output position in the interface – the compiler will complain otherwise. In return for this restriction, the interface becomes “covariant” in T, which means that an IEnumerable<A> is considered an IEnumerable<B> if A has a reference conversion to B.

    As a result, any sequence of strings is also e.g. a sequence of objects.

    This is useful e.g. in many LINQ methods. Using the declarations above:

    var result = strings.Union(objects); // succeeds with an IEnumerable<object>

    This would previously have been disallowed, and you would have had to to some cumbersome wrapping to get the two sequences to have the same element type.

    Contravariance

    Type parameters can also have an “in” modifier, restricting them to occur only in input positions. An example is IComparer<T>:

    public interface IComparer<in T>
    {
                 public int Compare(T left, T right);
    }

    The somewhat baffling result is that an IComparer<object> can in fact be considered an IComparer<string>! It makes sense when you think about it: If a comparer can compare any two objects, it can certainly also compare two strings. This property is referred to as contravariance.

    A generic type can have both in and out modifiers on its type parameters, as is the case with the Func<…> delegate types:

    public delegate TResult Func<in TArg, out TResult>(TArg arg);

    Obviously the argument only ever comes in, and the result only ever comes out. Therefore a Func<object,string> can in fact be used as a Func<string,object>.

    Limitations

    Variant type parameters can only be declared on interfaces and delegate types, due to a restriction in the CLR. Variance only applies when there is a reference conversion between the type arguments. For instance, an IEnumerable<int> is not an IEnumerable<object> because the conversion from int to object is a boxing conversion, not a reference conversion.

    Also please note that the CTP does not contain the new versions of the .NET types mentioned above. In order to experiment with variance you have to declare your own variant interfaces and delegate types.

    COM Example

    Here is a larger Office automation example that shows many of the new C# features in action.

    using System;
    using System.Diagnostics;
    using System.Linq;
    using Excel = Microsoft.Office.Interop.Excel;
    using Word = Microsoft.Office.Interop.Word;

    class Program
    {
        static void Main(string[] args) {
            var excel = new Excel.Application();
            excel.Visible = true;

            excel.Workbooks.Add();                    // optional arguments omitted

            excel.Cells[1, 1].Value = "Process Name"; // no casts; Value dynamically 
            excel.Cells[1, 2].Value = "Memory Usage"; // accessed

            var processes = Process.GetProcesses()
                .OrderByDescending(p =&gt; p.WorkingSet)
                .Take(10);

            int i = 2;
            foreach (var p in processes) {
                excel.Cells[i, 1].Value = p.ProcessName; // no casts
                excel.Cells[i, 2].Value = p.WorkingSet;  // no casts
                i++;
            }

            Excel.Range range = excel.Cells[1, 1];       // no casts

            Excel.Chart chart = excel.ActiveWorkbook.Charts.
                Add(After: excel.ActiveSheet);         // named and optional arguments

            chart.ChartWizard(
                Source: range.CurrentRegion,
                Title: "Memory Usage in " + Environment.MachineName); //named+optional

            chart.ChartStyle = 45;

            chart.CopyPicture(Excel.XlPictureAppearance.xlScreen,
                Excel.XlCopyPictureFormat.xlBitmap,
                Excel.XlPictureAppearance.xlScreen);

            var word = new Word.Application();
            word.Visible = true;

            word.Documents.Add();          // optional arguments

            word.Selection.Paste();
        }
    }

    The code is much more terse and readable than the C# 3.0 counterpart.

    Note especially how the Value property is accessed dynamically. This is actually an indexed property, i.e. a property that takes an argument; something which C# does not understand. However the argument is optional. Since the access is dynamic, it goes through the runtime COM binder which knows to substitute the default value and call the indexed property. Thus, dynamic COM allows you to avoid accesses to the puzzling Value2 property of Excel ranges.

    Relationship with Visual Basic

    A number of the features introduced to C# 4.0 already exist or will be introduced in some form or other in Visual Basic:

    ·         Late binding in VB is similar in many ways to dynamic lookup in C#, and can be expected to make more use of the DLR in the future, leading to further parity with C#.

    ·         Named and optional arguments have been part of Visual Basic for a long time, and the C# version of the feature is explicitly engineered with maximal VB interoperability in mind.

    ·         NoPIA and variance are both being introduced to VB and C# at the same time.

    VB in turn is adding a number of features that have hitherto been a mainstay of C#. As a result future versions of C# and VB will have much better feature parity, for the benefit of everyone.

    Resources

    All available resources concerning C# 4.0 can be accessed through the C# Dev Center at www.csharp.net. Specifically, this white paper and other resources can be found at the Code Gallery site code.msdn.com/csharpfuture. Enjoy!

    Posted by 사나에
    개발 이야기/Visual C#2008. 12. 19. 23:42
    Get Microsoft Silverlight 

    Visual Studio 2010 CTP && .Net Framework 4.0

    URL's referenced in this episode:
    http://tinyurl.com/GetCTP
    http://tinyurl.com/VSFeedback
    http://tinyurl.com/CTPActivation

    For more 10-4 episodes, be sure to visit:
    http://channel9.msdn.com/Shows/10-4/

    Virtual PC 2007로 제공되네요.
    OS : Windows Server 2008


    출처  : 10-4 Episode 1: Working with the Visual Studio 2010 CTP VPC
    Posted by 사나에
    개발 이야기/Visual C#2008. 11. 25. 08:48

    요즘 저는 우리 제품의 코드 리뷰를 하고 있고 거기서 성능 이슈를 야기하는 문제점 몇 가지를 발견하였습니다. 그래서 코딩 표준화로 시스템의 성능을 형상시키는 방법을 공유하고 싶습니다.

     

    1. String vs StringBuilder 

    요즘 String은 개발자에게 일반적인 타입이 되었고 이것은 문자의 수를 표현합니다. 사실, String은 문자의 배열입니다.

     

    String은 많은 개발자들이 다음과 같이 사용합니다.

     

    String output = "";

    output += "Hello";

    output += " ";

    output += "World";

     

    System.Diagnostics.Debug.WriteLine(output);

     

     

    output+=“xx" 을 호출했을 때 백엔드에서 어떻게 실행될까요? 실행해 봅시다.

     

    Char[] tempValue = new Char[output.Length + "Hello".Length];

    tempValue = output + "Hello";

    Array.Clear(output, 0, output.Length);

    output = null;

    output = new Char[tempValue.Length];

    output = tempValue;

    Array.Clear(tempValue);

     

     

    위 코드 처럼 Char 배열을 길이를 설정하고 문자열을 넣고 그 전의 문자열을 지우게 됩니다. 이런 작업을 문자열 연산이 있을 때 마다 진행합니다. 그러므로 문자열 연산이 자주 일어날 시에는 += 방법은 추천하지 않습니다.

     

    StringBuilder는 동적 배열로 런타임에서 메모리에 할당됩니다. 여러분이 문자를 끝에서 추가 할 때 그 추가한 변수 값은 메모리에 할당되어서 문자열을 출력할 때 병합됩니다. 컴파일러는 StringBuilder를 제공하며, 이는 Append 메서드를 통한 변경은 지원합니다.

     

     

    2. 문자열 추가

     String = “xxx” + yyy + “ “ + zzz

    때때로 당신은 상기와 같은 형식으로 문자열이 필요합니다.

    이 아티클을 읽은 후에는 다음과 같은 문자열 포맷을 이용하기를 바랍니다.

    String.Format("xxx{0} {1}", yyy, zzz);

     

    String.Format는 문자열을 포맷하는데 도움이 됩니다.

    하지만 여러분이 다른 문자열 변수에 어떤 문자열을 추가하기를 원한다면 String.Format보다 String.Concat을 사용하는 게 성능상 효율적입니다.

    String.Concat("xxx ", yyy, zzz); 

     

    3. String.Equals vs String == CompareValue 

    당신이 두 문자열을 비교할 경우, 정상적으로 당신은 String == CompareValue을 사용할 것입니다. 그러나 어떤 경우에는 원래의 문자열 비교 값과 같지 않는 경우가 있을 것입니다.( 대소문자를 구분하기때문에..) 
    그래서 이런 경우는 저는 다음과 같이 사용했습니다.
     

    String source = "abcdef";

    String compareValue = "Abcdef";

    if (source.ToLower() == compareValue.ToLower())

    {

        //Do something

    }

     

     

    ToLower() or ToUpper() 둘 다 좋은 방법이긴 하지만 이는 가상 변수를 만드는 것으로 ToLower()를 호출 시에 다른 가상의 변수를 만들고 비교 값을 저장하게 됩니다. 비교하고 다시 그 가상변수를 없애는 작업을 하게 됩니다.

     

    그러므로 개인적으로 다음 방법을 추천합니다.

    이는 Object를 비교하는 방법으로 당신의 코드를 업데이트 시킬 수 있습니다. 

    if (source.Equals(compareValue, StringComparison.OrdinalIgnoreCase))

      

    4. String != null && String != “”  

    내가 보는 것 중에 또 다른 것은 문자열을 확인하는 것입니다.

    String source = "";

    if  ((source != null) && (String != ""))

    {

        //Do something

    }

     

    이는 다음과 같이 String.IsNullOrEmpty()을 사용할 수 있습니다.

    if (String.IsNullOrEmpty(source))

    {

        //Do something

    }

     

    StringBuilder에서 MaxCapacity속성을 통해 더 빠른 성능을 나타낼 수 있습니다. (MaxCapacity보유할 수 있는 최대 문자 수를 지정하는 것입니다.)

     

    다음에는 배열(Array)에 대해 알아보겠습니다.

    읽어 주셔서 감사합니다.

     
    ===============================================================================================
    출처 : http://www.hoons.kr/Board.aspx?Name=cshaptip&Mode=2&BoardIdx=17164&Key=&Value=

    Posted by 사나에