도대체 [구조체]가 [클래스]보다 좋은점이 뭔가요?

이소희의 이미지

클래스를 만들어도 되는 것들을 궂이 구조체로 만들어 사용하는 이유가 뭔지요?
구조체에서 할 수 있는거. 클래스에서도 다 되고,
구조체로 만든다고 메모리 크기가 작은것도 아니구...
연산 속도가 빠르다면, 왜? 빠른지요?
초보적인 질문같지만, 꼬옥 답변 해주셨으면 합니다.

댓글

ironiris의 이미지

c 에서 쓸수 있기 때문이 아닐까요?
클래스는 c++에서 지원되는거라... c에서 쓰려면 어쩔수 없겠지요. :) 먼저 나온 개념이니..

익명 사용자의 이미지

C에서도 사용할 수 있다는 말은.
C로 만든 프로그램과 호환때문이라는 뜻인가요?

익명 사용자의 이미지

C를 먼저 배웠기 때문이겠죠.

익명 사용자의 이미지

그렇다면 구조체가 클래스보다 좋은점은 없나요?

조의 이미지

=연산자로 생성할 때
구조체는 값복사
클래스는 참조복사가 일어나요. ^^

조의 이미지

[정리]
==================
구조체는 상속이 안됨. 클래스는 상속이 됨.
구조체의 =연산자로 인한 객체생성은 멤버 초깃값들이 값복사가 일어나나
클래스의 =연산자로 인한 객체생성은 멤버 초깃값들이 참조복사가 일어나요.
구조체는 멤버 초기화하는데 있어서 까다롭기 때문에 그 규칙을 좀 익혀야 하나
클래스는 그냥 평소 아시는대로 하면 돼요.

구조체는 매개변수가 없는 생성자가 이미 가지고 있기 때문에
생성자를 굳이 만드시고 싶으면 반드시 매개변수가 있는 생성자를 만들어야 하며
매개변수가 있는 생성자를 만들때는 무조건 가지고 있는 모든 변수를 초기화해야 함.
초기화 할 때는 멤버 변수 선언과 동시에 =연산자로 직접 초기화할수 없고
함수 안에서 초기화 시켜야 해요.
================

조의 이미지

구조체는 매개변수가 없는 생성자가 이미 가지고 있기 때문에
=> 구조체는 매개변수가 없는 생성자를 이미 가지고 있기 때문에
(사실 이것은 억지 이야기이긴 해요.) 저도 배우는 입장이니 내부적인 사항은 잘 모릅니다.

HideOnBush의 이미지

전제가 빠지셨네요. C에서의 구조체와 C++에서의 클래스라고 하셔야됐었네요..

neogeo의 이미지

좋은 점 나쁜 점 이라니 -_- 뭔가 좀 이상하군요.

구조체의 용도와 class 의 용도는 명백히 다르므로 비교 자체가 조금 이상한 것이라고 봅니다.

C++ 에서 struct 를 굳이 쓴 것은 아마도 특별한 이유가 있어서 겠지요.

C 라면 어차피 class 가 없구요.

( struct 만의 class 대비해서 특별한 성질이라고 해봐야 -_- 메모리 단위로 접근 정도 랄까.. 밖엔 제가 떠오르는게 없네요. 다른 분들이 좀더 잘 설명 해주시겠죠. )

그런데 struct 가 class 보단 메모리 덜 먹지 않나요. ( 아닌가 ㅡ,.ㅡ. 일단 class 에서 memeber function 의 code 공간위치가 다르긴 하지만 적어도 -_- 다른 정보가 좀 더 들어가는 걸로 아는데. )

속도가 빠른건 class 의 기본 성질 때문입니다.

일단 생성시 constructor 가 수행되고 사라져야 할땐 destructor 가 수행되며,

여러가지 연산에 대해 operator 가 따로 수행되고 ( 뭐 copy constructor 라던가 상황에 따라 여라가지 -_- 행동을 하겠죠 )

struct 야 -_- 어차피 저런것을 전혀 사용하지 않으니 생성과 삭제, 사용하는데 있어서는 조금이라도 더 빠르겠지요. ( 하지만 큰 차이는 없다고 들었습니다. )

Neogeo - Future is Now.

코에이의 이미지

C++에서 본질적으로 struct와 class는 같습니다.

C로 된 코드에서도 돌아갈 수 있게 하위호환성을 위해서 struct를 쓰고요

C++에서만을 주제로 친다면

유일한 차이점은 기본 권한이 class는 private:이고 struct는 public:입니다.

C++에서 virtual 함수를 가지지 않는 이상 struct와 class는 같은 크기를 가집니다.

멤버함수를 위해서 따로 공간을 가지는 것은 아닙니다.

역으로 생각해보면 struct에도 virtual 함수가 들어갈 수 있으니 같은 내용이 됩니다.

sodomau의 이미지

neogeo wrote:
좋은 점 나쁜 점 이라니 -_- 뭔가 좀 이상하군요.

구조체의 용도와 class 의 용도는 명백히 다르므로 비교 자체가 조금 이상한 것이라고 봅니다.

C++ 에서 struct 를 굳이 쓴 것은 아마도 특별한 이유가 있어서 겠지요.

C 라면 어차피 class 가 없구요.

( struct 만의 class 대비해서 특별한 성질이라고 해봐야 -_- 메모리 단위로 접근 정도 랄까.. 밖엔 제가 떠오르는게 없네요. 다른 분들이 좀더 잘 설명 해주시겠죠. )

그런데 struct 가 class 보단 메모리 덜 먹지 않나요. ( 아닌가 ㅡ,.ㅡ. 일단 class 에서 memeber function 의 code 공간위치가 다르긴 하지만 적어도 -_- 다른 정보가 좀 더 들어가는 걸로 아는데. )

속도가 빠른건 class 의 기본 성질 때문입니다.

일단 생성시 constructor 가 수행되고 사라져야 할땐 destructor 가 수행되며,

여러가지 연산에 대해 operator 가 따로 수행되고 ( 뭐 copy constructor 라던가 상황에 따라 여라가지 -_- 행동을 하겠죠 )

struct 야 -_- 어차피 저런것을 전혀 사용하지 않으니 생성과 삭제, 사용하는데 있어서는 조금이라도 더 빠르겠지요. ( 하지만 큰 차이는 없다고 들었습니다. )

C++에서는 struct나 class나 기본적으로 똑같기 때문에
(default 로 public 인지 private인지를 제외하고는)
constructor 역시 똑같이 실행됩니다.

theuhm의 이미지

전 개인적으로.. public: 이라고 쓰는게 귀찮을 경우에 class 대신에 struct를 사용합니다만.. 그외의 모든 성질은 똑같으니까요.. 상속, 가상함수, 다중상속, 오버라이딩, this포인터 등등...

주로 STL알고리듬에서 요구하는 프리디케잇은 struct로 만들게 되죠? 전 vector2d나 vector3d 클래스나.. 뭐 그밖에도 public이라고 구태여 쓰기 귀찮은 경우.. struct로 만드는게 타이핑 노력을 줄이는 방법이 되죠 =3 =33
(결국, 전 귀차니스트란 말이 되는군요)

..

theuhm의 이미지

코에이 wrote:
C++에서 본질적으로 struct와 class는 같습니다.

C로 된 코드에서도 돌아갈 수 있게 하위호환성을 위해서 struct를 쓰고요

C99에서는 바뀐 것으로 알고 있습니다만.. ANSI C에서는.. 구조체 선언시에
struct struct_name struct_variabel;
같은 식으로 되어야 하지 않나요? C++에서
struct_name struct_variabel;
위와 같은 형태로 선언된 코드는 하위 호환성이 없지 않을까요

..

JuEUS-U의 이미지

C++에서 struct 키워드, 표준 여부는 잘 모르겠고
일단 컴파일러에서 먹어주지 않던가요 = _=)

drinkme의 이미지

c++ 컴파일러가 c컴파일러보다 좋다는 말씀이신지?

koder의 이미지

저같은 경우 struct 와 class 는 용도에 따라 다르게 씁니다.

class 는 멤버 함수가 있을 경우에 쓰고, struct 는 없을경우에 씁니다.

class 는 액션이 가능한 객체일때, struct 는 단순 데이타만을 저장하는 공간으로 사용할때 씁니다.

가끔 struct 내부의 멤버 변수를 초기화 하기 위해서 ctor 를 쓰기도 하지만 어디까지나 편리를 위해서 일뿐이죠.

저는 다른분들도 이렇게 쓰시는줄 알았는데.. 아닌가 보군요..

이소희의 이미지

답변해주신 내용들을 쭈욱 읽어보면,
성능이나, 사용성 면에서 구조체가 클래보다 좋은점은 보이지 않는거 같네요.
그런데도, Win32 API내부 환경 변수들도 구조체를 사용하고, 네트워크 프로그래밍을 할때도 패킷구성을 주로 구조체를 이용해서 하는 이유는 뭘까요?
단지, 전통적인 관례로 프로그래머가 구조체 사용하는걸 좋아하기 때문 일까요?
지금까지 답변해주신 내용만으로 감사하게 생각하지만.. 조금 더 궁금해지내요.
자꾸 허접꼬투리 질문 올려서 죄송합니다.

내 삶속에 던져진 나.

익명 사용자의 이미지

이소희 wrote:
답변해주신 내용들을 쭈욱 읽어보면,
그런데도, Win32 API내부 환경 변수들도 구조체를 사용하고, 네트워크 프로그래밍을 할때도 패킷구성을 주로 구조체를 이용해서 하는 이유는 뭘까요?

Win32 api 는 클래스를 지원하지 않는 c 기반입니다.
네트워크 프로그래밍할떄 어떤 라이브러리를 사용하시는 지는 모르겠지만 마찬가지 일것 같습니다.

소리의 이미지

theuhm wrote:
코에이 wrote:
C++에서 본질적으로 struct와 class는 같습니다.

C로 된 코드에서도 돌아갈 수 있게 하위호환성을 위해서 struct를 쓰고요

C99에서는 바뀐 것으로 알고 있습니다만.. ANSI C에서는.. 구조체 선언시에
struct struct_name struct_variabel;
같은 식으로 되어야 하지 않나요? C++에서
struct_name struct_variabel;
위와 같은 형태로 선언된 코드는 하위 호환성이 없지 않을까요

네.

참고로 C99도

struct Mystruct {
...
};

Mystruct instance;

이런 식의 타입 정의를 허용하지 않습니다.

C에서 Mystruct는 struct 키워드에 붙는 tag일 뿐, 타입으로 정의되지 않죠. :)

dreamer의 이미지

네트웍 프로그램에서는 실제로 전송되는 데이타의 정렬과 위치 사이즈가 정확해야 합니다.
그래야 상대편에서 오류없이 동작을 할 수 있고요..
그러므로 날아가는 데이타의 구조를 정확히 표현해야 합니다. 위치 , 사이즈
클래스는 보통 함수들이 포함되기도 하니까, 이 부분이 어렵지 않을까요

운형의 이미지

후후.. 답은 아니구요.

비슷한 류의 질문을 하나 던지고 싶어지네요.

구조체로 해도되는 것을 클래스로 구태여 지정하는 이유는 뭘까요?

Do you think that's the air you are breathing now?

이소희의 이미지

네트웍 프로그램에서는 실제로 전송되는 데이타의 정렬과 위치 사이즈가 정확해야 합니다. 
그래야 상대편에서 오류없이 동작을 할 수 있고요.. 
그러므로 날아가는 데이타의 구조를 정확히 표현해야 합니다. 위치 , 사이즈 
클래스는 보통 함수들이 포함되기도 하니까, 이 부분이 어렵지 않을까요

class도 함수 빼고 멤버변수들로만 구성하면 구조체처럼 데이터 정렬위치랑 싸이즈가 정확해 지지 않나요??

후후.. 답은 아니구요. 
비슷한 류의 질문을 하나 던지고 싶어지네요. 
구조체로 해도되는 것을 클래스로 구태여 지정하는 이유는 뭘까요?

저는 상속이 필요한 패턴을 할때 사용하고, 멤버 함수등이 많이 포함되어 있을때도 클래스를 사용하고, 단순한 데이터 저장용으로 사용할때는 구조체를 사용합니다.

내 삶속에 던져진 나.

dwfree74의 이미지

답변해주신 내용들을 쭈욱 읽어보면, 
성능이나, 사용성 면에서 구조체가 클래보다 좋은점은 보이지 않는거 같네요. 
그런데도, Win32 API내부 환경 변수들도 구조체를 사용하고, 네트워크 프로그래밍을 할때도 패킷구성을 주로 구조체를 이용해서 하는 이유는 뭘까요? 
단지, 전통적인 관례로 프로그래머가 구조체 사용하는걸 좋아하기 때문 일까요? 
지금까지 답변해주신 내용만으로 감사하게 생각하지만.. 조금 더 궁금해지내요. 
자꾸 허접꼬투리 질문 올려서 죄송합니다.

과거로부터 컴퓨터의 발전 과정,
MS 윈도우즈의 발전과정,
네트워크 프로그래밍의 발전과정,
컴퓨터 프로그래밍 언어/툴의 발전과정

등에 대한 배경 지식이 빠진 상태의 질문으로 보입니다.

저는 주로 마이크로 소프트웨어 잡지의
안윤호님 칼럼을 간간히 읽는 편입니다.

여러가지 유익한 배경지식을 알수가 있거든요.

kldp.net 에 많은 프로그래머들이 동참하기를 바라며...^^

chronon의 이미지

C++ 에서 구조체와 클래스는 public 이냐 private 이냐의 차이 이상은 없는 것으로 알고 있습니다.
보통은 멤버 함수가 필요 없는 클래스에 대해 이 클래스는 멤버 함수가 없다 하는 것을 명시적으로 보여주기 위해서 사용하는 것으로 알고 있습니다.

Win32API 나 네트웍 프로그래밍 등에서 구조체를 사용하는 것은 아마
같은 코드를 가지고 C와 C++에서 동시에 사용할 수 있게 하기 위한 것이 아닐까요?
세상에는 C++가 아닌 C로 Win32 프로그래밍을 하는 사람들도 있으니깐요.
당연 C++안 쓰고 C로 네트웍 프로그램 하는 사람들은 더 많구요.

zelon의 이미지

저도 윗분들과 비슷한 생각을 가지고 있습니다. 액션(멤버함수)이 있을 때는 class, 단순히 데이터를 저장할 때는 주로 struct 를 씁니다.

왠지 단어 자체에 대한 의미와도 맞아떨어지는 것 같고, 그리고 이 습관이 팀 작업에서도 그 의미를 잘 전달해 주는 것 같습니다.

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

이소희의 이미지

과거로부터 컴퓨터의 발전 과정, 
MS 윈도우즈의 발전과정, 
네트워크 프로그래밍의 발전과정, 
컴퓨터 프로그래밍 언어/툴의 발전과정 

등에 대한 배경 지식이 빠진 상태의 질문으로 보입니다.

위에 말씀하신것들에 대한 정보를 가지고 계시다면, 첨부파일로 올려주시면 안되겠는지요?
파일이 없으시다면, 알고 계시는 제대로 된 싸이트 링크라도 알려주셨으면 합니다.

알고 계시는 지식을 조금이나마 오픈해주시길 정중히 부탁드립니다.

내 삶속에 던져진 나.

wafe의 이미지

윈도우즈는 VMS의 개발자들이 개발하였고, 처음에는 VMS 유닉스가 그랬듯이 C로 개발되었으나 중간에 C++로 개발한다는 방침이 세워지는 바람에 모두 C++로 바꾸는 과정이 있었다고 알고 있습니다. 그래서 win32 api가 C 형태를 띄고 있는게 아닐까요.

Heejoon Lee

dwfree74의 이미지

Quote:

과거로부터 컴퓨터의 발전 과정, 
MS 윈도우즈의 발전과정, 
네트워크 프로그래밍의 발전과정, 
컴퓨터 프로그래밍 언어/툴의 발전과정 

등에 대한 배경 지식이 빠진 상태의 질문으로 보입니다. 

위에 말씀하신것들에 대한 정보를 가지고 계시다면, 첨부파일로 올려주시면 안되겠는지요?
파일이 없으시다면, 알고 계시는 제대로 된 싸이트 링크라도 알려주셨으면 합니다.

알고 계시는 지식을 조금이나마 오픈해주시길 정중히 부탁드립니다.


답변 한번 달았다가...^^;
마이크로소프트웨어 잡지 목록 정리 중입니다.

Quote:

2002년 1월호
260 운영체제 오딧세이 2002 - 첫 번째 이야기 1 |
운영체제 사기 유닉스 열전 안윤호

2002년 4월호
126 안윤호의 IT 인물열전 |‘미래는 우리를 기다리지 않는다’ 빌 조이

2002년 5월호
126 안윤호의 IT 인물열전 |마빈 민스키와 인공의 세계

2002년 6월호
126 안윤호의 IT 인물열전 |노버트 위너-사이버네틱스와 사회

2002년 7월호
124 안윤호의 IT 인물열전 | 리 펠젠스타인과 홈브루 컴퓨터 클럽

2002년 8월호
123 안윤호의 IT 인물열전 | 데이터 스모그와 오버클러킹

2002년 9월호
123 안윤호의 IT 인물열전 | 지식 사회와 피터 드러커

2002년 10월호
123 안윤호의 IT 인물열전 | 스톨만 이의(異議) 있다

2002년 11월호
119 안윤호의 IT 인물열전 | 코끼리와 벼룩

2002년 12월호
125 안윤호의 IT 인물열전 | 네트워크와 네트워크의 세상

2003년 1월호
120 안윤호의 IT 인물열전 | 리누스 토발즈와 리눅스

2003년 2월호
120 안윤호의 IT 인물열전 | 킬러 앱스와 우연의 왕국

2003년 3월호
120 안윤호의 IT 인물열전 | 포스트모더니즘 사회와 미디어 바이러스

2003년 4월호
126 안윤호의 IT 인물열전 | PARC 이전의 컴퓨터 업계

2003년 5월호
120 안윤호의 IT 인물열전 | 튜링과 에니그마

2003년 6월호
120 안윤호의 IT 인물열전 | 메멕스와 엥겔바트

2003년 7월호
117 안윤호의 IT 인물열전 |상상력 증폭기와 앨런 케이

2003년 8월호
88 안윤호의 IT 인물열전 |오타쿠와 프로그래머

2003년 9월호
85 안윤호의 IT 인물열전 | 작은 것이 아름답다

2003년 10월호
88 안윤호의 IT 인물열전 | 마이크로프로세서 전쟁 I

2003년11월호
89 안윤호의 IT 인물열전 | 마이크로프로세서 전쟁 Ⅱ

2003년 12월호
89 안윤호의 IT 인물열전 | 마이크로프로세서 전쟁 Ⅲ 안윤호

2004년 1월호
안윤호의 IT 인물열전 | 컴퓨팅 역사에서 바라본 AMD의 탄생

2004년 2월호
안윤호의 IT 인물열전 | 통제력, 또는 힘에 대하여

2004년 3월호
88 | 안윤호의 IT 인물열전 | 복잡한 것들

2004년 4월호
안윤호의 IT인물열전 | 개미의 푸가

2004년 5월호
89 | 안윤호의 IT 인물열전 | 마이크로소프트의 역사(1)

2004년 6월호
89 | 안윤호의 IT 인물열전 | 마이크로소프트의 역사(2)

2004년 7월호
94 | 안윤호의 IT 인물열전 | NT의 기술 유전자(?), VMS 연대기

2004년 8월호
329 | 안윤호의 IT 인물열전 | 비트맵 그래픽과 GUI

2004년 9월호
300| 안윤호의 IT 인물열전 | 윈도우의 역사

2004년 10월호
318 | 안윤호의 IT 인물열전 | 웹 브라우저의 역사

2004년 11월호
356 | 안윤호의 IT 인물열전 | 로봇 이야기

2004년 12월호
328 | 안윤호의 IT 인물열전 | 혁명이라는 이름이 뒤에 붙는 변화의 시기들

================================
위의 내용들은 www.imaso.co.kr 에서 가져왔습니다.
pdf를 포인트를 사용해서 다운로드 가능하나(포인트 거의 유료죠..^^)
pdf자료실에서 년도와 월을 선택해서 검색하시면 다운로드 받을 수 있습니다.
도서관에서 찾아서 보셔도 되구요.

===============================

kldp.net 에 많은 프로그래머들이 동참하기를 바라며...^^

ted78의 이미지

C라는 언어에는 class라는 키워드가 없기 때문입니다. C++를 공부하더라도 적어도 C와 C++이 어떻게 다른지 아는 것은 중요합니다.

C는 아직도 가장 많이 쓰이는 언어중 하나입니다. 일례로 물어보신 WIN32 API 스펙의 사용언어도 C입니다. 이걸 C++ 좋아하는 사람들을 위해 더 객체지향적으로 랩핑한 라이브러리가 그 유명한 MFC구요. 네트워크 프로그래밍도 마찬가집니다.

나는 생각하는 갈대다?

ㅡ,.ㅡ;;의 이미지

일단 구조체는 C,C++에서 모두사용가능하다
클레스는 그렇지 않다
또한 처음접하는사람들이 클레스란 말자체를 어려워하는사람들도 좀되는거 같다.

구조체는 자료형태만을 표현하고 만들어냄으로써 그형태가 간단명료하다
클레스는 그렇지 않다
예를들면 어떤사람이 쇠고기를 사고 싶은데 쇠고기전문점으로 가는게 좋을것이다
대형마트에 갔다 무엇무엇잡다한것다있고 쇠고기가 어느구석에서 파는지도 잘찾아봐야할것이다
쇠고기전문점이 대형마트보다 도데체 좋은점이 뭐냐고 묻는거나 마찬가지죠..

더구나 구조체에서도 함수포인터를 적제하고 하위구조체에 함수를 상속시킬수있습니다.
이러니 클레스가 있음에도 불구하고 구조체를 계속사용하게되고 또한 구조체가 사라지지 않는이유죠.


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

Gethoper의 이미지

:)

cbycby의 이미지

운형 wrote:
후후.. 답은 아니구요.

비슷한 류의 질문을 하나 던지고 싶어지네요.

구조체로 해도되는 것을 클래스로 구태여 지정하는 이유는 뭘까요?

c++ programming style에 근거한거 아닐까요?
struct의 경우 struct내에 member function을 넣는것이 이상하게 보일 수 있기때문에(C 프로그래머에서 C++로 전환하는 대상자들에 안함)
class로 쓰는 경형이 있는것 같습니다.

http://www.korone.net QT 커뮤니티 사이트

fibonacci의 이미지

요새는 OOP로 프로그래밍을 시작할수도 있으니까
이런 질문도 나오는군요. :o

No Pain, No Gain.

이소희의 이미지

답변주신 모든분들께 감사의 말씀 올립니다. ^^

메리 크리스마스 되세요 ~~~~!

내 삶속에 던져진 나.

saxboy의 이미지

Quote:
요새는 OOP로 프로그래밍을 시작할수도 있으니까
이런 질문도 나오는군요.

호호호, 원츄!

이소희의 이미지

요새는 OOP로 프로그래밍을 시작할수도 있으니까 
이런 질문도 나오는군요.

ㅡㅡ;

저 역시 C를 배우고 C++을 배웠습니다.
직업도 C/C++로 밥벌이를 하는 서버 프로그래머입니다.
너무도 어설프게 공부를 했던거 같았고, 문득 막연히 사용하던 구조체의 효용성이 진짜 뭘까? 하는 궁금증이 생겨 질문을 올리게 되었습니다.

('') 위에 리플에 원츄~라는 단어까지 있는걸 보니까.
기분이 좀 않좋네요. ㅡㅡ;

내 삶속에 던져진 나.

zelon의 이미지

전 프로그램을 본격적으로 배우기 시작했던것이 C++ 부터입니다. 근데 OOP 는 아니죠 ㅎㅎ

아무래도 OOP 개념부터 확실히 알고 프로그래밍을 시작하기는 조금 재미없지 않나요? 일단 Hello World 부터 찍고 시작해야죠. 설마 Hello World 를 처음부터 OOP 로 가르켜주는 서적은 못 본 것 같은데요 ^^;;

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

musiphil의 이미지

C에는 어차피 class라는 게 없고요.

C++에서 class는 struct와 똑같은데 다만 처음에 아무 말도 없으면 private으로 시작하는 것만이 다를 뿐이죠. 실제로 뭔가 더 "있어 보이는" 느낌을 주긴 하지만, class나 struct나 어느 한 쪽이 다른 한 쪽보다 더 우수하거나 뛰어난 것은 하나도 없습니다. struct라고 더 빠르거나 멤버의 위치, 크기 등이 더 구체적으로 명확히 정해지는 것도 아니고, 반대로 생성자나 소멸자, 멤버 함수, 가상 멤버 함수 등을 class에서만 쓸 수 있고 struct에서 못 쓰는 것도 아닙니다. 마치 template <class T>와 template <typename T>가 똑같은 것과 비슷하다고나 할까요. (괜히 아까운 키워드 하나 잡아먹었다는 생각도 듭니다. class라는 변수명 쓰는 C 프로그램도 꽤 있는데. -_-;)

운형의 이미지

이소희 wrote:

('') 위에 리플에 원츄~라는 단어까지 있는걸 보니까.
기분이 좀 않좋네요. ㅡㅡ;

요즘 게시판에 댓글 잘 안다는데요... 여기는 두번이나.. 후후.. 것두 쓸데없없어보이는거..

원츄가 무슨뜻으로 쓰이길래 기분까지 나빠지는 건가요.?

그리고.. struct와 class가 단순히 키워드 차이는 아니라고 알고 있는데, class에 메소드가 없더라도, 가상 함수 테이블이 생성되는 거 아닌가요? c++이 c에 비해 조금이라도 인스트럭션이 늘어나는 것도 이것 때문인걸로 알고 있는데요.

허접한 씨프로그래머 였습니다.

Do you think that's the air you are breathing now?

익명 사용자의 이미지

구조체와 클래스와의 차이는 이제 상속정도 된다고 하더군요...
이것도 지금 되는 지는 모르겠습니다만...구조체는 상속을 지원하지 않고 클래스는 상속이 된다고 하더군요...
그런데 씨샵에서 그럼 sealed클래스와 구조체의 차이가 뭐냐 이러면 저도 궁금합니다.쿨럭...

doldori의 이미지

운형 wrote:
그리고.. struct와 class가 단순히 키워드 차이는 아니라고 알고 있는데, class에 메소드가 없더라도, 가상 함수 테이블이 생성되는 거 아닌가요? c++이 c에 비해 조금이라도 인스트럭션이 늘어나는 것도 이것 때문인걸로 알고 있는데요.

지나가던 과객 wrote:
구조체와 클래스와의 차이는 이제 상속정도 된다고 하더군요...
이것도 지금 되는 지는 모르겠습니다만...구조체는 상속을 지원하지 않고 클래스는 상속이 된다고 하더군요...

어디서 어떤 얘기를 들으셨는지는 모르겠으나 전혀 근거없는 얘기입니다.
바로 위에 musiphil님이 쓰신 대로 디폴트 접근 권한과 디폴트 상속 모드 외에는
아무런 차이가 없습니다.
zelon의 이미지

운형 wrote:

그리고.. struct와 class가 단순히 키워드 차이는 아니라고 알고 있는데, class에 메소드가 없더라도, 가상 함수 테이블이 생성되는 거 아닌가요? c++이 c에 비해 조금이라도 인스트럭션이 늘어나는 것도 이것 때문인걸로 알고 있는데요.

가상 함수 테이블은 virtual function 가 있어야만 만들어집니다. class A 를 sizeof() 해보시면, 아무리 일반 function 을 늘여도 크기는 그대로 인데, virtual function 이 하나 이상 추가되면 특정 바이트의 크기(일반적으로 4바이트)가 늘어나죠. ^^ 즉, 가상 함수가 있어야 가상 함수 테이블이 생성됩니다.

Quote:

씨샵에서 그럼 sealed클래스와 구조체의 차이가 뭐냐 이러면 저도 궁금합니다.쿨럭..

C# 에서 기본적으로 class 를 new 하면 heap 에 생성되고, struct 를 new 하면 stack 에 생성됩니다.

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

chadr의 이미지

저같은 경우에는 뭔가 큰일을 하는것은 class로.. 단순 데이터 패키징및 저장 목적은 struct로 합니다..

파일단위로 쪼개는 단위가 클래스 단위로 쪼개는 습관 때문이기도 하구요..

(abcd라는 클래스를 작성한다면 abcd.h, abcd.cpp 이렇게 작성하고 한 파일에는 한 클래스만 넣거든요.. :oops: )

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

ㅡ,.ㅡ;;의 이미지

제가볼때는 class 는 변수,함수군 들의 관리 차원에서 나왔다고 생각되는군요.그런후 C++로 이름한..
개발자를 사용자로 만들기위한 전략도 내포된듯한 느낌을 받는..

http://home.postech.ac.kr/~istpark/htmdir/humor/c++.html
.


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

saxboy의 이미지

Quote:
('') 위에 리플에 원츄~라는 단어까지 있는걸 보니까.
기분이 좀 않좋네요. ㅡㅡ;

아. 기분이 나쁘셨다면 죄송합니다. "전혀" 나쁜뜻은 없었답니다.

하지만 확실한 것은 처음에 이소희님께서 올리셨던 질문을 보고 누구라도 처음에 드는 느낌은 "C에 익숙하지 않은 상태에서 C++를 알게 되었구나"라는 것이지요.

alwaysN00b의 이미지

코에이 wrote:
C++에서 본질적으로 struct와 class는 같습니다.

C로 된 코드에서도 돌아갈 수 있게 하위호환성을 위해서 struct를 쓰고요

C++에서만을 주제로 친다면

유일한 차이점은 기본 권한이 class는 private:이고 struct는 public:입니다.

C++에서 virtual 함수를 가지지 않는 이상 struct와 class는 같은 크기를 가집니다.

멤버함수를 위해서 따로 공간을 가지는 것은 아닙니다.

역으로 생각해보면 struct에도 virtual 함수가 들어갈 수 있으니 같은 내용이 됩니다.

정답입니다.

언제나 시작

이소희의 이미지

아. 기분이 나쁘셨다면 죄송합니다. "전혀" 나쁜뜻은 없었답니다. 

하지만 확실한 것은 처음에 이소희님께서 올리셨던 질문을 보고 누구라도 처음에 드는 느낌은 "C에 익숙하지 않은 상태에서 C++를 알게 되었구나"라는 것이지요.

원추~ 리플보고 처음엔 자격지심에 맘상했었는데.... :oops:
맞는 말씀입니다. 요즘 프로그래밍을 하면서 제가 느끼는건 ' 내가 몰라도 너무 모르는구나' 하는 마음입니다.
덕분에 다시 한번 반성하게 되었습니다.
그리고 이제는 예전 보다 많은 것을 아는 상태에서 구조체와 클래스를 쓸 수 있게 되었네요.
답변주신분들께 다시한번 감사의 말씀 올립니다.
:D 메리크리스마스~~~~ :wink:

내 삶속에 던져진 나.

doldori의 이미지

자격지심 가지실 필요 없어요. C++의 고수들은 C++을 배우기 위해 C를 배우지는
말라고 하더군요. C++에 익숙하지 않은 상태에서 C#을 알게 되는 것이 별로
이상하지 않은 것과 마찬가지지요.

ㅡ,.ㅡ;;의 이미지

doldori wrote:
자격지심 가지실 필요 없어요. C++의 고수들은 C++을 배우기 위해 C를 배우지는
말라고 하더군요. C++에 익숙하지 않은 상태에서 C#을 알게 되는 것이 별로
이상하지 않은 것과 마찬가지지요.

사실 그렇죠..C++은 있는것을 사용하는 식이죠.
그러나 만일 Window 프로그램할것이라면 맞는말일수도 하지만.
더system적인 프로그램하려면 잘못된것같군요.


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

죠커의 이미지

지나가던 과객 wrote:
구조체와 클래스와의 차이는 이제 상속정도 된다고 하더군요...
이것도 지금 되는 지는 모르겠습니다만...구조체는 상속을 지원하지 않고 클래스는 상속이 된다고 하더군요...
그런데 씨샵에서 그럼 sealed클래스와 구조체의 차이가 뭐냐 이러면 저도 궁금합니다.쿨럭...

상속이 차이난다는 말은 의미를 모르겠습니다. 표준에서도 그런 차이를 규정하고 있지 않는 걸로 압니다.

개인 적인 기준은 private: public: 타이핑을 귀찮아해서 어느 쪽이 더 많을 것 같은지에 따라서 struct와 class를 구별해서 이용해 왔습니다. :-)

myueho의 이미지

ㅡ,.ㅡ;; wrote:
doldori wrote:
자격지심 가지실 필요 없어요. C++의 고수들은 C++을 배우기 위해 C를 배우지는
말라고 하더군요. C++에 익숙하지 않은 상태에서 C#을 알게 되는 것이 별로
이상하지 않은 것과 마찬가지지요.

사실 그렇죠..C++은 있는것을 사용하는 식이죠.
그러나 만일 Window 프로그램할것이라면 맞는말일수도 하지만.
더system적인 프로그램하려면 잘못된것같군요.

전혀 찬동할 수 없습니다. :evil:
theuhm의 이미지

ㅡ,.ㅡ;; wrote:
doldori wrote:
자격지심 가지실 필요 없어요. C++의 고수들은 C++을 배우기 위해 C를 배우지는
말라고 하더군요. C++에 익숙하지 않은 상태에서 C#을 알게 되는 것이 별로
이상하지 않은 것과 마찬가지지요.

사실 그렇죠..C++은 있는것을 사용하는 식이죠.
그러나 만일 Window 프로그램할것이라면 맞는말일수도 하지만.
더system적인 프로그램하려면 잘못된것같군요.

C++은 C의 '거의' 완전한 슈퍼셋이므로, C로 할 수 있는 일이라면 무엇이든 C++로 할 수 있다고 생각하는데요. 오히려 C++이 훨씬 더 expressive 한 면이 장점이 될 수 있다고 생각합니다 :)
C++보다 더 low-level한 언어는 C가 아니라 어셈블리가 유일하지 않을까 하네요.

..

doldori의 이미지

흠... 또다시 C와 C++의 flame war가 발생할 조짐이 있어 말씀드립니다.
제가 처음에 말한 의도는 "어차피 C++은 (논쟁의 소지는 있으나) C의 수퍼셋이므로
C++을 배우면 자연히 C도 알게 되는 것이니 일거양득이다"는 뜻이 아니었습니다.
저는 오히려 C와 C++은 전혀 다른 언어라고 생각하며, 두 언어가 비슷한 모습을
갖고 있는 것은 역사적인 이유로 인한 우연성 이상은 아니라고 보는 거죠. 앞으로
차이는 더욱 벌어질지도 모르고 솔직히 그래도 상관없다고 봅니다.

C++이 multi-paradigm 지향의 언어라고는 하지만 단지 보다 엄격한 타입 체킹,
안전성 등만을 목적으로 C++을 사용하려는 사람은 거의 없을 거라고 봅니다.
즉 데이터 추상화, OOP, generic programming, STL 같은 것을 목적으로 하는
사람이 훨씬 많을 거라는 거죠. 이렇게 C에서는 지원하지 않는 언어적 특징들을
목적으로 한다면 C를 배울 필요는 없으며 또한 그래서도 안됩니다.
(노파심에 말씀드립니다만 "지원하지 않는다"는 뜻은 이런 것들을 C로 구현하려면
불가능하거나 보통 이상의 기술과 노력이 든다는 뜻입니다.)

요약하면 제 뜻은 이렇습니다. "C가 필요하면 C를 배우고, C++이 필요하면 처음부터
C++을 배우십시오."

ps. 저는 C와 C++을 모두 좋아합니다. 현업에서는 주로 C++을 쓰기는 하지만 C에
대해서도 계속 관심을 갖고 있습니다. 그래서 전웅님의 책이 빨리 나오기를 기다리고
있답니다.

ps2. 시스템 프로그래밍에 C와 C++ 중 어느 것이 더 적합하냐는 저의 관심사항이 아닙니다.

pool007의 이미지

습관일거 같습니다.

원래 C에서는 데이터를 구조적으로 저장하는데
구조체를 사용하게 되었고,

C++은 여기에 그 데이터에 대한 연산까지를 하나로
묶어 클래스를 만들게 되었죠.

그래서 C를 하다가 C++을 하게 된 경우에는,
데이터를 저장한다고 하면 습관적으로 struct가 나오게
될 수 있을겁니다. 그래서 쓰는 정도의 의미만 있을거라고
생각하고, 사실 둘간의 차이는 private/public 이런 것 외에는 없죠.

마찬가지로 제 경우는 C->C++->JAVA의 순으로 흘러왔는데
JAVA를 하면서 단지 값만 저장할게 뻔한데

public class xxx{
   public int x;
   public int y;
}

이런식으로 코드를 쓰다보면 왜 구조체 같은게 없는거지?
라고 답답해 하기도 합니다... 워낙 습관이 되서요.

연산을 추상화하느냐, 데이터 멤버에 대한 접근역시 추상화해서
코드 수정의 여지를 남겨두느냐에 대해서는 개인차가 있을텐데요..
특히나 데이터 멤버도 public이었으면 좋겠고 연산같은건
만들기 싫다면 더욱이 구조체를 자꾸 쓰고 싶어져요.
그러나 그 일을 클래스로 했어도 아무 상관은 없는일이죠.

--
Passion is like genius; a miracle.

cppig1995의 이미지

1 페이지에 Hello, World 프로그램을
OOP를 안 쓰고 작성하니까
OOP로 프로그래밍을 시작하는
없다고 하신 분 ㅡ,.ㅡ

다음의 소스는 뭡니까?

cout << "Hello, World" << endl;

분명히 cout 는 객체입니다.

Quote:
typedef basic_ostream<char> ostream;

ostream cerr, clog, cout;

참고로,

산양미디어 C++ Bible wrote:
14장. 생성자와 소멸자 - 7절. Bye, Crazy World!

//CrazyWorld.cpp - List 14.7

#include <iostream>

using namespace std;

class CrazyWorld
{
    public :

    CrazyWorld()
    {
        cout << "Bye, Crazy World!" << endl;
    }
}

int main()
{
    CrazyWorld GoodBye;

    return 1;
}

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

chronon의 이미지

C++ 에서 cout 안 쓰고 printf 쓴다고 해서 문제될 것은 없지요.
좀 오래된 책들에서는 C++ 에서 fstream 안 쓰고 FILE* 로 파일 입출력을 가르치더군요.
그리고 꽤 많은 사람들이 그렇게 쓰기도 합니다.

C++ 에서는 기본 자료형을 포함해 모든 변수가 객체로써 만들어 지는 것으로 알고 있습니다.
그렇다고 해서 "C++ 에서는 OOP 없이 프로그래밍 할 수 없다" 라고 하면 단순한 말꼬리잡기가 되어버렬 것 같다는 생각이 드는군요.

여하튼,
C++ 의 세계에서 class와 struct 의 차이는 public 이나 private 이냐의 차이밖에 없고,
C#이나 그 외에 다른 언어로 가면 조금 달라지는 모양이군요..

ㅡ,.ㅡ;;의 이미지

theuhm wrote:
ㅡ,.ㅡ;; wrote:
doldori wrote:
자격지심 가지실 필요 없어요. C++의 고수들은 C++을 배우기 위해 C를 배우지는
말라고 하더군요. C++에 익숙하지 않은 상태에서 C#을 알게 되는 것이 별로
이상하지 않은 것과 마찬가지지요.

사실 그렇죠..C++은 있는것을 사용하는 식이죠.
그러나 만일 Window 프로그램할것이라면 맞는말일수도 하지만.
더system적인 프로그램하려면 잘못된것같군요.

C++은 C의 '거의' 완전한 슈퍼셋이므로, C로 할 수 있는 일이라면 무엇이든 C++로 할 수 있다고 생각하는데요. 오히려 C++이 훨씬 더 expressive 한 면이 장점이 될 수 있다고 생각합니다 :)
C++보다 더 low-level한 언어는 C가 아니라 어셈블리가 유일하지 않을까 하네요.


할수 있다 할수 없다의 차이가 아니죠..C++로 물론할수는 있겠죠..
그러면 C++로 할수 있는 모든일을 C도 할수 있기는 마찬가집니다.
이전에 말했던 말을또하게 되었지만..
다할수있다는건 특화되지못했다는말과 같게됩니다.즉,영양제500개던져주고 니가필요한것 다있으니 찾아먹어라..여기에 다있다..
일단 기존의 SOURCE 등도 그렇고 시스템적인부분은 C가 훨씬많아보이는군요.


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

ux의 이미지

ㅡ,.ㅡ;; wrote:
제가볼때는 class 는 변수,함수군 들의 관리 차원에서 나왔다고 생각되는군요.그런후 C++로 이름한..
개발자를 사용자로 만들기위한 전략도 내포된듯한 느낌을 받는..

http://home.postech.ac.kr/~istpark/htmdir/humor/c++.html
.

Forbidden

You don't have permission to access /~istpark/htmdir/humor/c++.html on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

라네요 -_-;; 무슨 내용일까? 궁금합니다...^^

@UX... Vnn~

doldori의 이미지

ux wrote:
ㅡ,.ㅡ;; wrote:
제가볼때는 class 는 변수,함수군 들의 관리 차원에서 나왔다고 생각되는군요.그런후 C++로 이름한..
개발자를 사용자로 만들기위한 전략도 내포된듯한 느낌을 받는..

http://home.postech.ac.kr/~istpark/htmdir/humor/c++.html
.

Forbidden

You don't have permission to access /~istpark/htmdir/humor/c++.html on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

라네요 -_-;; 무슨 내용일까? 궁금합니다...^^


이상하네요. 저는 잘 보이는데...
http://www.enzoy.pe.kr/doc/doc_fun/fuck_cpp.htm에서 보셔도 됩니다.
Bjarne이 자기 홈페이지에서 언급할 정도로 유명한 유머인데,
(http://www.research.att.com/~bs/bs_faq.html#IEEE)
저도 이거 처음 봤을 때 배꼽 잡고 웃었습니다.
zelon의 이미지

cppig1995 wrote:
1 페이지에 Hello, World 프로그램을
OOP를 안 쓰고 작성하니까
OOP로 프로그래밍을 시작하는
없다고 하신 분 ㅡ,.ㅡ

다음의 소스는 뭡니까?

cout << "Hello, World" << endl;

분명히 cout 는 객체입니다.

Quote:
typedef basic_ostream<char> ostream;

ostream cerr, clog, cout;

참고로,

산양미디어 C++ Bible wrote:
14장. 생성자와 소멸자 - 7절. Bye, Crazy World!

//CrazyWorld.cpp - List 14.7

#include <iostream>

using namespace std;

class CrazyWorld
{
    public :

    CrazyWorld()
    {
        cout << "Bye, Crazy World!" << endl;
    }
}

int main()
{
    CrazyWorld GoodBye;

    return 1;
}

^^; 제가 의도한 소스는 두번째 꺼였구요. 그러나 Hello World 를 뜻한 것은 처음부터( ! )를 말하는 것이었습니다. 보시다시피 14장에서 나오지 않습니까? 그만큼 OOP 가 바로 시작하는 것(1장부터 저 두번째 코드를 가르치는것)은 어려움을 얘기한 거였죠 ^^

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

musiphil의 이미지

cppig1995 wrote:
1 페이지에 Hello, World 프로그램을
OOP를 안 쓰고 작성하니까
OOP로 프로그래밍을 시작하는
없다고 하신 분 ㅡ,.ㅡ

다음의 소스는 뭡니까?

cout << "Hello, World" << endl;

분명히 cout 는 객체입니다.

Quote:
typedef basic_ostream<char> ostream;

ostream cerr, clog, cout;


사족입니다만, 객체(object)를 썼다고 전부 객체지향(object-oriented)이라고 부르지는 않습니다. int, char 등도 공식적으로 object이며, C 표준에서도 object라는 말을 사용합니다. 심지어는 단지 클래스와 멤버 함수를 썼다고 해서 이를 object-oriented라고 부르지도 않는 것으로 알고 있습니다.

객체지향(object-oriented)의 특징을 다음 네 가지로 얘기합니다.

  • dynamic lookup
  • abstraction
  • subtyping
  • inheritance
[/]
jam02의 이미지

neogeo wrote:
좋은 점 나쁜 점 이라니 -_- 뭔가 좀 이상하군요.

구조체의 용도와 class 의 용도는 명백히 다르므로 비교 자체가 조금 이상한 것이라고 봅니다.

C++ 에서 struct 를 굳이 쓴 것은 아마도 특별한 이유가 있어서 겠지요.

C 라면 어차피 class 가 없구요.

( struct 만의 class 대비해서 특별한 성질이라고 해봐야 -_- 메모리 단위로 접근 정도 랄까.. 밖엔 제가 떠오르는게 없네요. 다른 분들이 좀더 잘 설명 해주시겠죠. )

그런데 struct 가 class 보단 메모리 덜 먹지 않나요. ( 아닌가 ㅡ,.ㅡ. 일단 class 에서 memeber function 의 code 공간위치가 다르긴 하지만 적어도 -_- 다른 정보가 좀 더 들어가는 걸로 아는데. )

속도가 빠른건 class 의 기본 성질 때문입니다.

일단 생성시 constructor 가 수행되고 사라져야 할땐 destructor 가 수행되며,

여러가지 연산에 대해 operator 가 따로 수행되고 ( 뭐 copy constructor 라던가 상황에 따라 여라가지 -_- 행동을 하겠죠 )

struct 야 -_- 어차피 저런것을 전혀 사용하지 않으니 생성과 삭제, 사용하는데 있어서는 조금이라도 더 빠르겠지요. ( 하지만 큰 차이는 없다고 들었습니다. )

제가 경험한 바로는 constructor와 destructor의 차이 때문입니다.
상황에 따라 다르게 적용되는 부분입니다.

제가 클래스로 디자인했다가 구조체로 바꾼 부분은
백만번 이상.. 정말 빈번하게 생성하고 없애는 경우의 자료인데요.

정의된 클래스의 메모리 공간을 new를 이용해서 메모리를 할당받고 delete로 해제하는 경우에, 아무것도 수행하지 않는 constructor나 destructor가 있다고 하더라도.. 호출되는 자체도 엄청난 오버헤드가 되는 상황입니다.

그래서 그러한 자료를 관리하는 부분은 클래스로 구성하고,
각각의 자료들을 구조체에 담아 malloc으로 할당 받습니다.

네트워크의 경우도 이러한 경우인 것 같네요.

hyperhidrosis의 이미지

Quote:

정의된 클래스의 메모리 공간을 new를 이용해서 메모리를 할당받고 delete로 해제하는 경우에, 아무것도 수행하지 않는 constructor나 destructor가 있다고 하더라도.. 호출되는 자체도 엄청난 오버헤드가 되는 상황입니다.

이해가 가지 부분이네요.

구현의 문제이기는 하지만, "멤버 변수가 없는 클래스"와 구조체 구현이
내부적으로 다를 이유가 있나요?

class A
{
int i;
};
struct B
{
int i;
}

A *a = new A;
B *b = (B*)malloc(sizeof(B));

이 둘이 "실질적인" 구현에 차이가 있나요?

corba의 이미지

ㅡ,.ㅡ;; wrote:
할수 있다 할수 없다의 차이가 아니죠..C++로 물론할수는 있겠죠..
그러면 C++로 할수 있는 모든일을 C도 할수 있기는 마찬가집니다.

저도 그렇게 생각했었는데 요즘 템플릿메타프로그래밍을 보고 생각이 바뀌고 있습니다.
메타프로그래밍을 거의 써먹을 일이 없었는데 요즘 구조체를 COM으로 반자동 래핑 해주게 하는 라이브러리를 만드는 일을 하면서 유용하게 써먹고 있습니다.
corba의 이미지

jam02 wrote:
제가 경험한 바로는 constructor와 destructor의 차이 때문입니다.
상황에 따라 다르게 적용되는 부분입니다.

제가 클래스로 디자인했다가 구조체로 바꾼 부분은
백만번 이상.. 정말 빈번하게 생성하고 없애는 경우의 자료인데요.

정의된 클래스의 메모리 공간을 new를 이용해서 메모리를 할당받고 delete로 해제하는 경우에, 아무것도 수행하지 않는 constructor나 destructor가 있다고 하더라도.. 호출되는 자체도 엄청난 오버헤드가 되는 상황입니다.

그래서 그러한 자료를 관리하는 부분은 클래스로 구성하고,
각각의 자료들을 구조체에 담아 malloc으로 할당 받습니다.

네트워크의 경우도 이러한 경우인 것 같네요.


struct던 class던 명시적으로 생성자를 할당해 주지 않으면 private, public 외의 차이는 없다고 알고 있습니다.
반대로 명시적으로 생성자를 할당해 줘도 차이는 없구요.
구조체를 new로 할당할 수도 있으니까요.
kewlbear의 이미지

생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

corba의 이미지

kewlbear wrote:
생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

예, 제가 좀 의도를 잘못 적었네요. :)
제가 하고 싶었던 말은 new를 하던 malloc을 하던 class와 struct는 차이가 없다는 거지요.
결국 default가 public, private인 것만 빼면 물리적으로 차이가 없다는 말을 하고 싶었던 거죠.
creativeidler의 이미지

Hello World의 의미는 그 언어로 된 코드를 처음 사용해서 실행까지 해본다는 의미가 가장 큰 것이고 그건 언어의 문법을 배우기 전에 단순히 익숙해지기 위한 과정일 뿐입니다. 영어를 배울 때 명사가 뭔지 형용사가 뭔지도 모르지만 Good morning부터 배우는 거랑 같은 거죠. 그러니 Hello World는 뭘로 가르치든 그게 OOP부터 시작하지 않는다는 얘기는 될 수 없습니다.

제가 기억하기로 그런 의미에서 OOP부터 가르치는 책이 몇 권 있었습니다. Hello World는 어땠는지 모르겠지만 심지어 기본 자료형도 배우기 전에 Object의 개념부터 가르치는 책도 있었고 if/else, for 등의 제어구조, 함수 등 SP의 개념들보다 Object의 개념을 먼저 배우는 책은 적지 않았습니다. 얼핏 기억나는 책 제목은 Onto C++이군요. 자바 책도 두어 권 그런 책을 본 것 같습니다. 그리고 제가 기억하기로 모두 좋은 평가를 받는 책들이었죠.

kenny007one의 이미지

아직 C++의 개발 이유를 모르시는 분이군요..

C++은 괜시리 프로그래밍을 어렵게 해서 아무나 섭불리 범접못하게 할려는 목적입니다.

클래스쓰고 거기에 private public protected friend 쓰기 시작하면 도저히 누구도 분석하기 힘듭니다.

현존 최고의 복잡성을 갖는 언어입니다.

hyperhidrosis의 이미지

kewlbear wrote:
생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

생성자를 선언하지도 않았는데 생성자가 호출되지는 않겠지요.
그런점에서 멤버 변수가 없는 클래스는 내부적으로 구조체와
동일하게 처리될 것이라고 예상할 수 있습니다.

htna의 이미지

kenny007one wrote:
아직 C++의 개발 이유를 모르시는 분이군요..

C++은 괜시리 프로그래밍을 어렵게 해서 아무나 섭불리 범접못하게 할려는 목적입니다.

클래스쓰고 거기에 private public protected friend 쓰기 시작하면 도저히 누구도 분석하기 힘듭니다.

현존 최고의 복잡성을 갖는 언어입니다.


"현존 최고의 복잡성을 갖는 언어"
인지에는 관심이 없지만.

"C++은 괜시리 프로그래밍을 어렵게 해서 아무나 섭불리 범접못하게 할려는 목적"
에는 재밌는 관심과 동조를 하는 편입니다.

그래도 언어 타이핑의 편리성땜시 C보다는 C++이 편하더군요...

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

kewlbear의 이미지

hyperhidrosis wrote:
kewlbear wrote:
생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

생성자를 선언하지도 않았는데 생성자가 호출되지는 않겠지요.
그런점에서 멤버 변수가 없는 클래스는 내부적으로 구조체와
동일하게 처리될 것이라고 예상할 수 있습니다.

프로그래머가 생성자를 선언하지 않더라도 new를 사용하면 컴파일러는 생성자를 호출해야하기 때문에 묵시적으로 생성자를 추가합니다.

ed.netdiver의 이미지

packing의 경우는 어떤가요?
class가 packing 가능한가요?

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

hyperhidrosis의 이미지

kewlbear wrote:
hyperhidrosis wrote:
kewlbear wrote:
생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

생성자를 선언하지도 않았는데 생성자가 호출되지는 않겠지요.
그런점에서 멤버 변수가 없는 클래스는 내부적으로 구조체와
동일하게 처리될 것이라고 예상할 수 있습니다.

프로그래머가 생성자를 선언하지 않더라도 new를 사용하면 컴파일러는 생성자를 호출해야하기 때문에 묵시적으로 생성자를 추가합니다.

정의되어 있지도 않고 구현되어 있지도 않은 생성자를
컴파일러가 굳이 묵시적으로 만들고 이를 호출해서
속도와 메모리를 잡아 먹을 이유가 없습니다.

이러한 것은 최적화가 잘된 컴파일러라면 내부적으로 다
삭제를 해버릴 껍니다.

kewlbear의 이미지

hyperhidrosis wrote:
kewlbear wrote:
hyperhidrosis wrote:
kewlbear wrote:
생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

생성자를 선언하지도 않았는데 생성자가 호출되지는 않겠지요.
그런점에서 멤버 변수가 없는 클래스는 내부적으로 구조체와
동일하게 처리될 것이라고 예상할 수 있습니다.

프로그래머가 생성자를 선언하지 않더라도 new를 사용하면 컴파일러는 생성자를 호출해야하기 때문에 묵시적으로 생성자를 추가합니다.

정의되어 있지도 않고 구현되어 있지도 않은 생성자를
컴파일러가 굳이 묵시적으로 만들고 이를 호출해서
속도와 메모리를 잡아 먹을 이유가 없습니다.

이러한 것은 최적화가 잘된 컴파일러라면 내부적으로 다
삭제를 해버릴 껍니다.

Effective C++의 45번 항목을 한번 읽어보시기 바랍니다. 클래스에 생성자가 없으면 필요한 경우 기본 생성자를 컴파일러가 만들게 되어 있습니다.

TC++PL 10.4.2에는 다음과 같은 문장이 나옵니다.

Quote:
If a user has declared a default constructor, that one will be used; otherwise, the compiler will try to generate one if needed and if the user hasn't declared other constructors.
cocas의 이미지

kewlbear wrote:
hyperhidrosis wrote:
kewlbear wrote:
hyperhidrosis wrote:
kewlbear wrote:
생성자를 명시적으로 정의하느냐의 문제가 아니라 malloc을 쓰느냐 new를 쓰느냐에 따른 차이입니다. malloc을 쓰면 생성자가 호출되지 않고 new를 쓰면 생성자가 호출되는 것이지요. 자세한 내용은 More effective C++을 참조하세요.

생성자를 선언하지도 않았는데 생성자가 호출되지는 않겠지요.
그런점에서 멤버 변수가 없는 클래스는 내부적으로 구조체와
동일하게 처리될 것이라고 예상할 수 있습니다.

프로그래머가 생성자를 선언하지 않더라도 new를 사용하면 컴파일러는 생성자를 호출해야하기 때문에 묵시적으로 생성자를 추가합니다.

정의되어 있지도 않고 구현되어 있지도 않은 생성자를
컴파일러가 굳이 묵시적으로 만들고 이를 호출해서
속도와 메모리를 잡아 먹을 이유가 없습니다.

이러한 것은 최적화가 잘된 컴파일러라면 내부적으로 다
삭제를 해버릴 껍니다.

Effective C++의 45번 항목을 한번 읽어보시기 바랍니다. 클래스에 생성자가 없으면 필요한 경우 기본 생성자를 컴파일러가 만들게 되어 있습니다.

TC++PL 10.4.2에는 다음과 같은 문장이 나옵니다.

Quote:
If a user has declared a default constructor, that one will be used; otherwise, the compiler will try to generate one if needed and if the user hasn't declared other constructors.

TC++PL에서 그 뒤의 내용도 살펴보면 컴파일러가 만든 기본 생성자는 해당 클래스의 클래스 타입 멤버들의 기본 생성자와 base class의 기본 생성자를 호출 한다고 되어 있습니다. 여기서 클래스가 아닌 멤버들의 초기화는 수행하지 않고요.

C++에서 구조체에 malloc을 쓰려면 상속도 없고 내부에 클래스 멤버도 아닌 경우만 가능합니다. 이런 경우라면 컴파일러가 생성하는 기본 생성자에도 하는 일은 없고 최적화가 알아서 되지 않을까요?

doldori의 이미지

kewlbear wrote:
hyperhidrosis wrote:
정의되어 있지도 않고 구현되어 있지도 않은 생성자를
컴파일러가 굳이 묵시적으로 만들고 이를 호출해서
속도와 메모리를 잡아 먹을 이유가 없습니다.

이러한 것은 최적화가 잘된 컴파일러라면 내부적으로 다
삭제를 해버릴 껍니다.

Effective C++의 45번 항목을 한번 읽어보시기 바랍니다. 클래스에 생성자가 없으면 필요한 경우 기본 생성자를 컴파일러가 만들게 되어 있습니다.

TC++PL 10.4.2에는 다음과 같은 문장이 나옵니다.

Quote:
If a user has declared a default constructor, that one will be used; otherwise, the compiler will try to generate one if needed and if the user hasn't declared other constructors.

네, kewlbear님의 말씀이 원칙적으로 맞습니다. 그 점은 hyperhidrosis님도 알고
계신 듯 하고요. 그런데 표준의 내용은 언어의 정의를 추상적으로 정의한 것이고,
그것을 어떻게 구현하느냐는 별개의 문제라고 할 수 있겠습니다.
지금 논의는 POD 형 클래스와 구조체의 생성자와 소멸자가 번역 과정에서 실제로
정의되고 (인라인이 아닌 일반 함수처럼) 호출이 되는가의 문제로 보입니다. 그런데
이것은 기계어 코드를 살펴보지 않는 한 겉으로 보기에는 구분이 불가능합니다.
그리고 컴파일러, 최적화 옵션 등에 따라 차이가 있을 것 같고요.

다른 한 가지의 논점은

hyperhidrosis wrote:
구현의 문제이기는 하지만, "멤버 변수가 없는 클래스"와 구조체 구현이
내부적으로 다를 이유가 있나요?

입니다. (아마 "멤버 변수"가 아니라 "멤버 함수"를 의도하신 건 아닌가 합니다만.)
이것 역시 추상적 정의와 구현의 문제인데, 환경이란 것이 너무나도 다양하다 보니
이런 문제에 대해서는 "알 수도 없고 알 필요도 없다"는 식으로 포기해버린 지 오래
됐습니다. --; 아무튼 지금 제 머리로는 달라질 이유를 생각해낼 수 없군요.
(물론 POD 형에 한해서입니다.)
lovewar의 이미지

doldori wrote:

지금 논의는 POD 형 클래스와 구조체의 생성자와 소멸자가 번역 과정에서 실제로
정의되고 (인라인이 아닌 일반 함수처럼) 호출이 되는가의 문제로 보입니다. 그런데
이것은 기계어 코드를 살펴보지 않는 한 겉으로 보기에는 구분이 불가능합니다.
그리고 컴파일러, 최적화 옵션 등에 따라 차이가 있을 것 같고요.

POD-struct 나 POD-union 을 POD 클래스라고 하는 것 같은데,

달리 사용되는 건인가요?

htna의 이미지

ed. wrote:
packing의 경우는 어떤가요?
class가 packing 가능한가요?

packing은 class냐 struct냐에 상관이 없는것으로 알고 있습니다.
아님 말구요.. ^^;

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

doldori의 이미지

lovewar wrote:
doldori wrote:

지금 논의는 POD 형 클래스와 구조체의 생성자와 소멸자가 번역 과정에서 실제로
정의되고 (인라인이 아닌 일반 함수처럼) 호출이 되는가의 문제로 보입니다. 그런데
이것은 기계어 코드를 살펴보지 않는 한 겉으로 보기에는 구분이 불가능합니다.
그리고 컴파일러, 최적화 옵션 등에 따라 차이가 있을 것 같고요.

POD-struct 나 POD-union 을 POD 클래스라고 하는 것 같은데,

달리 사용되는 건인가요?


그러고 보니 제가 잘못 썼군요. 말씀하신 대로 POD class 또는 POD type은
POD-struct와 POD-union을 통칭하는 용어입니다.
제가 쓴 "POD 형 클래스"는 잘못된 말입니다.
buelgsk8er의 이미지

new 구문이 사용된다고 해서, 반드시 생성자가 호출된다고는 볼 수 없습니다.

묵시적 생성자는 "필요한 경우"에 만들어진다고 되어있죠. 그러나 new 구문을 사용하는 모든 경우가 여기에 해당하지는 않습니다. 즉

Quote:

new를 사용하면 컴파일러는 생성자를 호출해야하기 때문에

이 말씀엔 반례가 존재합니다. POD 타입(POD-struct, POD-union 포함)은 초기화를 하지 않아도 되기 때문에, 생성자를 호출할 "필요"가 없죠. 따라서 굳이 묵시적 생성자를 만들어낼 필요도 없습니다. 이건 '최적화를 통해 날린다' 이전의 문제라고 보는데요.

C++표준에서 이 문제를 "구현나름"으로 해놓았는지 어떤지는 모르겠지만, legacy C 헤더에서 정의하고 있는 수많은 struct들이 엄연히 존재하는데, 상식적으로 거기에 new 구문을 적용할 때마다 묵시적 생성자를 만들어 호출하도록 강제하고 있지는 않을 거라고 생각합니다. 설사 표준에선 "구현나름"으로 정의해 놓았다 해도, 실용성 때문에라도 그런 구현이 존재할 것 같지도 않습니다.

kewlbear의 이미지

buelgsk8er wrote:
new 구문이 사용된다고 해서, 반드시 생성자가 호출된다고는 볼 수 없습니다.

묵시적 생성자는 "필요한 경우"에 만들어진다고 되어있죠. 그러나 new 구문을 사용하는 모든 경우가 여기에 해당하지는 않습니다. 즉

Quote:

new를 사용하면 컴파일러는 생성자를 호출해야하기 때문에

이 말씀엔 반례가 존재합니다. POD 타입(POD-struct, POD-union 포함)은 초기화를 하지 않아도 되기 때문에, 생성자를 호출할 "필요"가 없죠. 따라서 굳이 묵시적 생성자를 만들어낼 필요도 없습니다. 이건 '최적화를 통해 날린다' 이전의 문제라고 보는데요.

C++표준에서 이 문제를 "구현나름"으로 해놓았는지 어떤지는 모르겠지만, legacy C 헤더에서 정의하고 있는 수많은 struct들이 엄연히 존재하는데, 상식적으로 거기에 new 구문을 적용할 때마다 묵시적 생성자를 만들어 호출하도록 강제하고 있지는 않을 거라고 생각합니다. 설사 표준에선 "구현나름"으로 정의해 놓았다 해도, 실용성 때문에라도 그런 구현이 존재할 것 같지도 않습니다.

POD라는 것이 있었군요. 역시 아직도 배울 것이 많네요. 지적해 주셔서 감사합니다. 검색해보니 아래와 같은 내용이 나오는 것으로 봐서 제가 한 말은 POD에는 해당되지 않는 것 같습니다.

Quote:
5.3.4p15: POD class objects created with "new" have an indeterminate value.

출처: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1324.html

NN의 이미지

이 문제는 크게 (추상성의 순서대로) 세가지 차원에서 접근할 수 있겠네요.

1. 컴파일러 구현차원-특정 컴파일러에서의 구조체, 클래스 구현물은 어떠할것인가?

2. 언어정의 차원-C, C++ 표준에 명기된 내용에 의해 구조체와 클래스가 어떤 공통점과 차이점을 보일것인가?

3. 방법론 차원-구조적, 객체지향 방법론상에서 구조체와 클래스가 쓰이는 용도와 그 개념적 차이가 어떠한가?

이 쓰레드 내용을 전부 읽지는 못했는데 아마 바로 위 몇개 글에서는 합쳐진 상태의 1, 2가 집중 논의된것같군요. 1에서의 구현상 세부적이고 다양한 차이점들이 이곳분들에게는 사소한것으로 여겨질만하다는 가정하에 제외시켜본다면(어떤분들에겐 사소하지 않겠지만) 2기준에서 구조체를 클래스의 한 special case로 보는것에 대해선 대부분 동의하시는듯 합니다.

그런데 3의 관점에서라면 구조체와 클래스는 완전히 달리봐야 하는것들이네요. (이 관점에서는 구현상의 문제는 논외가 됩니다. 완전히 디자인 관점으로 바뀌는거죠.)

잘 아시겠지만, 구조적 방법에서의 구조체는 수동적으로 접근되는 repository 개념이 강한반면 객체지향에서는 능동적인 agent(이 용어가 여러 분야에서 다양한 용도로 사용되는 이유로 이렇게 사용하는것이 매우 조심스럽긴 합니다만, 능동성을 강조하는 단어로 이것만큼 적절한것이 없다고 생각되어서 그냥 씁니다.)로서의 클래스가 강조됩니다. 이것은 구조적 방법론과 객체지향 방법론이 채용하고 있는 data-process model, state-behavior model 에 의한 자연스런 결과로 설령 상당히 유사하게 구현되어 있는 어떤 구조체와 클래스가 있다 하더라도 그것들이 어떤 방법론에 따라 디자인된 결과냐에 따라 전체 디자인 맥락상에서 그것이 어떻게 해석되어야 하는지, 또 향후 무슨 역할을 담당해야 할것인지에 대한 전혀 다른 답이 나올 수 있음을 의미합니다.

이런 등등의 경우를 고려해 볼때 구조체와 클래스를 단순히 사용 편의성 측면에서 어떤것이 무엇보다 더 낫다라고 하거나 또 사용하기 나름이라는 약간은 뻔한 대답을 반복하는것보다는(그 대답들이 틀렸다는것은 물론 아닙니다만) 1, 2, 3 각각의 수준별로 구조체와 클래스의 특성을 식별해내고, 이들이 어떤 연관관계를 갖게 되는지를 논해보는것이 더 많은 도움이 될듯합니다. 이렇게 하면 자연스럽게 각 구조물에 대한 전체적인 통찰이 얻어질 수 있을것 같군요.

현재까지의 논의는 구현과 언어 경계상의 문제에 포커스가 맞춰져 있어서 전체 숲을 놓고 볼 때 약간 지엽적인 부분으로 흐른다는 느낌이 듭니다.

하긴 질문자체가 구현-orient된 것이었기도 하고, 또 이곳 상당수의 사람들이 구현자체에 큰 관심을 보이는 사람들이니 이런 현상이 자연스러운것일수도 있겠네요. 어쨋든 제가 볼때는 최소한 위의 1~3과 같은 공통된 기준이라도 갖고 논의를 하는것이 더 좋겠다는 생각입니다.

breadncup의 이미지

굉장히 큰 Thread 이군요. :)
Thread를 모두 읽어 본 것은 아닙니다만, 재미있는 주제네요.

그런데, 대체적으로 구현및 지엽적인 부분으로만 접근하는 방법밖에 없어서 아쉽네요. 다만, NN님이 제시한 관점에서의 토론이 이어졌으면 더 좋았을 것 같다는 생각이 드네요. 특히 방법론의 차원에서의 접근으로 나누어진 Modeling에 대한 깊은 관심이 있다면, 더 좋을 것 같네요. :)

~~~~~~~~~~~~~ Signature from here
http://kblog.breadncup.com/about/에, 저에 대한 소개와
혹 올려지는 Q&A에 대해서 이 사람의 수준이 어디쯤 있는가에 대해서
참고 해 볼 수 있도록 기록되어 있습니다.
~~~~~~~~~~~~~ Signature to here

죠커의 이미지

NN wrote:
2. 언어정의 차원-C, C++ 표준에 명기된 내용에 의해 구조체와 클래스가 어떤 공통점과 차이점을 보일것인가?

클래스와 구조체의 차이는 C++ 표준에만 나타나 있는 것이겠지요.

이전부터 몇번 살펴보았습니다만 표준에 나온 차이는 지정되지 않을 때 public이냐 private인지의 차이만 있는 것으로 보입니다.

deisys의 이미지

POD라는걸 처음 들었습니다. 검색해보니 나오는군요. 배우고 갑니다.

creativeidler의 이미지

이 쓰레드를 보니 역시 C++은 졸라 어렵구나..하는 생각이 드는군요-_-

pool007의 이미지

struct와 class의 가장 큰 차이는 기본이 private인가 public 인가의 차이
밖에 없다라고 effective STL에 나와있습니다... 저도 그 이상의 차이는
없다고 생각됩니다.

하지만 구조체를 쓰면서 여기에 일부러 private을 지정해서 멤버 변수를
선언하는것은 class가 있는데 굳이 그렇게 할 필요가 있나라는 생각이
듭니다. 결국, struct는 상태가 필요없는 functor에 적합한 용도가
아닌가 생각됩니다. 또는 모든 것이 public 이 되는 데이터 구조 그 자체
(예를들어 struct data { int a, string b; } 와 같은 경우)외에
C++에서 일부러 struct를 찾아서 쓸 필요는 없겠죠.

--
Passion is like genius; a miracle.

lovewar의 이미지

struct(POD 클래스)와 class (NON-POD 클래스)간의 차이점은
물리적 메모리 접근(번지 연산)을 자유롭게(?) 할수 있는가를 설명하면
될것 같습니다.

페이지

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.