Does not mean to re-implement Python again.
Reply content:
Greenspun ' s tenth rule, with June encouragement:
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, Bug-ridden, Slow implementatio N of half of Common Lisp. Thank you for your invitation.
The purpose of the question is somewhat questionable. After reading most of the answers here, my feeling is that maybe we all misunderstood the questioner's meaning. I guess the intention of the questioner is nothing to do with Python, and the real meaning is: "Can we plug in as many common C + + functions as possible into the standard library, so that C + + programmers no longer need to take care of the details". As for the so-called "reach and development efficiency of Python", it is just an analogy.
If my guess is not wrong, then my answer is: yes, but only in specific areas.
Older programmers familiar with distributed programming may remember CORBA and ICE. CORBA is a distributed architecture of the older generation, C/C + + binding is used for the type of a string, while ICE uses the C + + standard library string directly. More than that, ICE has used a large number of STL standard libraries. When it comes to development efficiency, the ICE C + + binding really saves me a lot of time tossing the C string allocation and deallocation problem in CORBA, making a small application really much easier.
But why do I say that it only works in specific areas? Because of the location of C + +, it has a huge limit. Still an example of a string: Does anyone know how many of the widely used C + + libraries do not implement their own string classes? ICU, Wxwidget, Qt, MFC, and a lot of popular libraries, are reinventing the wheel. I have no intention of asking why we are facing this chaotic situation: this is a historical issue. In any case, C + + using library fragmentation is already a fact that cannot if.
Now that we can't, if we talk about rebuilding the standard function library, it can only be confined to a specific framework, such as MFC, such as Qt. Within these specific frameworks, there can indeed be a much higher development efficiency than using the C + + standard library purely. The only problem: please do not go beyond the scope of the framework, or you may cause trouble for yourself.
So, under ideal circumstances, can we achieve Python's development efficiency? Maybe, but if the ideals are not reached, I think we should not discuss, based on reality better. C + + is inherently raw Memory processing language
If you do not have to deal with the original user-state memory, but you have chosen C + +, it means you do not understand
Because you gave up the most useful features of both languages. You're talking about writing a DSL in C + +? No.
You'll spend about the same time as Python.
Python twice times the time to type.
Python 100 times times the time to compile.
Add up to 10 times times more time debug memory out of bounds and wild pointers. C + + When I feel that the most impact on development efficiency I think it is not like Python can print out anything.
and a mature logging log library to help with debugging.
So when I developed C + +, I wrote a header file library. Without reliance, there is no harm.
Direct include comes in and you can use it.
https:// Github.com/yanyiwu/limo NP
Hope it would help answer the question first, no! (only the C + + language is answered)
From the perspective of the language itself, C + + is not designed for this production environment, even if a lot of class library, and then more patches, to achieve more Python functionality, she is C + +, the C + + functionality is still there, and more features of course bring more complex logic, so it is not as fast as python development. and this C + + library is probably too big for ordinary PCs to tolerate, compile time and size are not acceptable to ordinary users.
But!! If you have a very large class library, it does greatly increase the learning cost of C + +, while increasing the complexity of C + +, while the source code of C + + will become relatively short is also true, if the library is well written, the code is simplified and Python is not a big difference, or more like a magical C + + Similar memory auto-management language.
I have just come into contact with a very large C + + library, is now learning, personal feel like in a completely unfamiliar language, all kinds of calls to query long documents to write a few lines of code, but if skilled, should be able to do the original C + + at least half of the code to solve the same problem. Why not understand: some people in order to use C/C 艹 language to achieve high development efficiency, finally invented python?
What do you think of the C in CPython? Objectivec.
Fast development speed but slow execution c++11 + STL + boost development efficiency can be a battle with Python, but the speed of compilation is no better than
for(autox:{1,2,3,5,8,13,21,34})cout<<x<<'\n';
