관리되는 코더 및 네이티브 코더

저는 코더이며 네이티브 코드와 관리 코드 모두에 경험이 있습니다. Pascal과 C로 시작한 다음 C ++로, 결국 C #으로 옮겼습니다.

지난 한 해 동안 나는 거의 독점적으로 C #으로 코딩을 해왔으며 C ++ 코더 일 때 자연스럽게 왔던 많은 것을 잃어 버렸습니다.

몇 주 전 네이티브 C ++ 코드를 작성하기 위해 앉았을 때, 나는 복잡성, 단점 및 특질에 천천히 익숙해지면서 스스로 혼란에 빠졌습니다. 크기를 전달하지 않고 동적으로 할당 된 배열을 함수에 전달하면 수신 함수가 배열의 길이를 알 수있는 방법이 없다는 것을 완전히 잊어 버렸다고 거의 당황합니다.

관리되는 코드와 관리되지 않는 코드를 비교하고 대조하는 수많은 기사와 문서가 있습니다. 잘 알고있는 네이티브 코드는 관리 코드보다 훨씬 빠르고 가볍게 실행될 수 있습니다. 반면에 관리 코드에는 가비지 수집기 및 런타임 CPU 관련 및 OS 별 최적화 기능이있어 네이티브 코드에 돈을 줄 수 있습니다.

순전히 기술적 관점에서 볼 때 명확한 승자는 없습니다.

관리 코드가 코딩과 이해가 훨씬 간단하다는 것은 의심의 여지가 없습니다. Win32 C ++와 C #에서 간단한 GUI를 구성하는 데 필요한 줄 수의 차이를 살펴보십시오.

필자의 기본 코딩 시대로 돌아가서 나는 대부분 수퍼 컴퓨터에서 실행되는 수학적 시뮬레이션을 작성했습니다. 그들은 추악한 CLI를 가지고 있었고 주로 알고리즘 중심이었습니다. 요즘 나는 C #으로 작성하고 아름다운 GUI 응용 프로그램을 생산하지만 모국어에서 비슷한 구경을해야한다면 길을 잃을 것입니다. QT와 같은 프레임 워크를 사용하더라도 C ++에서보다 C ++ / QT에서 무언가를 생성하는 데 여전히 두 배의 시간이 걸립니다.

C / C ++로 모든 기능을 갖춘 대규모 GUI 응용 프로그램을 작성한 사람을 볼 때마다 나는 경외감을 느끼고 질투의 힌트를 느낄 수 없습니다.

다른 숙련 된 코더가 관리되는 언어와 관리되지 않는 언어를 어떻게 보는지 궁금합니다. 관리 코드가 아마추어 처럼 보 입니까? 네이티브 코더가 더 하드 코어라고 생각 하십니까?

내 일은 현재 C ++이지만 더 이상 차이를 거의 느끼지 못할 정도로 여러 언어로 프로그래밍했습니다. 내 관찰은 다음과 같습니다.

• 다른 언어와의 비 효율성 주장은 C ++ 프로그래머가 모범 사례로 자주 구현하는 경우가 많습니다. 최소한 데이터 처리에 중점을 두지 않는 코드의 경우 자동으로 이러한 작업을 수행하지 않는 언어로 얻을 수있는 실행 속도 이점을 크게 무효화하기에 충분한 null 검사, 배열 범위 검사, 유형 검사, 입력 유효성 검사 등을 추가합니다.
• 그 여분의 상용구는 잠시 후에 심오한 습관이되어 실제로 추가 작업처럼 느끼지 않고 빠졌을 때 아픈 엄지 손가락처럼 튀어 나옵니다.
• "관리되는"언어로 프로그래밍 할 때 메모리 누수가 발생하지 않도록 메모리 할당에 대해 계속 생각합니다. 명시 적으로 넣지 않았을 수도 delete있지만 가비지 수집기가 삭제 대상으로 간주하는 시점을 여전히 알고 있습니다. C ++에서했던 것보다 Java에서 시작하는 메모리 부족 문제를 해결하기가 더 어려웠습니다. 아마도 C ++에서는 오랫동안 무시하기가 훨씬 어렵 기 때문일 것입니다.
• 동적 타이핑도 마찬가지입니다. 함수 매개 변수가 배열인지, 정수인지, 아니면 문자열인지를 여전히 추적해야합니다. 사실, 유형이 나에게 명확하게 나열되어 있지 않기 때문에 더 많은 노력이 필요합니다.
• 최신 C ++ 스타일은 C # 이전 시대와 매우 다릅니다. 사람들은 언어가 바뀌지 않고 기존의 C ++ 기능을 고유 한 방식으로 사용하여 과거의 많은 메모리 관리를 피하는 방법을 "발견"했습니다. 메모리를 자동으로 확보하는 디자인 패턴은 현재 매우 일반적입니다.
• 내가 아는 한 코드 만 작성하여 GUI 응용 프로그램을 만들 수는 있지만 QT 디자이너와 같은 그래픽 디자이너는 주로 이벤트 처리기 또는 런타임 사용자 지정에만 사용되는 코드와 함께 선호되는 방법입니다.
• 한동안 광범위하게 사용하지 않은 언어는 주로 구문을 기억하더라도 약간 어색한 느낌이 듭니다. 1 년 동안 파이썬을 쓰지 않으면 잊어 버린 많은 특질이 있으며, 객관적으로 대부분의 사람들이 파이썬을 "쉬운"언어로 생각하지만 C ++보다 한층 더 어색한 느낌이 듭니다.

이러한 모든 요소의 조합으로 인해 C ++과 다른 언어로 프로그래밍 할 때 내 정신 모델은 상당히 일관성이 있으며 차이점은 대부분 구문에 불과합니다. 물론 많은 것이 C ++ 언어 자체에 내재 된 기능보다는 훈련, 습관, 코딩 표준 및 현대적인 디자인 패턴의 결과이지만 비교는 여전히 유효합니다.

내가 말하려는 것은 내 경험상 프로그래머의 훈련이 그가 사용하는 언어보다 훨씬 더 큰 차이를 만든다는 것입니다.

관리 코드가 아마추어처럼 보입니까? 네이티브 코더를 더 하드 코어로 보십니까?

아니.

엔지니어와 프로그래머의 차이점을 봅니다. 하드 코어 엔지니어는 항상 허용 런타임 표준에 최소한의 시간에 일을 얻기 위해 적절한의 언어 / 기술 스택을 선택합니다.

요즘 프로세서 전원으로, 실제의 주파수를 필요로 낮은 수준을 사용하여 많은 아웃 기계의 수와 같은 얻을 수는 모국어가 적게 받고있다. 일반적으로 비즈니스 사례는 아닙니다. 생산성은 항상 실행 시간의 몇 밀리 초 차이보다 우선합니다.

안타깝게도 Microsoft는 "Managed Code"를 C # /. Net 클래스 라이브러리와 연결하도록했습니다.

여기에는 두 가지 별개의 관련성이 거의없는 것들이 있습니다.

1. 멋진 .Net 라이브러리.

2. 관리 코드.

C #은 단 하나의 가격으로 깔끔하고 지원되며 사용하기 쉬운 패키지로 제공합니다.

C ++에는 .Net이 수행하는 거의 모든 기능을 수행하는 수많은 멋진 라이브러리가 있습니다. "네이티브 C ++"코드를 C # /. Net 코드보다 더 많은 "복잡성, 쿼크 및 특유성"이 있다고 비난하기보다는 더 나은 C ++ 라이브러리를 찾을 수 있습니다.

더 나은 라이브러리를 사용하면 멋진 C ++ 코드를 작성할 수 있습니다.

C / C ++로 모든 기능을 갖춘 대규모 GUI 응용 프로그램을 작성한 사람을 볼 때마다 나는 경외감을 느끼고 질투의 힌트를 느낄 수 없습니다.

잘못된 정책. 대신 어떤 클래스 정의 라이브러리를 사용했는지 찾아야합니다. 당신도 그 라이브러리를 사용할 수 있습니다.

도구에 관한 모든 것입니다. 도구가 없으면 바지를 입은 동물 일뿐입니다.

"네이티브 C ++"가 모든 도구를 버려야한다는 의미는 아닙니다. 좋은 도구를 찾아야한다는 뜻입니다. Microsoft는 더 이상 지원하지 않으므로 적절한 도구 조합을 찾는 데 시간을 투자해야합니다.

여기서 문제는 하드 코어 프로그래밍이나 그와 관련된 것이 아니라 제어에 관한 것입니다. 사실 C #은 제어 비용으로 생산성을 제공합니다. 많은 양의 제어가 필요한 프로그램을 작성하는 경우 (이 메모리는 정확히 할당이 취소됨) C ++를 사용할 수밖에 없습니다. 빠르게 완료해야하는 경우 C #을 사용해야합니다. 문제는 C #에 대한 지원 라이브러리가 C ++에 제공되는 것보다 훨씬 더 좋고 최신이라는 것입니다. 예를 들어, MFC는 매우 오래되었고, 그 관행은 끔찍한 것으로 알려져 있으며, 대부분 표준화 이전에 작성되었습니다. 예를 들어, Microsoft가 새로운 C ++ 라이브러리를 제공하는 데 노력을 기울인다면 Visual Studio 2010에서 새 PPL을 확인한 다음 이상하게도 C ++에서이 작업이 쉬워집니다. 저는 그들이 그런 식으로 이주하고 있다고 생각합니다.

반면에 관리 코드에는 가비지 수집기 및 런타임 CPU 관련 및 OS 별 최적화 기능이있어 네이티브 코드에 돈을 줄 수 있습니다.

나는 많은 매니지드 언어 지지자들이 이런 말을한다고 들었지만 실제로는 사실을 본 적이 거의 없습니다. 사실 새로운 CPU에서 사용할 수있는 새로운 CPU 명령어는 하드 코어 수학을하지 않는 한 그다지 큰 이점을 제공하지 않습니다.이 경우 실행시 컴파일하거나 해석해야하는 오버 헤드를 감당할 수 없습니다 -Intel의 C ++ 컴파일러를 사용하여 최신 SSE를 사용하십시오. C ++의 컴파일러 최적화 범위는 JIT와 비교할 때 엄청나게 큰데, 프로그램이 실행되는 동안 JIT를 약간만 실행하면되지만 C ++ 컴파일러는 컴파일하는 데 달콤한 시간이 걸리기 때문에 매우 전설 적이기 때문입니다.

가비지 콜렉션은 마술처럼 위대한 것이 아니며 알고리즘 선택입니다. 모든 상황에 적합합니까? 아니는 IDisposable C #에서 혼란과 방법에서 멀리있는 모습으로 자바도 C ++의 소멸자가 파일을 닫습니다 반면, 그 문제를 시도 귀찮게하지 않았다 및 메모리 확보 및 GC는 일부 프로그램에 좋은 곳입니다 등 등 가까이 소켓을, , 일부는 그렇지 않습니다.

제 생각에는 네이티브 C / C ++는 C #과 비교할 때 C / C ++ 자체의 어셈블러처럼 보입니다. 또 다른 복잡한 추상화 계층 (매우 사실은 아니지만 그렇게 말합시다)은 개발이 쉬워 지지만 속도는 약간 떨어지고 메모리 사용량은 과도하게 줄어 듭니다. 보시다시피, 그것은 다른 범주로 나뉘어 새로운 하위 유형의 프로그래머를 만듭니다.

추상화 수준에 대한 Btw C #은 엄청나게 빠르며 Microsoft는 훌륭한 일을했습니다.

아마추어 언어가 아닌 아마추어 프로그래머가 있습니다. 그들의 언어는 모두 (적어도 대부분은) 그들의 목적을 가지고 있습니다.

현재 생산 시스템을 테스트하는 데 사용되는 보험 계산 엔진을 공동 작업하고 있습니다. 프로덕션 시스템은 C로 만들어졌으며 엔진은 Java로 이루어졌으며 오랜 시간이지나면서 C 엔진보다 성능이 뛰어나면서 훨씬 더 생산적이었습니다. Java 자체가 C보다 빠르기 때문에 속도가 빠르며 알고리즘이 더 좋고 알고리즘을 더 쉽게 구현할 수 있으며 코드를 더 빠르고 효율적으로 테스트하고 리팩토링 할 수 있습니다.

또한 계산 결과를 프로덕션 데이터베이스의 내용과 비교하는 테스트 코드를 작성했습니다. C가 아니라 Java가 아니라 Ruby입니다. 다시 말하지만 충분히 빠르며 훨씬 적은 코드가 필요하므로 구현하기 쉽고 테스트하기 쉽고 확장하기 쉽습니다.

그리고 어떤 언어를 사용하든 아마추어적인 느낌이 들지 않습니다. 그런 일이 있어서는 안되는 어리석은 벌레를 만들 때만 그런 느낌이 듭니다.

작년에 제가 일한 회사는 무차별 대입으로 통신 CRC 코드를 리버스 엔지니어링했습니다. 3 명의 개발자가 각각 Borland C, C # .Net 2008, VB6 버전을 가지고있었습니다. VB6은 분명히 느리고 Borland C는 빠르지 만 C # .net은 12 배나 빨랐습니다. 우리가 전혀 기대 한 것이 아니 었습니다.

그것은 혼합 된 것들에 의존하지만 기본적으로 다른 모든 것은 동일합니다. 예, 네이티브 코드는 관리 코드보다 "하드 코어"입니다.

일반적인 비즈니스 응용 프로그램의 경우 일반적으로 나쁜 일이라고 생각합니다. 일반 개발자가 코드의 비 비즈니스 측면에 더 많은 정신 에너지를 넣어야하기 때문입니다.

내 프로그램은 Java와 같은 C ++로 가장 잘 설명 될 수 있습니다. 내 의견은 Java에서 동일한 저수준 프로그래밍을 달성 할 수 있지만 C ++의 저수준 프로그래밍보다 훨씬 어렵습니다. 그러나 일반적으로 적은 수의 코드로이 낮은 수준의 프로그래밍이 필요하며 관리되는 언어가 더 생산적이지 않은 경우에 필요합니다.

네이티브 개발자는 일반적으로 하드 코어가 더 많고 그렇게 행동하기 때문에 하드 코어가 더 많다는 평판을 얻습니다. 기본 개발자는 실수를 용납하지 않는 시스템에 대해 교육을받습니다. 필연적으로 하드 충돌이나 무한한 메모리 누수로 이어지기 때문입니다. 특히, .NET은 모든 것을 둘러보고 시도하는 것과 같은 게으른 해킹을 허용하여 개발자가 핵심 문제를 이해해야한다고 생각하는 것을 방지합니다. 코드가 중요합니다! "). 이것은 전혀 흑백이 아니지만 관리되지 않는 세계에서 자랐으며 이제는 관리 코드에서 풀 타임으로 일하고 있습니다.

또한 관리되는 개발자는 훨씬 깨끗하고 체계적인 BCL에 액세스하는 경향이 있습니다. 이것은 종종 그들이 커버 아래에서 실제로 일어나는 일을 탐구하지 않도록 권장합니다. 사실, STL 또는 Boost에 대해서도 마찬가지이지만 .NET 클래스 라이브러리는 종종 지적 적으로 게으른 게되기에 충분합니다.

즉, 좋은 배송 가능 관리 프로그램을 작성하려면 많은 작업이 필요합니다. 즉, 관리되지 않는 개발자가하는 것과 비슷한 방식으로 메모리 및 CPU 프로파일 링, 단위 테스트 및 코드 분석을 수행해야합니다. 관리되지 않는 개발자는 이러한 상황을 이해하는 경향이 있으며 관리되는 개발자는 그렇지 않은 사람들을 더 포함하는 경향이 있습니다.

다시, 흑백이 아닙니다. 지적 적으로 게으른 관리되지 않는 개발자와 하드 코어 관리되는 개발자가 많이 있습니다. 정의상 다른 것보다 더 엘리트적인 것도 아닙니다.

관리 코드가 아마추어처럼 보입니까? 네이티브 코더를 더 하드 코어로 보십니까?

두 세계 사이 에 차이 가 있으며 그 이유를 알 수 없습니다. 관리 시스템은 어딘가에 네이티브 코드로 작성됩니다 (최종적으로 모든 것이 "조립"으로 실행 됨). 내가보고 싶은 것은 (아직도 내 인생에서) 응용 프로그램 구성 시스템이며 응용 프로그램의 모든 하위 작업이 올바른 언어 유형으로 작성됩니다.

Go 가 출시 된 이후 네이티브 코드가 쉬워 졌습니다. Java 및 C #보다 읽고 쓰기가 더 쉽다는 것을 알았습니다. Go를 사용한 GUI 프로그래밍은 현재로서는 좋지 않지만 (옵션을 간단히 살펴 보았습니다). C #에 비해 대규모 커뮤니티 와 다양한 라이브러리
가 부족하다고 판단하지 마십시오 (예 : 여전히 새로운 것으로 간주되기 때문에).