1. 하나의 값을 여러개의 변수가 가리킬 수 있다
하나의 내용물이 여러개의 그릇에 담겨있는 건 좀 이상..
2. x = Foo()
여기서 Foo()에 의해 객체가 생성되고 이게 x의 값이 된다
즉 객체가 먼저 생기고 변수가 뒤에 생긴다
내용물부터 만들고 그 담에 그릇을 만들면 이상..
변수를 태그라 생각하면 모든게 해결됨
여러개 붙어도 되고 나중에 만들어도 됨
하나의 내용물이 여러개의 그릇에 담겨있는 건 좀 이상..
2. x = Foo()
여기서 Foo()에 의해 객체가 생성되고 이게 x의 값이 된다
즉 객체가 먼저 생기고 변수가 뒤에 생긴다
내용물부터 만들고 그 담에 그릇을 만들면 이상..
변수를 태그라 생각하면 모든게 해결됨
여러개 붙어도 되고 나중에 만들어도 됨
그릇에 주소를 담는 거잖아요
변수는 사실상 메모리 셀의 추상화이기에 거기 뭘 담는다는 생각은 이상할게 없음
1. 주소를 담는다 2. 변수(메모리)는 원래 있었고 거기에 객체를 담는다
변수가 메모리 셀의 추상화라는 건 제 뇌피셜이 아니고 PL 교과서에 나오는 소리임
변수는 똥물입니다
로우레벨로 가면 그리 설명할 수 있는데 보통 이런 이야기를 할때는 좀더 추상레벨의 이야기죠. 레퍼런스 타입의 객체를 다룰 때는 태그 개념이 유용합니다.
"변수가 선언했을 때 생긴다" 라는 잘못된 모델을 가지고 있으면 안 됨 그런식으로 생각하면 지역변수를 쓰면 오히려 성능이 떨어져야 정상이잖음
흠.. 언어에 레퍼런스 타입만 있다면..?
1, 2 번다 너무 띵한 소리라 솔직히 따져주기도 귀찮음.
참고로 이 주장은 제 고유의 생각이 아니라 알렉스 마르텔리와 루치아노 라말료의 주장
너 까지 포함해서 셋이라고 하자.
1, 2 번 모두 IQ 80 짜리 문돌이 꼰대새끼가 만들어 놓은 고집스런 괴상망칙한 행위 정의임.
셋은 아닐껍니다 요새 꽤 쓰이는 설명법이라 ㅋㅋ
나라는건 실체고, 내가 명함을 뿌리고 다니는게 레퍼런스인데 그게 유일성과 무슨상관임?
변수란건 지갑이고 거기다 명함을 꽂았는데 1번이 왜 나와 병신같이.
물론 이것도 세련된 표현은 아님.
유일성에 대한 반박일 뿐.
실체가 객체고 명함이 변수다 실체는 하나고 명함은 여러장이다 내가 만들어지고 내 설명을 담은 명함을 제작한다 이런 논리죠
워 갑자기 병신이라는 욕지거리 대화 끝
아니 지금 내가 멍청한건지 저 글이 이상한건지... 그냥 메모리 셀로 생각하면 문제없는데 int a; 는 그냥 0x00... 의 주소에서부터 4바이트만큼 정수형 자료가 담길것. 이란건데
Foo() 가 만들어지고 담기는 변수란 공작대고 그 위에 올려진 결과물을 어느 진열장에 담든 생성주기와는 상관없음
공작대는 레지스터고 진열장은 메모리지
공작대도 진열장도 컨테이너 개념이 맞음
우리 추상화 그만하고 구체화 합시다
관념적으로 안맞다는게 저 글의 내용인데, 병신같은 소리하고 병신소리듣기 싫으면 어쩔 수 없는거지
rudel/ 실제 데이터가 메모리위에서 어떻게 생성되는지를 생각하면 그게 맞죠. 위 글은 소스코드 상에서 추상적인 이해를 돕기 위해 만들어진 설명입니다 사실. 그릇이라 말할 때 추상적으로는 오해를 유발할 수 있다라는 문제제기에서 나온. ㅇㅇ
컨셉잡을때 써먹는걸로 딴지건건지 음....
예를 들어 a = [0, 1]; a = b; 하고 b를 조작하는데 왜 a가 변경되느냐를 설명할 때 그릇보다는 태그가 더 추상적으로는 맞다 이런 주장이죠.0
아캄의 면도날 바보야
오캄의 면도날.
실제로는 a와 b라는 변수의 값이 리스트 그 자체가 아니라 리스트의 헤더이기 때문이지만..
이슈키 헤더란 말도 똑바로 못쓰네 너 문돌이 맞지?
추상화 하지마시고 그냥 메모리 주소로 이해하세요....
헤더는 앞에 와서 붙는 존재를 말하는거지 시작을 가리키는 녀석이 아니야
codesaf/ 언어에 따라 레퍼런스타입의 객체에 대한 정보를 담고 있는 걸 헤더라 부르기도 해요. 제가 쓰는 언어도 그럼.
그냥 이슈키 용어 자체가 다 괴상망칙하고 지랄발광하는데 개념적 차용은 죄다 웹이나 자바스크립트에서 따온듯 작위적임.
저게 어떤 언어인지는 모르겠는데 go에서도 리스트랑 비슷하게 슬라이스를 쓰고 그 슬라이스의 헤더를 동적으로 만들어서 unsafe한 변환을 하기도 하는데, 그 때 헤더라는 용어가 공식적으로 쓰입니다.
ㅇㅇ 가 말하는건 고전적 구조체에서 self specification 하기 위한 헤더 그자체를 말하는거고
그건 실제 body 앞에 나오니까 헤더라고 해도 되지
헤더가 아무데나 갖다 붙일 수 있는 단어가 아니야. 공간이 있어야해.
헤더 자기스스로 공간을 확보해야 한단소리지.
정확히는 바디와 동떨어진 공간에 있기는 한데, 암튼간에 이런 논리를 가정하고 보면 저 말도 이해가 되기는 하고...... 저게 실제 해당 언어의 공식 스펙인지는 모르겠지만
아니 저 변수가 리스트의 헤더다 같은 괴랄한 소리가 이해된다고?
리스트가 메모리상에서 연속이 안돼?...
지금 저 말의 실제 의미와 제가 받아들인 의미가 같은지는 모르겠.... ㅇㅇ
리스트가 어느 언어 리스트인지 어떤 구조인지는 모르겠고, go에서 슬라이스는 슬라이스 헤더 공간이 따로 있고 슬라이스의 내용물을 담은 공간이 따로 존재
그 슬라이스 헤더 공간에 슬라이스의 내용물의 타입이 뭔지, 개수가 몇개인지, 어디주소부터 시작하는지가 하나의 구조체 형태로 적혀있습니다
C 배열 생각했죠 전... 신기하네요 그건
이걸 직접 편집할 수도 있고요, 물론 unsafe
지금 정확히 찾아보니 타입은 아니고 length, capacity, address 3가지가 구조체로 담겨있네요 ㅇㅇ
무식해야 나올 수 있는 이야기다.
참고로 이 구조는 relfect.SliceHeader 타입으로 사용할 수 있고 이걸로 go의 데이터 모델을 무시하고 자기 맘대로 막 컨버젼할 때 종종 쓰임 ㅇㅇ 글쓴이의 논리와 상관 없이 그냥 헤더 얘기가 나오길래 써봤습니다
니가 말하는 링크 형태면 엄밀히 헤더가 아님.
근데 그게 헤더란 네이밍으로 쓰일수 있는건 고전적 자기명세를 포함한 구조체들이 그런 양식을 가졌었기 때문
헤더의 일반적 의미가 정확히 어찌 정의되는지 모르겠는데, 암튼 header가 공식 스펙상에서 이런 의미로 쓰일 때는 있네요 ㅎㅎ
사실 제가 생각해도 header라는 이름 자체를 생각해보면 원래는 코세님 말씀이 맞는 듯요
전체의 크기 바디의 크기 바디의 시작주소와 실제바디가 연속한 메모리공간에 세트로 몰려다녔었기 때문이란거지 그런걸 CHUNK 구조라고 부르는것.