샤프는 2000년쯤에 태어나 아주 유아기였고 플러스가 몰고 있었기 때문에 대중화를 위해 닷넷에 C++ 브릿지를 만들었습니다. 그건 그렇고, 샤프는 델파이와 C++빌더 개발자들이 만들었는데, 그 당시에는 공통적인 개념이 얼마나 많은지 매우 놀랐습니다. 동일한 속성, 이벤트를 가져옵니다.
IMHO, Sharp는 Microsoft의 다소 성공적인 프로젝트입니다. /Net 플랫폼에서 사람들을 유인했을 뿐만 아니라 .Net에서 언어의 모든 잡종 구문을 제공 했습니다. 최소한 BASIC으로 작성하십시오!
마지막 예에 마법을 추가하자)))) 손으로 쓰기에는 너무 게으른, 내가보고 싶었던 바로 그 개념, 내가 보는 것 같아, 이제 clave를 덜 노크 할 수 있습니다
interface IStrategy
{ void Algorithm() { Print ( "Это не должно запускаться!!!" ); } };
//+------------------------------------------------------------------+class CStrategy : public IStrategy
{
protected :
int x;
};
//+------------------------------------------------------------------+#define CLASS(NAME) class NAME: public CStrategy{\
public : NAME() { Print ( __FUNCTION__ ); x = 01 ; }\
void Algorithm() { Print ( __FUNCTION__ , ", x = " , x);} };
//+------------------------------------------------------------------+
CLASS( CStrategy_01 );
CLASS( CStrategy_02 );
//+------------------------------------------------------------------+class Context
{
private :
IStrategy *s;
public :
Context(IStrategy *_strategy) { Print ( __FUNCTION__ ); s = _strategy; }
~Context() { delete s; }
void GetStrategy() { s.Algorithm(); }
};
//+------------------------------------------------------------------+
Context c1( new CStrategy_01);
Context c2( new CStrategy_02);
//+------------------------------------------------------------------+voidOnStart ()
{
c1.GetStrategy();
c2.GetStrategy();
}
//+------------------------------------------------------------------+
Vladimir Simakov : 그리고 그것은 나를 끌어들이지 않습니다. 편리하고 단순해 보이지만 드라이브는 프로에서 처럼 뭔가. 철에서 멀리 이동하십시오.
제 생각에는 C ++가 하드웨어에 더 가깝다는 환상이 있습니다. 현대 프로세서용 코드를 가능한 한 효율적으로 작성하기 위해 올바른 코드 작성에 대한 도크를 어디선가 찾을 수 있을지 의심스럽습니다. 90년대 후반에 저는 Pentiums에서 읽는 것을 좋아하지만 그루터기 줄이 급격히 증가하기 시작했을 때 읽을 시간조차 없다는 것을 깨달았습니다. 그러나 지금은 프로세서용 Windows 드라이버를 이미 설치하고 있습니다. IMHO 말도 안되는 소리, 어떻게 될 수 있습니까 장작 퍼센트 미만으로 수행 ... 그러나 아아, 이제 모든 것이 그렇게 작동합니다. 모든 것이 가상이고 모든 것이 기성품 성경을 통해 이루어지며 모두 컴파일러 최적화를 통해 이루어집니다 .... 일반적으로 IMHO는 매우 효과적인 것을 작성하는 환상입니다. 코드가 원래 한 곳에서 비뚤어진 손으로 작성된 경우 아무 것도 도움이되지 않는다는 것이 분명합니다.)))
예, 샤프에서는 훨씬 쉽습니다. 그리고 속도는 거의 동일하지만 cli가 없으면 플러스가 1.5 배 승리합니다.
베어 사이클을 기반으로 하는 모든 종류의 유사한 테스트를 보았지만 이것은 아무것도 아닙니다. CLR 아래에 있는 스레드 수(최소한 바이트 코드는 컴파일해야 함)와 이 경제가 차지하는 메모리 양에 대해 생각하는 사람은 아무도 없습니다.
오래전에 어떻게든 cTrader를 설치했는데, 인상이 브레이크 g .... .
그리고 일반적으로 - 모든 사람이 구현하는 최소 세트와 같은 프로세서 명령의 균일성에 동의할 수 있는데(비록 바이너리 소프트웨어가 매우 잘 허용됨) 다른 추상화 계층(바이트 코드, 가상 머신 )을 생성해야 하는 이유는 무엇입니까? 아마도 그들이 신이고 무엇과도 바꿀 수 없는 샌드박스를 만들고자 하는 욕망일 것입니다. 그들은 닷넷을 통해 끈질기게 밀어붙이는 동시에 플러스에 글을 쓰고 싶어하는 사람들의 삶을 복잡하게 만들었습니다.
추신: 나는 cli c ++에 대해 말하는 것이 아닙니다. 이것은 일반적으로 일종의 오해입니다.
추신: 통계의 경우 - github의 C/C ++ 프로젝트는 Sharp(17년)보다 3배 더 많습니다.
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ... 여기에서 오랫동안 생각할 수 있습니다
상황을 평가할 때 중요한 포인트는 중국과 인도의 프로그래머 수입니다. 정말 많습니다. 이 국가의 업계 동향은 모릅니다. 아마도 그들은 지금 C++에 앉아 있을 것입니다.
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"이었으며 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다))), 2017에는 C ++가 많이 있습니다. 2019년에는 많은 C# 프로젝트가 있을 수 있습니다. 여기서 추측할 수는 없습니다.
추신: 매우 주관적인 평가입니다... 하지만 Python에 있는 프로젝트는 몇 개입니까? - Google의 모든 새 동영상은 Python으로만 제공되는 모든 프레젠테이션
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ... 여기에서 오랫동안 생각할 수 있습니다
상황을 평가할 때 중요한 포인트는 중국과 인도의 프로그래머 수입니다. 정말 많습니다. 이 국가의 업계 동향은 모릅니다. 아마도 그들은 지금 C++에 앉아 있을 것입니다.
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"이었으며 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다))), 2017에는 C ++가 많이 있습니다. 2019년에는 많은 C# 프로젝트가 있을 수 있습니다. 여기서 추측할 수는 없습니다.
추신: 매우 주관적인 평가입니다... 하지만 Python에 있는 프로젝트는 몇 개입니까? - Google의 모든 새 동영상은 Python으로만 제공되는 모든 프레젠테이션
글쎄, 모든 언어로 된 프로젝트에 대한 모든 종류의 작업이 있으며 평균적으로 특정 평균 프로젝트가 나와야합니다.https://githut.info/ 에 자세한 통계가 있지만 14세입니다.
나는 적어도 이념적인 이유로 샤프에 가고 싶지 않다. 나는 Java로 글을 쓸 가능성이 더 큽니다(가능성은 낮지만).
GitHub provides publicly available API to interact with its huge dataset of events and interaction with the hosted repositories. GitHub Archive takes this data a step further by aggregating and storing it for public consumption. GitHub Archive dataset is also available via Google BigQuery. The quantitative data used in GitHut is collected from...
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ... 여기에서 오랫동안 생각할 수 있습니다
상황을 평가할 때 중요한 포인트는 중국과 인도의 프로그래머 수입니다. 정말 많습니다. 이 국가의 업계 동향은 모릅니다. 아마도 그들은 지금 C++에 앉아 있을 것입니다.
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"이었으며 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다))) , 2017에는 C ++가 많이 있습니다. 2019년에는 많은 C# 프로젝트가 있을 수 있습니다. 여기서 추측할 수는 없습니다.
추신: 매우 주관적인 평가입니다... 하지만 Python에 있는 프로젝트는 몇 개입니까? - Google의 모든 새 동영상은 Python으로만 제공되는 모든 프레젠테이션
2005년에 저는 독일 사무실에서 C++에서 C#으로 롤 프린터용 GUI를 다시 작성하면서 약간의 일을 했습니다. 그제서야 샤프가 교과서 같은 걸 주는 걸로 알고 있어서 번역에 전혀 문제가 없었다. 그는 지루해져서 떠났지만 그냥 앉아서 다시 쓰기, 생각할 필요가 없습니다.
Python을 사용하면 이 해석되고 느리고 추악한 언어가 어떻게 정상에 도달할 수 있는지 미스터리입니다.
샤프는 2000년쯤에 태어나 아주 유아기였고 플러스가 몰고 있었기 때문에 대중화를 위해 닷넷에 C++ 브릿지를 만들었습니다. 그건 그렇고, 샤프는 델파이와 C++빌더 개발자들이 만들었는데, 그 당시에는 공통적인 개념이 얼마나 많은지 매우 놀랐습니다. 동일한 속성, 이벤트를 가져옵니다.
IMHO, Sharp는 Microsoft의 다소 성공적인 프로젝트입니다. /Net 플랫폼에서 사람들을 유인했을 뿐만 아니라 .Net에서 언어의 모든 잡종 구문을 제공 했습니다. 최소한 BASIC으로 작성하십시오!
IMHO, Sharp는 Microsoft의 다소 성공적인 프로젝트입니다. /Net 플랫폼에서 사람들을 유인했을 뿐만 아니라 .Net에서 언어의 모든 잡종 구문을 제공 했습니다. 최소한 BASIC으로 작성하십시오!
@fxsaber가 다음 위치에 많은 예를 게시 했기 때문에 포럼에서 검색을 했습니다.
마지막 예에 마법을 추가하자)))) 손으로 쓰기에는 너무 게으른, 내가보고 싶었던 바로 그 개념, 내가 보는 것 같아, 이제 clave를 덜 노크 할 수 있습니다
그리고 그것은 나를 끌어들이지 않습니다. 편리하고 단순해 보이지만 드라이브는 프로에서 처럼 뭔가. 철에서 멀리 이동하십시오.
제 생각에는 C ++가 하드웨어에 더 가깝다는 환상이 있습니다. 현대 프로세서용 코드를 가능한 한 효율적으로 작성하기 위해 올바른 코드 작성에 대한 도크를 어디선가 찾을 수 있을지 의심스럽습니다. 90년대 후반에 저는 Pentiums에서 읽는 것을 좋아하지만 그루터기 줄이 급격히 증가하기 시작했을 때 읽을 시간조차 없다는 것을 깨달았습니다. 그러나 지금은 프로세서용 Windows 드라이버를 이미 설치하고 있습니다. IMHO 말도 안되는 소리, 어떻게 될 수 있습니까 장작 퍼센트 미만으로 수행 ... 그러나 아아, 이제 모든 것이 그렇게 작동합니다. 모든 것이 가상이고 모든 것이 기성품 성경을 통해 이루어지며 모두 컴파일러 최적화를 통해 이루어집니다 .... 일반적으로 IMHO는 매우 효과적인 것을 작성하는 환상입니다. 코드가 원래 한 곳에서 비뚤어진 손으로 작성된 경우 아무 것도 도움이되지 않는다는 것이 분명합니다.)))
예, 샤프에서는 훨씬 쉽습니다. 그리고 속도는 거의 동일하지만 cli가 없으면 플러스가 1.5 배 승리합니다.
베어 사이클을 기반으로 하는 모든 종류의 유사한 테스트를 보았지만 이것은 아무것도 아닙니다. CLR 아래에 있는 스레드 수(최소한 바이트 코드는 컴파일해야 함)와 이 경제가 차지하는 메모리 양에 대해 생각하는 사람은 아무도 없습니다.
오래전에 어떻게든 cTrader를 설치했는데, 인상이 브레이크 g .... .
그리고 일반적으로 - 모든 사람이 구현하는 최소 세트와 같은 프로세서 명령의 균일성에 동의할 수 있는데(비록 바이너리 소프트웨어가 매우 잘 허용됨) 다른 추상화 계층(바이트 코드, 가상 머신 )을 생성해야 하는 이유는 무엇입니까? 아마도 그들이 신이고 무엇과도 바꿀 수 없는 샌드박스를 만들고자 하는 욕망일 것입니다. 그들은 닷넷을 통해 끈질기게 밀어붙이는 동시에 플러스에 글을 쓰고 싶어하는 사람들의 삶을 복잡하게 만들었습니다.
추신: 나는 cli c ++에 대해 말하는 것이 아닙니다. 이것은 일반적으로 일종의 오해입니다.
IMHO, Sharp는 Microsoft의 다소 성공적인 프로젝트입니다. 그들은 /Net 플랫폼에서 사람들을 유인했을 뿐만 아니라 .Net에서 언어의 모든 잡종 구문을 제공 했습니다. 최소한 BASIC으로 작성하십시오!
나는 다르게 말할 것입니다. 사람들은 Windows에서 쫓겨났습니다. 어쩌면 주관적일 수 있습니다.
추신: 통계의 경우 - github의 C/C ++ 프로젝트는 Sharp(17년)보다 3배 더 많습니다.
추신: 통계의 경우 - github의 C/C ++ 프로젝트는 Sharp(17년)보다 3배 더 많습니다.
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ... 여기에서 오랫동안 생각할 수 있습니다
상황을 평가할 때 중요한 포인트는 중국과 인도의 프로그래머 수입니다. 정말 많습니다. 이 국가의 업계 동향은 모릅니다. 아마도 그들은 지금 C++에 앉아 있을 것입니다.
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"이었으며 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다))), 2017에는 C ++가 많이 있습니다. 2019년에는 많은 C# 프로젝트가 있을 수 있습니다. 여기서 추측할 수는 없습니다.
추신: 매우 주관적인 평가입니다... 하지만 Python에 있는 프로젝트는 몇 개입니까? - Google의 모든 새 동영상은 Python으로만 제공되는 모든 프레젠테이션
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ... 여기에서 오랫동안 생각할 수 있습니다
상황을 평가할 때 중요한 포인트는 중국과 인도의 프로그래머 수입니다. 정말 많습니다. 이 국가의 업계 동향은 모릅니다. 아마도 그들은 지금 C++에 앉아 있을 것입니다.
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"이었으며 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다))), 2017에는 C ++가 많이 있습니다. 2019년에는 많은 C# 프로젝트가 있을 수 있습니다. 여기서 추측할 수는 없습니다.
추신: 매우 주관적인 평가입니다... 하지만 Python에 있는 프로젝트는 몇 개입니까? - Google의 모든 새 동영상은 Python으로만 제공되는 모든 프레젠테이션
글쎄, 모든 언어로 된 프로젝트에 대한 모든 종류의 작업이 있으며 평균적으로 특정 평균 프로젝트가 나와야합니다.https://githut.info/ 에 자세한 통계가 있지만 14세입니다.
나는 적어도 이념적인 이유로 샤프에 가고 싶지 않다. 나는 Java로 글을 쓸 가능성이 더 큽니다(가능성은 낮지만).
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ... 여기에서 오랫동안 생각할 수 있습니다
상황을 평가할 때 중요한 포인트는 중국과 인도의 프로그래머 수입니다. 정말 많습니다. 이 국가의 업계 동향은 모릅니다. 아마도 그들은 지금 C++에 앉아 있을 것입니다.
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"이었으며 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다))) , 2017에는 C ++가 많이 있습니다. 2019년에는 많은 C# 프로젝트가 있을 수 있습니다. 여기서 추측할 수는 없습니다.
추신: 매우 주관적인 평가입니다... 하지만 Python에 있는 프로젝트는 몇 개입니까? - Google의 모든 새 동영상은 Python으로만 제공되는 모든 프레젠테이션
2005년에 저는 독일 사무실에서 C++에서 C#으로 롤 프린터용 GUI를 다시 작성하면서 약간의 일을 했습니다. 그제서야 샤프가 교과서 같은 걸 주는 걸로 알고 있어서 번역에 전혀 문제가 없었다. 그는 지루해져서 떠났지만 그냥 앉아서 다시 쓰기, 생각할 필요가 없습니다.
Python을 사용하면 이 해석되고 느리고 추악한 언어가 어떻게 정상에 도달할 수 있는지 미스터리입니다.
주관적인 평가, 품질 또는 오히려 프로젝트 작업은 매우 작을 수 있습니다 ...
글쎄, 내가 위에서 쓴 것처럼 - C ++에서 C #으로의 전환은 매우 "고통"입니다. 여기서 Microsoft는 프로그래머가 앞뒤로 서두르게 만들기 위해 모든 것을했습니다)))
Python을 사용하면 이 해석되고 느리고 추악한 언어가 어떻게 정상에 도달할 수 있는지 미스터리입니다.
나는 그것이 다음과 같이 갔다고 생각한다:
1. 프로그래머나 프로그래밍의 기본에 익숙한 사람보다 항상 더 많은 사용자가 있습니다.
2. 인터프리터는 사용자가 더 잘 이해할 수 있습니다.
기계에서 응답을 받았지만 그녀가 거기에서 어떻게 생각하는지 이해하지 못하지만 다시 작성하면 기계가 당신처럼 생각한다는 것을 알 수 있습니다)))
3. 유형에 대한 불필요한 지식과 기타 넌센스로 사용자에게 부담을 주지 않는 고품질의 통역사가 필요합니다.
4. 언어가 방대해지기 위해서는 소프트웨어가 가능한 한 개방적이고 접근 가능해야 합니다.
음, 결과는 1,2,3,4입니다 - Python은 자체적으로 통합되었으며 사용자의 군대가 있는 경우 해당 사용자를 끌어들인 프로그래머가 해결하고 차례로 무리를 만든 문제가 분명히 있을 것입니다. 도서관의
))))
나는 Sharp의 장점에 동의하지만 반대 방향으로 단어에서 c / c ++에 대한 지식이 전혀 없다면 ... 일부 헤더 파일은 새싹에있는 Sharpist의 모든 욕구를 죽일 것입니다. 임호.
여기 당신이 옳았지만 아무도 특히 C #에서 C ++로 다시 실행하지 않습니다 - 왜? 글쎄, C ++에서 완성 된 dll을 Sharp에 연결하고 사용하십시오. 특히 dll을 포함 할 C #에서 하나의 exe-shnik을 쉽게 만들 수 있기 때문에
나도 모르겠다, 나는 C#의 세계를 발견했다 - 나는 그것을 닫지 않을 것이다, 그것은 매우 편안하다, 그물에 많은 매뉴얼이 있고, 훨씬 더 많은 기성품 라이브러리가 있다, 10명의 목숨은 ' 모든 것을 시도하기에 충분합니다)))