|
|
I think it is, for the most part. His whining about compile times is understandable because most people don't seem to know how to write header files with that in mind. PIMPL being not used enough is another cause.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Sure, I can't use either 
|
|
|
|
|
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
|
|
|
|
|
Well.. C++ multiple inheritance is always full of surprise, isn't it?! 
|
|
|
|
|
Dean Roddey wrote: you can't write even a modest practical application without third party libraries.
I respectfully disagree. I've written several useful utilities using "pure" C++ (and the standard library.) Adding third party libraries make it even more rich, as it does with every language, including Python.
I'm now working on a server which uses asio, rapidJson, OpenSSL and LZ4 and SQLite. However, the majority of the code is "straight" C++.
|
|
|
|
|
I'm not sure I'd consider a utility to be a practical end user type application. Anyhoo, it's at a significant disadvantage relative to languages like C# or Java that have far more built in functionality. And it's far less likely that your experience working on project A will apply to project B when you move to another company.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: And it's far less likely that your experience working on project A will apply to project B when you move to another company.
Quite to the contrary. My C++ experience has transferred extremely well through the recent years and multiple contracts/short term jobs. In my most recent project, I easily cut months (no exaggeration) off the development time because of this.
|
|
|
|
|
Dean Roddey wrote: I'm not sure I'd consider a utility to be a practical end user type application.
I'll let my users know
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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, 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
|
|
|
|
|
Dean Roddey wrote: 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,...
Amen brother.
Dean Roddey wrote: ...but huge friction on the big ticket items.
I guess I'm part of the problem - C/C++ is all I got, and I probably use/understand a tenth of it. But it's got C, and that, to my feeble mind, keeps it close to the bits that sometimes get overclocked. I like that.
Can't presume to add anything to the 'what we need' discussion, save to say less might be more.
Carry on
T
|
|
|
|
|
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
|
|
|
|
|
That can be true. Of course you don't have to use any of the 'modern' bits if you don't want, at least you don't if you are willing to roll your own. If you use third party libraries you are forced to use whatever hodgepodge of features that the libraries you use choose to implement, to some degree anyway.
But C++ had all the capabilities you really NEEDED a decade plus ago. There have been some useful things that are not burdensome added since then, and I make use of those, but it's not like you couldn't do really high quality, large scale code with C++ in the 2000s.
To me, things that increase compile time safety (where that doesn't mean over-templating) are all useful things. Override, method default, method delete, and [nodiscard] are simple to use, don't introduce overhead or complexity, and allow the compiler to watch your back day after day.
Lambdas if not abused can get rid of a class of complexities because of their ability to be capturing. But, you can't pass capturing lambdas to function pointer parameters. So you are forced to use generic templated parameters, which gets you into the massive silliness that is so much part of modern C++, the 'one error generates a million barely comprehensible errors' thing.
Stuff like RAII and smart pointers (which I call janitors because the concept really goes way beyond RAII) has always been around. One thing that amuses me is how 'modern C++' people somehow think putting everything in a smart pointer is somehow magically making their code safe. Often it is just moving the dangers to other realms, which are just as hard to see (maybe more so sometimes), and just as silently deadly (maybe even more so sometimes.)
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.
|
|
|
|
|
Dean Roddey wrote: and leaving C++ in a situation where even now you can't write even a modest practical application without third party libraries.
Not quite sure what you mean by "modest practical" but I haven't written any application in over 25 years (at least) in any language without relying on third party libraries.
Wouldn't even agree to that unless who ever was paying the bills agreed to at a minimum a much larger project timeline. And I would use that extra time to re-engineer existing libraries very likely using those third party library API definitions to replicate them.
Certainly 25 years ago I can remember creating my own logging library and implementing a testing framework as two examples of libraries that I consider essential now. I see no point in re-implementing those, especially given that I know the difficulties I had getting just those right then.
|
|
|
|
|
I write huge applications without third party libraries. If I could to it by myself, then clearly the collective C++ community could have (in all these years) managed to get standard and portable and reasonable subsets of at least a large core set of commonly required functionality into the language itself, in order to be more competitive with newer languages like Java and C#.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: collective C++ community could have (in all these years) managed to get standard and portable and reasonable subsets of at least a large core set of commonly required functionality into the language itself
Rather certain that the C++ community specifically does not want to do that.
There was a magazine called the 'C++ Users Journal' which had at least one columnist and perhaps two that were active participants (and perhaps chairs) on the ANSI C++ committee. From what they wrote over years, as I recall, there were specific attempts to move additional libraries into the core language and those were rejected basically unanimously. Even getting templates in there and the template libraries was a fight.
|
|
|
|
|
Too bad the process didn't work for the Template libraries
Explorans limites defectum
|
|
|
|
|
As I recall there were specific attempts to preclude the STL from the language. That library both by being contentious and in attempts to limit the scope extended the certification process by years.
If I recall correctly there was also an attempt to specifically include threads which failed.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
