Is the new C++ as easy to use as Python?
-
Modern C++ is very complex and the bulk of people who use it probably don't understand half of the details. It's vastly over-templated. It's not really possible to keep build times low when you have enormous amounts of templated code in a large code base because all that code is inlined. A lot of folks in the 'modern' camp seem to have convinced themselves that inheritance is evil, and will jump through fairly ridiculous hoops not to use it, using horrendously ugly stuff like the standard variant stuff and basically doing what OO was invented to avoid (lots of switch statements everywhere, and standard variant is just a particularly ugly switch statement.) A huge amount of effort was spent creating a seriously over-engineered container system, while leaving fundamental stuff not dealt with, and leaving C++ in a situation where even now you can't write even a modest practical application without third party libraries.
Explorans limites defectum
Dean Roddey wrote:
while leaving fundamental stuff not dealt with
Like what?
-
Dean Roddey wrote:
while leaving fundamental stuff not dealt with
Like what?
Language-wise decent enumerations would be a big one IMO. Otherwise, a vast swath of functionality that things like C# has built in that are important to most practical applications. Sockets, text transcoding, loadable resources, XML, JSON, HTTP, MVC, graphic file formats, image manipulation, a good streaming system, RPC of some number of types, and on and on. Look, don't get me wrong, I probably have 10 times the vested interest in C++ than all of you put together. But as it stands right now, it's got problems. I know what it's like to work in a C++ system with all those things and much, much more since I've created one. That's what C++ should be like by now.
Explorans limites defectum
-
Language-wise decent enumerations would be a big one IMO. Otherwise, a vast swath of functionality that things like C# has built in that are important to most practical applications. Sockets, text transcoding, loadable resources, XML, JSON, HTTP, MVC, graphic file formats, image manipulation, a good streaming system, RPC of some number of types, and on and on. Look, don't get me wrong, I probably have 10 times the vested interest in C++ than all of you put together. But as it stands right now, it's got problems. I know what it's like to work in a C++ system with all those things and much, much more since I've created one. That's what C++ should be like by now.
Explorans limites defectum
Dean Roddey wrote:
a vast swath of functionality that things like C# has built in
were written in C++. What's your point?
-
Dean Roddey wrote:
a vast swath of functionality that things like C# has built in
were written in C++. What's your point?
Well, part of my point is that your point would be a lot more interesting if you could USE that code in C++, which you can't, so it's sort of a moot point.
Explorans limites defectum
-
Well, part of my point is that your point would be a lot more interesting if you could USE that code in C++, which you can't, so it's sort of a moot point.
Explorans limites defectum
Do you want to use .Net in Assembly too?
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Well, part of my point is that your point would be a lot more interesting if you could USE that code in C++, which you can't, so it's sort of a moot point.
Explorans limites defectum
Well, I take your point - reuse is good. Having a complete library is good. But we are primitive monkeys. We compete with OS's. We compete with API's. We compete with whatever's on the browsers' default. I don't want a language that does everything. I want a language that can do everything. When you come up with something better than C++ lemme know. Cheers T
-
This forum posting seems to say yes. So-called "modern C++" (basically C++11 and beyond) is really immensely more ple... | Hacker News[^]
Yes and no. The biggest problem by far is C++'s compatibility with C and modern C++'s compatibility with ancient C++. Meaning if you look for tutorials or ask in forums, you may and very much will come across information from the days of old, when C++ had all the disadvantages of low-level C and high-level-languages combined without any advantages. Well, this sentence is somewhat exaggerated, but the point stands: There's too much reading material on C++ and too many C++ programmers stuck in the past. To take advantage of modern C++, you need to understand when you're facing old C++ and avoid that. That said, modern C++ itself isn't quite as easy to use as Python as you still have the static typing system, but once you learn to use it properly, it's a) actually darn easy to use (and you can kill a huge lot of difficulties by typing everything as auto) and b) the compiler catches tons of errors due to said static typing and the overall more static nature of the language. Short: It's more complicated to quickly prototype in but the investment pays back huge when you build complex software that needs to bloody hell run. Still, the overhead of avoiding all the legacy crap is rather substantial. I dearly wish the C++ committee came up with a modern mode. Let's say, unless a code file contains a #pragma(IAmStuckInThePast), every non-modern construct for which there's a modern replacement is a compiler error.
-
This forum posting seems to say yes. So-called "modern C++" (basically C++11 and beyond) is really immensely more ple... | Hacker News[^]
-
Yes and no. The biggest problem by far is C++'s compatibility with C and modern C++'s compatibility with ancient C++. Meaning if you look for tutorials or ask in forums, you may and very much will come across information from the days of old, when C++ had all the disadvantages of low-level C and high-level-languages combined without any advantages. Well, this sentence is somewhat exaggerated, but the point stands: There's too much reading material on C++ and too many C++ programmers stuck in the past. To take advantage of modern C++, you need to understand when you're facing old C++ and avoid that. That said, modern C++ itself isn't quite as easy to use as Python as you still have the static typing system, but once you learn to use it properly, it's a) actually darn easy to use (and you can kill a huge lot of difficulties by typing everything as auto) and b) the compiler catches tons of errors due to said static typing and the overall more static nature of the language. Short: It's more complicated to quickly prototype in but the investment pays back huge when you build complex software that needs to bloody hell run. Still, the overhead of avoiding all the legacy crap is rather substantial. I dearly wish the C++ committee came up with a modern mode. Let's say, unless a code file contains a #pragma(IAmStuckInThePast), every non-modern construct for which there's a modern replacement is a compiler error.
I think you've hit the nail on the head - the vast baggage that comes along with C++'s attempts to retain (at least superficially) compatibility with the past iterations makes it both incredibly difficult to ensure you are up to date and using the 'correct' constructs, and also means - unless you can avoid using/calling legacy code etc - that there are so many possible ways of doing things that it has become 'too difficult' to use unless you are immersed. I gave up developing in C++ for the most part when I realised it was taking me more time and effort to understand and use correctly the various constructs that made the language most effective than it was to solve the generally non-time critical problems I was working on. Obviously others will have different experiences and hence viewpoints, I'm not saying mine is the only one. To my mind C++ has effectively evolved into a new language, so much so that someone coming to it from new is probably in a much better place than someone like me who started with assembly language and has moved through C, C++ etc over the years. I think it is past time really for the latest iteration of C++ to drop all the 'legacy/compatability' stuff and stride out as a new language without all the baggage.
-
This forum posting seems to say yes. So-called "modern C++" (basically C++11 and beyond) is really immensely more ple... | Hacker News[^]
-
Modern C++ is very complex and the bulk of people who use it probably don't understand half of the details. It's vastly over-templated. It's not really possible to keep build times low when you have enormous amounts of templated code in a large code base because all that code is inlined. A lot of folks in the 'modern' camp seem to have convinced themselves that inheritance is evil, and will jump through fairly ridiculous hoops not to use it, using horrendously ugly stuff like the standard variant stuff and basically doing what OO was invented to avoid (lots of switch statements everywhere, and standard variant is just a particularly ugly switch statement.) A huge amount of effort was spent creating a seriously over-engineered container system, while leaving fundamental stuff not dealt with, and leaving C++ in a situation where even now you can't write even a modest practical application without third party libraries.
Explorans limites defectum
I tend to agree with you on your assessments, though I am not all that familiar with the C++ language in depth. many years ago when dinosaurs were still considered big pets, I met a senior C++ engineer and had a very nice discussion with him. He had been coding in C++ for over 25 years and he told that the majority of issues with C\C++ development come from the fact that the majority of developers using this language really did not understand the language in depth; hence the many issues with C++ applications. He went on to say that do quality C\C++ development you really have to spend a lot of time understanding how the internals work...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
This forum posting seems to say yes. So-called "modern C++" (basically C++11 and beyond) is really immensely more ple... | Hacker News[^]
Let's compare these two equivalent code snippets: C++:
auto start = std::chrono::high_resolution_clock::now();
doStuff();
auto stop = std::chrono::high_resolution_clock::now();
auto diff = stop - start;
auto ms = std::chrono::duration_cast(diff);
std::cout << "Elapsed ms: " << ms.count() << " ms\n";Python:
start = time.perf_counter()
do_stuff()
stop = time.perf_counter()
ms = (stop - start) * 1000.0
print('Elapsed ms: ', ms, ' ms')In this case, the equivalent code is pretty similar, but modern C++ is generally more verbose out of the box.
-
Modern C++ is very complex and the bulk of people who use it probably don't understand half of the details. It's vastly over-templated. It's not really possible to keep build times low when you have enormous amounts of templated code in a large code base because all that code is inlined. A lot of folks in the 'modern' camp seem to have convinced themselves that inheritance is evil, and will jump through fairly ridiculous hoops not to use it, using horrendously ugly stuff like the standard variant stuff and basically doing what OO was invented to avoid (lots of switch statements everywhere, and standard variant is just a particularly ugly switch statement.) A huge amount of effort was spent creating a seriously over-engineered container system, while leaving fundamental stuff not dealt with, and leaving C++ in a situation where even now you can't write even a modest practical application without third party libraries.
Explorans limites defectum
I agree. At my last job where many people so embraced the "Modern" paradigm that they would rewrite stuff to use the latest language features, things went from code reviews requiring clear, readable code to the standard being "just cut and paste this templated blob and don't worry about how it works". Someone literally spent a couple of week turning a three line function call including lambda callback into a two line templated mess and were pleased with themselves it was shorter now.
-
Let's compare these two equivalent code snippets: C++:
auto start = std::chrono::high_resolution_clock::now();
doStuff();
auto stop = std::chrono::high_resolution_clock::now();
auto diff = stop - start;
auto ms = std::chrono::duration_cast(diff);
std::cout << "Elapsed ms: " << ms.count() << " ms\n";Python:
start = time.perf_counter()
do_stuff()
stop = time.perf_counter()
ms = (stop - start) * 1000.0
print('Elapsed ms: ', ms, ' ms')In this case, the equivalent code is pretty similar, but modern C++ is generally more verbose out of the box.
And, to be fair, you only got it that small by giving up compile time safety though use of auto, which is one of the reasons you'd use C++ to begin with.
Explorans limites defectum
-
Yes and no. The biggest problem by far is C++'s compatibility with C and modern C++'s compatibility with ancient C++. Meaning if you look for tutorials or ask in forums, you may and very much will come across information from the days of old, when C++ had all the disadvantages of low-level C and high-level-languages combined without any advantages. Well, this sentence is somewhat exaggerated, but the point stands: There's too much reading material on C++ and too many C++ programmers stuck in the past. To take advantage of modern C++, you need to understand when you're facing old C++ and avoid that. That said, modern C++ itself isn't quite as easy to use as Python as you still have the static typing system, but once you learn to use it properly, it's a) actually darn easy to use (and you can kill a huge lot of difficulties by typing everything as auto) and b) the compiler catches tons of errors due to said static typing and the overall more static nature of the language. Short: It's more complicated to quickly prototype in but the investment pays back huge when you build complex software that needs to bloody hell run. Still, the overhead of avoiding all the legacy crap is rather substantial. I dearly wish the C++ committee came up with a modern mode. Let's say, unless a code file contains a #pragma(IAmStuckInThePast), every non-modern construct for which there's a modern replacement is a compiler error.
This assumes that you believe that all of the modern stuff is actually better, which plenty of folks don't. Some of it is clearly useful, but some is very much a matter of opinion. And of course you have to distinguish between the language and the library. A lot of the stuff that most anyone writing new code wouldn't want to use is the old library stuff, while a lot of thew new language stuff is much more debatable as to whether it's better or just different, or whether any advantage is does have is outweighed by different problems it introduces.
Explorans limites defectum
-
Well, I take your point - reuse is good. Having a complete library is good. But we are primitive monkeys. We compete with OS's. We compete with API's. We compete with whatever's on the browsers' default. I don't want a language that does everything. I want a language that can do everything. When you come up with something better than C++ lemme know. Cheers T
Better is subjective, but the thing is that being better is not really enough anyway. You have to have a corpus of available and experienced developers who know the language and others who don't but yet who are willing to invest significant parts of their career development on it, which it might ultimately be of no value to them relative to learning other things. Chicken and egg and all that. Some folks would argue that Rust is a better language. From my semi-gross level scan I don't agree, at least as a very general purpose language, but some people obviously do think so. But will it ever be more than a niche language? The odds are against it, and it probably has more advantages than most new languages by far (being backed by a large organization that's not seen as having greedy or insular motivations.) And how many developers out there right now are experts at Rust if you wanted to hire up and start a big project? It seems to me that Rust could remain caught between Java/C# on one side and C++ on the other, without there ever being a big enough incentive for large numbers of people from either camp to move to the middle. These days it seems that there's almost no friction when it comes to introducing yet another UI framework or module manager or web app framework, but huge friction on the big ticket items.
Explorans limites defectum
-
And, to be fair, you only got it that small by giving up compile time safety though use of auto, which is one of the reasons you'd use C++ to begin with.
Explorans limites defectum
Auto deduces the type at compile time, so it's safe unless you intend the variable to be a base class of whatever the initializer returns.
-
Auto deduces the type at compile time, so it's safe unless you intend the variable to be a base class of whatever the initializer returns.
But that's the problem, you didn't say explicitly what it should be. If the right side gets accidentally changed, nothing is going to complain if what it got changed to supports the same interface (not terribly uncommon in the modern world if lots and lots of operator driven stuff.) If you explicitly say what it's supposed to be, then two things have to get simultaneous broken in the same way. If you don't, then only one has to get broken for potential silent errors.
Explorans limites defectum
-
But that's the problem, you didn't say explicitly what it should be. If the right side gets accidentally changed, nothing is going to complain if what it got changed to supports the same interface (not terribly uncommon in the modern world if lots and lots of operator driven stuff.) If you explicitly say what it's supposed to be, then two things have to get simultaneous broken in the same way. If you don't, then only one has to get broken for potential silent errors.
Explorans limites defectum
If that was the case I wouldn't use
auto. The situation you described is actually a feature of theautokeyword. It's pretty useful to only change the initializer without have to change the type declaration during refactoring. -
If that was the case I wouldn't use
auto. The situation you described is actually a feature of theautokeyword. It's pretty useful to only change the initializer without have to change the type declaration during refactoring.I don't think the point of a language should to make it easy to refactor without having to really think about what you are doing and the potential silent errors it could introduce. Significant refactoring isn't common and it should be approached very carefully. Being explicit it always safer.
Explorans limites defectum