|
"A little time, a little trouble, your better day"
Badfinger, "Better Days" No Dice Album
Great guitar solo from Pete Ham
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
|
ELO and Olivia Newton-John in Xanadu - my favorite ELO music
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
Billy Joel “You may be right, I may be crazy. But it just might be a lunatic you’re looking for”
Within you lies the power for good - Use it!
|
|
|
|
|
It just might be this one: The I-95 Song[^] NSFW so use the headphones. I actually got a DJ to play this one at a family friendly bar in beautiful, downtown Cheyenne, WY in 1989, and it got quite a bit of applause. 
Will Rogers never met me.
|
|
|
|
|
I think I got a new favourite song.
Within you lies the power for good - Use it!
|
|
|
|
|
|
Hanging on in quiet desperation...
pibbuR who has written his first post on CodeProject
|
|
|
|
|
We Gotta Get Out of This Place from The Animals
or
Highway to Hell from ACDC
|
|
|
|
|
AC/DC Dirty Deeds Done Dirt Cheap
It covers both me and my coding style 
(I had to reply to this one. I've lurked for years.)
|
|
|
|
|
|
|
|
Depending on the day, either Sledgehammer (Peter Gabriel) or King of Pain (The Police)
|
|
|
|
|
"I've always been crazy, but it's kept me from going insane."
|
|
|
|
|
|
As an incredibly enthusiastic user of C++ from its very first release, I've expressed this (personal) opinion a number of times over recent years: C++ has lost its way - it now takes more time, learning, effort and skill to make good, efficient use of C++ than it takes to solve the problems one is using it for.
A caveat: I am thinking specifically of business tasks and related domains - I accept that for the most cutting edge stuff near to the metal it still offers the one of the best overall effort/performance ratios.
In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways.
This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^]
Discuss! (ducks for cover...)
|
|
|
|
|
Quote: However, there are other common solutions that we also employed to reduce build times, including local caching, remote caching, and precompiled headers.
From the rest of the writing, it seems they haven't implemented precompiled headers correctly, because all their efforts to eliminate redundant headers amount to very little savings if the precompiled header gets each precompilation unit added once and then not again with additional redeclarations. At least that is the way I understand precompiled headers, and they have saved me a bunch of time in the past. I wish they would have talked about that aspect more as my understanding could be deepened.
PS - Mike Winiberg wrote: In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways.
This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^]
I don't see that article supporting your assertion in any meaningful way. All it seems to be saying is that their coders haven't kept their headers clean, and often included unneeded headers that they had to take out. That doesn't seem to be speaking about the difficulties inherent in modern C++.
|
|
|
|
|
"I don't see that article supporting your assertion..."
Well, YMMV indeed, but it demonstrates quite nicely, I think, how - in an attempt to maintain backward compatability - the C++ environment has required ever more esoteric procedures to keep it usable both compiling the code and learning the language and its libraries etc. That one should need to have precompiled headers, write add-ons (which even google had to do) to make compilation times acceptable etc speaks very well to the increasing complexity of the whole ecosystem, in my view.
Don't get me wrong, I'm not saying it isn't a good powerful dev environment - my team developed a whole airline/shipping/freight system in C++, and financial applications using parallel C++ for market-maker using a Transputer farm. But I reached a point where I realised it was taking far longer (for us anyway) to learn how to make good use of the ever increasing new features than it was to solve the problems we were facing.
Having made extensive use of one feature (manipulators on streams) to control printing, only to have that broken - and hence needing a rewrite - in version 2, followed by a partial regression in version 3 (another rewrite!), then complete collapse of our system after a third-party database library we were using was updated and broke references (implementing them by copying FFS) we came to the conclusion we were spending more time fighting the language environment than writing software.
Switched to Java, then later to Python, and heve not used C++ in a meaningful manner since.
If there is one thing I have learnt in my altogether too-long time in software dev, it is that - with a few domain specific exceptions - the language you develop with is largely irrelevant, so the less it gets in the way of the task you want to accomplish, the more productive you can be.
|
|
|
|
|
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
I agree with you that C++ is in danger of becoming a modern version of PL/1, containg something for everyone. I also agree that learning the entire language (and standard libraries) is becoming more and more difficult. However, C++ shares with C the philosophy that "if you don't use it, you don't pay for it" (or words to that effect). There is no reason that you can't use C++ as "C with classes", or at any other level between that and C++20/23/xx.
The language features I most use are RAII (exists from the ARM), templates & exceptions (C++98), threads & atomic variables (C++11), smart pointers (C++11?), and a few more advanced features (various, up to C++17). These have changed slighly over the years, but the changes are manageable.
Obviously, I use the standard library as well, but most changes to that have not been breaking changes.
Mike Winiberg wrote: Speeding Up C++ Build Times | Figma Blog[^]
Lastly, a decent developer spends most of his/her time on designing, writing code, and thinking about the code (debugging). The compilation time should be a small fraction of the total development time, and even that (as the article points out) may be optimized with a good design of your system.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Damn, that article is making the rounds !!
The (one of) problem with C++ is that it's an old language that needs to compete with more modern languages.
It can only be incrementally improved.
We underestimate how large the C++ code base is actually in production.
You can't just break backward compatibility (as much as I would like them to do it)
If that happens, many, many large organisations will never upgrade their toolsets.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Mike Winiberg wrote: As an incredibly enthusiastic user of C++ from its very first release,
45 years. And still enthusiastic?
Not denigrating C++ but rather that it is difficult to keep the same enthusiasm for anything that long.
Mike Winiberg wrote: technical debt that then has to be fought against in other ways.
Get a very old set of libraries, say before templates, update them to work with your compiler and then just don't use anything new.
Mike Winiberg wrote: This article I think demonstrates this nicely
Far as I can tell that doesn't enumerate the size of the code base. But it certainly seems to suggest that the author is working with a large one.
And a legacy one at that.
So I don't really see anything that suggests that there is a problem with C++ but rather a process problem that has been allowed to grow without bound. And so they want to use technology to fix it. Rather than decoupling the code base to reduce the dependent sections.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
