C# Winform으로 만든 간단한 타이머입니다.

이 장난감(?)은 누구든지 자유롭게 디컴파일링, 분해, 구축이 가능합니다. 편히 쓰세요.

please.zip

* 사용법

- 딱히 없습니다. 프로그램을 실행하고, 퇴근시간 설정 버튼으로 시간을 설정 후 어디 구석에 놔두시면 됩니다. 

그리고 멍하니 처다봅니다.

- 작업표시줄에 표시되지 않습니다.

- 기본적으로 시작프로그램에 등록이 되게 됩니다. 시작시 실행을 원치 않으신다면 꼭 해제해주세요.

- 출근시간 전에 이 프로그램을 실행하셨다면 아주 성실하신 분이므로 칭찬합니다. 출근시간까지 n시간 남았다고 표시합니다.

- 퇴근시간을 넘어가면 자동으로 야근모드로 바뀝니다.

- 시간설정에 기본적으로 24시계를 적용합니다. 저녁 6시라면 18시로 입력하셔야 합니다.

- 프로그램이 계속 실행되고 있고 자정을 넘어서도 철야로 야근을 하고 계신게 아니라면, 시간을 다시 리셋하셔야 합니다.

등대 여러분들은 조속히 퇴근해주시길 바랍니다.

- 반드시 timeData.dat 파일이 같은 장소에 있어야합니다. 출퇴근시간 및 코멘트를 BinaryFormat 형태로 저장합니다.

디버깅이란 항상 그렇듯 수시간 또는 수일을 고민해서 결국 해결봤더니 별 거 아니었더라.. 하는 경우가 많은데

이번에도 정말 어김없이, 그랬다. 두 번 겪고싶지는 않아서 기록해 둠.

이번 이슈의 개요는,

<MissingReferenceException>

Device Camera를 이용한 AR 프로젝트 빌딩 중, 여러 컨텐츠를 왔다갔다 실행하며 저 Exception Error을 띄웠다.

StackTracing을 해봤더니 전혀 엉뚱한 곳을 가리키고 있길래 아! 요고요고 그거다, eventHandler를 제대로 관리하지 않았구나, 하고 감이 왔었다.

<SceneLoad 관련 Action 추가함수>

간단한 디버깅 결과, 저 Action에서 null참조를 가리킨다는 것을 알았고(사실 여기까지 멍청하게 한시간 이상 걸림) 원인 파악에 나섰다.

+ 연산으로 Event Handler에 등록된 게임 오브젝트가 씬 전환 등으로 삭제가 되면

이 레퍼런스는 당연히 없는(null) 값을 가리키게 될 것이고, 그 값 또한 GC에 의해 null로 셋팅된다. 즉 헛손질을 하게 된다..는 것이었다.

그 후, 다시 + 연산이 호출될 때 null 값으로 정의된 레퍼런스는 그대로 유지된 채 Event가 붙어버려 Missing 오류를 띄우는 것.

객체를 두 개 이상 생성하는 것도 멍청했고, 이 Event의 참조 또한 객체 수만큼 늘어나는게 원초적인 문제라면 문제였다.

원래는 위 주석처리된 함수처럼 람다식을 이용해 event를 붙였지만, 객체가 생성과 파괴를 반복할 수도 있다는 것을 알았으니

함수형으로 만들고, 해당 객체가 파괴되기 전에 Action을 빼 주는 코드를 추가했다.

<자, 이제 빼 주자.>

객체가(여기서는 AR관련 스크립트를 포함한 객체) 비활성화 될때 해당 Action을 빼 준다. 해결!! 하면서 다시 테스트를 해 보았지만..

안된다.(2차빡침)

왜? 대체 왜? 분명히 Event까지 잘 빼주고, 객체가 다중생성 되는것, 그리고 GC와 Resource관련 패널도 정확히 검사했는데 대체 왜..?

그리고 이 버그가 특정 Scene의 이동시에만 발생하는 버그가 StackTracing을 더 어렵게 만들었다.

아무리 생각해도 이 Action에서 문제를 일으키는건 응당해보여서 다시 Test를 해봤더니..

OnDisable()이 호출 자체가 안 된다.

-_-?? 그럴 수 있나?

코드를 보면 알겠지만 해당 액션은 SceneManager의 sceneLoaded에 관한 것이다. 하지만 해당 스크립트를 사용하는 씬은 Additive모드로 가져온 것.

<해당 Scene의 Hierarchy 구조>

현재 ARCamera Scene이 Additive 모드로 불려져 있고, 여기서 네트워크 신호(Exit Response)를 받으면 다른 Scene이 AsyncLoad가 되는 구조였다.

즉, 본디 실행중인 메인 Scene에서 비동기 씬로드가 이루어지면 Additive Scene에 포함된 객체에서 OnDisable()이 호출이 되지 않는다는 것.

호오.......

응, 그래서 어떻게든 객체가 파괴되는 시점은 분명히 올 것이라 생각하고 OnDestroy에 넣었더니

정상적으로 Event를 잘 빼주게 되더라. 여기서 1차 환호. 디버깅은 완료했다.

사실 Event Handler에 등록한 그 Action은 단순히 Device Camera를 찾아 셋팅하는 기능 밖엔 없었다 ^ u^;; 결국 1회용 함수라 생각해서

카메라를 끌 때 빼는것도, 파괴될때 빼는것도 아닌 그냥.. 그냥 넣자마자 빼면 단순히 해결이 되는 문제였다 - _-;

분명 며칠전까지만 해도 아주 잘 되던 유니티 Apk빌드가 갑자기 말썽을 일으켰습니다.

Git branch를 잘못 따라간 것도 아니었고... 분명 빌드 설정이나 셋팅에 관해선 아~~무것도 만진 것이 없었는게 갑자기 말이에요.

제가 했던 진짜 수많은 삽질은 좀 뒤로 하고, 문제 해결에 도움이 되었던 결정적인 방향들만 기록해둡니다.

일단 발단은 이렇습니다. 잘 되던 유니티 빌드가 안 되고, 로그를 추적해 보니..

CommandInvokationFailure: Unable to merge android manifests. 

C:/Program Files/Java/jdk1.8.0_221\bin\java.exe -Xmx4096M -Dcom.android.sdkmanager.toolsdir="C:\Users\user\AppData\Local\Android\sdk\tools" -Dfile.encoding=UTF8 -jar "C:\Program Files\Unity\Editor\Data\PlaybackEngines\AndroidPlayer/Tools\sdktools.jar" -

stderr[

Error: [Temp\StagingArea\AndroidManifest-main.xml:4, C:\Project\01.Client\Temp\StagingArea\android-libraries\AndroidPlugin\AndroidManifest.xml:16] Trying to merge incompatible /manifest/application/activity[@name=kr.co.d.MainActivity] element:

  <activity

--    @android:configChanges="mcc|mnc|locale|touchscreen|keyboard|keyboardHidden|navigation|orientation|screenLayout|uiMode|screenSize|smallestScreenSize|fontScale|layoutDirection|density"

--    @android:hardwareAccelerated="false"

--    @android:label="@string/app_name"

  <activity

++    @android:name="kr.coid.MainActivity">

++    <intent-filter>

++        <action

]

stdout[

[Temp\StagingArea\AndroidManifest-main.xml:18, C:\Project\CotrasHybrid\01.Client\Temp\StagingArea\android-libraries\AndroidPlugin\AndroidManifest.xml:29] Skipping identical /manifest/application/receiver[@name=kr.co.netblue.cotrashybrid.BootBroadcastReceiver] element.

]

exit code: 1

정확히 1년만의 포스팅 (...) 왜냐하면 실컷 놀았거든요.

-------------------------------------------------------------

지금 개발하고 있는 프로젝트에선.. 정말 특이하게 단순정보만 담은 리소스들도 DB로 관리하고 있습니다.

아니, DB로만 관리하는게 아니라 어디엔 xml, 어디엔 스크립트 안에서(;;) 아주 중구난방이긴 한데

기획자들에게 직접 DB수정을 요할 수는 없으니 대부분 요청사항을 전달받을 때 Excel로 작업하곤 합니다.

보통 데이터테이블을 csv형식으로 뽑아주면, 이를 엑셀로 Import시켜 기획팀에서 수정 후 다시 엑셀을 제가 받아오는.. 그런 식인데

어찌됐든 요놈을 db에 집어넣고, 파싱하고, bytes파일로 바꾸고 하는 일은 온전히 제 일이란 말이죠. 그런데 말썽이.. 좀 있었습니다.

뭐 예를 들어, column별로 정리된 데이터테이블이 있다고 칩시다.

제 인생은 되는 일이 잘 없더라구요.

일단 구글링을 좀 해보니, DB INSERT시 칼럼이 NOT NULL 여부에 관계없이 실수, 정수형 데이타에 빈 문자열을 입력하면 발생하는 오류랍니다.

위에 엑셀 파일에 null값을 넣었는데, 처음엔 저게 빈칸으로 왔었어요.

일일히 쿼리문 써가면서 수정하자니 머리가 나빠 손이 고생하는 느낌도 들고..

뭐 여튼 해결방법은, 제한설정을 좀 풀어주면 됩니다. 자료형이 비좁다면 더 크게 바꾸고, 65535바이트 이상이라면 MEDIUMTEXT로 바꾸고 뭐 그런 식이요.

그리고 null값 관련은 ini 설정에서 

sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”

추가해주시면 됩니다.

그리고 아주 약간의 하드코딩을 통해, sql을 그대로 .db로 바꿔주는 함수를 짜둡니다.

그렇게 db파일을 퉤 하고 뱉어내면 확장자를 .bytes로 바꾸어 주면 됩니다.

그래도 일단 이렇게 만들어두면 XML, DB, bytes, csv 형식을 자유로이 왔다갔다 할 수 있어서 앞으론 좀 편하겠네요.

언제부턴가 마비노기 염색 도우미가 안 되기 시작했다. 자꾸만 막대 색상변경이 감지되었다고.

읽어들이는 막대색상이 자꾸만 변하길래 아 이건, 읽어들이는 픽셀값이 막대색이 아닌 배경색임을 짐작,

뭔가 읽어들이는 픽셀값 위치가 어긋나있음을 예상했다.

 -> 

이유인 즉슨 염색바 진행픽셀 길이(!!)가 더 길어졌다는 점.

아니, 창 크기 자체가 달라졌으니 자꾸 애꿎은 배경색만 스포이드로 인식한다는게 이유인 듯 했다.

그럼 어떡해 픽셀만 옮겨줘야지 - "-

일단 프로그램부터 뜯어보기로 한다.

데...델파이?! -_-

끽해야 닷넷이겠거니 하고 아무 디컴파일러를 쓸 생각이었는데 델파이라니. orz

델파이 언어는 저번 OpenCV 호작질하며 컴파일하며 써본 적이 있다. 마침 디컴파일러는 DeDe가 있어서 써보기로 함.

물론 DeDe 단독 말고 디버깅 도구와 함께 쓰도록 한다.

'염색 진행 막대 색상 . . .'으로 시작하는 String Reference를 찾는다. 여기렸다.

마찬가지로 관련 클래스의 Seek 픽셀들을 전부 오른쪽으로 더 당김

전부 수정했으면 다시 컴파일하고 나머지는 백업해둠

Hex값이 잘 바뀌어있는지 확인하고

실행

콘솔 잘 올라오고

(Modified By Nalchi -"-)

된다!!!

(0927 추가 : 마도카에 업데이트 된 버전이 올라와있었다고 한다. 그것도 이 주 전에. -_-)

회사 동기중 한명이 ifstream의 getline이 fgets보다 성능이 좋다는 썰을 풀길래 이건 무슨 신박한 개소리인가 싶어 간단히 속도 테스트를 해보았습니다. 테스트 환경은 윈10 64bit, 약 14M 정도의 로그 데이터파일을 기준으로 짜둠!

..일단 결론부터 말하면, ifstream은 쓸 것이 못 됩니다. 수백메가도 아닌 단 몇천줄 로그파일 읽는데에도 시간이 훨씬 차이가 납니다.

1) getline()으로 직접 읽기. 버퍼를 지정하고 직접 넘겨주기에 ifstream 중에서 그나마 성증이 좋음

void test_ifstream1() {
	std::ifstream inFile;
	inFile.open(TEST_FILE);

	if (!inFile.is_open()) exit(1);

	char buf[512];
	while (!inFile.getline(buf, sizeof(buf)).eof()) {

	}
}

2) istreambuf_iterator 사용. 모든 내용은 vector<char>형태로 저장. 나름 버퍼를 사용하는구나 싶어 성능이 좋겠다 생각했지만, 정반대이다.

void test_ifstream2() {
    std::ifstream inFile;
    inFile.open(TEST_FILE);
   
    if (!inFile.is_open()) exit(1);

    std::istreambuf_iterator<char> begin(inFile);
    std::istreambuf_iterator<char> end;
    std::vector<char> contents(begin, end);
}

3) fopen()과 fread()를 사용. 한꺼번에 512byte 정도를 읽어오며, 딱 한 줄씩 읽어오지는 않는다. ifstream을 사용할때보다 약 7배이상 성능이 좋음.

   대신, 한 줄씩 읽어서 처리할 경우 문자별 매칭을 수행해야하는 번거로움이 생긴다.

void test_osfile1() {
    FILE *fp = fopen(TEST_FILE, "r");

    if (NULL == fp) exit(1);

    char buf[512];

    size_t len = 0;
    while (!feof(fp)) {
        len = fread(buf, sizeof(buf[0]), sizeof(buf)/sizeof(buf[0]), fp);
    }
    fclose(fp);
}

4) fgets() 함수. 위의 fread보단 시간이 약-간 더 걸렸다.

void FREAD_TEST() {
	FILE *fp = fopen(TEST_FILE, "rb");
	if (NULL == fp)
		exit(1);

	char buf[BUF_SIZE] = { 0, };

	char buf[BUF_SIZE] = { 0, };
	while (NULL != fgets(buf, sizeof(buf), fp)) {}

	fclose(fp);
}

normal read에선 크게는 7000msec 까지 차이가 나더이다. 이는 엄청난 수치죠. binary read라면 워낙 빠르기에 차이가 미미할 수도 있지만..

사실 여러 운영체제에 포팅하는 경우 이식성을 높이기 위해선 ifstream을 쓰는 것이 가장 좋을수도 있습니다. 하지만 성능이 문제라면.. 다른 공통으로 사용할 수 있는 라이브러리는 찾는게 방안일 수도 있겠네요. 안정성과 검증을 해야하는 문제도 있고..

하지만 fopen()은 공통 c라이브러리이기 때문에 대부분 호환 가능해서 이식성에 어려움은 없습니다. 문제는 기존 C++의 stl과 연동이 자연스럽지 않기에 이를 어떻게 풀어야 하는가. 즉, 해야할 일들이 많이 생기게는 되겠네요 = _=

어쨌든! 단순 성능비교를 할땐 fread()의 성능이 압도적인걸로!

보통 자바에서는 자료를 읽거나 쓰기 위해 Stream을 사용하고, 자바는 두 가지 형태의 Stream을 지원합니다.

Reader/Writer, Input/OutputStream이 그것인데, Reader/Writer는 High-Level의 I/O(String이라던가..)을 지원하고, Input/OutputStream은 Low-Level의 I/O(byte)를 지원합니다. 속도 향상을 위해서는 BufferedStream을 사용하지만 BufferedStream의 경우 버퍼의 기본값은 2k입니다. 이 값은 조정할 수 있으나 자료의 용량이 클 경우 메모리가 많이 필요하기 때문에 BufferedStream을 사용할 경우 여러가지 사항을 고려해야 합니다.

아래는 BufferedStream을 사용하지 않고 I/O를 했을 경우의 예제입니다. 370k의 JPEG 파일을 복사하는데 10800ms.

public static void copy(String from, String to) throws IOException {
    InputStream in = null;
    OutputStream out = null;
 
    try {
        in = new FileInputStream(from);
        out = new FileOutputStream(to);
 
        while (true) {
            int data = in.read();
 
            if (data == -1)
                break;
 
            out.write(data);
        }
        in.close();
        out.close();
 
    } finally {
        if (in != null)
            in.close();
             
        if (out != null)
            out.close();
    }
}

BufferedStream을 사용해서 퍼포먼스를 개선한 예제입니다. 같은 파일을 복사하는 데에 130ms밖에 걸리지 않습니다.

public static void copy(String from, String to) throws IOException {
    InputStream in = null;
    OutputStream out = null;
 
    try {
        in = new BufferedInputStream(new FileInputStream(from));
        out = new BufferedOutputStream(new FileOutputStream(to));
         
        while (true) {
            int data = in.read();
             
            if (data == -1)
                break;
                 
            out.write(data);
        }
         
    } finally {
        if (in != null)
            in.close();
             
        if (out != null)
            out.close();
    }
}

while 루프를 사용하지 않고 배열을 사용함으로써 퍼포먼스를 개선한 예제. 같은 파일을 복사하는 데에 33ms.

public static void copy(String from, String to) throws IOException {
    InputStream in = null;
    OutputStream out = null;
         
    try {
        in = new FileInputStream(from);
        out = new FileOutputStream(to);
         
        int length = in.available();
        byte[] bytes = new byte[length];
             
        in.read(bytes);
        out.write(bytes);
             
    } finally {
        if (in != null)
            in.close();
             
        if (out != null)
            out.close();
    }
}

하지만 바로 위 코드는 byte 배열로 선언되는 메모리 버퍼의 크기가 실제 파일의 크기와 동일해야 합니다. 이에 따라 두 가지 문제점이 발생할 수 있는데요, 첫 번째는 파일의 용량이 클 경우 상당한 메모리 낭비를 초래한다는 점. 두 번째는 Copy() 메소드가 수행될 대마다 new byte[]에 의해 버퍼가 새로 만들어진다는 점. 마일 파일의 용량이 클 경우 버퍼가 만들어지고 Garbage Collector에 의해 수집될 때 상당한 오버헤드를 초래할 수 있습니다.

예제4) Improved Custom Buffered Copy
static final int BUFF_SIZE=100000;
static final byte[] buffer=new byte[BUFF_SIZE];
 
public static void copy(String from, String to) throws IOException {
    InputStream in=null;
    OutputStream out=null;
 
    try {
        in=new FileInputStream(from);
        out=new FileOutputStream(to);
     
        while(true) {
            synchronized (buffer) {
                int amountRead = in.read(buffer);
                 
                if (amountRead == -1)
                    break;
     
                out.write(buffer, 0, amountRead);
            }
        }
    } finally {
        if (in!=null)
            in.close();
         
        if (out!=null)
            out.close();
    }
}

크기가 100k인 byte배열을 임시버퍼로 지정하고 이를 static으로 선언함으로써 퍼포먼스를 개선했습니다. 이 코드로 같은 파일을 복사하는데 22ms밖에 걸리지 않아요. static buffer의 사용으로 I/O작업을 수행할 경우 발생하는 문제점을 해결하기 위해 synchronized block을 사용했습니다. 비록 sync를 사용함에 따라 성능 저하를 일으킬 수도 있지만, 실제 while 루프에 머무는 시간이 극히 짧기 때문에 퍼포먼스에 문제는 없습니다. 테스트에 의하면 synchronized 버전과 unsynchronized 버전 모두 같은 시간에 수행을 완료했었습니다.

NFC 태그를 단말에서 인식하게 되면 그 정보는 인텐트의 부가 데이터로 넣어져 브로드캐스팅 됩니다. 이때, 인텐트에 들어있는 NFC 태그의 값을 확인하려면 'EXTRA_TAG'를 키값으로 하여 Parcelable 객체를 참조하면 됩니다. 브로그캐스팅 되는 인텐트를 받기 위한 대상 액티비를 결정하는 과정 중에 가장 먼저 확인하는 것이 되려면.. 다음과 같은 enableForegroundDispatch() 메소드를 호출하면 됩니다.

[Reference]

public void enableForegroundDispatch (Activity activity, PendingIntent intent, InterFilter[] filters, String[][] techLists)

public void disableForegroundDispatch (Activity activity)

이 메소드들은 NfcAdapter 객체에 정의되어 있습니다. 다음과 같이 NfdAdapter 객체를 참조한 후 액티비티의 onResume() 메소드 안에서는 enableForegroundDispatch()를, 그리고 onPause() 메소드 안에서는 disableForegroundDispatch()를 실행합니다.

[Reference]

public static NfcAdapter getDefaultAdapter (Context context)

만약 이렇게 참조한 NfcAdapter 객체가 활성화되어 있지 않다면 NFC를 사용할 수 없는 상태가 되므로 널값인지 여부와 함께 isEnabled()메소드를 이용해 활성화 여부를 확인할 수 있습니다.

enableForegroundDispatch() 메소드의 파라미터로 전달되는 PendingIntent 객체는 NFC 태그가 인식되어 브로드캐스팅으로 인텐트를 받았을 대, 실행할 액티비티를 지정하는 역할을 합니다. 세 번째와 네 번째 파라미터는 필터와 사용할 상세 기술의 내용이 들어갑니다.

10억 층 빌딩

네 살 반의 우리 딸이 10 억 층 건물을 가지고 싶어합니다. 이것이 얼마나 큰 크기인지 딸을 이해시키는 것이 어렵다는 것 뿐만 아니라, 딸이 극복해야 할 수많은 다른 어려움들을 모두 설명하긴 힘드네요.

Keira^[각주:1], Steve Brodovicz, Media, PA

 케이라Keira야,

 만약 네가 빌딩을 너무 크게 만든다면 윗부분이 너무 무거워 아래를 찌그러트릴 거란다.

 혹시 땅콩 버터로 타워를 만들어 본 적이 있니? Blobby^[각주:2]의 성처럼 작은 건 만들기 쉬울거야. 그 건물은 서 있기에 충분히 강할 테니까. 그런데 만약 이것보다 훨씬 더 큰 성을 짓는다면 아마 땅콩 버터는 무너져 내려 팬케익처럼 되어버릴거야.

아빠가 너를 말리지 못 하게 해. 만약 너보고 청소하라고 한다면 캔을 몰래 방으로 가지고 들어가 카펫 위에서 하렴. 내가 허락하마.

 빌딩에서도 똑같은 일이 일어나. 우리가 만들 빌딩은 매우 튼튼하지만, 그것이 우주까지 올라가게 만들 수는 없어. 아마 밑부분이 찌그러질거야.

 우리는 꽤나 높은 건물을 만들 수는 있어. 가장 높은 건물은 거의 1km나 되고, 아마 우리가 원한다면 2, 3km짜리 건물을 세울 수 있을지도 몰라. 그 높은 건물들은 스스로의 무게를 이겨내게 될태고. 하지만 그 이상 높이는 어려울걸.

 그치만 무게 외에도 다른 문제들이 몇 가지 더 있어.

 한 가지 문제는 바람이야. 높은 곳에서 부는 바람은 정말로 강해서, 건물들은 이 바람을 견뎌낼 수 있도록 튼튼해야만 해.

 또다른 문제라면 바로... 놀랍게도 엘리베이터야. 높은 건물들은 엘리베이터가 필요하지. 아무도 수백층짜리 계단을 직접 올라가고 싶진 않을거야. 만약 네 건물이 많은 층이 있다면 그만큼 각자 다른 엘리베이터가 더 필요할 거야. 많은 사람이 동시에 올라가고 내려가진 않을테니까. 만약 네가 건물을 엄청 높게 짓는다면 엘리베이터가 그만큼 공간을 많이 차지해서, 방 하나를 놓을 공간이 없을지도 몰라.

위층으로 갈수록 더 적은 엘리베이터가 필요하고, 그만큼 방이 더 많아지니 더 많은 엘리베이터가 필요하고..

 아마 엘리베이터 없이 사람을 위로 올려보내는 방법을 생각할 수도 있어. 10층 크기의 거대 엘리베이터를 만들거나 롤러코스터처럼 움직이는 엘리베이터를 만들 수도 있지. 아니면 사람을 열기구에 태워서 위층으로 올려보내거나, 투석기로 사람을 쏘아 보낼수도 있어.

출처 : 나사

 엘리베이터와 바람도 문제지만, 가장 큰 문제는 아마 돈일거야.

 아주 큰 건물을 지으려면 누군가는 돈을 내야 해. 그리고 아무도 엄청 큰 건물을 짓는 데에 돈을 쓰고싶진 않을거야. 수 마일 크기의 빌딩을 짓는 데엔 수십 억 달러가 들어가. 10억 달러면 굉장히 큰 돈이지! 만약에 네가 10억 달러가 있다면 큰 우주선을 하나 빌릴 수도 있고, 전세계 멸종위기의 여우원숭이들을 구할 수도 있고, 미국의 모든 사람에게 1달러씩 줄 수도 있어. 그러고 나서도 조금 남을거야. 사람들은 수 마일 높이의 건물을 세우는 데에 이렇게 많은 돈을 쓸 가치가 있다고 생각하진 않겠지.

만약 네가 정말 부자라서 건물을 짓는 비용을 온전히 낼 수 있고, 몇몇 공학적인 문제들을 해결했다 하더라고 10억 층 건물을 짓기엔 너무 커. 10억 층은 너무 많아.

하나의 큰 고층건물은 약 100층이야. 1층짜리 작은 집을 100개 쌓은 꼴이 되겠지.

커다란 초원에 100개의 집이 같은 장소에 있네

만약 네가 100개의 고층건물을 쌓아서 메가-고층건물을 지었다면, 우주까지의 절반정도 높이일거야.

우우우우우우주로!

 이 메가-고층건물은 너의 10억 층에 비해선 아직 10,000층밖에 안 돼. 100개의 각각의 고층건물엔 100개의 층이 있을테니 메가-고층건물의 층수는 그 100배인 10,000이겠지.

 그러나 너는 1,000,000,000층짜리 건물이 가지고 싶다 했으니 100개의 메가-고층건물을 쌓아서 메가-메가-고층건물을 만들어보자.

그리고 난 지금 Jillian Mayer의 'Mega-Mega Upload'^[각주:3]가 머릿속에서 떠나질 않아

 메가-메가-고층건물은 지구로부터 너무나 멀리 뻗어져 나와서 우주선이 건물에 부딫힐 수도 있어. 건물로 향하는 우주정거장이 있다면 부딫히지 않기 위해 로켓을 써야겠지.^[각주:4] 나쁜 소식은, 우주엔 부서진 우주선이나 위성의 쓰레기 잔해들이 너무도 많이 무분방하게 날아다니고 있다는 거야. 만약 네가 메가-메가-고층건물을 짓게 된다면 그것들이 아마 처박히겠지.

 뭐 어쨌든, 메가-메가-고층건물은 10,000층의 100배인 = 1,000,000층 밖에 안돼. 아직 네가 원하는 1,000,000,000층보단 낮아!

 메가-메가-고층건물을 100개 더 쌓아서 메가-메가-메가-고층건물(...)을 만들어보자:

우주 경계 위원회의 승인을 받을 수 있을까 걱정하기 시작했다

 이 메가-메가-메가-고층건물은 진짜 너무 커서 거의 달에 닿을 정도야.

 그러나 이것도 아직 100,000,000층 밖에 안 돼! 1,000,000,000층에 다다르기 위해서 10개의 메가-메가-메가-고층건물을 쌓아 케이라-고층건물을 만들어 보자.

우리는 저 작은 루프를 만들기 위해 가니메데와 유로파를 분해했다

 케이라-고층건물은 만들기엔 너무 클 지도 몰라. 너는 이 건물이 달에 부딫히지 않고, 지구 중력에 의해 끊어지지 않아야 하고, 무너져내려 공룡을 멸망시킨 운석처럼 되지 않도록 신경써야 할 거야.

 그러나 몇몇 기술자들은 너의 건물과 비슷한 생각을 가지고 있어! - 바로 우주 엘리베이터야. 이것이 네 건물만큼 그리 크진 않지만(우주 엘리베이터는 달까지 가는 도중까지니까.), 어쨌든 비슷하지!

 몇몇 사람들은 우주 엘리베이터를 지을 수 있다고 생각하고, 다른 몇몇은 미친 생각이라 하지. 아직은 우리가 해결할 수 없는 문제-타워를 튼튼하게 만들 방법, 위쪽까지 엘리베이터 전기를 전달할 방법-들 때문에 지을 수는 없어. 만약 네가 정말로 거대한 건물을 짓고 싶다면 이들이 겪고 있는 문제들을 한 번 찾아보고, 마침내 이 문제들을 해결할 수 있는 사람들 중 하나가 될 수 있을거야. 그러면 언젠가는, 정말 우주로 향하는 큰 건물을 지을 수 있겠지.

 하지만 그 건물이 땅콩버터로 만들어지진 않을거야.

케이라 때문이야

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

using System;  

public struct MyStruct  
{  
    public int Width;  
}  

public class ListView  
{  
    MyStruct ms;  
    public MyStruct Size  
    {  
        get { return ms; }  
        set { ms = value; }  
    }  
}  

public class MyClass  
{  
    public MyClass()  
    {  
        ListView lvi;  
        lvi = new ListView();  
        lvi.Size.Width = 5; // CS1612                                                                                  
    }  

    public static void Main()   
    {  
        MyClass mc = new MyClass();  
        // Keep the console open in debug mode.  
        Console.WriteLine("Press any key to exit.");  
        Console.ReadKey();     
    }  
}  

C++에서 C#으로 옮기면서 겪는 백만스물두 가지 정도 고통 중의 하나입니다.

보통 List 안에 구조체 변수를 넣고 돌리는 경우가 종종 있는데, 무려 C#에서는 컴파일 에러가 나는 코드입니다.

이유가 뭐인고 하니 인덱스에서 값 형식을 찾아갈때는 그 개체 자체의 참조변수가 아닌 '복사본'을 얻게 된다는 것.

이 '복사본'은 저장소 위치를 가르키는 것이 아닌 단순한 메소드이기 때문에 인덱스에 저장되진 않는다는 겁니다.

한 마디로 개체참조를 하려고 했더니 헛손가락질을 한다는 것.

'당연한 거 아니야?' 라고 한다면 그런거겠지..만 이게 익숙해진 사람들에겐 의외로 짜증나는 것이거든요 -_-;

생각보다 해결 방법은 많습니다.

1. 구조체 선언 시 접근속성 부여

2. 구조체에 고유한 인스턴스를 만들고, 해당 필드를 수정 후 다음 전체 구조체를 속성에 다시 할당하기 (2중 구조체)

3. 구조체를 클래스로 변경하기 (?)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

public MyClass()  
    {  
        //ListView lvi;  
        //lvi = new ListView();  
        //lvi.Size.Width = 5; // CS1612                                                                                

        MyStruct ms;  
        ms.Width = 5;  
        lvi.Size = ms;
    }  

그냥 재할당을 해주면 단순히 해결되긴 합니다 ~_~