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

201–210 of 285 posts

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

#201

Post by PopsiclePete »

srcmap wrote: post #174
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.

I used C++ for embedded CPU 68332 (25 MHz CPU) with 4MB of SRAM in ~1996 for DNA sequencer machine. ~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc. No template, no virtual functions. Worked very well at that time. The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the…

The C++ you wrote in 1996 is basically a different language from the C++ that you're encouraged to write today.

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

#202

Post by pfultz2 »

> What does that do? It makes the variable x refer to the object that y is referring to

In Java/C#, it doesn't always:

int x = 1; int y = 2; x = y;

The variable `x` does not refer to the object that `y` is referring to(as there is no reference involved at all).

Assignment is a procedure that makes `x` equal to `y` without modifying `y`. However, if `x` refers to `y`, then we can modify `y` after assignment to `x`. This destroys the ability to reason locally about the code, because each object essentially becomes as good as a global variable.

Even though C++ has areas where things gets complicated, this is the one thing that C++ keeps very simple and consistent. There is only one definition of copy, assignment, and equality, whereas in java there is multiple definitions(deep copy vs shallow copy, `==` vs `.equals`).

> That’s called value semantics, although I would prefer the term state semantics: objects do not have a value, they have state, and that’s what’s being transferred here.

No. Its value semantics, as these objects represent some entity. The interpretation of the state(or datum to be more precise) is the known as the object's value. For example, when copying a `std::vector` the internal state of the vector will be different on copy, as it will point to new piece of memory, however, its value will still be the same.

> But experience shows that making a copy of an object is hard.

The compiler already generates a copy constructor and assignment for you. Its only necessary to write one, when one is dealing with low-level pointers. Using the standard built-in types and containers, writing a copy constructor is never needed.

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

#203

Post by AnimalMuppet »

notacoward wrote: post #129
oselhn wrote: post #89

Earlier quoted context omitted.

I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this: * lack of namespaces - all names with long prefix look the same to me * just text based macros * no generics * error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking * no polymorphism * ton of un…

All your complaints about C are valid, except I'd say defined but stupid behavior buried somewhere in a gargantuan language spec is effectively the same as undefined behavior. The difference is, C lets you control how much baggage you carry along and C++ doesn't. If I want a higher-level abstraction in C, I can usually implement it pretty well using inlines and macros, void and function pointers. Will it be pretty? H…

> 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.

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

#204

Post by maxxxxx »

snarfy wrote: post #130
clishem wrote: post #18

Earlier quoted context omitted.

Sure, it's a large and complex language that takes time to master. But I'm interested to hear examples of what you call 'profusion of edge cases'. > The ratio between what a C++ compiler will accept and what it will produce sane code for is huge. As is the case for any programming language. > C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. C++ is de…

> C++ is designed by its standards committee... When it comes to design, C++ is a good example of why having a benevolent dictator is better than a committee. I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.

Definitely agree about the ABI. In C# it's a pleasure to write libraries for others and use other libraries whereas in C++ it's almost always a pain.

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

#205

Post by AnimalMuppet »

pjmlp wrote: post #80
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…

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 existing embedded code base. And some embedded code bases live for decades.

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

#207

Post by srcmap »

pjmlp wrote: post #186
srcmap wrote: post #174

Earlier quoted context omitted.

I used C++ for embedded CPU 68332 (25 MHz CPU) with 4MB of SRAM in ~1996 for DNA sequencer machine. ~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc. No template, no virtual functions. Worked very well at that time. The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the…

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 counter wrap around for 10 milliseconds timer call) - from that point on - all firmware release pass 3 months continuous test on multiple systems before release.  


  Agree with your point: Dev culture matter a lot.   This was a mac (powerpc mac) base dev house.   C++ was the big thing in the SW (Mac) side of the dev team.    


  In my career, I worked on  15+ projects - most were embedded system projects.   Only two projects are C++.   The other project only small subset is C++.   On this project - 90% of code base running in target are C++ and full OO design and 80% of the classes reuse from other projects.

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

#208

Post by maxxxxx »

api wrote: post #21
notacoward wrote: post #16

The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge . That's…

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

"Sticking to the features you need" is pretty hard to implement. Either you end up with a stale code base that doesn't use new and useful features. Or you start using new features and only later realize the headaches they may cause. Neither situation is desirable.

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

#209

Post by masklinn »

jhasse wrote: post #169
masklinn wrote: post #165

Earlier quoted context omitted.

> There's also the case though where the Rust compiler isn't helping you, but is just wrong. Bugs aside, compilers are not wrong, they may be too limited for what you're trying to do. Which is a different situation.

Well, most compiler bugs are cases where the compile "is wrong" and "being too limited for what I'm trying to do" also sounds like a bug. So this reads to me as "aside from when they are wrong, compilers are not wrong" ;)

> Well, most compiler bugs are cases where the compile "is wrong"

Most compiler bugs are situations where the compiler allows stuff it should not or generates incorrect code.

> "being too limited for what I'm trying to do" also sounds like a bug. So this reads to me as "aside from when they are wrong, compilers are not wrong" ;)

Most every compiler is "too limited" to do some things, that is a big reason why dynamically typed languages are still a thing. For instance I can't tell Java to just take any object with an attribute "foo" despite it being the only thing I want to use (and I don't even care about its type) — bypassing the compiler via reflection aside. Do you think that's a bug in the compiler?

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

#210

Post by maxxxxx »

convolvatron wrote: post #29
api wrote: post #21

Earlier quoted context omitted.

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

just a contrary opinion. I read the c++ book in the very early 90s. someone told me it was the future of programming. every single c++ shop I've worked at since has said, 'well, yes the language is a mess, but if you stick to a well controlled subset, its really pretty good' and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so…

"dragged in every last weird and contradictory feature of what is a really enormous language"

This happens with every language that has a lot of features. You have to try them before you can form an opinion.

Post reply on HN