포인터가 4바이트인 이유는?

taeyeung의 이미지

32비트 운영체제에서 포인터는 4바이트로 알고 있고 당연하다고

생각하고 사용을 해 왔는데 어느날 아는 후배가 왜 포인터의 크가가

4바이트이냐고 물어 보니 이유를 답변하기가 애매해졌습니다.

제가 아는 이유는 CPU의 버스가 32비트로 처리되기 때문이라고 알고

있는데 다른 이유가 있는 건가요?

댓글

익명 사용자의 이미지

사용하는 주소가 32비트이므로 포인터가 4바이트인거 아닌가요??

douner의 이미지

4G 의 메모리 주소를 지정할 수 있기 때문이 아닐까요?
32비트로 만들 수 있는 경우의 수가 2의32제곱인 4G잖아요.

인생, 쉬운 것만은 아니네..

익명 사용자의 이미지

32비트 CPU라고 불리는 이유가 바로 한번에 처리할 수 있는 데이터의 크기(이를 word라고 하는데, 요새는 word가 그냥 16비트의 크기를 지칭하는데 쓰이더군요)가 32비트이기 때문입니다.

미친눅대의 이미지

word의 크기는 computer architecture마다 다른 것으로 알고 있습니다. 32비트 시스템에서의 워드 크기는 otherwise specified되지 않은한 일반적으로 32비트라고 생각하시면 됩니다.

cjh의 이미지

사용하는 플랫폼에서 프로세스 공간의 주소를 나타낼 때 어떤 크기를 쓰는지에 따라 다릅니다. x86 계열의 보호 모드이면 32비트이고, 64비트 플랫폼이라면 64비트일 확률이 높겠죠.

http://en.wikipedia.org/wiki/Pointer

--
익스펙토 페트로눔

익명 사용자의 이미지

포인터는 메모리 주소를 담는 변수입니다.

현재 가장 일반적으로 쓰이는 인텔 플랫폼(IA32, x86 등으로 불리우는)의 메모리 주소 크기가 32bit 입니다.

그래서 포인터 크기가 32bit 가 되는 것입니다.

포인터 크기는 아키텍쳐의 메모리 모델에 따라 결정됩니다.

thyoo의 이미지

옛날 옛날 한옛날 인텔 8086이 IBM PC의 uP로 채택이 됐을 때 얘기.

XT 8086의 Address Pin(버스 비트 크기)수가 16핀이었지요.
그시절엔 메모리가 64K-Byte면 뒤집어 쓰는 줄 알았으니까요.
(XT의 포인터 싸이즈: 16비트)

메모리 64K는 비좁았습니다.
그래서 어드레쓰를 20핀으로 만든 80286이 등장합니다.
1M-Byte까지 액세스 가능하게 됐습니다.
헌데 문제는 286이라는 녀석이 16비트 레지스터를 갖고 있는 놈이라.
20비트 어드레스를 포인팅하기가 곤란했단 말씀입니다.
여기에서 두통을 유발하는 어드레씽 모드가 나오고 세그먼트가 나오고
Near, Far...
(AT 286에서 포이터 싸이즈: Segment Pointer(16) << 4 + NearPointer(16) == 20)

32비트 386시대가 도래하여 286시절의 투통이 해소됩니다.
(IA32 프로텍티드 모드에서: 32)

___________________________________
Less is More (Robert Browning)

drinkme의 이미지

XT에 사용된 8086/8088의 address line은 20pin입니다.
물리적으로 가능한 memory는 1mbyte입니다.
그래서, s/w를 작성할 때에 memory model을 고려해야 했었습니다.
(tiny, small, medium, huge 등의 model이 있었답니다.)
long pointer냐 아니냐.
즉, pointer type이, 2byte짜리가 있고, 4byte짜리가 있었죠.
지금 생각해 보면, 참으로 짜증나는 얘기입니다만.

AT에 사용된 80286은 address line이 24pin입니다.
물리적으로 16MByte가 접근 가능하지만,
real mode에서는 8086과 유사하게 동작합니다. 1Mbyte+alpha의 영역을 접근가능하죠.

moonzoo의 이미지

thyoo wrote:
메모리 64K는 비좁았습니다.

비좁았습니다. 이거 맞춤법 맞는 건가여?

"비좁았습니다"를 한글자 한글자 뚫어져라 쳐다보고 있노라면--;

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

근데 논리적으로 따져보면 맞는 말 같긴한데..

웬지 어색함을 지울수가 없네요..

ashuaria의 이미지

제 기억이 맞다면, 20비트 어드레스는 XT(8088)로 기억합니다. AT(80286)은 16메가(24비트)로 알고 있습니다.

이야기하자면 CPU에 따라 틀리긴하지만, CPU가 다루는 레지스터의 크기 때문입니다. 64비트 CPU는 64비트 연산을 할수 있기 때문만은 아니겠지요. 주소를 담을수 있는 레지스터의 크기가 64비트면 포인터가 64비트가 되고 32비트면 포인터가 32비트가 되겠죠.
옛날 8088,80286같은 놈들은 레지스터 크기가 16비트(16비트 CPU라고 불렀었죠)였으나 물리적인 어드레스핀이 20,24개 였기 때문에 꽁수를 쓰게된것입니다. 16비트 레지스터를 2개 쓴거죠 ^^;. 당근 두개의 16비트 포인터를 써야ㅤㄷㅚㅆ죠.

<FONT face="Times New Roman" size=4>שלום צליכם מאת ארוננו ישוצ המשיח</FONT>

thyoo의 이미지

ashuaria wrote:
제 기억이 맞다면, 20비트 어드레스는 XT(8088)로 기억합니다. AT(80286)은 16메가(24비트)로 알고 있습니다.

8086 다뤄본지가 너무 오래돼서 부정확한 글을 썼군요. ^^
8088도 그림을 보니 20핀이군요.

찾아보니 죄다 밀려썼습니다.
정리하겠습니다.

8085 : (8비트) 16p
8088/8086 : 20p
80286: 24p
80386/486/pentium: 32p
pentium-pro: 36p

참고 싸이트
http://www.x86.org/articles/computalk/help.htm

___________________________________
Less is More (Robert Browning)

partout의 이미지

moonzoo wrote:

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

'웬지' 가 아니라 '왠지' 아닌가요?
헤깔리네..

어찌나 졸린지..~~

미친눅대의 이미지

부사 왜인지의 준말이므로 왠지가 맞습니다.

헤깔리다 (x) -> 헛갈리다/헷갈리다

moonzoo의 이미지

partout wrote:
moonzoo wrote:

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

'웬지' 가 아니라 '왠지' 아닌가요?
헤깔리네..

맞습니당--;

익명 사용자의 이미지

pointer가 32 bit인 이유는 32-bit machine의 address space가 2^32이기 때문임. address space는 왜 2^32냐? bus가 32 bit이기 때문임.

죠커의 이미지

포인터의 크기가 현재 플랫폼의 어드레스와 같다는 것은 거짓일 수도 있습니다.

워드단위로만 접근을 할 수 있는 시스템이라면 3번째 워드의 1번째 바이트의 의미를 담는 형태로 포인트가 구성되어 있을 수도 있고 그 경우에는 그것은 거짓이 됩니다. 그리고 그 경우엔 자료형에 따라서 포인터의 크기도 달라집니다.

codepage의 이미지

좀 구체적인 설명이 필요하지 않을까요?
포인터 변수는 메모리의 주소 값을 담고 잇는 변수를 의미하는데요.
그래서 32비트 CPU일 경우에는 최대 2^32 크기의 메모리를 가질 수 있고
그 번지를 변수에 담을려니 (0번지부터 2^32 - 1번지까지) 32비트의 메모리 공간이 필요한 것으로 알고 있는데요?
주소를 나타내는 값에 '3번째 워드의 1번째 바이트의 의미'를 담는 다는 말이 같은 우리나라 말인데도 전혀 이해가 되지 않는군요.

상세한 설명을 해주심이...

죠커의 이미지

포인터는 메모리 주소의 값을 의미하지는 않습니다. 이 쓰레드를 읽어보시면 더 자세히 알게되실 겁니다.

3번째 워드의 첫번째 바이트 식으로 쓰이는 하드웨어는 워드 단위의 접근만 허용하는 하드웨어입니다. 워드는 대체로 바이트 단위보다 크니 워드를 쪼개어서 쓰게되고 이럴 경우 char형 포인터는 어느 워드를 쪼개어서 쓴 것인지 체크하도록 설계됩니다.

익명 사용자의 이미지

자료형이 어떤게 나오던 포인터의 크기는 달라지지 않습니다.

세벌의 이미지

partout wrote:
moonzoo wrote:

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

'웬지' 가 아니라 '왠지' 아닌가요?
헤깔리네..

헤깔리네가 아니고 헷갈리네가 맞겠죠?

그런데 이러다가 매 맞겠네요.주제와 관계없는 글 올린다고...

partout의 이미지

sebul wrote:

partout wrote:

moonzoo wrote:

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

'웬지' 가 아니라 '왠지' 아닌가요?
헤깔리네..

헤깔리네가 아니고 헷갈리네가 맞겠죠?

그런데 이러다가 매 맞겠六?주제와 관계없는 글 올린다고...

ㅎㅎ.. 그러네요..
그나저나 ... 매 맞을 일이긴 한데.. 이것도 나름대로 재미있네요.

어찌나 졸린지..~~

swirlpotato의 이미지

x86 기준으로 하나의 세그먼트는 최대 크기 4gb를 가질 수 있게 되어있습니다. (디스크립터에서 최대 limit을 적을 수 있는 양이 4gb(20비트 * 단위4k) 이기에 4gb를 지원합니다.)

이걸 표현하려면 32비트가 필요하죠 2^32

그래서 32비트입니다.

@_@홍홍홍..

익명 사용자의 이미지

* 386~ MMU(Memory Management Units)
인텔이 386만들고, 가장 자랑한 기술중 하나가 MMU를 내장한것입니다.
하드웨어 수준의 프로텍션 및 가상메모리 기법입니다.

* 메모리 관리 모드는 2가지가 있는데(운영체제 로딩시점에 프로그램으로 세팅하지요)
1) Flat memory model
- 하나의 세그먼트만 가지는 메모리 모델
- 한 세그먼트의 최대 크기는 4GB(2^32-1)까지 가능
2) Segmented Model
- 최대 16,383 세그먼트가 가능 (16k*4G=> 64 Tera Byte까지 가능;386일때 이미......)

* 인텔 프로세서를 채택한 운영체제는 하부구조로, 플랫 메모리 모델을 사용했습니다.예를 들어, NT, OS/2 및 Linux, 또는 X가 만든 운영체제 XX등 입니다.
이유는 세그먼트 모델보다, 단순하기 때문이기도 하고,( 프로그램짜기 쉬우니까.)
초기 GNU 개발도구(GCC등)이 기초 모델로 했던, 680x0 프로세서의 메모리 모델과도 유사했기 때문입니다.
그리고, 그 당시라면, 4기가메모리는 꿈의 메모리이기도 했습니다.(너무 크다는..)

* 포인터가 4바이트인 이유
대체로, 운영체제의 표준 워드크기를 씁니다.
운영체제 워드? 운영체제를 만들때, 하부 CPU가 최소 얼마(n-bits)라는 것을 보통 가정합니다. 운영체제 설계가 가정한 하부구조(하드웨어)가 맞지 않으면, 하드웨어 추상화를 통해 달성합니다.(당연히, 최적의 하드웨어가 가장 빠르지요. 나머지는 에뮬레이션하려니 느려지고, ...그래도, 돕니다....)
리눅스를 Sun이나 HP등의 머신으로 포팅한 멋진 사람들의 기고를 참고하시길.
* 표준 유닉스는 32비트 머신을 기반으로 설계되었습니다.
* 리눅스, NT, OS/2도 마찬가지로, 하부 CPU가 인텔프로세서인 경우, 하부 메모리구조는 플랫 모델썼고, 최대 메모리는 4GB였습니다.

* 다 과거형으로 쓴것은 지금도 마찬가지겠지만, 워낙 혁신적인 리눅스라, 지금 어떤지 몰라서 입니다.( 제생각에, 플랫메모리 + 알파를 쓸듯합니다., 세그먼트 모델로 하면 포터빌리티 마구 떨어질테구, 속도 마구 느려질테구, 필요한가?.....)

* 여담으로 64비트 프로세서 써도 별로 안빨라지는 패키지들이 있는데, 그 이유들중 하나는 64비트 프로세서에 32비트 프로세서 에뮬레이션모드가 동작해서 돌릴때가 있었습니다.

ㅡ,.ㅡ;;의 이미지

taeyeung wrote:
32비트 운영체제에서 포인터는 4바이트로 알고 있고 당연하다고

생각하고 사용을 해 왔는데 어느날 아는 후배가 왜 포인터의 크가가

4바이트이냐고 물어 보니 이유를 답변하기가 애매해졌습니다.

제가 아는 이유는 CPU의 버스가 32비트로 처리되기 때문이라고 알고

있는데 다른 이유가 있는 건가요?

흠.. 32 비트 (운영체) / 8비트(1바이트) = 4바이트(주소체계)
32비트주소체계로 운영되는 시스템 => 32비트 운영체 => 32bit OS
32비트가 4바이트랑 같은말인데 왜그러냐는건...
비트와 바이트의 관계를 알려주세요..


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

cinsk의 이미지

대부분 시스템에서 포인터의 타입에 상관없이 포인터의 크기가 CPU의 address space를 전부 access 할 수 있는 크기로 고정되어 있지만, 반드시 그렇다고 보장할 수 없습니다. offset 값만을 가지고 좁은 구역에서 access할 수 있는 포인터가 존재할 수 있기 때문에..

따라서 N bit machine에서 pointer의 크기는 N bit이다라고 말하는 것은 조금 성급한 정의가 아닌가 합니다.

또한 type에 상관없이 모든 종류의 pointer가 같은 크기를 가진다라고 말할 수도 없습니다.

김일영의 이미지

마침 더 잘 설명해 주셨네요. 역시 고수는 다르시군여~

포인터는 포인터일뿐 크기라든지 등등은 아무런 정해진 바가 없으므로
억지로 어떤 특징을 가정하려는 것은 피해야 할 것 같다는 생각입니다.

litdream의 이미지

moonzoo wrote:
thyoo wrote:
메모리 64K는 비좁았습니다.

비좁았습니다. 이거 맞춤법 맞는 건가여?

"비좁았습니다"를 한글자 한글자 뚫어져라 쳐다보고 있노라면--;

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

근데 논리적으로 따져보면 맞는 말 같긴한데..

웬지 어색함을 지울수가 없네요..

'비좁다' 는 표준말인가요, 아니면 사투리인가요?
만약 사투리라면 '비좁다' 의 표준말은 뭐죠?
지금 '비좁았습니다.' 를 다른말로 바꿔보려고 해도, 도통 다른 단어가
떠오르지 않습니다.. 머리가 굳어가는 느낌...

삽질의 대마왕...

익명 사용자의 이미지

litdream wrote:
moonzoo wrote:
thyoo wrote:
메모리 64K는 비좁았습니다.

비좁았습니다. 이거 맞춤법 맞는 건가여?

"비좁았습니다"를 한글자 한글자 뚫어져라 쳐다보고 있노라면--;

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

근데 논리적으로 따져보면 맞는 말 같긴한데..

웬지 어색함을 지울수가 없네요..

'비좁다' 는 표준말인가요, 아니면 사투리인가요?
만약 사투리라면 '비좁다' 의 표준말은 뭐죠?
지금 '비좁았습니다.' 를 다른말로 바꿔보려고 해도, 도통 다른 단어가
떠오르지 않습니다.. 머리가 굳어가는 느낌...

Quote:
......중략 .....
저도 웹을 검색해 보기 전까지는 '비싸다' 의 '비'는 한자어 '아닐 비(非)'자 인줄
알았습니다. 그런데 '아니다'라는 뜻으로 쓰이는 접두사 '비'는 주로 한자어 앞에
붙는다고 했으니 '싸다'는 순 우리말로서, '비싸다'의 '비'는 '아니다'의 뜻을 나타내는
접두사 '非' 가 아님을 알수 있습니다. 같은 맥락으로 '비웃다'의 '비'도, '비좁다'의
'비'도 모두 아니다 라는 뜻인 한자어 접두사인 '非'는 아니라는 뜻이겠죠. '비웃다'나
'비좁다' 나 각각 분해할 수 없는 고유한 뜻을 가진 한 단어인 셈 입니다
......중략 .....
좁다 라는 말은 웃다 라는 말보다는 좀 더 쉽습니다.
좁다는 넓이를 나타내는 개념으로서 폭이나 공간이 '적은'의 뜻이 있으니 반대말로는 당연히
'넓다' 라는 말이 쉽게 떠 오르니까요.
......중략 .....

참고 : http://kdaq.empas.com/dbdic/db_view.tsp?num=4166927&ps=src
음 국어 공부하게 하는군요. :evil:
익명 사용자의 이미지

국어사전에서...

Quote:
비좁다

비-좁다 [비ː―따] <형용사> 여럿이 촘촘히 들어 있어 빈 자리가 몹시 적다. ¶원래 통로가 좁은 시장 골목이 장을 보러 나온 주부들로 더욱 비좁았다. <작은말> 배좁다.

음 ,.... 배좁다......! 쿵~~! :roll:

ㅡ,.ㅡ;;의 이미지

cinsk wrote:
대부분 시스템에서 포인터의 타입에 상관없이 포인터의 크기가 CPU의 address space를 전부 access 할 수 있는 크기로 고정되어 있지만, 반드시 그렇다고 보장할 수 없습니다. offset 값만을 가지고 좁은 구역에서 access할 수 있는 포인터가 존재할 수 있기 때문에..

따라서 N bit machine에서 pointer의 크기는 N bit이다라고 말하는 것은 조금 성급한 정의가 아닌가 합니다.

또한 type에 상관없이 모든 종류의 pointer가 같은 크기를 가진다라고 말할 수도 없습니다.


만일 그런이유라면 첨부터 N bit 머신 이라고 이름붙인 자체가 잘못이죠.. 그리고 Nbit 머신이 Nbit주소인 통상적인 이유를 말하겠죠 그렇지않다면 아래와같은경우도 생기겠죠.
A:나는집으로 달려갔다
B:당신은 그렇게 말할수 없다 왜냐면 골목모퉁이를 돌때 완전히 달렸다고 할수 없기때문이다.
A: ㅡ,.ㅡ;;쿵..


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

xster의 이미지

moonzoo wrote:
thyoo wrote:
메모리 64K는 비좁았습니다.

비좁았습니다. 이거 맞춤법 맞는 건가여?

"비좁았습니다"를 한글자 한글자 뚫어져라 쳐다보고 있노라면--;

웬지 철자가 어색한 단어같은 느낌이 드는건 저 뿐인가요?

근데 논리적으로 따져보면 맞는 말 같긴한데..

웬지 어색함을 지울수가 없네요..


가끔 그런 일이 있더군요.
내가 쓴 말이고 딴사람은 아무렇지도 않게 생각하는데 종종 무슨 말을 써놓은 건지 잘 이해도 안 가고
뭔가 어색한 느낌이 드는 경우가 있더군요.
길을 걷다가 갑자기 어질하는 경우와 비슷한 걸까요?
둘 다 뇌의 기능인데 하나는 균형감각이 잠깐 맛이 가는 경우고
하나는 언어 감각이 잠깐 맛이 가는 경우고, 그렇게 생각하고 있습니다.

전 그런 느낌이 들 때마다 마치 딴 세상에 혼자들어간 듯 기분이 좋더군요.

훗. 변태

익명 사용자의 이미지

xster wrote:

...
전 그런 느낌이 들 때마다 마치 딴 세상에 혼자들어간 듯 기분이 좋더군요.
...

혼자가면, 외롭지 않나요? :twisted:

cinsk의 이미지

ㅡ,.ㅡ;; wrote:
cinsk wrote:
대부분 시스템에서 포인터의 타입에 상관없이 포인터의 크기가 CPU의 address space를 전부 access 할 수 있는 크기로 고정되어 있지만, 반드시 그렇다고 보장할 수 없습니다. offset 값만을 가지고 좁은 구역에서 access할 수 있는 포인터가 존재할 수 있기 때문에..

따라서 N bit machine에서 pointer의 크기는 N bit이다라고 말하는 것은 조금 성급한 정의가 아닌가 합니다.

또한 type에 상관없이 모든 종류의 pointer가 같은 크기를 가진다라고 말할 수도 없습니다.


만일 그런이유라면 첨부터 N bit 머신 이라고 이름붙인 자체가 잘못이죠.. 그리고 Nbit 머신이 Nbit주소인 통상적인 이유를 말하겠죠 그렇지않다면 아래와같은경우도 생기겠죠.
A:나는집으로 달려갔다
B:당신은 그렇게 말할수 없다 왜냐면 골목모퉁이를 돌때 완전히 달렸다고 할수 없기때문이다.
A: ㅡ,.ㅡ;;쿵..

제가 말한 것은 포인터의 크기가 타입이나 N-bit machine에 따라 항상 고정되어 있다고 보장할 수 없다는 것입니다.

즉, sizeof(void *) == sizeof(float *) == sizeof(int *) 등과 같은 관계가 보장되어 있지 않는다는 것을 말하고 싶었습니다. 제가 잘못 알고 있는 것인가요?
또한 32bit 머신, 정확히 말해 int가 32bit인 컴파일러에서 반드시 pointer가 32-bit라고 가정할 수 없다는 것을 말하고 싶었습니다.

doldori의 이미지

cinsk wrote:

제가 말한 것은 포인터의 크기가 타입이나 N-bit machine에 따라 항상 고정되어 있다고 보장할 수 없다는 것입니다.

즉, sizeof(void *) == sizeof(float *) == sizeof(int *) 등과 같은 관계가 보장되어 있지 않는다는 것을 말하고 싶었습니다. 제가 잘못 알고 있는 것인가요?
또한 32bit 머신, 정확히 말해 int가 32bit인 컴파일러에서 반드시 pointer가 32-bit라고 가정할 수 없다는 것을 말하고 싶었습니다.


적어도 C나 C++에 한해서라면 cinsk님이 알고 계신 것이 맞습니다.
이것 말고도 함부로 가정해서는 안될 것이 많이 있습니다.
atie의 이미지

sizeof(int*) vs sizeof(int)
http://www.clanghelp.com/sizeofint_vs_sizeofint-7418256-5298-a.html

IBM AS400 (64bit machine) sizeof(size_t) == 4, sizeof(int*) == 16
메모리와 디스크를 하나의 가상 메모리로 잡아야 하기 때문에 포인터의 크기가 무척 크지요.

----
I paint objects as I think them, not as I see them.
atie's minipage

익명 사용자의 이미지

cinsk wrote:

...
즉, sizeof(void *) == sizeof(float *) == sizeof(int *) 등과 같은 관계가 보장되어 있지 않는다
...

이것은 보장되어야 한다고 생각하는데요?

doldori의 이미지

Anonymous wrote:
cinsk wrote:

...
즉, sizeof(void *) == sizeof(float *) == sizeof(int *) 등과 같은 관계가 보장되어 있지 않는다
...

이것은 보장되어야 한다고 생각하는데요?


보장되는 것은 sizeof(void*) == sizeof(char*) == sizeof(signed char*) == sizeof(unsigned char*) 뿐입니다.
K&R 시절에는 char*가 void* 역할을 했는데 이것이 표준에도 반영됐기 때문인 것으로 알고 있습니다.
ㅡ,.ㅡ;;의 이미지

cinsk wrote:
즉, sizeof(void *) == sizeof(float *) == sizeof(int *) 등과 같은 관계가 보장되어 있지 않는다는 것을 말하고 싶었습니다. 제가 잘못 알고 있는 것인가요?

그렇지 않은경우가 있다면 그것은 일반적인 void *형태의 크기보다 특수하게 작게 사용하려는 목적이나 일반적인 번지의 크기는
sizeof(void *) 로 봐야할것아닌가요?
아이: 바지는왜 가랭이가 두개야?
엄마: 그건사람다리가 두개기때문이지..
지나가던사람 : 다리한개인사람도 있죠.. 그렇게 말하면안되죠.
라는거나 비유가 되지 않나요..

Quote:

IBM AS400 (64bit machine) sizeof(size_t) == 4, sizeof(int*) == 16

일단 이예기는 좀다른예기구요. size_t는 int나 포인터크기와는 다르죠.


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

죠커의 이미지

ㅡ,.ㅡ;; wrote:
그렇지 않은경우가 있다면 그것은 일반적인 void *형태의 크기보다 특수하게 작게 사용하려는 목적이나 일반적인 번지의 크기는
sizeof(void *) 로 봐야할것아닌가요

여러 머신에서 메모리의 한 위치를 자연스럽게 가리키기 위해서 표준에 그렇게 정의되어 있습니다.

int의 형의 크기가 32비트로 정해져 있는게 아니라 short <= int <= long 으로 되어 있는 것 처럼 그 머신에 맞는 형태로 자연스럽게 구현하도록 되어있습니다.

오히려 PC라는 환경에 C언어를 종속시킬려고 하는 것이 문제가 아닐까요?

ㅡ,.ㅡ;; wrote:
일단 이예기는 좀다른예기구요. size_t는 int나 포인터크기와는 다르죠.

typedef int size_t 되어 있는 구현도 많습니다. size_t도 다른 자료형을 통해서 구현됩니다.

doldori의 이미지

맞는 말씀입니다만

CN wrote:

typedef int size_t 되어 있는 구현도 많습니다.

이런 구현이 있다면 표준을 따르는 구현은 아닙니다.
size_t는 반드시 무부호 정수형이어야 합니다.
musiphil의 이미지

Anonymous wrote:
cinsk wrote:

...
즉, sizeof(void *) == sizeof(float *) == sizeof(int *) 등과 같은 관계가 보장되어 있지 않는다
...

이것은 보장되어야 한다고 생각하는데요?

꼭 그럴 필요는 없지 않겠습니까?

비유를 하자면, 호텔의 방을 하나 지정하기 위해서는 4자리수가 필요하다 하더라도, 층을 하나 지정하기 위해서는 2자리수만 있어도 되는 것과 같다고 할까요. 데이터형 자체가 커지면 그만큼 그 형의 개체가 놓일 수 있는 위치의 가짓수가 적어지기 때문에, 크기가 작은 포인터를 쓰는 것이 가능합니다. (하려면 할 수 있다는 얘기입니다. 꼭 바람직하다기보다는.)

musiphil의 이미지

ㅡ,.ㅡ;; wrote:
32비트가 4바이트랑 같은말인데 왜그러냐는건...
비트와 바이트의 관계를 알려주세요..

이건 그냥 사족입니다만, 1바이트가 늘 8비트인 것은 아닙니다. 1바이트가 9비트인 시스템도 존재하고, 실제로 1바이트가 16비트여서 sizeof(char)==sizeof(int)==1, sizeof(long)==2인 DSP 칩에서 프로그래밍도 해 봤습니다. :D

따라서 "32비트가 4바이트와 같은 말이다"라는 표현은 조심해서 사용해야 할 것 같네요. (그래서 어떤 분야에서는 아예 바이트라는 말 대신 옥텟(octet; 정의상 8비트)이라는 용어를 쓰기도 하죠.)

김일영의 이미지

윗글과 별 상관 없는 이야깁니다만
1바이트가 9비트인 시스템에서도 sizeof(char) == 1 입니다.
하지만 다른 타입의 크기는 정해져 있지 않습니다.

포인터도 대략 마찬가지로 생각하면 될 것 같습니다.
우리집 주소랑 옆집 주소가 길이가 같아야 하는건 아니듯;;;

익명 사용자의 이미지

musiphil wrote:

...
꼭 그럴 필요는 없지 않겠습니까?
...

저는 생각이 다릅니다.

1. 함수포인터를 고려해보면
- 정수형 함수포인터 : 4바이트라고 가정
- 실수형 함수포인터 : 2바이트라고 가정
- TEXT영역(Code)의 액세스가 난해하겠습니다.
?
2. 가정 32비트 어드레스 공간에서...
가정
- int 16비트 포인터
- char 8비트 포인터
주소공간을 액세스(포인터사용시마다)할때마다, 절대번지, 상대번지등을 고민하면서 코딩해야겠군요.
filling algorithm같은(구한말얘기지만) 그래픽스 프리미티브 제작시 고민이 좀 되겠군요.
3. C 프로그래머의 실수가 더 많아질것 같고요.
- 도스시절에 하던 메모리 모델(tiny,small, ~, huge) 및 near, far modifier도 필요할테고 같은 구문이 필요하게 될것 같군요.
- 프로그래머들은 이 문제를 다시 돌이켜봐야할테고,
- 아울러, 컴파일러도 손좀봐야겠고),....
4. 포터빌리티가 떨어질것 같다는...
5. 컴파일러, 링커, 로더 제작자가 고민이 많아지겠네요.

익명 사용자의 이미지

2바이트가 부족해서 4바이트를 쓴거고..
4바이트는 어느정도 충분하니까.. 오래쓰고 있는게 아닐까요?
앞으로 곧 8바이트로 늘어나지 않겠어요?

jongwooh의 이미지

일반적으로 포인터의 크기는 '프로그램 카운터(PC)' 또는 '인스트럭션 포인터(IP)' 이라고 부르는 레지스터 크기와 같습니다. address 가능한 메모리 크기와 같다는 것이죠.

8비트 프로세서들의 경우에 프로그램 카운터를 8비트로 두기엔 너무 프로그램이 들어갈 공간이 작으니까(256바이트로 프로그램을 짜라고..) 대부분 16비트 카운터를 가지고 있고 그래서 8비트 프로세서들도 포인터는 16비트(2바이트) 인 경우가 대부분입니다.

그리고 아시다시피 대부분의 32비트 RISC,CISC 프로세서들도 처음엔 32비트 프로그램 카운터를 사용했다가 몇년 전부터 64비트로 확장되면서 카운터도 자연스럽게 64비트 레지스터를 쓰게끔 되었습니다. 하지만 포인터마다 64비트를 지정하는건 너무 낭비이기 때문에 64비트 머신들도 32비트 포인터를 쓰는 경우가 종종 있습니다. 어드레싱을 32비트로 해도 대부분의 프로그램에서 충분하기 때문에..

you must know the power of dark side.

죠커의 이미지

Anonymous wrote:
musiphil wrote:

...
꼭 그럴 필요는 없지 않겠습니까?
...

저는 생각이 다릅니다.

1. 함수포인터를 고려해보면
- 정수형 함수포인터 : 4바이트라고 가정
- 실수형 함수포인터 : 2바이트라고 가정
- TEXT영역(Code)의 액세스가 난해하겠습니다.
?
2. 가정 32비트 어드레스 공간에서...
가정
- int 16비트 포인터
- char 8비트 포인터
주소공간을 액세스(포인터사용시마다)할때마다, 절대번지, 상대번지등을 고민하면서 코딩해야겠군요.
filling algorithm같은(구한말얘기지만) 그래픽스 프리미티브 제작시 고민이 좀 되겠군요.
3. C 프로그래머의 실수가 더 많아질것 같고요.
- 도스시절에 하던 메모리 모델(tiny,small, ~, huge) 및 near, far modifier도 필요할테고 같은 구문이 필요하게 될것 같군요.
- 프로그래머들은 이 문제를 다시 돌이켜봐야할테고,
- 아울러, 컴파일러도 손좀봐야겠고),....
4. 포터빌리티가 떨어질것 같다는...
5. 컴파일러, 링커, 로더 제작자가 고민이 많아지겠네요.

포인터의 크기가 동일하지 않기 때문에 컴파일러, 링커, 로더 개발자가 편해질 것입니다. word단위의 머신에서 char를 word단위즤 자료형과 같은 방법으로 지정할려면 word단위의 자료형의 지정이 비효율적일 적이고 자연스럽지 않을 것입니다.

말씀하신 이식성에 대한 부분은 포인터에 적합하지 않은 자료를 가리킬려고 하는 행위자체가 잘못된 프로그램 습관이라고 생각합니다. 적합한 포인터 사용과 generic pointer(void *)의 범위에 벗어나는 트릭은 피하는 편이 옳다고 생각합니다.

swirlpotato의 이미지

musiphil wrote:
ㅡ,.ㅡ;; wrote:
32비트가 4바이트랑 같은말인데 왜그러냐는건...
비트와 바이트의 관계를 알려주세요..

이건 그냥 사족입니다만, 1바이트가 늘 8비트인 것은 아닙니다. 1바이트가 9비트인 시스템도 존재하고, 실제로 1바이트가 16비트여서 sizeof(char)==sizeof(int)==1, sizeof(long)==2인 DSP 칩에서 프로그래밍도 해 봤습니다. :D

따라서 "32비트가 4바이트와 같은 말이다"라는 표현은 조심해서 사용해야 할 것 같네요. (그래서 어떤 분야에서는 아예 바이트라는 말 대신 옥텟(octet; 정의상 8비트)이라는 용어를 쓰기도 하죠.)

그럼 정확한 바이트의 정의는 뭘까요? -_-;;
네이버 백과사전 기준으로 8비트가 1바이트라고 정의되어있습니다만..
http://100.naver.com/100.php?id=717109

nohmad의 이미지

http://en.wikipedia.org/wiki/Byte

wikipedia wrote:
A contiguous sequence of a fixed number of bits. On modern computers, an eight-bit byte or octet is by far the most common. This was not always the case. Certain older models have used six-, seven-, or nine-bit bytes - for instance on the 36-bit architecture of the PDP-10. Another example of a non eight-bit sequence is the 12-bit slab of the NCR-315. A byte is always atomic on the system, meaning that it is the smallest addressable unit. An eight-bit byte can hold 256 possible values (28 = 256) -- enough to store an unsigned integer ranging from 0 to 255, a signed integer from -128 to 127, or a character of a seven-bit (such as ASCII) or eight-bit character encoding.

네이버 사전(두산세계대백과)은 특정분야의 전문가들이 참고로 사용하기에는 지나치게 내용이 빈약합니다.

cppig1995의 이미지

1바이트가 8비트가 아닐 수도 있습니다.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

죠커의 이미지

K&R 첫번째 판에도 1byte가 9bit인 머신을 소개하고 있습니다.

cinsk의 이미지

1 byte는 CHAR_BIT만큼 bit를 가집니다.

doldori의 이미지

또는 std::numeric_limits<unsigned char>::digits 만큼의 bit수를 갖습니다. :)

ㅡ,.ㅡ;;의 이미지

32비트OS 라면 8비트가 1바이트겠죠..


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

nohmad의 이미지

ㅡ,.ㅡ;; wrote:
32비트OS 라면 8비트가 1바이트겠죠..

아니라고 그렇게 얘기하는데도 기운 빠지는 얘기를 하시는군요.

덧말: 포인터가 32비트냐에서 1바이트가 8비트냐로 공이 넘어갔군요.

ㅡ,.ㅡ;;의 이미지

nohmad wrote:
ㅡ,.ㅡ;; wrote:
32비트OS 라면 8비트가 1바이트겠죠..

아니라고 그렇게 얘기하는데도 기운 빠지는 얘기를 하시는군요.

덧말: 포인터가 32비트냐에서 1바이트가 8비트냐로 공이 넘어갔군요.

제가 사오정인가보죠..ㅡ,.ㅡ;;
근데 아직도 모르겠는걸요.. 32비트OS 중에 8비트가 1바이트가 아닌 OS가 어떤게 있죠?

애초 이쓰레드의 질문은
"32비트 운영체제에서 포인터는 4바이트로 알고 있고 당연하다고 ..."
였습니다. 전 공을 어디로 넘긴게 아니라 계속 "32비트 운영체제 하에서.." 의 토론이라고 생각하고 있었는데요..


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

mancord의 이미지

4바이트 인 이유는 메모리를 가르킬려면 그정도 범위의 값이 필요 함으로,,

extrealm의 이미지

포인터 크기는 CPU의 인덱스 레지스터의 영향을 받습니다.
전적으로 CPU의 레지스터 조건에서 최대성능을 이끌어내는 (최소한의 기계어 코드로 구성되는) 크기로 설정됨이 타당합니다

다음과 같은 C코드와 어셈블리 인스트럭션이 있다면,

int* ptr = 0xFFFF;
int var = *ptr;

LD  IX, #FFFFh
LD  A, (IX)

만약 IX라는 인덱스레지스터의 크기가 16비트 크기라면 이 CPU 기반의 머신에서는 sizeof(int*) == 2 일때 최적의 성능을 발휘합니다.
비슷한 맥락에서 프로그램의 실행위치를 기억하는 프로그램 카운터(PC)의 비트폭에 따라 함수 포인터의 크기가 결정되겠습니다.

다만, OS(플랫폼)수준의 가상메모리 에뮬레이션이 지원되거나, 아키텍쳐의 단순화를 도모하거나, 보편적인 컴파일러와의 호환성 향상을 위해 (성능저하에도 불구하고) sizeof(int*) = 4 인 모드를 컴파일러가 지원할 수도 있겠네요.

사족 : 결국 프로그램은 인간이 원하는 동작을 하기 위한 절차의 기술에 지나지 않음을 재확인 합니다. 코드크기가 작다고 효율적이라 단정할 수 없으며, 실행이 빠르다고 효율적이라 단정할 수 없으며, 프로그래밍 모델이 심플하다고 효율적이라 단정할 수 없으니, 이는 모두가 쓰는 사람의 목적에 준한다는... (ㅡ,.ㅡ)

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

ashuaria의 이미지

저도 한마디만 할께요.

pointer는 메모리 주소의 번지를 담는것입니다. 따라서 그 CPU, architecture가 사용하는(다루는) PC(Program Counter)와 같은(혹은 그와 비슷한) 레지스터의 크기에 영향을 받습니다. AMD64의 경우는 64bit mode에서 그 레지스터가 64비트를 쓰기 때문에 64비트 모드에서 포인터의 크기가 64비트가 되는것 뿐입니다.

여러분들이 헷갈리는것이 있는데, 버스의 크기(혹은 bandwidth)라고 하는것을 말씀하실때는 확실히 구분 하셔서 이야기를 하셔야됩니다.
I/O bus의 경우 이미 pentium시절때 부터 64bit의 크기로 가고 있습니다.
I/O bus의 그 비트수는 단순히 데이터를 전송 할수 있는 능력을 높이기 위한 것 뿐이라고 생각을 하시면 됩니다. 즉 IO bus bandwidth= bus size 64bit * 100Mhz = 800MB/sec(물론 peak치 일뿐입니다.) 라는것을 도출할때 쓰이는 버스입니다.
요즘 많이들 쓰시는 듀얼 체널을 보면 메모리 bus는 64bit 메모리 모듈을 2개를 동시쓸수 있게 해서 128bit를 내는것입니다.

갑자기 삼천포로 빠졌네요. 음 MIPS의 R4400(기억이 가물)이라는 CPU가 있었습니다.
이놈은 GPR(General purpose register)는 128bit이였지만, PC는 64bit, ALU는 32bit였던것으로 기억합니다. 포인터는 64bit였지만 32bit 정수연산을 하는 특이한 CPU로 기억됩니다. (벡터 유닛은 128bit 연산을 했고요)
즉, CPU의 ALU와 GPR과 PC의 비트가 다 다를수도 있습니다.

결국 제가 생각 해볼때는 PC를 몇비트를 쓰는가가 포인터의 크기를 결정하게 되겠네요.

또 다른 사족이지만, 요즘 나오는 CPU들의 SSE와 같은 연산들은 128bit Vector Register들이 존재하고 128bit 연산도 가능하죠 ^^;
SIMD라서 메모리 bandwidth를 peak에 근접하게 사용 가능하죠.

만고 제 생각입니다.

<FONT face="Times New Roman" size=4>שלום צליכם מאת ארוננו ישוצ המשיח</FONT>

ashuaria의 이미지

오우 벌써 설명을 위에 하셨군요...^^;

<FONT face="Times New Roman" size=4>שלום צליכם מאת ארוננו ישוצ המשיח</FONT>

zeroty의 이미지

포인터는 말그대로 주소만을 담을 수 있는 그릇이에요-_-포인터가 32bit환경에서 4byte인 이유는 그 이상 필요가 없기때문이죠-_-현존하는 메모리가 아무리 크다하여도 2의 32승로 그 주소의 표현이 가능하기 때문이죠...다들 논점에서 벗어난 듯하네요-_-~

죠커의 이미지

zeroty wrote:
포인터는 말그대로 주소만을 담을 수 있는 그릇이에요-_-포인터가 32bit환경에서 4byte인 이유는 그 이상 필요가 없기때문이죠-_-현존하는 메모리가 아무리 크다하여도 2의 32승로 그 주소의 표현이 가능하기 때문이죠...다들 논점에서 벗어난 듯하네요-_-~

C/C++ 표준에서의 포인터는 선형 메모리 모델과 상관없습니다.

각자의 플랫폼에 적합한 방법으로 구현하는 것이 일상적입니다만 2의 32승의 주소로 표현은 부적합해 보입니다.

zeroty의 이미지

CN wrote:
zeroty wrote:
포인터는 말그대로 주소만을 담을 수 있는 그릇이에요-_-포인터가 32bit환경에서 4byte인 이유는 그 이상 필요가 없기때문이죠-_-현존하는 메모리가 아무리 크다하여도 2의 32승로 그 주소의 표현이 가능하기 때문이죠...다들 논점에서 벗어난 듯하네요-_-~

C/C++ 표준에서의 포인터는 선형 메모리 모델과 상관없습니다.

각자의 플랫폼에 적합한 방법으로 구현하는 것이 일상적입니다만 2의 32승의 주소로 표현은 부적합해 보입니다.

1byte는 8bit이며 4byte는 32bit이므로 포인터는 2의 32승만큼 표현이 가능하다. 2의 32승이면 20억이 넘으므로 포인터는 20억개의 위치를 저장할 수 있게 된다. 그러므로 현존하는 메모리가 크다고 하더라도 4byte만으로 충분히 모두 access가 가능하고 처리할 수 있게 된다. 더 자세한 사항은 유닉스 시스템 프로그래밍(2002년 한빛미디어 정재은)씨의 이메일 주소로 질문 해 보시길 바람

imarchie@hamail.net

죠커의 이미지

포인터는 선형 메모리 모델과 상관이 없기 때문에 2의 32승이니 모든 주소를 가르킬 수 있다는 접근이 부적당하다는 것입니다. 선형 메모리 모델을 벗어나지 않고서는 이해하시지 못합니다. 포인터에 대해 사람들이 말하는 것은 선형 메모리 모델이 아니라는 것입니다. 이 점을 이해하시지 못하고 계속 줄 세울 수 있다고 답변하시는 것이 아쉽습니다.

- CN의 낙서장 / HanIRC:#CN

cppig1995의 이미지

2^32는 대략 43억 정도니까 정재은씨가 INT_MAX(=2^31-1, 2147483647) 혹은 그냥 2^31이랑 혼란했을 가능성이 높군요.
벌써 해당 책의 신빙성이 없어지기 시작합니다.

덧붙이면 지금도 서버급, 아니 워크스테이션만 해도 메모리는 16GB 정도 들어가는데 그때라고 그다지 달랐을 것 같진 않군요.
아무래도 필자가 유닉스의 주요 용도를 잠시 잊어버리셨었나 봅니다.

게다가 저걸 또 메모리 용량이랑은 왜 연관시키나요?
Windows가 2GB, Linux가 3GB 대역에 커널 영역을 잡을 겁니다.
1GB인 제 데스크탑으로는 Linux는 커녕 Windows도 못 돌리겠군요. :)



(전략) 항복 권고를 받은 키탈저 태수 아지엣 사카라는 "항복? 먹는 거냐?"라는 짤막한 답장을 써보냈다. 베로시 토프탈은 행간에서 낄낄거림이 묻어나는 문체로 항복은 먹는 것이 아니라 자신의 미력함을 인정하고 상대에게 굴복하는 것이라는 상냥한 답을 보냈다. 그러자 아지엣 사카라는 "못 먹는 것이면 관심 없다."는 답장을 보냈다.
몽화 대사전 - http://cppig1995.n-pure.net/mh

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

lsj0713의 이미지

gamja9e wrote:
포인터가 4바이트인 이유는?

아래에서 설명하겠지만, 포인터는 '제맘대로의 크기를 가질 수 있습니다.'-_-; 그러나 대체로 해당 환경에서 가장 빨리 접근할 수 있는 크기(혹은 사용할 수 있는 메모리 공간 전체를 가리킬 수 있는 크기)가 선택이 됩니다. 그리고 우리가 흔히 사용하는 32비트 환경(x86 인텔기계)에서는 그 크기가 4바이트(정확히는 32비트)입니다. 그렇기에 포인터의 크기가 4바이트인 것입니다. 먼 옛날 8086, 80286 시절에는 포인터의 크기가 4바이트가 아니었지요.

gamja9e wrote:
그럼 정확한 바이트의 정의는 뭘까요? -_-;;

일단 C99에서는 byte를 다음과 같이 정의하고 있습니다.

Quote:

'실행 환경에서 사용하는 기본 character set' 안에 포함된 어떤 문자라도 표현할 수 있는 크기의, 접근할 수 있는 최소 저장 단위

이 정의를 이해하기 위해서는 C99에서는 character set을 source character set과 execution character set으로 나누고 그것들을 다시 basic character set과 extended character set으로 나누어 구분한다는 것을 알 필요가 있습니다.

여기서 source character set과 execution character set을 서로 구분하고 있다는 점이 상당히 재미있는데, 이것은 source code는 ASCII를 사용하고 컴파일 결과물은 EBCDIC로 내놓는 C 컴파일러도 가능하다는 얘기가 됩니다. 뻔한 얘기죠? ^^;; 소스 코드 작성 환경이 아니라 실행 환경을 기준으로 하는 것 또한 역시 뻔한 얘기죠.

참고로 몇가지 더 적자면 C에서는 무조건 sizeof(char) == 1이며, 무조건 CHAR_BIT >= 8 이어야 합니다.

pointer에 대해서는 특별히 따로 정의해 놓진 않았습니다만, pointer to void가 pointer to char와 같은 내부 표현을 가져야 한다는 점을 제외하면 그 내부 표현이나 크기에 대해서 특별한 제한 사항을 요구하고 있지 않습니다. 즉 가리키는 자료형에 따라서 각각의 포인터는 서로 다른 내부 표현과 크기를 가질 수 있다는 말입니다. 잘 지켜지진 않습니다만(사실 저도 습관이 안되서 잘 안 붙입니다-_-;), 사실 표준을 따르자면 printf문에 넘겨지는 포인터 주소값마다 (void *) 형변환 연산자를 붙이는 것이 맞습니다.

하지만 이것은 원론적인 얘기이고, 쉽게 접할 수 있는 환경이 아니므로 일반적으로 1byte=8bit로, 포인터의 크기=32bit로 생각하셔도 큰 문제 없겠습니다. 다만 아닌 환경도 있으며, 앞으로 그런 환경이 새로 나올 수도 있다는 걸 알아두는게 좋겠죠.

Prentice의 이미지

zeroty wrote:
CN wrote:
zeroty wrote:
포인터는 말그대로 주소만을 담을 수 있는 그릇이에요-_-포인터가 32bit환경에서 4byte인 이유는 그 이상 필요가 없기때문이죠-_-현존하는 메모리가 아무리 크다하여도 2의 32승로 그 주소의 표현이 가능하기 때문이죠...다들 논점에서 벗어난 듯하네요-_-~

C/C++ 표준에서의 포인터는 선형 메모리 모델과 상관없습니다.

각자의 플랫폼에 적합한 방법으로 구현하는 것이 일상적입니다만 2의 32승의 주소로 표현은 부적합해 보입니다.

1byte는 8bit이며 4byte는 32bit이므로 포인터는 2의 32승만큼 표현이 가능하다. 2의 32승이면 20억이 넘으므로 포인터는 20억개의 위치를 저장할 수 있게 된다. 그러므로 현존하는 메모리가 크다고 하더라도 4byte만으로 충분히 모두 access가 가능하고 처리할 수 있게 된다. 더 자세한 사항은 유닉스 시스템 프로그래밍(2002년 한빛미디어 정재은)씨의 이메일 주소로 질문 해 보시길 바람

imarchie@hamail.net


python에서 import math후 print math.pow(2,32)를 해보니 40억이 넘는 것 같습니다. 인텔 x86에서 PAE를 사용해서 paging으로 64GB의 램을 액세스할때는 40억개의 위치로 불충분하지 않나요..? 64GB면 2^36바이트, 687억이 넘습니다.
puzzlet의 이미지

글을 읽다보니 궁금해져서 우문을 하나 던지겠습니다.

C와 C++에서 int*, char*, class* 등을 void*로 캐스팅하는 것은 비표준인가요?

발발다빠따반반나다발딸발발다빠따따맣발발다뿌
멓터벅더떠벋떠벌더벌벌떠벌떠더법벍떠더벌벌떠

lsj0713의 이미지

puzzlet wrote:

C와 C++에서 int*, char*, class* 등을 void*로 캐스팅하는 것은 비표준인가요?

void *는 범용 포인터이기 때문에 모든 포인터는 void *형으로 변환될 수 있으며 그 반대도 가능합니다. 또한 void *형으로 변환되었다가 다시 원래의 자료형으로 변환했을 경우 그 결과값은 원래의 것과 동일합니다.

그리고... 제가 좀 잘못 알고 있었던 부분이 있는 것 같습니다. -_-;; 공부를 대충대충 하다보니 허술한데가 많습니다. -_-;

다시 한번 검토해본 결과, 정렬 제한(메모리에서 특정 자료형의 변수를 어떤 수의 배수의 주소값을 갖는 공간에만 저장할 수 있는 제한)에만 어긋나지 않는다면, 모든 포인터 타입(엄밀히는 object 아니면 incomplete type에 대한 포인터)은 다른 형(역시 object 아니면 incomplete type)에 대한 포인터로 변환될 수 있으며, 다시 원래의 자료형으로 변환했을 경우 그 결과값은 원래의 것과 동일해야 합니다.

즉, 모든 포인터형들이 같은 크기나 내부 표현 방법을 가져야 된다는 말은 안나오지만, 정렬제한을 어기지 않는다면 서로간에 변환되었다가 다시 되돌렸을 때 원래의 값과 동일한 결과가 나오는 것은 보장이 되는 모양입니다. 어떻게 보면 '모든 포인터형은 같은 크기를 가져야 된다'라고 해석할수도 있는 내용입니다.

하지만 이것을 '포인터 사이에는 자유롭게 변환이 가능하다'라고 해석하면 곤란합니다. 실제로는 정렬제한을 어기지 말아야 된다는 전제조건이 상당히 까다롭지요. 주소값에 따라서는 char * -> float *이 undefined behavior를 보일 수 있게 됩니다.

따라서 특정 자료형에 대한 포인터 -> void* -> 원래의 '특정 자료형에 대한 포인터' 이외에는 포인터 사이의 변환은 허용되지 않는다고 보는게 편합니다. (사실은 qualifier가 붙는 포인터형 사이의 변환이나 signed와 unsigned 사이의 변환 등은 허용이 됩니다만... 복잡하니까 패스^^;) 특별한 경우가 아니라면 그 이외의 포인터끼리의 변환은 피하는 것이 좋습니다.

ㅡ,.ㅡ;;의 이미지

ashuaria wrote:
저도 한마디만 할께요.

pointer는 메모리 주소의 번지를 담는것입니다. 따라서 그 CPU, architecture가 사용하는(다루는) PC(Program Counter)와 같은(혹은 그와 비슷한) 레지스터의 크기에 영향을 받습니다. AMD64의 경우는 64bit mode에서 그 레지스터가 64비트를 쓰기 때문에 64비트 모드에서 포인터의 크기가 64비트가 되는것 뿐입니다.

여러분들이 헷갈리는것이 있는데, 버스의 크기(혹은 bandwidth)라고 하는것을 말씀하실때는 확실히 구분 하셔서 이야기를 하셔야됩니다.
I/O bus의 경우 이미 pentium시절때 부터 64bit의 크기로 가고 있습니다.
I/O bus의 그 비트수는 단순히 데이터를 전송 할수 있는 능력을 높이기 위한 것 뿐이라고 생각을 하시면 됩니다. 즉 IO bus bandwidth= bus size 64bit * 100Mhz = 800MB/sec(물론 peak치 일뿐입니다.) 라는것을 도출할때 쓰이는 버스입니다.
요즘 많이들 쓰시는 듀얼 체널을 보면 메모리 bus는 64bit 메모리 모듈을 2개를 동시쓸수 있게 해서 128bit를 내는것입니다.

갑자기 삼천포로 빠졌네요. 음 MIPS의 R4400(기억이 가물)이라는 CPU가 있었습니다.
이놈은 GPR(General purpose register)는 128bit이였지만, PC는 64bit, ALU는 32bit였던것으로 기억합니다. 포인터는 64bit였지만 32bit 정수연산을 하는 특이한 CPU로 기억됩니다. (벡터 유닛은 128bit 연산을 했고요)
즉, CPU의 ALU와 GPR과 PC의 비트가 다 다를수도 있습니다.

결국 제가 생각 해볼때는 PC를 몇비트를 쓰는가가 포인터의 크기를 결정하게 되겠네요.

또 다른 사족이지만, 요즘 나오는 CPU들의 SSE와 같은 연산들은 128bit Vector Register들이 존재하고 128bit 연산도 가능하죠 ^^;
SIMD라서 메모리 bandwidth를 peak에 근접하게 사용 가능하죠.

만고 제 생각입니다.


운영체가 CPU 의 레지스터 크기에 영향을 받는다고 말할수 있나요? 받는것도 있겠지만 안받는것도 있죠.
MSDOS 이거 어디서 돌리나 16비트 아닌가요?
더구나. OS가 CPU 에따라 주소체계가 마구 바뀌는게 그리 많았던가요?
제가 알기론 대부분 고정적일거라 생각하는데
더구나 32비트OS라는말은 이미 32비트 주소체계로 고정되어 있다는뜻아닌감요?


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

gyumee의 이미지

ㅡ,.ㅡ;; wrote:

제가 사오정인가보죠..ㅡ,.ㅡ;;
근데 아직도 모르겠는걸요.. 32비트OS 중에 8비트가 1바이트가 아닌 OS가 어떤게 있죠?

제가 넘겨 집기로 32비트 OS중에서 8비트 가 1바이트가 아닌 OS가 없을 것이라고 생각합니다. 32비트OS라면 말이죠 하지만 위엣분이 말한 것은 모든 컴퓨터에서 1바이트가 반드시 8비트로 구성되지는 않는다는 말을 한 것으로 보입니다.

ㅡ,.ㅡ;; wrote:

애초 이쓰레드의 질문은
"32비트 운영체제에서 포인터는 4바이트로 알고 있고 당연하다고 ..."
였습니다. 전 공을 어디로 넘긴게 아니라 계속 "32비트 운영체제 하에서.." 의 토론이라고 생각하고 있었는데요..

단순하게 말하면 32비트 운영체제라고 꼭 포인터가 4바이트가 될 것이라는 보장은 없습니다. 포인터는 운영체제 보다는 CPU의 디자인과 관계된 것으로 봐야 할 것입니다. 다양한 CPU를 경험해 보지 않아서 모르겠지만 원론적으로는 그렇습니다.
이유는 여러분들어 설명을 했네요.
그런데 포인터의 종류에 따라서 크기가 다르다는 예기는 어떤 컴파일러가 특별한 목적으로 그렇게 만들지 않는 한 일반적으로는 있을 수 없는 경우가 아닌가 생각합니다.
gyumee의 이미지

ㅡ,.ㅡ;; wrote:
[
운영체가 CPU 의 레지스터 크기에 영향을 받는다고 말할수 있나요? 받는것도 있겠지만 안받는것도 있죠.
MSDOS 이거 어디서 돌리나 16비트 아닌가요?
더구나. OS가 CPU 에따라 주소체계가 마구 바뀌는게 그리 많았던가요?
제가 알기론 대부분 고정적일거라 생각하는데
더구나 32비트OS라는말은 이미 32비트 주소체계로 고정되어 있다는뜻아닌감요?

영향을 받습니다. MSDOS가 어디에서나 16비트인 것이 아니라 CPU가 MSDOS가 돌기 좋게 자신을 16비트 CPU 처럼 돌아주기 때문에 돌아가는 것입니다. 만약 난 16비트 지원 안해! 하고 안돌아주면 MSDOS가 무슨 재주로 돌겠습니까?
그리고 OS가 CPU 맞춰서 왔다 갔다 합니다. 리눅스가 그렇지 않습니까?
ㅡ,.ㅡ;;의 이미지

gyumee wrote:
영향을 받습니다. MSDOS가 어디에서나 16비트인 것이 아니라 CPU가 MSDOS가 돌기 좋게 자신을 16비트 CPU 처럼 돌아주기 때문에 돌아가는 것입니다.

그건좀 어거지군요.. 어쨋거나 시퓨는 16비트가 아닌데도 16비트로 돌아간다는 얘기니 영향을 받지 않는다고 해야죠.
Quote:

만약 난 16비트 지원 안해! 하고 안돌아주면 MSDOS가 무슨 재주로 돌겠습니까?

16비트를 지원안한다.. 그럼 실행조차 안된다..
돌아가지도 않는 장비에대해서 시퓨에의해 번지수가 결정된다안된다를 말하는자체가 잘못된겁니다.
Quote:

그리고 OS가 CPU 맞춰서 왔다 갔다 합니다. 리눅스가 그렇지 않습니까?

물론 OS에따라서는 하드웨어적인특성에따라 커널이 재컴파일되거나 혹은 적합한커널이 설치되기도 하겠죠. 더구나 32비트OS가 64비트CUP라해서 64비트로 변하는경우는 없을겁니다.


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

cocas의 이미지

ㅡ,.ㅡ;; wrote:
gyumee wrote:
영향을 받습니다. MSDOS가 어디에서나 16비트인 것이 아니라 CPU가 MSDOS가 돌기 좋게 자신을 16비트 CPU 처럼 돌아주기 때문에 돌아가는 것입니다.

그건좀 어거지군요.. 어쨋거나 시퓨는 16비트가 아닌데도 16비트로 돌아간다는 얘기니 영향을 받지 않는다고 해야죠.
Quote:

만약 난 16비트 지원 안해! 하고 안돌아주면 MSDOS가 무슨 재주로 돌겠습니까?

16비트를 지원안한다.. 그럼 실행조차 안된다..
돌아가지도 않는 장비에대해서 시퓨에의해 번지수가 결정된다안된다를 말하는자체가 잘못된겁니다.
Quote:

그리고 OS가 CPU 맞춰서 왔다 갔다 합니다. 리눅스가 그렇지 않습니까?

물론 OS에따라서는 하드웨어적인특성에따라 커널이 재컴파일되거나 혹은 적합한커널이 설치되기도 하겠죠. 더구나 32비트OS가 64비트CUP라해서 64비트로 변하는경우는 없을겁니다.

제 옛날 기억으로는 MS-DOS용 Turbo C 3.0에서 far pointer는 sizeof가 4, near pointer는 sizeof가 2였습니다. 고등학교에서 어설프게 배울때는 왜 sizeof가 2였다 4였다하는거지.. 해서 혼란스러웠고요. ㅡ,.ㅡ;; 님께서는 이것을 어떻게 생각하시는지요?

cppig1995의 이미지

cocas wrote:
제 옛날 기억으로는 MS-DOS용 Turbo C 3.0에서 far pointer는 sizeof가 4, near pointer는 sizeof가 2였습니다. 고등학교에서 어설프게 배울때는 왜 sizeof가 2였다 4였다하는거지.. 해서 혼란스러웠고요. ㅡ,.ㅡ;; 님께서는 이것을 어떻게 생각하시는지요?

cocas님, 혹시 이 글에 대한 말씀이신가요?

gyumee wrote:
그런데 포인터의 종류에 따라서 크기가 다르다는 예기는 어떤 컴파일러가 특별한 목적으로 그렇게 만들지 않는 한 일반적으로는 있을 수 없는 경우가 아닌가 생각합니다.

gyumee 님 말씀은 near *, far * 두 종류를 말씀하신 것이 아니라 int *, char *, double * 등 포인터의 종류를 말씀하신 것 같은데요?

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

ashuaria의 이미지

ㅡ,.ㅡ;; wrote:
ashuaria wrote:
저도 한마디만 할께요.

pointer는 메모리 주소의 번지를 담는것입니다. 따라서 그 CPU, architecture가 사용하는(다루는) PC(Program Counter)와 같은(혹은 그와 비슷한) 레지스터의 크기에 영향을 받습니다. AMD64의 경우는 64bit mode에서 그 레지스터가 64비트를 쓰기 때문에 64비트 모드에서 포인터의 크기가 64비트가 되는것 뿐입니다.

여러분들이 헷갈리는것이 있는데, 버스의 크기(혹은 bandwidth)라고 하는것을 말씀하실때는 확실히 구분 하셔서 이야기를 하셔야됩니다.
I/O bus의 경우 이미 pentium시절때 부터 64bit의 크기로 가고 있습니다.
I/O bus의 그 비트수는 단순히 데이터를 전송 할수 있는 능력을 높이기 위한 것 뿐이라고 생각을 하시면 됩니다. 즉 IO bus bandwidth= bus size 64bit * 100Mhz = 800MB/sec(물론 peak치 일뿐입니다.) 라는것을 도출할때 쓰이는 버스입니다.
요즘 많이들 쓰시는 듀얼 체널을 보면 메모리 bus는 64bit 메모리 모듈을 2개를 동시쓸수 있게 해서 128bit를 내는것입니다.

갑자기 삼천포로 빠졌네요. 음 MIPS의 R4400(기억이 가물)이라는 CPU가 있었습니다.
이놈은 GPR(General purpose register)는 128bit이였지만, PC는 64bit, ALU는 32bit였던것으로 기억합니다. 포인터는 64bit였지만 32bit 정수연산을 하는 특이한 CPU로 기억됩니다. (벡터 유닛은 128bit 연산을 했고요)
즉, CPU의 ALU와 GPR과 PC의 비트가 다 다를수도 있습니다.

결국 제가 생각 해볼때는 PC를 몇비트를 쓰는가가 포인터의 크기를 결정하게 되겠네요.

또 다른 사족이지만, 요즘 나오는 CPU들의 SSE와 같은 연산들은 128bit Vector Register들이 존재하고 128bit 연산도 가능하죠 ^^;
SIMD라서 메모리 bandwidth를 peak에 근접하게 사용 가능하죠.

만고 제 생각입니다.


운영체가 CPU 의 레지스터 크기에 영향을 받는다고 말할수 있나요? 받는것도 있겠지만 안받는것도 있죠.
MSDOS 이거 어디서 돌리나 16비트 아닌가요?
더구나. OS가 CPU 에따라 주소체계가 마구 바뀌는게 그리 많았던가요?
제가 알기론 대부분 고정적일거라 생각하는데
더구나 32비트OS라는말은 이미 32비트 주소체계로 고정되어 있다는뜻아닌감요?

86계열은 특이하게도 8086으로부터 계속 발전해 왔습니다.
8086의 범용 레지스터중 하나인 AX(16bit)는 AH(8bit)와 AL(bit)로 나누어서 쓸수가 있었죠. 80386에서 기존의 8086과 호환이 되는 모드와 32bit를 제대로 쓰기위한 모드를 지원했었죠. EAX(32bit)안에 AX를 감싸고 AX안에 AH,AL을 넣는 식으로 되어 있죠. 그런식으로 register를 공유 할수 있었습니다.
운영체제 이야기를 꺼내셨습니다. 도스로요. 당시 도스는 8086(REAL MODE)호환 모드로 돌았죠. 그건 80386이 8086과의 하부 호환이 되었기 때문일뿐입니다. 만일 80386이 8086과 호환이 되지 못했다면 80386용 DOS가 따로 나올수도 있었겠죠. 그렇게 된다면 포인터가 4바이트가 되겠죠.
운영체제가 포인터크기를 결정한것이 아니라 DOS는 8086호환 모드로 동작했기 때문에 16비트(2바이트) 포인터를 썼던것 뿐입니다. 실재로는 세그멘트+오프셋을 써서 총 20bit를 다루도록 했지만요.
예를 들어 보죠. 옵테론이 x86호환 없이 64비트를 지원한다면 도스, x86용 윈도, x86용 리눅스 등은 실행될수 없을것입니다. 옵테론이 64비트 모드로 동작할때는 RAX(64bit)를 씁니다. 물론 PC도 64비트를 쓰고요. 하지만 x86-32bit모드로 동작하면 EAX를 쓰고, PC도 32비트만 씁니다.
확실히 x86은 특이합니다.
8086(16비트)->80386(32비트)->AMD64/EMT64(64비트) 이렇게 발전하면서도 하위 호환성을 지켜나간 특이한 아키텍쳐죠.
심지어 PC-BIOS는 아직도 그 옛날 IBM이 만든 코드에 기초하여 동작하고요.
하위 호환성이라는것이 물론 x86만의 것은 아니지만, 다른 CPU 혹은 architecture들과는 호환이 되는 정도(?)가 틀린것 같습니다.

<FONT face="Times New Roman" size=4>שלום צליכם מאת ארוננו ישוצ המשיח</FONT>

ㅡ,.ㅡ;;의 이미지

윗분 호환성을위해 CPU가 지원하느냐 아니면 OS가 지원하느냐에서 결국 CPU가 지원한셈이지요 즉 OS는 무관하게 동작가능하다 ,
CPU특성을 타지 않아도 된다는 말이되죠.


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

Anti-Lock의 이미지

누가 먼저 지원하느냐에따라 다를것입니다.

CPU와 OS 가 있는데,
CPU가 하위호환을 지원하면 기존 OS는 그 CPU에서 돌아가겠지요.

하지만 반대로 CPU가 하위호환을 하지 않으면??
이경우 OS가 CPU에 관계없이 동작하기위해
하위호환을 지원하지않는 CPU에 '포팅'되어야 겠지요.

이준의 이미지

일단 정답은 어쩌다보니 그렇게 됐다입니다.

간단한 CPU를 설계 해보셨다면 아시겠지만 결국에 만드는 사람 마음 아닙니까?

편의해 의해 비트의 수가 짝수로 2배씩 늘어난뿐이죠..

보편적으로 하나의 레지스터 크기에 의해 어드레스라인 크기가 결정되지만..

만드는 사람이 다르게 만들수도 있는거고요.. 보통 그렇다는거죠...

그게 제일 편하고 보편적이니까요..

또 1byte=8bit 이다 라는 개념은..

보통 1byte는 8bit니까 1byte가 8bit이라고 한거고

특이하게 1byte가 9bit인 컴퓨터가 생긴거지

그렇다고 1byte != 8bit이라고 할 필요는 없지 않습니까?

어떤 의학서적에 "인간은 발이 2개다" 라고 써있는데

거기다 대고.. 발3개 달린 기형아도 잇으니 인간은 발이 2개나 3개다

라고 말하느거랑 비슷한거 같군요 ㅋㅋ

Hyo-Sung Lee(李曉星/Mark Lee)

KRSF Certified Inline Skate Instructor
Fitness Inline Skate Trainer
Mogul&Freeride Skier
IDOne ski rider
Cafe MogulBuddy/KoreaMogul
E-Leader(C) Programmer

cocas의 이미지

이준 wrote:
일단 정답은 어쩌다보니 그렇게 됐다입니다.

간단한 CPU를 설계 해보셨다면 아시겠지만 결국에 만드는 사람 마음 아닙니까?

편의해 의해 비트의 수가 짝수로 2배씩 늘어난뿐이죠..

보편적으로 하나의 레지스터 크기에 의해 어드레스라인 크기가 결정되지만..

만드는 사람이 다르게 만들수도 있는거고요.. 보통 그렇다는거죠...

그게 제일 편하고 보편적이니까요..

또 1byte=8bit 이다 라는 개념은..

보통 1byte는 8bit니까 1byte가 8bit이라고 한거고

특이하게 1byte가 9bit인 컴퓨터가 생긴거지

그렇다고 1byte != 8bit이라고 할 필요는 없지 않습니까?

어떤 의학서적에 "인간은 발이 2개다" 라고 써있는데

거기다 대고.. 발3개 달린 기형아도 잇으니 인간은 발이 2개나 3개다

라고 말하느거랑 비슷한거 같군요 ㅋㅋ

바이트가 왜 8비트라는 말과 같아지게 되었는지 나와있는 글입니다.

http://www.bobbemer.com/BYTE.HTM

인간이 발이 2개인것과는 다른 문제 같습니다. 모든게 인간의 개입속에서 만들어진 컴퓨터와 인간의 개입 없이 설계된 인간을 같이 비교하는 건 말이 안된다고 생각합니다.

Prentice의 이미지

발..에서 약간 방향을 틀어서, 발가락 수를 생각해봅시다. 대부분의 사지동물(팔다리가 두개씩인 동물)의 경우 발가락이 발에 다섯개씩입니다. 다섯개보다 적으면 퇴화되거나 변형된 흔적이 그만큼 보입니다.

이게 항상 이래왔던 것은 아니고 초기 양서류의 경우 그보다 발가락이 많았습니다. Ichthyostega의 경우 발가락이 일곱개입니다.

사지동물의 발가락은 항상 다섯개였던 것은 아닙니다.

lsj0713의 이미지

이준 wrote:

그렇다고 1byte != 8bit이라고 할 필요는 없지 않습니까?
어떤 의학서적에 "인간은 발이 2개다" 라고 써있는데
거기다 대고.. 발3개 달린 기형아도 잇으니 인간은 발이 2개나 3개다
라고 말하느거랑 비슷한거 같군요 ㅋㅋ

그렇다고 다리 하나인 장애인이나 다리 3개인 장애인에 대한 배려를 하지 않을수는 없습니다. 우리나라야 컴퓨터의 보급이 늦었으니까 무조건 1byte=8bit지만 미국에선 이미 70~80년대에도 광범위하게 컴퓨터가 쓰여왔으며 또한 그시기에 쓰인 컴퓨터중에는 기형적인 구조를 가진 놈들이 적지않게 있습니다.

http://en.wikipedia.org/wiki/Byte

더더욱 문제는 앞으로도 개발자의 편의 또는 목적에 따라서 '기형아'가 얼마든지 나올 수 있다는 겁니다. Y2K문제가 왜 생겼겠습니까? 프로그래머가 작성한 코드는 몇십년을 살아남을 수 있습니다.

일단 생각해 볼 수 있는 경우는 UCS2 혹은 UCS4의 보편화입니다. 1character가 16bit 혹은 32bit 되고 그러다가 1byte가 16bit 혹은 32bit되는 일이 절대 없으리라고 장담할 수 없습니다.

kenos의 이미지

당연히 똑같은거죠. 주소를 가르키는건데 그 내용의 형태나 크기와 무슨 상관인가요.

자기가 1억을 가르키든 1원을 가르키든 주소는 독같은 주소죠.

김일영의 이미지

당연하다고 생각하지 마시고 표준에서 한번 찾아보세요.
정말 당연한건 이미 표준에 나와 있고 여기 분들이 이미 언급을 해 주셨습니다.
너무 당연해서 표준에 안 쓴거라면 표준에 언급된 내용들도 없었어야 하겠지요.
그러니까 표준에 언급이 안된건 정말 보장이 안된다고 봐야 합니다.

익명 사용자의 이미지

주소의 크기가 32비트 운영체제인 윈도우들(보호모드)에서

크기가 4바이트 자나요?

다른 댓글다신 분들 글을 보고 있노라면

주소의 크기가 변할 수 있다고 그러시는데요.

네, 충분히 변할 수 있다고 생각은 하지만...

32비트를 초과해서 지정 가능한가요?

예를 들어 레지스터 2개를 써서 64비트 주소를 지정하게 할 수 있느냐는거죠.

물리적으로 4G 초과의 메모리를 메인보드에서 인식한다면

그 메모리에 접근해서 데이터를 쓰고 읽을 수 있나요?

제가 알기로 질문자와 같이 주소 버스가 32비트 이기 때문에라고 알고 있는데,

그 이상도 가능할까 싶어서 질문 합니다.

만약 안된다면 결국 32비트가 최대 표현 가능 주소가 되는 거겠죠?

익명 사용자의 이미지

CPU가 달라지면 주소의 크기나 포인터의 크기가 달라질 수 있습니다.

세상에는 윈도우만 있는게 아니듯이
x86만 있는게 아닙니다.

cppig1995의 이미지

그걸 위해 주소라는 녀석은 페이징을 거쳐 선형 주소가 되고 MMU(세그먼테이션)를 거쳐 실제 주소가 됩니다.
물론 32비트 환경에서는 4GB 초과를 동시에 사용하긴 힘들죠.



(전략) 항복 권고를 받은 키탈저 태수 아지엣 사카라는 "항복? 먹는 거냐?"라는 짤막한 답장을 써보냈다. 베로시 토프탈은 행간에서 낄낄거림이 묻어나는 문체로 항복은 먹는 것이 아니라 자신의 미력함을 인정하고 상대에게 굴복하는 것이라는 상냥한 답을 보냈다. 그러자 아지엣 사카라는 "못 먹는 것이면 관심 없다."는 답장을 보냈다.
몽화 대사전 - http://cppig1995.n-pure.net/mh

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

김일영의 이미지

대부분의 경우 그렇기는 하지만, 단정해서는 안됩니다.
http://minjang.egloos.com/1458391

semmal의 이미지

char가 왜 1바이트인가요?
int가 왜 4바이트인가요?

char가 1바이트인 이유는 지금 쓰시는 컴퓨터가 char를 1바이트로 처리하기때문입니다.
int가 4바이트인 이유는 지금 쓰시는 컴퓨터의 데이터 버스, 또는 그 버스를 다루는 프로그램이 4바이트기 때문입니다.
포인터가 4바이트인 이유는 지금 쓰시는 컴퓨터의 주소 버스, 또는 그 버스를 다루는 프로그램이 4바이트기 때문입니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

김일영의 이미지

C 언어 표준 어디에도 그런 규정은 없습니다.

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.