Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ and the Culture of Complexity (2013)

blog.greaterthanzero.com

Post reply on HN
Print view View original

221–230 of 285 posts

Re: C++ and the Culture of Complexity (2013)

#221

Post by AnimalMuppet »

notacoward wrote: post #217
AnimalMuppet wrote: post #203

Earlier quoted context omitted.

> Using a feature in C++ means carrying along all of the baggage from its dependencies and interactions with every other feature. Only if you use every other feature. Don't do that. Use the features you need (and understand well), not every feature. It actually becomes much like you say C is, except that you don't have to write the features.

> Only if you use every other feature. Not true at all. A lot of the features have either an interface or an implementation driven by the possibility of combination with some other feature. The cognitive and/or performance costs remain even if that other feature isn't used. For example, it's easy to get mired in writing extra constructors/destructors and virtual hooha just because someone using your class might also…

> For example, it's easy to get mired in writing extra constructors/destructors and virtual hooha just because someone using your class might also use some feature besides the one you used yourself.

I don't think I've ever seen that. (In a library, sure. In application code, no.) If you know it's going to be needed (or you know it's very likely), sure. If not, every place I've worked in added the extra constructors when needed, and only when needed.

Extra destructors? Other than empty destructors, I don't think it's possible to create an "extra" destructor, because each class can only have one. (And, in the case of virtual destructors, adding them is good practice. But that's not "combination of features", it's part of the deal you sign up for when you start using polymorphism. (Though I guess you could describe it as the combination of destructors and polymorphism, which is true, but it's simple enough I have a hard time regarding it as out-of-control complexity explosion.))

Re: C++ and the Culture of Complexity (2013)

#222

Post by pjmlp »

srcmap wrote: post #207
pjmlp wrote: post #186

Earlier quoted context omitted.

Very interesting, thanks. I got introduced to C++ via Turbo C++ 1.0 for MS-DOS, in 1993. So if it was good enough for 640 KB max, with 64KB executables, it shouldn't be an issue in most micro-controllers, but the biggest issue is the existing dev culture.

Forgot to mention couple other design decisions: No new, delete operators in any C++ code. ISR code was also in C++. All objects are statically allocated - with 4MB of SRAM, one can easily see why. It allows tightly control memory usage by the developer. All regression tests are automated. There were test scripts for all functional HW/SW components. Found one bug triggered in 24.9 days time frame (31 bit timer counte…

Thanks for sharing.

I eventually moved into Java/.NET stacks, but still follow on C++, as my to go tool when they need some unmanaged help.

Re: C++ and the Culture of Complexity (2013)

#223

Post by pedasmith »

bayindirh wrote: post #52
pedasmith wrote: post #27

Earlier quoted context omitted.

Well, you can spend 5 months writing your software in C++, and a month fixing your bugs and doing a bit of optimization. Or you can spend 3 months writing C# or other modern language and have another 3 months to optimize, all the while enjoying substantially faster compile times and super easy refactoring.

This is not an apples to apples comparison. I've given examples from runtime, not from development time. OTOH, refactoring in C++ is not hard, at least from my experience. With some knowledge of the language, everyone can write reasonably bug-free C++ (or any other language) application in one go. Compilation in C++ is a different story. C# is not native. It's converted to CLI (was that the name, I don't use Win32 fo…

Why would you only include some of the overall time? All of our companies get clients based on our overall ability to help clients be more productive. Looking at just one part f the pipeline isn't likely to produce the best results for our customers.

Re: C++ and the Culture of Complexity (2013)

#224

Post by PopsiclePete »

tandr wrote: post #185
tomohawk wrote: post #67

Earlier quoted context omitted.

Having used c++ for many years, this does not come across as a ringing endorsement for looking into Haskell or Rust. I'm quite happy with my current gig using Go. Looking back, the culture of complexity surrounding c++ is obvious, but talking with my peers who have only ever done c++ - it's like they have Stockholm Syndrome.

Any language (or tool for that matter) that you have to invest heavily in, and use for a while will produce a symptoms of "Stockholm Syndrome". Moreover, once you are hard pushed to switch from it to something else, withdrawal symptoms are quite pronounced too. Go has its own share of idiosyncrasies, and it drives me nuts sometimes even more than C++ did, but these bursts of mental grind are less common and much shor…

I sometimes like to dabble in C++, late at night, while sipping some whisky. For short periods of time.

Last night, I decided to "practice" writing iterators. Specifically, I wanted to write a class that i could use in a new-style C++ range loop that would give me all files in a directory. Useless but fun practice, I thought.

I had Bjarne's latest book by my side, and the final draft of the C++17 spec in open in a PDF, and it took me a good 2-3 hours of trying before I "got" it.

I'm still not sure I'm doing it correctly, btw. It does compile without warnings, and it works, but I can tweak the iterator function signatures in seemingly incompatible ways and it still doesn't complain and still works, even when I swear it shouldn't. "Ok, surely by doing this I'll break it!" - nope, still works.

I don't love everything about Go, and once in a while I'll wish for more expressiveness, but I was never, ever, as 10% confused with it as I am with whenever I attempt to do something seemingly trivial in C++.

Re: C++ and the Culture of Complexity (2013)

#225

Post by pjmlp »

AnimalMuppet wrote: post #205
pjmlp wrote: post #80

Earlier quoted context omitted.

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

Depends on the embedded system. I've worked on embedded systems running embedded Linux, with megabytes to gigabytes of storage, for the last dozen years, using C++. If you're still dealing with an 8051, I'll agree that you're less likely to have moved to C++. One other thought: Embedded toolchains are typically set at the start of the (original) project. I don't remember ever seeing a compiler upgrade happen in an ex…

I fully agree with you, and given my preference for type safe languages, I find interesting that other languages are also an alternative, depending on the use case constraints.

However from a few CppCon and Meeting C++ talks, it appears that in such scenarios moving beyond C, is more of a cultural issue than technology one.

Re: C++ and the Culture of Complexity (2013)

#226

Post by pjmlp »

AnimalMuppet wrote: post #220
pjmlp wrote: post #20

Earlier quoted context omitted.

Oh boy, you must be really young. No parallel in C++?!!!?? That is where EJBs and Spring come from. The enterprise architects that created those kind of designs, were the same ones that on earlier decade were doing them with C++. Apparently micro-services are now a thing, well on the late 90's we had Sun RPC, CORBA, DCOM. All tied together with a cluster distributed transaction management. Sprinkled with code generat…

I suspect (but I am not certain) that any language that wants to work in that space is going to turn into Java EJB or C++ with CORBA and/or DCOM. I think it's the space, not the language, that produces such appalling monstrosities. (And, if you needed that kind of thing, even EJB or CORBA was better than implementing that same functionality by hand...)

Yep.

Somehow I am starting to feel that micro-services are the new EJBs.

Re: C++ and the Culture of Complexity (2013)

#227

Post by pjmlp »

bayindirh wrote: post #114
pjmlp wrote: post #106

Earlier quoted context omitted.

Well, since Windows 8 .NET store apps don't support JIT, they only run AOT compiled to native. And NGEN is a standard component of the .NET SDK since the beta days. So AOT compilation has been part of the default tooling since ever.

Well, I’m not very knowledgeable about Windows world, as I said before, I’m not using Windows for 15 years or so. So, my bad, sorry.

If you, or others want to know a bit more about it,

NGEN

https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...

AOT Compilation for Windows 8.x store apps, based on Singularity's Bartok compiler

https://channel9.msdn.com/Events/Build/2012/3-005

https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an...

AOT Compilation for Windows 10 store apps, using Visual C++ backend

https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

https://docs.microsoft.com/en-us/dotnet/framework/net-native...

Re: C++ and the Culture of Complexity (2013)

#228

Post by pjmlp »

notacoward wrote: post #133
cageface wrote: post #76

Earlier quoted context omitted.

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from…

> it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. For a certain class of program , you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc. Those can be wr…

We are starting to see that trend on GUI frameworks and game engines.

C++ is still there, doing what it does best, driving pixels around with maximum performance.

But the upper layer, exposed to app developers and game designers, is done in another language.

Re: C++ and the Culture of Complexity (2013)

#229

Post by pjmlp »

nextos wrote: post #128
poster123 wrote: post #113

Earlier quoted context omitted.

If you are doing scientific computing, have you considered Fortran? The gfortran (GCC Fortran) compiler supports Fortran 2003, which has object-oriented features, and since Fortran 90 the language has had array operations and syntax similar to Matlab or Python with numpy.

I'm not a big fan of Fortran for my particular domain, which includes lots of strings (biological sequences). Here Fortran is not as quick. See for example the k-nucleotide benchmark: https://benchmarksgame.alioth.debian.org/u64q/performance.ph...

I worked with a customer that was using .NET for DNA sequencing.

Not sure what tricks they pulled off regarding unsafe code and parallelism, but it was fully done in C#.

Re: C++ and the Culture of Complexity (2013)

#230

Post by notacoward »

AnimalMuppet wrote: post #221
notacoward wrote: post #217

Earlier quoted context omitted.

> Only if you use every other feature. Not true at all. A lot of the features have either an interface or an implementation driven by the possibility of combination with some other feature. The cognitive and/or performance costs remain even if that other feature isn't used. For example, it's easy to get mired in writing extra constructors/destructors and virtual hooha just because someone using your class might also…

> For example, it's easy to get mired in writing extra constructors/destructors and virtual hooha just because someone using your class might also use some feature besides the one you used yourself. I don't think I've ever seen that. (In a library, sure. In application code, no.) If you know it's going to be needed (or you know it's very likely), sure. If not, every place I've worked in added the extra constructors w…

> In a library, sure. In application code, no.

It has been a long time since I worked on an application so trivial that parts of it weren't broken out into separate libraries. Most often, those libraries end up being maintained by people other than their users, and the users always end up using the library in unexpected ways or contexts so these protective measures always become necessary.

Perhaps more to the point, I don't think there should even be multiple constructors each called in different situations that it takes several pages to describe. This complexity mostly exists because the people who defined C++ don't seem to understand the significance of value vs. reference semantics, as the OP also noted. Move semantics and rvalue references represent a tacit omission that the previous semantics were broken, but they just introduce even more non-intuitive syntax and another few pages to describe what happens in which situations. That's exactly the kind of spurious complexity that makes compiler writers want to go on killing sprees and folks like me want to avoid the whole morass.

Post reply on HN