변수이름 첫글자에 숫자가 올 수 없는 이유를 써 놓은 것을 보았는데, 핵심을 놓치고 있는것 같아서 적어봅니다.

궁극적인 이유는 lexical analysis의 편의를 위해서입니다.
컴파일 과정은 크게 3단계로 나뉘는데, 첫번째 단계가 lexical analysis, 두번째가 syntax analysis, 세번째가 code generation입니다. 간략히 설명드리자면,

lexical analyzer : 소스코드를 의미를 가지는 최소한의 심볼 단위로 자릅니다. 이렇게 자른 심볼을 lexeme, 즉 어휘라고 부르며, 이 렉심을 종류에 따라 구분하여 이것이 상수인지, 변수인지, 연산자인지를 판단하여 token으로 분류하여, 이 토큰의 열을 구문 분석기로 전달합니다. 따라서 어휘 분석기는 해당 언어에서 허용하는 어휘의 종류를 어떻게 판단할 수 있는지를 알아야 합니다. 즉, 소스 코드의 문자열이 어떻게 구성되어 있느냐에 따라 종류를 구분할 수 있어야 합니다.
예를 들어, a = 10; 이라는 구문이 있을 때, 어휘분석기는 이 구문을 다음과 같이 해석하여 구문 분석기로 전달합니다.
{a, 식별자}
{=, 연산자}
{10, 상수}
{;, 세미콜론}


syntax analyzer : 어휘 분석기로부터 넘어오는 토큰의 열이 문법에 맞는지를 검사합니다. 구문 분석기는 실제 lexeme이 무엇인가는 고려하지 않으며, 토큰의 구성 관계가 문법에서 허용하는 구성 방식인가만을 고려합니다. 따라서 구문 분석기는 언어의 문법에 관한 정보가 필요하게 됩니다. 만약, 언어에서 허용하는 문법 중에 <구문> ::= <식별자> <연산자> <상수> <세미콜론> 이라는 문법이 있고, 위의 예에서와 같이 {a, 식별자}, {=, 연산자}, {10, 상수}, {;, 세미콜론}과 같은 토큰의 열이 들어온다면, 구문 분석기는 lexeme은 고려하지 않고, 토큰의 종류만 보고서 이 토큰의 열이 문법에 맞는 구문이라고 받아들이게 됩니다. 만약, 토큰의 열이 {a, 식별자}, {=, 연산자}, {;, 세미콜론}, {10, 상수} 과 같은 순서라면, 해당하는 문법이 존재하지 않으므로 에러를 내게 됩니다.

code generator : 구문 분석기가 분석한 정보를 바탕으로 실제 오브젝트 코드를 생성합니다. 즉, a=10; 이라는 구문이 문법에서 적절한 구문이라면, a에 해당하는 메모리 번지에 10이라는 값을 쓰는 기계어 코드를 생성합니다.


위 컴파일 과정에서, 어떤 토큰이 변수명인지 상수인지를 구분하는 것은 lexical analyzer의 역할입니다. 이러한 lexical analysis는 기본적으로 문자열의 '패턴'을 보는 것이며, 이러한 문자열의 패턴은 거의 항상 Finite State Machine의 일종인, Deterministic Finite State Automata(이하 DFA)로 해석합니다. 여기에서 DFA의 자세한 동작을 설명드릴 수는 없고, 일단 간략히 설명드리자면, 기본적으로 DFA는 자신의 상태에 따라 입력을 하나씩만 보면서 자신의 상태를 바꿔 나가는 해석기입니다. 즉, 상태0에서 첫 글자가 A이면 상태1로 변하고, 첫글자가 B이면 상태 0으로 그대로, 그 밖의 경우에는 상태2로 변한다, 라는 식입니다. 즉, 글자를 하나씩 보면서 상태가 바뀌되, 그 앞의 입력을 다시 보는 경우는 없다, 라는 것이 DFA의 특징입니다.

이론적으로 DFA는 정규식으로 표현되는 어떠한 패턴의 문자열이라도 그 종류를 구분해 낼 수 있는 능력이 있으므로, lexical analysis의 근간을 이루는 계산 모델을 이룹니다. 하지만, 실제 컴파일러에게 필요한 lexeme의 종류는 한정되어 있으며 일정한 규칙이 있으므로, lexer의 스테이트 전이를 간단하게 만들 수 있는 규칙의 집합을 적절히 설계하는 것이 효율적인 컴파일러 작성에 중요합니다.
따라서, C의 lexer는 이를테면, 다음과 같은 식으로 구성되어 있습니다.

초기상태 : 알파벳, 혹은 _가 들어오면 "식별자 해석 상태"로 전이
초기상태 : 숫자가 들어오면 "상수 해석 상태"로 전이
초기상태 : 그밖의 다른 문자가 들어오면 "연산자 해석 상태"로 전이
식별자 해석 상태 : 알파벳이나 숫자, _가 들어오면 상태를 바꾸지 않음
식별자 해석 상태 : 그밖의 다른 특수문자가 들어오면 지금까지 읽어들인 문자를 모두 식별자로 해석하여 구분문석기에 넘겨주고 "초기상태"로 전이
상수 해석 상태 : 숫자가 들어오면 상태를 바꾸지 않음
상수 해석 상태 : 다른 문자가 들어오면 "XXXXX상태"로 전이
........ (이하생략) .......

즉, 첫 글자를 기준으로 상태를 크게 세 갈래로 바꾸어 해석함으로써 어휘 분석을 쉽게 할 수 있는 장점이 있게 됩니다. 첫글자가 숫자이면 "상수 해석 상태"에서 "식별자 해석 상태"로 전이할 일이 없게 되는 구조가 되어 lexical analysis구현이 훨씬 효율적으로 가능해지는 장점이 있게 되는 것이죠. 자세한 것은 Automata 교재나 컴파일러 교재를 참조하시기 바랍니다.

출처: http://www.codeguru.com/cpp/cpp/cpp_mfc/callbacks/article.php/c10557

Callback Functions Tutorial

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Login to rate.

• September 16, 2005
• By Marius Bancila
• 
• Send Email »
• More Articles »

Font Size

typedef int (__stdcall *CompareFunction)(const byte*, const byte*);

void DLLDIR __stdcall Bubblesort(byte* array,
                                 int size,
                                 int elem_size,
                                 CompareFunction cmpFunc);

void DLLDIR __stdcall Quicksort(byte* array,
                                int size,
                                int elem_size,
                                CompareFunction cmpFunc);

void DLLDIR __stdcall Bubblesort(byte* array,
                                 int size,
                                 int elem_size,
                                 CompareFunction cmpFunc)
{
   for(int i=0; i < size; i++)
   {
      for(int j=0; j < size-1; j++)
      {
         // make the callback to the comparison function
         if(1 == (*cmpFunc)(array+j*elem_size,
                  array+(j+1)*elem_size))
         {
            // the two compared elements must be interchanged
            byte* temp = new byte[elem_size];
            memcpy(temp, array+j*elem_size, elem_size);
            memcpy(array+j*elem_size,
                   array+(j+1)*elem_size,
                   elem_size);
            memcpy(array+(j+1)*elem_size, temp, elem_size);
            delete [] temp;
         }
      }
   }
}

Note: Because the implementation uses memcpy(), these library functions should not be used for types other than POD (Plain-Old-Data).

int main(int argc, char* argv[])
{
   int i;
   int array[] = {5432, 4321, 3210, 2109, 1098};

   cout << "Before sorting ints with Bubblesort\n";
   for(i=0; i < 5; i++)
      cout << array[i] << '\n';

   Bubblesort((byte*)array, 5, sizeof(array[0]), &CompareInts);

   cout << "After the sorting\n";
   for(i=0; i < 5; i++)
      cout << array[i] << '\n';

   const char str[5][10] = {"estella",
                            "danielle",
                            "crissy",
                            "bo",
                            "angie"};

   cout << "Before sorting strings with Quicksort\n";
   for(i=0; i < 5; i++)
      cout << str[i] << '\n';

   Quicksort((byte*)str, 5, 10, &CompareStrings);

   cout << "After the sorting\n";
   for(i=0; i < 5; i++)
      cout << str[i] << '\n';

   return 0; 

class CCallbackTester
{
public:
   int CALLBACK CompareInts(const byte* velem1, const byte* velem2);
};

Bubblesort((byte*)array, 5, sizeof(array[0]),
           &CCallbackTester::CompareInts);

Memory management is done automatically in Java. The programmer doesn't need to worry about reference objects that have been released. One downside to this approach is that the programmer cannot know when a particular object will be collected. Moreover, the programmer has no control over memory management. However, the java.lang.ref package defines classes that provide a limited degree of interaction with the garbage collector. The concrete classes SoftReference,WeakReferenceand PhantomReference are subclasses of Reference that interact with the garbage collector in different ways. In this article we will discuss the functionality and behavior of the PhantomReference classes and see how it can be used.

Problem with Finalization

To perform some postmortem cleanup on objects that garbage collector consider as unreachable, one can usefinalization. This feature can be utilized to reclaim native resources associated with an object. However, finalizers have many problems associated.

Firstly, we can’t foresee the call of finalize(). Since the Garbage Collection is unpredictable, the calling of finalize() cannot be predicted. There is no guarantee that the object will be garbage collected. The object might never become eligible for GC because it could be reachable through the entire lifetime of the JVM. It is also possible that no garbage collection actually runs from the time the object became eligible and before JVM stops.

Secondly, Finalization can slowdown an application. Managing objects with a finalize() method takes more resources from the JVM than normal objects.

As per doc,

You should also use finalization only when it is absolutely necessary. Finalization is a nondeterministic -- and sometimes unpredictable -- process. The less you rely on it, the smaller the impact it will have on the JVM and your application

 In Effective Java, 2nd ed., Joshua Bloch says,

there is a severe performance penalty for using finalizers... So what should you do instead of writing a finalizer for a class whose objects encapsulate resources that require termination, such as files or threads? Just provide an explicit termination method, and require clients of the class to invoke this method on each instance when it is no longer needed.

In short, Finalize() isn't used often, and also there is no much reason to use it. If we have a class with methods likeclose() or cleanup() and that should be called once user done with the object then placing these methods call in finalize()can be used as a safety measure, but not necessary.

Phantom Reference

phantom reachable, phantomly reachable

An object is phantom reachable if it is neither strongly nor softly nor weakly reachable and has been finalized and there is a path from the roots to it that contains at least one phantom reference.

The PhantomReference constructor accepts two arguments:

referent - the object the new phantom reference will refer to
q - the reference is registered with the given queue.

The argument q represents the instance of the ReferenceQueue class. If the garbage collector determines that the referent of a phantom reference is phantom reachable, then the PhantomReference will be added to thisReferenceQueue. You can then retrieve the PhantomReference by using the remove() methods of the ReferenceQueueclass.

Consider the following example,

PhantomReference, when to use?

Phantom Reference can be used in situations, where sometime using finalize() is not  sensible thing to do.This reference type differs from the other types defined in java.lang.ref Package because it isn't meant to be used to access the object, but as a signal that the object has already been finalized, and the garbage collector is ready to reclaim its memory.

As per API doc,

Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.

People usually attempt to use finalize() method to perform postmortem cleanup on objects which usually not advisable. As mentioned earlier, Finalizers have an impact on the performance of the garbage collector since Objects with finalizers are slow to garbage collect.

Phantom references are safe way to know an object has been removed from memory. For instance, consider an application that deals with large images. Suppose that we want to load a big image in to memory when large image is already in memory which is ready for garbage collected. In such case, we want to wait until the old image is collected before loading a new one. Here, the phantom reference is flexible and safely option to choose. The reference of the old image will be enqueued in the ReferenceQueue once the old image object is finalized. After receiving that reference, we can load the new image in to memory.

Similarly we can use Phantom References to implement a Connection Pool. We can easily gain control over the number of open connections, and can block until one becomes available.

Reference Objects and Garbage Collection

Soft Reference can be garbage collected after there are no strong references to the referent. However, it typically retained until memory is low. All softly reachable objects will be reclaimed before an OutOfMemoryException is thrown. Therefore, it can be used to implement caches of objects that can be recreated if needed. 

Weak Reference can be garbage collected when there are no strong or soft references to the referent. However, unlikeSoft Reference, they are garbage collected on a gc even when memory is abundant. They often can be used for “canonical mappings” where each object has a unique identifier (one-to-one), and in collections of “listeners”

On the other hand, Phantom Reference, can be garbage collected once there are no strong, soft or weak references to the referent. When object is phantomly reachable, it means the object is already finalized but not yet reclaimed, so the GC enqueues it in a ReferenceQueue for post-finalization processing.

As per Java Doc,

Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.

A PhantomReference is not automatically cleared when it is enqueued, so when we remove a PhantomReference from aReferenceQueue, we must call its clear() method or allow the PhantomReference object itself to be garbage-collected. 

Summary

In short, we should avoid finalize() as much as possible. There is no guarantee if the finalize() method will be called promptly following garbage collection, or even it will be called. If the finalize method runs for a long time, it can delay execution of finalize methods of other objects. Instead of relying on finalize(), we can use reference types define injava.lang.ref package.

Beside java.lang.ref package, Google collection library also provide some alternatives. For example,FinalizablePhantomReference extends java.lang.ref.PhantomReference, deals with processing the ReferenceQueue and call back a convenient method finalizeReferent(). So if we want to do some cleanup operation when an object is claimed by the garbage collector (GC) then we just need to override the finalizeReferent() method.

Resources

Garbage Collection

PhantomReference

http://docstore.mik.ua/orelly/java-ent/jnut/ch13_01.htm

Understanding Weak References

출처: http://java.dzone.com/articles/finalization-and-phantom