지금은 c++ 로 어플리케이션을 개발해도 애지간한 로직은 스크립트로 빼버리는 세상인데,
생산성도 문제지만, 가장 큰 이유는 개발 인력 수급의 문제임.
아무리 c++ 을 개선하면 뭐하냐고ㅋ 애들이 기피하는 3D 언어인데ㅋ
그리고 지금 뭐 c++ 을 개선해서 뭐 어쩌구 해봤자, 대학교에서 그걸 가르칠 인간들이 누군질 생각해보자고ㅋ
가르치는 사람들이 바로 은퇴해서 교수 되려고 아둥 바둥 뛰는 강사 아재 아니면 레알 틀딱임.
그 아재와 틀딱이 지금 개선되는 새로운 c++ 개발환경을 배워서 커리큘럼을 만들 것 같으심?
그래도 꾸역꾸역 c++ 을 개선하면 언젠가는 좋아지겠지라지만, 그 사이에 고급언어는 발전 안하나.
c++ 로 개발하면야 물론 다른 고급언어보단 빠르긴 하겠지.
근데 고급언어가 괜히 c++ 과의 연동을 지원하는게 아님.
속도가 중요한 부분만 c++ 로 개발해 모듈화해서 붙이고, 전체 소프트웨어는 다른 고급언어, 심지어 웹으로 개발해도 그리 큰 성능 저하는 없음.
이쯤 되면 c++ 의 주 목적은 특수한 코드를 제작하기 위한 최적화로 제한될 수 밖에 없는 상황임.
그리고 2017년 현재를 기준으로 코드 최적화의 핵심은 분기문 제거/재배치와 메모리 접근 최적화임.
이건 생성될 어셈 코드를 예상 못하면 c++ 로 짜나 마나라고 보는데.
솔까말 파이프라인에 최적화 안한 코드는 c++ 로 짜나 c# 으로 짜나 별 차이 없을 정도니까.
근데 파이프라인 최적화와 관련된 문서 자체가 어셈을 기준으로 만들어져있어서 어셈을 제대로 모르고선 읽을 수가 없는 상황임.
결론은 c++ 을 배우려면 걍 어셈부터 해야지.
다들 개발환경이 다르고 또 취향이 다르니까 가능한 서로 존중은 해야겠지만..
어쨌든 내 개인적 생각은...
c++ 은 어셈블리 코드를 생성하는 스크립트 언어라고 보는게 현대 c++ 의 사용 목적에 맞는 일이라고 생각하는 상황임.
그런 목적이 아니라면 굳이 c++ 을 고집할 필요는 없다고 보니까.
요즘 고급언어 생각보다 빠른 편입니다. 너님이 만든 소프트웨어를 나중에 유지보수할 입장도 생각해보자구요.
c++ 로 몽창 개발해버리면... 나중에 c++ 개발자 못구하면 유지보수도 못함ㅋ
이분 딱 온건한 야이미친(닉네임)성님인데
다만 C++ 개발자를 뽑을 정도의 회사면 유지보수 할 인재를 구할 걱정은 안할것 같네요 ㅇㅅㅇ..
저는 동의합니다 절대 C++이 싫어서 그러는 건 아니구요 ^0^
뭐 극소수의 대기업이야 그런 걱정을 안하겠지만, 우리가 다 그런 극소수의 대기업에서만 일하는 것이 아니라서... 글고 개발자는 실력도 중요하지만 인성 및 팀워크 문제도 있는지라. 안그래도 리스크 덩어리인 개발자를 풀이 좁은 곳에서 구하는 짓은 사업가들이 좋아할만한 일은 아니지 싶은...
C++ 언어의 발전방향과는 전혀 다르게 해석하시는거임 ㅇㅇ C++은 고급 추상화의 방향으로 쭉쭉 직진하는 중 - return 0;
근데 그렇게 최적화용도로만 쓸거면 차라리 C가 ㅈ낫지 않나요?
C는 너무 틀딱이라서 안 쓴다?
경험상 c 나 c++ 이나 차이는 없던데요. c는 드라이버 제작할 때나 c++ 컴파일러 지원 안되는 플랫폼에서 울며 겨자먹기로 쓰는거구...
어차피 어셈 코드 생성되는 꼴이라던가 파이프라인에서 돌아가는 꼴은 딱히 c 가 더 빠를 이유는 없으니까요. 같은 값이면 c++ 이 편하니.
커헉 // 대학교 돌아다니면서 강사/교수들을 설득해서 MFC 좀 집어치우라 하시고, 글고 학생들에게 C++ 도 발전하고 있다고 해주세요ㅋ 부탁드립니다ㅋㅋㅋ
최적화용도로 C++을 쓰면 요즘 "대세"랑은 많이 다르게 쓸 거 같네욤 STL도 잘 안 쓸 듯
정말 하드코어하게 가면 malloc도 시스템에 맞게 뜯어 고치던데 너무 무섭읍니다
그리고 사실 요즘 C++ 컴파일러들은 어셈블리 예측도 쉽지 않음. 워낙 최적화가 칼질을 미친듯이 하다 보니까 어셈블리 보면 못 알아봄. 깜짝 깜짝 놀라는 것의 연속 - return 0;
ㄴ그래서 오히려 예측이 쉬운 C를 써버리는 건 아님?
제 주변에서는 C++ 뽕 맞은 사람들이 좀 있어서 ㅇㅇ 단순히 문제 풀이 용이 아니라 아예 개발로 C++ 하는 사람들이 공부하는 사람 꽤 있음 - return 0;
이젠 STL 쓸 코드는 애지간하면 걍 C# 으로 써버리는 편임. 솔까말 C++ 의 STL 에서 귀찮게 allocator 잡아주지 않으면 걍 process heap 을 써버리는데 그럴거면 차라리 전용 heap 을 가진 c# 이 안정성이나 성능에서 봐도 훨 유리하지. 성능 측정해봐도 C++&STL vs C# 에서 C#이 안밀리니까.
현실은 그냥 쓰고싶은 언어 쓰지. 장점을 나열해볼까? runtime이나 vm없이 돌아야 하는 환경이 있는데 c로하긴 뭣같고 생산성도 어느정도 나오고 가져다쓸 라이브러리도 많고, STL쓰면 코드재활용해서 윈도,리눅스 코드재사용가능하고 임베디드에서도 쓸수있고. 속도가 안 빨라도 되는 로직이라도 한번만들어 두면 자바에붙였다 파이선에 붙였다. 대부분의 스크립트에서 JNI같은 인터페이스 지원하니까, 언어 환경 제약없이 가져다쓸수있고. 이런건 스크립트로 못하지 장점도 의외로 많음
malloc() 쓸거면 걍 C# 쓰자구요. 윈도우 기준으로 malloc() 은 process heap 에서 HeapAllocate() 로 할당하는데 애초에 윈도우의 -Heap 시스템은 옛날 메모리 16메가 64메가 하던 시절을 기준으로 개발된거라 주소공간만 reserve 하고 물리적 메모리의 commit 은 페이지가 필요할 때 몇개씩만 하는, 지금 시대 기준으론 느리고 비효율적인 시스템임.
까라면 까야지
그렇지않겠읍니까
39.115 // 뭐 각자 환경이 다르니까 따지고 보면 그게 정답이긴 함. 난 걍 내 개발환경 경험에 기반한 지극히 주관적인 일반론(?) 일 뿐ㅋ
근데 규모 좀 되는 겜 만드는 분들은 C++말고는 답 없는 듯
주소공간만 reserve하고 물리적commit은 필요할때 하는건 java도 마찬가지 아니냐? 장점인데? 그렇게 안하는 시스템후진거 아니야?
39.115 // 메모리를 존나게 많이 쓰는 서버 어플 같은 프로그램에서 메모리 풀링할 땐 오히려 단점임.
말록을 요즘 세상에 누가 써요 new delete도 잘 안 쓰는데.. 기본 얼로케이터 써서 C#보다 느리다고요? 뭐 그렇게 주장하시니 할말은 없습니다만 벤치마크나 논문에서 JVM한테도 밀리는 CLR 이네요 - return 0;
당장 JVM은 GC 사이클만 ms 단위라는걸 기억합시다 ㅋㅋㅋㅋ - return 0;
메모리 풀링의 목적은 단순히 풀링하면 좋다가 아니라, 멀티쓰레딩에서 Thread Local Block Pool 을 통해 할당/반납 병목을 최소화하기 위함임. 예전 구글에서 내놓은 범용 메모리 할당 시스템도 Thread Local Block Pool 통해 성능향상을 입증했을 정도니까.
키야 고수분들의 대화에 불알을 탁 치고 갑니다
성능이 중요한 부분은 C++로 만들고 다른 부분은 고급언어로 만들자는데, 결국 C++ 개발자는 꾸준히 필요한거잖아. 그리고 Node.js 같은거 보면 결국 코어는 C++로 빼고 실제 개발은 자바스크립트로 하잖아? 자바, C#은 C++ 처럼 메모리를 다룰 수 있는 것도 아니고, 그렇다고 자바스크립트마냥 쉬운 것도 아니고. 어중간한 포지션에 있다가 스크립트 언어에 지분을 뺏겨버리는 게 당연하지 않음? 네 말대로라면 끝까지 살아남을 언어는 C++겠지 ㅋㅋ
응 AAA게임들 죄다 c++씀^^
20세기 cpp표준을 보고 계시나
ㄴㄴ응 JAVA가 언어 점유율 1위니 자바가 최고 언어임.