Talking to C Programmers about C++ [video] • Hacker News Board

Re: Talking to C Programmers about C++ [video]

#121

Post by jonstewart » Mon, Sep 26, 2016, 2:01 PM UTC

gravypod wrote: post #90

hackits wrote: post #37

Earlier quoted context omitted.

When I think about features in C++ that I would love to have in C, the only thing that comes to mind is constructors and deconstructions for RAII.

My issue with RAII is that it's fundamentally not what you expect to happen. If I say: int i; I don't expect that to create an integer. I expect that to reserve memory in the program's space for an integer. In the same way I don't expect this to call malloc: int *i; I just expect that to hold the space in the program data where and int pointer can be stored. Furthermore I don't expect this to run any code (just as th…

I think part of your expectation may be coming from Java, where only fundamental data types are stack allocated and everything else has reference semantics to heap-allocated objects.

For the sake of syntactic consistency, one could argue that C++ should mandate "()" as a suffix to declarations to invoke the default constructor. However, what good is an allocated object that's _not_ constructed? For many classes, of course, the default constructor is trivial, but for others it isn't. The purpose of the constructor is to provide invariants that the code can rely on--it isn't obvious to me what common use case you could consider for an object that's allocated on the stack but not constructed, and it seems like it's asking for trouble.

Also, since C++ inherits C's syntax and semantics for fundamental types, "int i;" must be legal. So we cannot abolish the form.

Re: Talking to C Programmers about C++ [video]

#122

Post by jonstewart » Mon, Sep 26, 2016, 2:17 PM UTC

gravypod wrote: post #99

tossaway1 wrote: post #86

Earlier quoted context omitted.

Well you didn't express your criticism a the reason C++ is difficult to learn, you described it as "the problem with C++" and it sounds like you don't have enough familiarity with the language to make that sort of assessment. C++ isn't a great choice for many purposes, but for some purposes it is the go-to language - and for good reasons, not just because of inertia as some like to suggest. As with all forms of craft…

Here is why C++ is difficult to learn. It's like my experience of dealing with Java's inherited state except at every point in the language. For people who have never touched java's inherited state from extending abstracts or base classes please don't fall into the traps I did. I was writing a redundant networking library that was meant to load packets on the fly so I had some cleaver "c++ level" abstraction written…

You've admirably demonstrated the willingness to ask questions and learn in this thread, so I will try to rise to the occasion. I'm sorry to have been dismissive with my original comment... please understand that C++ takes a lot of abuse from inexpert programmers on HN. For example, I never would criticize Ruby without spending more time than a semester's class using it.

>> string token = "";

No, you aren't opening yourself to bugs, but it's unnecessary. A default constructed string is already == to "", token.empty() will return true.

get_token_type() should likely take a const reference to the string, as all of the operations on the argument are const. I saw elsewhere in the thread where you said you've avoided const so far. Honestly, const may be C++'s greatest feature; it is far, far stronger than Java's "final" (or Scala's equivalent "val").

Looking over this code from a high level, I'm not sure why you have get_token_type() with a string parameter and a char parameter, when the former just forwards to the latter. Couldn't you have a second char variable, "prev_char" or "last_char", in get_next_token() and then detect when the type of it differs from the current char. Then the only operation you'd be doing on the string "token" is appending to it. I could be missing something, though, as I've only taken a quick glance through the code.

I would generally agree with you that C++ is poorly taught almost everywhere. I think it was a win for CS departments when they transitioned from C++ to Java for introductory courses (and now many are transitioning to Python, also a win). I am fairly convinced that C++ programming is a craft and is therefore best learned under an apprenticeship model, of routine practice with expert review and guidance, coupled with some self-study.

Re: Talking to C Programmers about C++ [video]

#123

Post by JohnLeTigre » Mon, Sep 26, 2016, 2:19 PM UTC

You won't convince me that c++ is as good as c simply by representing a plain old structure as a class or by talking about the type of arrays.

To me, data-oriented design is more interesting: https://www.youtube.com/watch?v=rX0ItVEVjHc

Re: Talking to C Programmers about C++ [video]

#124

Post by _yosefk » Mon, Sep 26, 2016, 2:47 PM UTC

pjmlp wrote: post #69

yosefk wrote: post #48

Earlier quoted context omitted.

As someone who's had to deal with C++ since the last century, I find that one problem with C++ is that people who aren't experienced C++ programmers can't get shit done, especially in a code base where experienced C++ programmers have demonstrated their erudition and knowledge of C++ arcana in all its glory. In fact, the intersection of people who had the patience to learn enough C++ to get shit done and people who a…

I was part of the C++ teaching group on CS labs on my university back in 1999. The majority of them surely were able to get shit done in C++ at the end of the semester.

Was it their first language though, and more generally, what did they already know?

Don't get me wrong, I remember the people who taught me C++ rather fondly. It's just done really terribly really often.

Re: Talking to C Programmers about C++ [video]

#125

Post by hellofunk » Mon, Sep 26, 2016, 8:09 PM UTC

dunkelheit wrote: post #29

TickleSteve wrote: post #6

Earlier quoted context omitted.

C++ is not one language... there are many styles, for example: - 'C with objects'. - 'Everything is a template'. - 'Embedded C++' (its a real standard, google it). - functional. - 'modern'. (thats not a complete list either). Each one of those is technically the same language, but they're all using a different subset of features and are almost unrecognisable from the rest.

This really starts to hurt when you go around shopping for C++ libraries. You can totally mandate a particular C++ style in an organization and achieve good results but good luck trying to use a library written in another style. Which is one of the reasons why C++ library ecosystem is relatively scarce.

What? C++ has a gigantic ecosystem for high quality libraries in a huge number of fields.

Re: Talking to C Programmers about C++ [video]

#126

Post by MichaelMoser123 » Tue, Sep 27, 2016, 1:41 PM UTC

yosefk wrote: post #48

jonstewart wrote: post #38

Earlier quoted context omitted.

The problem with posts about C++ on Hacker News is that people who aren't experienced C++ programmers (you've been using C++ for a semester? do tell) feel compelled to write posts explaining the problems with C++.

As someone who's had to deal with C++ since the last century, I find that one problem with C++ is that people who aren't experienced C++ programmers can't get shit done, especially in a code base where experienced C++ programmers have demonstrated their erudition and knowledge of C++ arcana in all its glory. In fact, the intersection of people who had the patience to learn enough C++ to get shit done and people who a…

> trying to understand what the fuck coutYou can always do fprintf instead of that; i almost never do C++ streams for io - there is always a way to avoid them.

Re: Talking to C Programmers about C++ [video]

#127

Post by gravypod » Tue, Sep 27, 2016, 3:38 PM UTC

MichaelMoser123 wrote: post #126

yosefk wrote: post #48

Earlier quoted context omitted.

As someone who's had to deal with C++ since the last century, I find that one problem with C++ is that people who aren't experienced C++ programmers can't get shit done, especially in a code base where experienced C++ programmers have demonstrated their erudition and knowledge of C++ arcana in all its glory. In fact, the intersection of people who had the patience to learn enough C++ to get shit done and people who a…

> trying to understand what the fuck cout You can always do fprintf instead of that; i almost never do C++ streams for io - there is always a way to avoid them.

I have also never seen a codebase that has used cout piping that was worth any salt.

But then why is it the first thing we shove into peoples faces when teaching them the language?

Re: Talking to C Programmers about C++ [video]

#128

Post by MichaelMoser123 » Sat, Oct 01, 2016, 9:34 AM UTC

gravypod wrote: post #127

MichaelMoser123 wrote: post #126

Earlier quoted context omitted.

> trying to understand what the fuck cout You can always do fprintf instead of that; i almost never do C++ streams for io - there is always a way to avoid them.

I have also never seen a codebase that has used cout piping that was worth any salt. But then why is it the first thing we shove into peoples faces when teaching them the language?

i think they want to make an impression: C++ is supposed to be a new language, and not just C with a class system + templates bolted on top of it. i guess streams is supposed to be the new way of doing IO, never mind the circular inheritance mess and virtual function calls for getting new data.