Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A useful discussion of the conversion and its motivation in the GCC Wiki:

http://gcc.gnu.org/wiki/cxx-conversion



Here's the rationale from that document:

* C++ is a standardized, well known, popular language.

* C++ is nearly a superset of C90 used in GCC.

* The C subset of C++ is just as efficient as C.

* C++ supports cleaner code in several significant cases.

* C++ makes it easier to write and enforce cleaner interfaces.

* C++ never requires uglier code.

* C++ is not a panacea but it is an improvement.

It's interesting to me how defensive many of those justifications are. "It's just as efficient!" or "It's just a superset anyway!" Not until halfway through the list do we get any real description of expected benefits: C++ makes it easier to write and enforce interfaces, and C++ supports cleaner code in several significant cases. The last item is the most telling though: it's clear that these developers feel they've hit a point of crisis, and they are willing to take risks like this in order to lift themselves out of the problem.


> * C++ never requires uglier code.

No... but it sure tends to encourage it.


You've not seen ugly code until you've read 90s-era Win32 UI code written with Hungarian notation everywhere. Ugly code comes from the programmer, not the language.


I blame the early Windows team by mistaking what Simonyi meant with Hungarian notation by misunderstanding what 'type' means. Which is why Office uses his notation in a much cleaner fashion.


Yea it's a shame that Hungarian notation has gotten such a bad rap. Done right i find it occasionally useful. Done the way most windows programmers have been taught is an abomination.


Can you give an example(or a link to an article discussing this)? I've never had the displeasure of working with the Windows API(though I often shook my head when I saw code for it)


Basically he intended 'type' as not 'datatype' as in 'dwSomething' (for double word) but the purpose of the variable. For example, if you're using an integer variable to store the length of some entity, you would name it something like 'lenSomething' as opposed to 'dwSomething'.

Storing the type of the variable makes little sense as in most cases it is only a quick grep away.


In the example you used, "context" seems to be a more appropriate word than "type".



That Wikipedia page does such a better job of describing it than I did.


http://www.joelonsoftware.com/articles/Wrong.html You have to read a bit, hungarian notation doesn't really show up until maybe 4/5 of the way through.


It definitely comes from both. Objective C Block prototypes? C typedefs? blech.


Unless I misunderstand you, block type syntax is almost identical to function pointers. In both cases, you should generally typedef them and then your code is once again free from ugliness.


Having to typedef at all is a sign of deep, unfixable badness.


I am unable to reply to my sibling poster, but I believe what you're saying is that having a hideous and unreadable syntax that forces the use of typedefs just so others can understand what you have written is a sign of deep, unfixable badness. And I agree.


I'm not sure how you arrived at that belief, unless perhaps you think everything should be (visibly to the programmer) type-free? Care to elaborate? I think it would be nice if C and C++ supported more type semantics than `typedef` and `class`, say something as powerful as Haskell's system...


It's the fundamental unfixable crappiness of C declaration syntax that makes 'typedef' necessary.


Example? What language doesn't need typedefs?

Java doesn't have typedefs, and most everyone agrees that's a language bug.


typedef as type aliasing: uncontroversial. typedef to paper over hideous syntax mistakes: disgusting.


Function pointers are also blech looking.


Some say there is no such thing as ugly code, only job security.

Also ugly code is less of an issue of an ugly design as you can look past how the code looks if the design of the program is sound.

But ugly is in the eye of the beholder and in that maybe more people are growing up with C++ and with a later dealing with C as apposed to the other way around. So maybe it is in many ways the mindset of the average age of the programmers around today are more comfortable with C++ as apposed to C and in that could see nicely laid out C code as having ugly bits as its easier for them to do it prettier in C++ and a biased C programmer will see it compeletly from the other perspective.

So its one of those debates were the best move is to get the popcorn as some people see ugly code were others see something nice and some will see C++ as better than they would C and vice versa. Just be glad i'm not involved or I'd be mentioning COBOL as a reality check :).


Why would C++ encourage it? i think its just as easy to make a c of convoluted madness as a c++ one :)


Interesting, but understandable given how much some people dislike C++.


I'm guessing they expected a lot of criticism for this change, which could be why the list is so defensive.


Also interesting to see how the style guide has changed: http://gcc.gnu.org/wiki/CppConventions; http://gcc.gnu.org/codingconventions.html


The "Spelling, terminology and markup" section is a bit painful. Does anyone really keep it printed and stapled to the wall in case they write non-zero rather than nonzero? Seems really petty. I hope the enforcement is done by simply running a regexp or ignored altogether.

Code is where conventions are important, within comments I really wouldn't be upset if someone called Objective-C "Objective C".


That's standard stuff for any organization that makes documents - keep in mind that the primary purpose of the list is for documentation and user-visible messages. The NY Times surely has a similar kind of list. Do you think that would be equally as painful?


Every decent paper has one; the NY Times is no exception. http://www.amazon.com/York-Times-Manual-Style-Usage/dp/08129.... 384 pages.


There are entire books written about those sort style details. Personally I find it comforting in a strange sort of way to know that there are rules out there that I can follow if I wish.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: