fatal error C1010 : unexpected end of file while looking for precompiled header directive


Visual Studio를 사용하면서 위와 같은 Error을 자주 접하게 된다.


이는 Visual C++ 컴파일러는 미리 컴파일된 해더(Precompiled Header)를 지원하고, 프로젝트 설정을 통해 대상 헤더를 지정할 수 있기 때문이다.


특히 MFC는 수정하지 않고 사용하는 헤더 수가 많기 때문에, 이 방식을 사용하면 매번 전체를 컴파일하지 않아 개발 속도가 빨라진다.





그런데 새로운 소스 파일을 추가하다 보면 다음과 같은 오류 메시지를 볼 수 있다.


fatal error C1010 : unexpected end of file while looking for precompiled header directive


이 오류 메시지는 미리 컴파일된 해더와 관련이 있으므로, 프로즈게트 설정에서 미리 컴파일된 헤더를 사용하지 않겠다고 설정하면 없앨 수 있다.


하지만 앞서 언급한 효율을 포기하는 것이므로 바람직하지는 않다.



project -> project Setting -> 좌측에서 원하는 .cpp 화일 선택 -> C/C++ 탭 선택 ->Category에서 precompiled Header 선택 -> Not using percompiled headers 선택



위와 같이 하게 되면 해당.cpp는 Precomplie 하지 않게 된다.


아니면, general 탭 에서 exclude file from build 를 체크해주면


빌드시에 아예 제외하게 된다.
메소드를 정의하기 위해서는 몇 가지 요소를 필요로 한다.


반드시 필요한 것은 리턴형과 메소드 이름이다.


나머지 접근자나 한정자 등은 선택적으로 사용한다.


접근자는 메소드의 접근 범위를 결정하며, 생략할 수 있다.


접근자가 생략되면 같은 패키지(디렉토리) 안에 있는


클래스나 객체로부터 접근을 허용하게 된다.


한정자는 특별한 제한이나 메소드의 특성을 결정하며, 역시 생략할 수 있다.


키워드는 다음과 같다.


1. static : 이 메소드는 객체 생성 없이 호출할 수 있는 메소드임을 의미한다.


보통 public 메소드로 정의되며 내부에 있는 인스턴스 변수를 이용할 수 없다.


2. final : 이 메소드는 클래스를 상속할 때 재정의할 수 없음을 의미한다.


3. native : 이 메소드는 C언어나 C++언어로 구현된 메소드임을 의미한다.


따라서, 이 메소드는 {}로 이루어진 몸체를 가지고 있지 않다.


4. synchronized : 이 메소드는 멀티스레드와 관련된 것으로 동시에


하나의 스레드만 호출할 수 있음을 의미한다.

운명같은 사랑이란...???

과연 운명이라는 것은 무엇이고, 운명같다는 건 또 무엇일까???

네이버 사전을 보니 운명이란,

"인간을 포함한 우주의 일체(一切)가 지배를 받는 것이라 생각할 때 그 지배하는 필연적이고 초인간적인 힘"

이란다...

필연적이라... 오늘 오랜 친구와 전화를 하면서 많은 것을 느꼈다...

그 친구는 직접적인 말을 없었지만, 내가 듣기에는 다분히 운명적인 사랑을 원하고 있었다.

내가 그 사람을 필요로 할때 그사람은 내 곁에 있어야 하며,

만약 그렇지 않다면, 우리 둘은 서로 맞지가 않는다는...

극장에 갔을때 문득 아무도 웃지 않는 장면에서 내가 웃음이 나오면

그 사람 또한 웃음이 나오는...

그런 운명(?)적인 사랑을 원하고 있었다.

물론 그렇지 않다고해서 내 사람이 아니다라는 것은 아니겠지만

만약 위에 같다면, 정말 내 사랑이다라고 느낀다는 거 같다...



물론, 나라도 내가 재미있으면 그사람도 같이 재미있기를 원하고,

그녀와 나만이 통하는 어떤 느낌이 있으면 좋겠다...

하지만, 구지 그렇지 않다고 해도 머... @^-^@

문득, 오히려 내가 재미없는 상황에서 그사람이 재미를 느낀다면, 참 신기할거 같다.

또, 그녀가 신기해보일거 같다.

그녀가 재미를 느끼는 상황에 나도 재미를 느껴보고 싶고,

나도 재미를 느낄 수 있을것만 같다.





예전에 세렌디피티 (Serendipity, 2001)라는 영화를 본 적이 있다.

Serendipity란 "운수 좋은 뜻밖의 발견"이라는 뜻으로

The Three Princes of Serendip라는 옛 이야기에서 주인공이 찾아도 없는 보물을 우연히 발견한 데서 유래된 말이란다.

이 영화를 보면, 여자는 운명적인 인연을 너무 사랑했고,

때문에 사랑하는 사람을 만나서 그 남자의 이름과 주소등을 5달러에 적어 가게에서 물건을 사버린다.

또, 자기에 전화번호를 낡은 유명한 책에 적어 헌책방에 팔아버린다.

그리고 나선, 운명이라면 다시 만날 것이라는 말만 남겨놓고 둘은 헤어진다.

그렇게 몇 년이 지나서도 둘은 서로를 잊지 못한다.

남자는 헌 책방을 그냥 지나치지 못했고,

여자는 5달러 짜리만 보아도 뒤를 살펴보는 습관이 생겨버린다.

결국 둘은 다시 만나 해피 엔딩으로 끝이 나지만,(모든 영화가 그렇듯이)

개인적으로는 너무 한다는 생각도 한다(물론, 재미있게 영화를 보았다 @^-^@)

과연 운명이란... 운명이라는 것은 무엇이고,

우리에게 무엇을 가져다 주는 것일까???

우리가 스스로 운명을 개척해 나갈 수는 없는건가???

결국 운명이라는 것은 그대로 되었을 때 두 사람에게 신비감만 더해주는것 같다.

운명같은 만남이라는...

하지만, 난 결코 그것이 사랑의 전제조건이라고 생각하진 않는다.
먼저 일반적으로 사용되는 ObjectOutputStream의 구조를 보자

FileOutputStream ostream = new FileOutputStream("t.tmp");
ObjectOutputStream p = new ObjectOutputStream(ostream);

p.writeInt(12345);
p.writeObject("Today");
p.writeObject(new Date());

p.flush();
ostream.close();


이를 보면 대부분 ObjectOutputStream은 FileOutputStream과 같이 사용되는 것을 볼 수 있다.

java에서 구성되고 있는 구조를 보자



이를 보면 ObjectOutputStream은 OutputStream을 상속받고 있으며,

Source를 보면 OutputStream을 상속받으면서도, 동시에 OutputStream을 맴버 변수로 가지고 있다.

때문에 ObjectOutputStream은 OutputStream을 생성자에서 인자로 받을수 있다.

이때 FileOutputStream은 OutputStream을 상속받기 때문에

ObjectOutputStream의 생성자 인자로 들어갈 수가 있다.



위에서 보듯이 ObjectOutputStream은 어떤 객체이든 writeObject()를 수행하면, 모두 기록이 가능하다(단, Serializable하다면)

하지만, Serializable의 내부를 보면 아무것도 없다! 전혀!!!

왜? Serializable은 단지 직렬화 가능한 객체라는 것을 표시하는 것 뿐이기 때문이다.

이는 다른 관점에서 이야기하면 Serializable을 구현한 객체는 직렬화를 위해 그 어떤 작업이나 특성을 가지지 않는다는 것을 의미한다.

그럼 여기서 왜 java는 위와 같은 구조를 가지며, 어떻게 Serializable 표시가 된 객체를 저장하고 읽어올수가 있는것일까?

정답은 Class에 있다.

ObjectOutputStream의 writeObject()는 Object를 인자로 받아

Object의 getName() 메소드를 통해 해당 Class의 이름을 String으로 알아낸다.

이미 눈치빠르신 분은 알겠지만, ObjectInputStream에서 반대로 forName()과 같은 메소드를 통해 다시 Object를 Class화 시킨다.

(이때, UTF-8을 이용하여 정확한 Class명을 얻어올수 있다. 자세한것은 생략)

이와 비슷한 방법으로 Field들도 단위적으로 저장하고 읽어올수 있다.

이런 식으로 하여 Object를 그의 특성에 맞게 저장하고, 다시 그대로 복원이 가능해진 것이다.






그렇다면, 이를 이용해 간단한 SimpleObjectOutputStream을 설계해 보자.

이는 java library처럼 객체내에 reference 변수가 있다면 그까지 저장하진 않고, 단순 객체만을 저장하고, 읽어오도록 하자.

이때 중요한것은, 해당 Object에 대한 정보를 SimpleObjectOutputStream이 알아내서 처리하는 구조가 아닌,

해당 Object에게 OutputStream을 전달하여 해당 Object가 실제로 자기 특성에 맞게 저장하는 모습이 더 낫다고 생각한다.

때문에, Serializable은 writeObject()와 readObject()를 구현해야만 하며, SimpleObjectOutputStream은 내부적으로 해당 객체의 writeObject()를 호출해주어야 한다.



구조는 java library와 전적으로 동일하다.

하지만, 이때 SimpleObjectOutputStream은 인자로 받은 Object의 특성을 모두 알아내어 OutputStream에게 보내는 것이 아니라,

Object에게 OutputStream을 인자로 보내어 Object 스스로 알아서 저장하고 읽어오게 하는 방법으로 설계하면 된다.
재미 있었던 MT로 기억남는다~

아무래도 4학년들이였고, 많은 인원도 아니였기에

예전 MT와는 사뭇 다른 느낌...

9월 30일



01, 02 여자애들도 가서 참 재미있게 놀았다~



숙소 밖에서 그릴에 굽는 고기 맛이란~~~ @^-^@

문기~~~ 수고했어~

나중에 천상연 또 부르자궁~~~



문득 비오는 문 밖을 보며...

10월 1일



아침에 일어나 계곡에 나가 보았다~~~

비가 와서 그런지 시원하게 흐르는 계곡에

물 흐르는 소리... @^-^@ 너무너무 좋았다는...



도저히 못참고 계곡에 발을 담가버렸당~~~

시원~~~시원~~~



냇가 건너에는 작은 언덕이 있었고,

그 위로 비치는 햇살이란~~~



드디어 다시 술을 마시기 시작했는데...

홍태가 취해버렸당~~~ 헤롱헤롱대는 모습.

그래두 여자애들에게 인기가 많더라구~~~

10월 2일



마지막 날에는 현백이가 맛이 가버렸다~~~

그래서 나에게 막 범인을 몰던 기억이...(첫날 저녁이였나???)

아무튼!!! 나뿐~~~넘~~~



중간에 잠깐 청소를 하는데...

흑흑... 4학년 MT다 보니까... 부러운 짬밥인 범석형이 눈에 보였당~

하긴 나두 이거 찍으면서 좀 놀았지 머~ 냐향향~



비슷한 사진 한방더!!!

왜??? 나두 놀구 있었으니...~~~



많이는 못찍고 이렇게 4학년 MT가 끝이 났다~~~
가끔 모현에 내려가는 길을 걷다가 보면...

참 이쁘다는 생각이 들때까 있다~

예전에도 몇장을 찍었는데...

좋은 느낌~~~





어머니 세례받으시는 날~

우리 어머니께선 하늘에서 내려오신 천사 같았당~~~ @^-^@

내 사진기로는 성당만 찍었다는~~~

우리 어머니 세례명~ 테레사~~~




+ Recent posts