[C++] C와 C++는 모두 강타입(strong typing)언어가 아니다..

영어에 대한 독해력 미비로 C, C++이 강타입(strongly-typed)언어에 속하지(?) 않다는 점을 이해하지 못했습니다.

강타입언어가 되기위해
C, C++ 언어가 갖는 부족한 점들에 대한 설명좀 부탁 드립니다.

-- 덧붙이는 글--

강타입(strongly-typed)을 쉽게 와닿게 할 수 있는 용어가 없을까요?
익숙하지 않아서 일까요...

void type 을 예로 들었던건 다음과 같은 이유 때문입니다.

예를 들어 smalltalk 이나 perl 같은 언어들을 보면 변수를 정의할 때에 특별하게 type 선언을 하지 않습니다.
심지어는 collection 안에서 각각의 element 들이 전혀 다른 클래스(또는 type)의 인스턴스여도 상관이 없지요.
이런 경우는 완벽하게 weak typed 언어라고 할 수 있을겁니다.
예를들어, Smalltalk 에서

aObj := FooClass new.
aObj doSomething: paramObj.
aObj := 'Foobar'.

이런다고 해서 전혀 문제가 안되거든요.

C/C++ 에서 이렇게 때에 따라 맘대로 전용할 수 있는 대표적인 type 이 void 입니다.

예를 들어서,

void foo;
int bar=10;
foo=(void)bar;

하는것은 전혀 문제를 일으키지 않습니다. 물론 이 경우 type casting 이 사용되었지요. 좀더 일반적인 예를 들면,

void* foo;
int x=10;
float y=1.1;
MyOwnStruct z;
foo=(void*)(&x);
foo=(void*)(&y);
foo=(void*)&z;

같은 경우를 볼 수 있겠죠.
그럼, 조금이나마 도움이 되셨길 빕니다.

vio:

void는 거기에 대응하는 내용이 없다는 걸 나타내기 위해서만 사용합니다. void로 identifier를 선언할 수는 있지만 void 형으로 캐스팅한다거나 값을 집어 넣는 것 뿐만 아니라 sizeof조차도 불가능합니다. void가 실제로 형으로 사용되는 경우는 void*, void** 같이 포인터로 쓰일 경우 뿐이며 이 때의 뜻은 type*, type** 등의 포인터를 대표하는 의미를 가집니다.

- 토끼군

개인적으로는 runtime에 어떤 variable에 대한 type을 알 수 있으면 strongly-typed이고 그렇지 않다면 weakly-typed라는 정의를 가장 좋아합니다. 즉, python이나, Java, lisp, ruby 등은 runtime에 어떤 variable의 type이 뭔지를 알 수 있으므로 strongly-typed이고, c의 경우는 type을 알 수 없으므로 weakly-typed이라는 거죠.

위키 백과에 나와 있는 다른 정의들중 일부 (예를 들면 형 사이의 변환이 금지되었으면 strongly-typed이다, 혹은 형 사이의 변환이 명시적으로 있어야만 strongly-typed이다 등)는 strictly-typed라고 부르는게 좀 더 자연스럽지 않나 생각합니다. (strictly-typed vs loosely-typed) 그리고 그 나머지는 statically-typed vs dynamically-typed 이거나 strictly와 statically의 mix-in인 것 같네요.

절대적인 정의는 아니지만, 저도 예전에 궁금해서 알아보고 나름대로 정리해 봤던 적이 있어서 포스팅 합니다. strongly-typed, strictly-typed에 대한 내용은 확실히 사람들마다 의견이 다르더군요. dynamic vs static은 거의 의견이 일치하지만...

p.s) python의 경우에는 strongly-typed, loosely-typed, dynamically-typed language이겠죠.

일단 이거에 대해서만 답변하면...가능합니다...

대학원 수준의 컴파일러 혹은 프로그래밍 언어 수업을 들으면
이런 증명하는거 합니다.

그리고 정의의 문제라고 하셨는데....정의를 수학적으로 표현해야 인정 받습니다...
그런데~~~현재 프로그래밍 언어중 완전히 수학적으로
정의를 한언어는 ML등의 몇몇 언어만 있는걸로 알고 있습니다. 이런 프로그래밍 언어는 모든 타입 오류를 찾을수 있습니다.
(잘은 몰라요~)

그런데 일반적으로 많이 사용되는 C C++ Java 는 수학적으로 표현이 안되어 있고 모든 타입 오류를 찾아준다고 증명을 못합니다. 그래서 Strong Typed System 이 아니라고 들었습니다.

약간 따른 이야기를 하면 지금 여러분들이 이야기하는 언어는
static typed system 입니다.
http://en.wikipedia.org/wiki/Datatype#Static_and_dynamic_typing

컴파일 시점에 타입이 결정 됩니다.

따라서 타입 오류를 컴파일 타입에 잡아낼수 있어야 합니다.
하지만...ML 을 제외한 지금 이야기한 어떤 언어도
모든 타입 에러를 컴파일 타임에 잡아낼수 없습니다.
그래서 대체적으로 강타입으로 보질 않는거 같습니다.

제가 이쪽 전공이 아니라서 어디서 주어들은 이야기라서 틀린 부분 있을수 있습니다.

추가로 한가지더...
http://en.wikipedia.org/wiki/Datatype#Static_and_dynamic_typing

Advocates of strongly typed languages such as ML and Haskell have suggested that almost all bugs can be considered type errors, if the types used in a program are sufficiently well declared by the programmer or inferred by the compiler

아, 지적해주셔서 감사합니다.
암튼 의미는 전달되었죠? ^^

음.. 말을 좀 바꾸겠습니다.
증명이 필요없다는 의미가 아니라,
증명에 관심없다로.

예를들어 함수형 언어의 대표주자중 하나인 LISP은 타입을 골치아프게 생각하는 언어가 아니죠.. 이런 상태에서 만약 "xxx 라는 functional language가 있는데 강타입이다" 라고 말하면 이건 하나의 특징적인 점이 됩니다. functional language 라는 것의 본래적인 특징은 imperative language가 가진 변수/반복문을 없애보자..라는 것이죠. 그런데 거기에 side effect 등이 첨가된 상태에서는 그 특징이 보다 온전하게 보이게 하기 위해서 '강타입이다'라고 증명하는게 의미가 있을 수 있겠죠.

하지만, imperative language에서 강타입이다라고 주장한다면, 요즘 같은 세상에선 "so what?' 이라는 반응이 나올 거라고 생각되는군요.

imperative language에서 강타입 언어중 하나인 Java의 예를들자면, 최근에 generics 기능이 추가되면서 ArrayList에 Stirng을 넣으려고하면 unsafe operation이라고 까지 경고해주죠. ArrayList말고 ArrayList<String> 쓰라면서. 하지만 이렇게까지 일일히 타입을 챙겨준다고해서 별다른 사용자들의 주목을 받지는 않고 있습니다. 굉장히 신경써주는덕에 굉장히 귀찮아졌음에도 불구하고.

JAVA spec에 보면 '이것이 어찌어찌해서 강타입이다'의 증명은 없죠. (VM 스펙은 본적이 없습니다. 거기엔 나와있을지도.) 반면 java.util.concurrency에서 바뀌게 된 메모리 모델의 스펙에 대한 모델 설명은 정말 길게도 늘어놓았죠. 이런 것이 현실적인 듯 하네요. 분명 타입 에러를 제대로 잡겠다는건 컴파일러와 VM을 구현하는 사람에게는 중요한 문제이고, 누군가는 이것이 제대로 돌아간다고 증명을 한번 해보고 검증도 했겠지만 아무의 주목도 받지 않게되는거죠.

플레임 워 일으킬 생각은 없지만 ML만이 강타입이라 -_-;; 는 건 참 .. 듣기 거북한 말이군요. 함수형 언어의 갈길은 '제가 강타입인데요' 라고 말하는게 아니라 그 느리고 느린 속력을 극복해서 다른 언어만큼의 인기를 누리는데 있을텐데 곁다리 친걸로 자랑하다니 -_;;

struct type1 { int x; };
struct type2 { long y; };

int main()
{
    struct type1 var1;
    struct type2 var2;
    var1 = *((struct type1 *)&var2);
    int var3;
    double var4;
    var3 = *((int *)&var4);
    return 0;
}

아, 위 코드를 컴파일해서 실행했더니 오류는 없었습니다. gcc -Wall -ansi로 컴파일 했을 때 Warning도 없었구요.

1. java generics에 관해,

generics가 귀찮아지기만 한것은 아니지요;;

casting을 안써도 되니까요.

그에 따라 type 안전성에 문제를 일으킬 소지가 있는 downcasting도 덜 일어나겠지요.

java가 strongly typed라지만 downcasting을 할수 있는 이상 안전성을 보장할수 없습니다.

문제가 일어날수 있는 코드를 줄일수 있다는 점만으로도 충분히 의미가 있다고 생각합니다.

2. imperative language에서의 증명

관심없으신 분들도 많지만 관심많은 사람도 있습니다.

다익스트라, 호어 등이 선구자입니다.

단지 imperative language쪽에서는 type으로 할수있는게 별로 없어서,

다른 방법(정적 분석, theorem proving 등등)으로 접근하는 경우가 많습니다.

아직 널리 쓰이고 있지는 못하지요.;;;

3. 타입 안전성 증명은 아무도 신경쓰지 않는다.

사실 증명이 스펙에 나올 필요는 없지요;;; type system rule은 나올수도 있겠지만요.

그리고 문서양이 많다고 꼭 좋은 것도 아닙니다. 자동화가 잘 된 부분일수록 문서가 적습니다.

대신 자동화 된 부분 또는 증명은 spec문서가 아니라 논문이 되겠지요.

반면 자세한 스펙 문서는 그부분이 아직 자동화되지 못해 프로그래머가 신경써줘야할 부분이라는 반증이기도 합니다.

Glasgow Haskell compiler가 곧 SMP 지원을 한다는 이야기가 나돌고 있는데, 아마 그쪽에서는 자바만큼의 동시성에 관한 문서를 제공하지 않을것입니다. 프로그래머는 예전과 다름없는 프로그래밍을 하게 될테니까요.

4. functional 언어의 성능

별로 안느리거덩요;;;;

Haskell은 솔직히 느려터졌지만 OCaml은 Java랑 비교할만합니다.

죄송. Class.forName("abc.def").newInstance() 를 하려고 했었는데 실수했네요.
그러나 이 코드를 썼어도 Object 라고 답하실 듯.. (맞는지요?)

그러나 제겐 그냥 모든 것의 타입이 Object라고 말해버리는건 웬지 정당하지 않아보이네요...;; 각자의 타입이 별개고 Object를 상속했다고 말하는 것과는 다르니까요..

public class CheckType
{
	public String returnClassName()
	{
		return this.getClass().getName();
	}
	static public void main(String[] args)
	{
		CheckType ct = new CheckType();
		System.out.println(ct.returnClassName());
	}
}

동적 바인딩 즉 리플렉션을 사용하면 실행시간 단계에서 객체의 정의 부터 사용까지 모두 가능합니다.

1. typeid 연산자와 type_info 클래스
typeid는 type_info 개체를 반환하고, type_info::name()은 피연산자의 이름을
반환합니다. (구체적인 이름은 구현체에 따라 달라질 수 있습니다.)

#include <typeinfo>

const char* typeName = typeid(typeName).name();

2. dynamic_cast
다형적인 클래스 사이의 downcasting에 주로 씁니다.

제가 생각한 건 이런 거였는데, 잘 되는군요.

class RunTimeTypeInfo
{
    public static void printClassName(Object instance)
    {
        System.out.println(instance.getClass().getName());
    }
    public static void main(String[] args)
    {
        RunTimeTypeInfo rtti = new RunTimeTypeInfo();
        printClassName(rtti);
    }
}

강한 타입 언어는 말 그대로 타입 체크를 컴파일 타임에 엄격하게 하여 대부분의 오류를 컴파일 타임에 잡아내자는 의도로 설계된 언어이지요. ML은 강한 타입 언어의 가능성을 타진하기 위해 만들어진 연구용 언어이므로 강한 타입 언어의 정의를 거의 완벽하게 지키려고 노력하고 있는 언어입니다.

반면, 써보시면 알겠지만 강한 타입 언어는 가끔 타입 체크의 제약때문에 코딩이 길어지거나 귀찮아지는 경우가 많이 있지요. (그런 부분에서의 고민이 코드에서의 오류를 현저하게 줄여주긴 합니다만.) 자바나 C/C++은 강한 타입 언어를 표방하고 만들어진 언어이지만, 어디까지나 연구용이 아니라 필드에서 활용하기 위해 만들어진 실용 언어이므로 강한 타입 언어의 제약이 지나치게 생산성을 저하시킨다고 생각되는 부분에 암묵적인 형변환이나 런타임 타입 체크와 같은 타입 체크를 약하게 만드는 스펙을 도입했다고 보면 됩니다.

누군가 C/C++은 강한 타입 언어가 아니라고 말한다면, 그저 강한 타입 언어의 엄격한 정의에는 정합하지 않는 스펙이 몇 개 있을 뿐인 것이죠. 이건 완전히 이론적인 문제고 실용적인 것과는 거리가 먼 이야기인데요. -_-; C/C++은 강한 타입 언어로 설계되었지만 실용성을 위해 강한 타입 언어의 특징을 스스로 포기한 부분이 많이 있으니까요. 이건 Java도 마찬가지고..

그리고 위에 누군가 '런타임에 타입 체크를 할 수 있으면 강한 타입 언어이다'라고 말씀하셨는데 그건 완전히 틀린 정의가 아닌가요? 인터프리터 방식의 스크립트 언어는 빠르고 간편한 구현을 목표로 하기 때문에 컴파일 타임부터 사소한걸로 딴지거는 강한 타입 언어보다는 처음부터 약한 타입 언어로 설계되는 경우가 많지요.

이 글타래에서 자주 등장하는 ‘증명’의 목적어가 조금 이상해서 확인하고 싶습니다. 제가 주로 접해온 증명은 대개 세 가지였습니다:

1. (임의의 언어로 작성한) 이 프로그램은 명세한 설계 대로 동작함을 이렇게 증명합니다.
2. 이 프로그래밍 언어로 (임의의) 프로그램을 작성하면 어떤 경우에도 타입 오류가 없음을 이렇게 증명합니다.
3. 이 프로그래밍 언어에 적용된 타입 시스템, 즉 타이핑 룰들이 sound함을 이렇게 증명합니다.

반대로 말하자면, 절차형 언어 중에 type-safe한 언어가 드문 것은 절차형 언어에 타입을 적용하기가 여러모로 껄끄러웠기 때문일 뿐, 결코 절차형 언어의 type safety를 논할 필요가 없어서가 아니었다는 뜻입니다. 실제로 적지 않은 사람들이 지금도 절차형 언어에 타입 이론을 적용하려고 노력하고 있습니다. 특히, 물리적인 기계의 작동이 여전히 절차형 계산 모델에만 의존하고 있는 현재로서는 함수형 언어로 프로그램을 작성해도 결국 극단적인 절차형 언어인 기계어로 번역(컴파일)해야하기 때문에, 기계어로 컴파일하는 동안 소중한 타입 정보를 놓치지 않고 간직하기 위한 연구도 큰 이슈입니다. 예를 들어 아쯔시 오호리가 기계어에 대한 증명 이론에 관해 쓴 글은 아주 흥미롭습니다. (읽어보시면 제목과 내용의 연결이 조금 이상하다는 느낌이 드실텐데, 정확히는 type-safe한 컴파일레이션 이론입니다. 결국 그 말이 그 말이긴 합니다만…….)

그보다는 오히려, 저로서는 ‘곁다리’라는 표현이 거북스럽습니다.

함수형 언어의 속도나 메모리 소모를 개선하는 문제도 물론 큰 이슈이고 실제로 많은 곳에서 활발히 연구되고 있습니다만, 그렇다고 해서 그것만이 함수형 언어 세계의 핵심 사안이라는 발언에 대해서는 오히려 이를 연구하고 있는 학자들조차도 동의해주지 않을겁니다. (학자들은 대단히 공정한 사람들이랍니다.) 비록 순수성은 떨어진다고 하지만 흔히 함수형 언어의 모태격으로 인정되는 LISP의 시대부터, 이미 함수형 언어의 기본적인 비전은 다분히 고수준 언어를 지향하는 것이었습니다. 오히려, 고수준 언어로서의 장점과 함수형 계산모델의 특징을 일부 버리면서까지 절차형 기계 위에서의 효율을 높이는 것과, 효율을 일부 포기해서라도 고수준 언어로서의 장점과 함수형 계산모델의 특징을 유지하는 것 중 하나를 택하라면, 적지 않은 사람들이 후자를 택할겁니다. 정 고효율이 필요한 계산을 프로그래밍해야할 경우라면, 그저 절차형 기계의 인스트럭션 셋으로 쉽고 군더더기 없이 변환(컴파일)되는 절차형 언어 중에서도 기계어에 적당히 근접한 중저수준 언어를 선택하면 그만이니까요.

많은 인기를 얻어 실세계에 다양하게 쓰이는 것도 당연히 중요하겠지만, 이 역시 함수형 언어의 유일한 비전이라는 데에는 동의할 사람이 거의 없을겁니다. 애초에 함수형 언어는 전통적인 수학의 계산 모델(즉, 함수형 계산 모델)을 그대로 사용해서 계산을 명령하자(프로그래밍하자)는 취지였기 때문에, 그것이 필요한 곳에서 적절하게 쓰이면 그만입니다. 그리고 절차형 언어의 type safety가 난관에 봉착한 채 더딘 발걸음을 보이고 있는 현재로서는, type safety를 보증받기에 태생적으로 매우 적절한 함수형 언어가 자신이 잘하는 영역에 치중하고 있는 현상을 ‘곁다리 친 것’으로 보기는 더더욱 어렵습니다.

strong typing vs weak typing이 아니기에 약간 논외이긴 하나 이 문제에 관심 있는 분이 많이 모여든 것 같기에-_- 질문 하나 던져 봅니다.

혹시 strong typing이 실질적인 버그 발생율을 감소시킨다거나 생산성을 향상시킨다는 연구 자료를 갖고 있으신 분이 있나요? 아시는 분 있으면 링크 걸어주시면 감사하겠습니다.

하지만 C의 대부분을 포함하기 때문에 C에서 하던 모든 뻘짓이 다 된다는 큰 단점인 동시에 장점이 있지요.

--
There's nothing so practical as a good theory. - Kurt Lewin

C언어에서 bool이랑 int는 서로 통용가능하지 않나요