문제:
sizeof(char *)가 4인 컴파일러에서 다음 식의 값은?
sizeof "hello"
① 4
② 5
③ 6
④ 7
⑤ 컴파일 오류: 괄호가 없어서
정답: ③ 6
해설:
"hello"라는 문자열 상수(string literal) 자체는 문자 배열을 나타낸다.
다시 말해 {'h', 'e', 'l', 'l', 'o', '\0'} 라는 상수 char 배열과 같은 것이다.
그래서 sizeof "hello"는 원소 개수가 6이고 원소 크기가 sizeof(char) == 1이므로(표준에 의해) 6*1 = 6이 된다.
sizeof "hello"가 아니라 sizeof("hello")가 되어야 하지 않겠나 싶은 사람도 있겠지만,
sizeof 자체는 연산자기 때문에 괄호가 필요 없다. 괄호가 있어야 하는 경우는 어떤 식이나 값이 아니라
자료형에 대한 크기를 조사할 때만 예외적으로 괄호를 써줄 뿐이다. 예) sizeof(int), sizeof 4, sizeof 5, sizeof "hello", sizeof a
(자료형의 크기를 조사할 때 괄호를 써주는 까닭은 형 변환(캐스팅) 할 때 (자료형) 형식으로 쓰는 것의 영향으로 보인다.)
해설을 원하는 사람이 있어서 굳이 올려 봄.
일본에서 한자를 번역한 예일 뿐. 네 말처럼.
개념이 처음 나오거나 용어가 생소하던 시절엔 일본식 표현을 빌려다가 많이 쓰지만 점차 정착되고 성숙되는 과정에서는 독자적인 표현이 정립되기도 하는데 정규 표현식이 그 대표적인 케이스인 것 같아요. terminology니깐 네이버 영어사전에서는 regular expression이라는 항목이 있는 것 자체만으로도 대단한 일인 거 같고요.
expression 에 대해 식도 일본식 한자 번역이고 표현도 일본식 한자 번역이고.
아 성님한테 도발할 의도는 없었는데 ㄷㄷ 제 표현이 좀 센(?) 거 같은데 "모두"가 아니라 "많은 사람들"이라고 정정할게요 :)
IT용어사전, 한국정보통신기술협회[네이버 지식백과] 정규 표현 [regular expression, 定規表現] (IT용어사전, 한국정보통신기술협회)
출처가 IT용어사전과 한국정보통신기술협회임.
모두 란 단어 사용이 무리하다고 이야기하는거야.
궁금한게 regular expression야 그럴 수 있다고는 보는데. 프로그래밍 관련해서 expression 자체를 표현이나 표현식이라고 쓰는 예는 못 본 것 같은데. 혹시 있나요? Regular Expression에서 expression을 표현이라고 번역한 것은 기존의 expression 개념과는 다르기 때문에 구분해서 번역한 것으로 보이거든요. 정규 표현식이나 정규식처럼 '식'을 등장시킨 것은 기존의 expression과의 혼동으로 보이고.
그래서 저는 expression은 모두 "식"이라고 쓴다고 쓴 거예요. 표현이라고 쓴 걸 한번도 본 적이 없어서요. 물론 코세 성님 경력에 비하면 저는 새 발의 피겠지만 그래도 나름 오래 해왔다고 자부하는데 그런 번역을 본 적이 없어요 ㄷㄷ
아 제 말은. 프로그래밍 언어에서 expression라고 말하는 그 개념을 우리말로 옮길 때 '표현'이든 '표현식'이든 '표현'이라는 말을 덧붙여서 번역한 사례가 있는지 궁금하다는 것이었습니다.
아마도 없을 것 같은데요.
Regular Expression에서의 expression은 기존의 expression과 다르게 그냥 express 본래의 의미(표현하다)에 가까우니까요. 문자열을 표현하는 정규 방법이라는 의미에 가까우니 그렇게 번역한 것으로 보여요.
암튼 Regular Expression은 우리 쟁점은 아니니깐요. 성질도 다르고.
내가 보기엔, 정규표현식에서, 위키든 엔하위키미러든, "정규표현식" 이라고 사용하고 있는 부분은 expression 이 자유도를 많이 함의하지만, regular expression 자체가 갖고 있는 약속으로부터의 규약이 '식' 과도 닮아 있기 때문에 둘 다 사용하는 것이고, 이런게, 고리타분한 IT 사전이나 정보통신기술협회의 정의보단 더 가깝다고 여겨져. 즉, 굳이 '식' 으로 할 필요도 '표현' 으로 단정할 필요도 없다고 여겨지는 것이지, 보다 폭넓게 이해와 정의를 돕기 위해서는 expression 이 표현쪽에 더 가까운건 맞아. 반면 regular language 와 구분지어져야 할 필요도 있는것이고 말이지. 오히려 정규식 이라고 부르게 된건 short cut 스러운 표현이라고 보는게 맞을듯.
제 개인적으로는 일본처럼 우리나라도 기술 용어에 대한 표준 번역을 정립할 필요가 있다고 느껴져요. 하나의 용어도 중구난방으로 번역해대니 원.
걍 구글에서 expression 이라고 쳐도. "표현" 이 표제어로 나와
일본은 기술 용어 다 번역하는 사람들끼리 약속하고 통일한다고 그러죠. 우리나라는 좀만 생소한 기술 용어가 나오면 용어 중구난방으로 자기 꼴리는 대로 번역해서 써대고요.
어떤 기구가 설립되어서 이런 문제를 바로잡아줬으면 좋겠네요 :)
object == 객체, instance == 개체, expression == 표현 || 식 어떤 것이 되었든. 딱딱 하나로 통일해 줬으면 표현에 있어서 모호성이 사라지니까요.
@codesafer // 제가 궁금한 것은 regular expression이야 그렇다 쳐도 프로그래밍 언어에서 말하는 expression 개념을 "표현"이나 "표현식"으로 번역한 예가 있냐는 것이에요. 저는 한번도 못 봤거든요. 찾아봐도 "식"으로만 나오고요. 그래서 de-facto standard라고 느껴져서 "모두"까지는 과장이겠지만 대부분 그렇게 쓴다고 얘기한 것이고요.
이 글의 주제로 돌아가서, statement 와 expression 을 놓고 보면, 아까말했듯 c/c++ 의 expression 은 완전히 자유롭진 않아. 그러니 formula 처럼 정형화되었다 볼 수 있어. 하지만, statement 와 대비되는 개념으로 쓰일때, 이것은 보다 약한 제약, 즉 자유도를 의미하는것이기도 해. expression 이 좀 더 광범위하게 사용되는건 의미적 포괄성에 있어. 표현이 광범위하게 사용되는것도 포괄성에 있고말야. 네가 말하는 분야 한정적 특수성도 분명 존재한다고 봐.
물론 expression라는 개념 자체를 이해하는 데 있어서는 "표현"이라는 번역도 틀리다고 할 순 없지만 그렇게 쓰는 사람을 못 봤어요. 언어의 사회성에 반한다는 말이죠.
프로그래밍 언어에서 식을 formula 로 번역한 예는 많아. 그리고, 책의 저자들도 lambda expression 을 모두 람다식 으로 번역하는건 아냐. 람다표현식이나 람다함수로 번역하는 애들도 많고. 다만, formula 는 공식, 즉 수학이나 물리의 notation 에 가깝게 되어 있으니 expression 을 쓰는거고, expression syntax 와 같이 expression 에 격식을 갖춘 형태의 한정사를 붙이는 경우도 있지.
물론 코세 성님이 그렇게 쓰신다면 적어도 코세 성님 한 분은 계시는 셈이지만. 적어도 두 분 이상은 계셔야 되지 않을까요. 언어라는 건 서로 의사소통하기 위해 존재하는 것이므로 말하는 사람도, 듣는 사람도 서로 통할 수 있어야 하니까요.
네 물론 lambda expression 같은 예를 보면 또 그럴 수 있겠군요.
lambda expression을 보니 expression을 표현으로 번역하자는 말씀이 확 와닿네요.
다만 문제는 expression 자체는 표현으로 번역한 사람을 못 봤어요. 성님 주장이 일반화되어서 쓰이기에는 언어의 사회성 문제가 있다는 말이죠.
expression, lambda expression, regular expression에서 영어 표기가 expression으로 같다는 건 영어에서의 이야기이고. 번역어는 다르게 번역할 수도 있는 것이거든요. 꼭 직역을 하라는 보장은 없어서요. :)
그 결과가 expression은 식, lambda expression은 람다 표현, regular expression은 정규 표현(표현식). 인 것이고요.
구글 번역기에 돌려보았습니다.
아시다시피 구글번역기는 통계기반이죠.
regular expression : 정규표현식
원래 이런 문제는 서로 토론해 봤자 끝이 안나는 토론이므로 중재자가 필요한 주제이지만, expression의 경우는 그 자체는 표현으로 쓰는 사람이 없다는 게 일단은 유효한 주장인 거 같네요. 제가 말한건 어디까지나 프로그래밍 언어에서 말하는 expression 개념이에요. lambda expression, regular expression은 다른 개념이라고 보고 배제했을 때 순수 expression의 번역어요.
물론 expression라는 영어 단어를 검색했을 때 "표현"이라는 정의가 나온다는 건 큰 의미가 없어요. 그건 expression이라는 영어 단어의 뜻일 뿐이고요.
assembly가 국회라는 뜻이라고 해서 어셈블리어를 국회어라고 번역하자고 주장하면 웃기잖아요.
programming language expression : 프로그래밍 언어 표현
직역해서 조립어 라고 번역하기도 뭐하니깐. 관습으로 어셈블리어라고 그냥 쓰잖아요? 제가 논의하는 부분은 그런 거죠. 관습에서 그냥 expression을 표현으로 번역하는 사람이 있냐는 거예요.
그 programming language expression에서의 expression과 프로그래밍 언어에서 말하는 expression이 같은 개념이라고 보시는 건가요?
구글 번역기 바보 ㅡㅡㅋ expression of programming language 가 발현이란다.
저건 어디까지나 문제를 "프로그래밍 언어로 옮겼을 때의 문제 표현"을 함축적으로 나타낸 말 아닌가요? 그 구문, 식 할 때의 식이 아니라요.
프로그램 언어의 표현을, 수학식으로 보느냐 언어로 보느냐의 차이라고 보는데?
ㅋㅋㅋㅋ
수학식과 가까운 언어도 있고, 언어의 표현과 가까운 언어도 있겠지.
구글 번역기도 c++ expression 처럼 돌리면 C++ 식 이라고 번역해. 반면, 언어가 앞에 나와버리면 표현으로 번역해 버리지.
네 그럴 순 있죠. 그런데 성님 말씀대로 그 개념 자체를 "표현"이라고 번역한 사례를 단 한 건도 본 적이 없어서... 물론 람다 표현이나 정규 표현의 예가 있지만. 이런 것은 간접적으로는 힘을 실어줄지 몰라도 한방은 되지 못하니까요. 번역어는 직역으로만 결정되는 게 아니기 때문에.
구글 번역기를 믿는단 이야기가 아니라, regular language 로 보느냐 formula translator 로 보느냐의 문제인것 같음.
아무튼 성님께서 아까 제가 expression을 식이라고 표현한 것은 formula와 구분지어야 할 필요가 있다고 하셔서 여기까지 이야기가 왔네요 ㄷㄷ. 저는 expression을 식이라고 번역하는 부분에 있어서는 딱히 문제가 있다고 보지는 않아서요. 실제로 그 문맥에서의 expression을 표현이라고 번역한 사례를 보지 못했기도 하고요.
네. 그런 관점은 있을 수 있다고 봅니다.
웃긴게 statement 는 문장 이라고 이야기 하면서
expression 은 식으로 부르고 있다는거.
다만 안타까운 건 "표현"이라고 번역한 것이 정착되지 않아서 아직까지는 힘이 실린 표기는 아닌 것 같아요. ㄸ
statement & expression 이걸 구글 번역 돌리면 문 & 표현 이라고 나옴.
또 아시다시피 프로그래밍 언어 개념은 수학에서 차용한 개념이 많다보니까 수학에서의 전통적인 번역을 존중한 것 같기도 하고요.
ㅋㅋㅋ 그건 프로그래밍 언어가 아니라 일반 언어적 쓰임 아닌가요 ㄷㄷ
문에 어울리는건 표현이지 식이 아님.
사실 마음 같아서는 variable은 저장 공간, function은 기능 덩어리라고 개명해버리고 싶죠. 근데 관습이 그렇질 못하니까요.
문이란 단어를 쓰고 있으니 그런거지.
네. statement는 언어 관점에서 바라보고 expression은 수식 관점으로 바라본다는 부분은 확실히 문제 제기를 해볼만 하죠.
융통성이 없으니깐요.
뭐 이런 토론은 재밌다.
다만 제 생각은 아마도. 프로그램 코드는 statement들로 이루어지지 expression으로 이루어지지 않는다는 점에서 그렇게 구분한 게 아닐까 싶어요.
언어와 수학 사이에 놓인 프로그래밍 언어의 입지를 잘 말해주는듯.
수학에서의 expression 은 식이 맞는거니까 말야.
C에서는 1; 처럼 expression이 statement가 될 수는 있지만. 그렇다고 이게 statement가 아니진 않으니까요. 어디까지나 statement로 구성된 프로그램일 뿐이죠.
수학에서 statement 를 쓴다는게 웃긴거지.
사실 그렇게 따지면 변수라는 번역도 좀 웃기지 않나요? ㅋㅋ
매개 변수나요.
변수의 의미는 똥물이잖아.
수학에서의 변수랑은 그냥 함수와 함께 쓰인다는 것 외엔 큰 공통점도 없는데 수학에서의 관습을 존중해 변수, 함수, 매개 변수 이렇게 표현하죠.
앜ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
그거 제가 어제 아는 형한테 써먹은 개그인데 ㅋㅋ
어제 갑자기 비가 와서 아 오늘 약속에 똥물이 생겼네요 식으로 드립쳤죠 ㅋㅋㅋ
근데 변수란 번역은 재밌는듯 나름.
보통 가능의 의미를 나타내는 표현으로 ~~ 할 수 있다. 라고 하잖아.
변할수. = variable 이니까 말야.
그러니까 데이터를 저장, 처리하는 부분에 있어서는 어디까지나 디지털을 존중해 거기까지는 수학의 개념을 차용해서 표현하는 것 같고. 그 외에 프로그램 소스 코드의 개념으로 들어오면 언어의 관점에서 바라보는 것 같아요. 수학 개념과 언어학 개념이 섞인 듯.
한자에서 뜯어내서 생각해보면 나름 잼.
수 : [의존명사] 어떤 일을 할 만한 능력이나 어떤 일이 일어날 가능성.
able 이랑 딱 맞음.
왜인진 모르겠지만 갑자기 유명한 시의 한 구절이 떠오르네요. 김춘수의 꽃이요. "내가 그의 이름을 불러 주기 전에는그는 다만 하나의 몸짓에 지나지 않았다. 내가 그의 이름을 불러 주었을 때 그는 나에게로 와서 꽃이 되었다."
댓글많노
1 + 2 같은 식은 수식에 불과하고 이걸 a = 1 + 2; 같은 소스 코드 문장으로 표현했을 때 언어의 의미가 있다. 랄까. 그런 입장에서 저 시의 구절이 떠오르네요.
"장미가 다른 이름으로 불린다 해도, 그 달콤한 향기에는 변화가 없을 것이다" - 셰익스피어
전자는 call by name 후자는 name mangling
@codesafer // ㅋㅋ 그게 인문학의 재미죠. ㅋㅋㅋ 서로 완전히 다른 주장도 가능하죠.
완전히 다르다기 보단 관점의 차이랄까. 세상은 흑백논리가 아니니깐요 :)
call by name, name mangling 앜ㅋㅋㅋ
여튼 이 쓰레드는 나름 시시콜콜한 재미가 있었으. : ) 좋은 대화 상대다.
그러게요. 저도 즐거웠습니다. 성님 :) 서로 관점이 다름을 이해하고 존중하는 토론의 기본 태도가 지켜져서 그런지 다른 어그로꾼들과는 다르게 역시 코세 성님과는. 즐거운 토론이 가능하네요.
사실 관습이라는 것도 별 거 아니어서 성님 표기가 더 합리적이라면 얼마든지 성님 표기가 일반화되어 정착될 수 있는 거거든요. 약정속성이라고 잘못된 게 얼마든지 잘못 고착화될 수도 있으니까요.
결국 제 주장의 근거는 "관습"이라는 것 하나 뿐인데. 이게 깨어지면 얼마든지 제 주장은 설 자리를 잃게 되죠.
네 말에 공감. 하지만 expression 을 표현으로 해석하는게 나 뿐이라는건 너의 무리수 : ) 여튼 둘이 맺음말에서 꺼낸 "이름" 에 대한 문학 구절들이 화룡점정 했다고 보여지네 : )
네 그건 확실히 제 무리수라는 걸 저도 공감합니다. 성급한 일반화의 오류지요. :) 제 주위에 그런 사람이 없었다고 해서 전 지구상의 모든 사람이 그렇다는 주장은 확실히 성급한 일반화의 오류를 범한 것입니다.
저희는 컴퓨터 뿐 아니라 전 분야, 그리고 인문학 쪽에도 관심이 많으니깐 이런 걸 다 인용하는 것이죠 :) 소위 말하는 통섭형 인재랄까요.
너무 컴퓨터만 하는 것도 안 좋더라고요. 가끔 전혀 상관없는 인문학 쪽의 것들도 공부하면 장시간의 프로그래밍으로 지친 뇌를 즐겁게 하는 shelter가 되기도 해요.
제가 한자 자원 연구하는 것도 그런 목적의 지적 유희 중 하나죠.
내가 세미콜론을 붙여주기전 까지는 그것은 다만 expression 에 지나지 않았다. 내가 세미콜론을 붙여주었을 때 expression 은 나에게로 와서 statement가 되었다.
앜ㅋ 역시 코세 성님입니다. 정말 잘 리메이크하셨네요. :)
regular expression 이 정규표현으로 불린다 해도, 그 딱딱한 문법에는 변함이 없을 것이다.
ㅋㅋㅋㅋ 좆목충 븅신 두명이서 잘 싸우네