초벌 프로그래밍의 네이밍은 완성된 형태와 조금 다를 필요가 있을 것 같다. (naming 의 light binding)

class 로 정리되기 전의 나열된 method 들에 대해,

공통 주체, 즉 객체에 해당하는 명사들은 대문자를 허용할까 하는 생각을 해 봄.


누가 내 코드 어순 가지고 시비걸었듯,

가령 get_volume_of_circle 을 get_circle_volume 이라고 한건, circle 로 먼저 정렬되어 보이기 위한것이었는데

CIRCLE_get_volume() 처럼 말이지. (나중에 CIRCLE 을 클래스로 만들꼬야! 하는 의지의 표현?)

하지만 결벽증이 도지면 모든걸 객체화 하고 싶어져서 스스로 무덤을 판다.

개발에 소요되는 시간을 비약적으로 폭발시킬 수 있는 일인것.

(달리 UNIX++ 이 망한게 아니지)


사실 아래 글에서 누군가 short 와 int 에 대해 질문했지만,

RAM / DISK ( sd card 와 같은 NAND memory 포함 ) 의 자료형은 '크기' 이외에 특별히 구별되는 특징이 없다.

(그래서 다양한 목적과 방법으로 사용할 수 있다)

RAM 은 1바이트 단위로 의미가 있고, DISK 는 BLOCK(512바이트 ~ 4096바이트) 단위로 의미가 있을 뿐.

(더 작은 단위의 입출력을 지원해주지 않으니까)

거기에 더해

system word, compiler word, memory alignment 와 cache line 단위의 부가적인 '크기' 의 영향을 받는 거지.

즉, 1바이트, 2바이트, 4바이트, 8바이트, (10바이트, 16바이트 - paragraph -) 단위의 자료형이란 것만 의미로운 것.

4bit 를 nibble 이라고 사용하던 과거의 알뜰한 단위는 요즘 세상에 의미가 없고 말야. (BCD 정도에나 쓰겠지)


c 언어에선 정수형 / 실수형 / 포인터형 에 따라 연산의 방식이 바뀐다.

부호부, 지수부+가수부가 있고 없고에 따라 이를 테면 union 으로 설계되어 있는 것이지.

각각 +-*/ 등의 산술 연산이 overriding 되어 있는 것 뿐.

당장은 int 가 가장 효율적인 타잎이겠지만,

대용량의 데이타 처리에서 구조체를 정의할때 비교적 큰 구조체의 단위를 bit field 로 쪼갠다든지,

캐시라인에 정렬시킬 때, 각각의 자료형은 모두 유용해진다.

ANSI string 일때 char 가, 8bit color channel 의 component 를 다룰 때 unsigned char 가 의미로운 것들 처럼 말야.