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

Modern C++ Programming Course

github.com

Post reply on HN
Print view View original

211–220 of 221 posts

Re: Modern C++ Programming Course

#211

Post by gpderetta »

rramadass wrote: post #204
gpderetta wrote: post #152

Earlier quoted context omitted.

Depends what you mean by "understand C". As you say, understanding the C abstract machine and memory model is critical for a C++ programmer. Understanding C idioms, the standard library, best practices, and general C software architecture , is less important if not downright negative early in your formation. You will end up picking a lot up anyway if you stick to C++ long enough.

> is less important if not downright negative "Less important" maybe but not "negative". You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive.…

By "negative" idioms I'm mostly referring to stdio, string.h (except for memcpy/memmove of course), goto-based cleanup, void* based generics, overuse of macros and a certain fondness for global mutable state in a lot of classic C codebases.

Re: Modern C++ Programming Course

#212

Post by tialaramex »

rramadass wrote: post #204
gpderetta wrote: post #152

Earlier quoted context omitted.

Depends what you mean by "understand C". As you say, understanding the C abstract machine and memory model is critical for a C++ programmer. Understanding C idioms, the standard library, best practices, and general C software architecture , is less important if not downright negative early in your formation. You will end up picking a lot up anyway if you stick to C++ long enough.

> is less important if not downright negative "Less important" maybe but not "negative". You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive.…

The main use of raw pointers in practical standard C++ is that they still don't have an analogue of Option so raw pointers (which can be null) let you write analogous code albeit in a less friendly way.

But this isn't so much like C, where raw pointers often express ownership.

You aren't going to really learn "everything" in C++ anyway, regardless of how you approach it, the language is a vast sprawling mess, the fact somebody wrote a serious book just about initialization [https://leanpub.com/cppinitbook] in C++ gestures at the problem. Freeing themselves of the need to have a language which is well-defined, or which can be demonstrated to be sound, or really follow any principles whatsoever was doubtless briefly convenient but the result is unmaintainable nonsense.

Re: Modern C++ Programming Course

#213

Post by rramadass »

tialaramex wrote: post #212
rramadass wrote: post #204

Earlier quoted context omitted.

> is less important if not downright negative "Less important" maybe but not "negative". You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive.…

The main use of raw pointers in practical standard C++ is that they still don't have an analogue of Option so raw pointers (which can be null) let you write analogous code albeit in a less friendly way. But this isn't so much like C, where raw pointers often express ownership. You aren't going to really learn "everything" in C++ anyway, regardless of how you approach it, the language is a vast sprawling mess, the fac…

The use of raw pointers in C++ which you deem analogous to a Rust feature is your view and not that of the vast majority of C++ programmers. Raw pointers in C++ are the same as in C and the usage techniques are up to the programmer.

As a diehard proponent of Rust your views on C++ are well known and there is nothing new here. But the fact of the matter is that the industry runs on C/C++ and the main reason is due to its baroque set of features whatever one may think of them.

Re: Modern C++ Programming Course

#214

Post by rramadass »

gpderetta wrote: post #211
rramadass wrote: post #204

Earlier quoted context omitted.

> is less important if not downright negative "Less important" maybe but not "negative". You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive.…

By "negative" idioms I'm mostly referring to stdio, string.h (except for memcpy/memmove of course), goto-based cleanup, void* based generics, overuse of macros and a certain fondness for global mutable state in a lot of classic C codebases.

Disagree here. Given the language's limitations, everyone of the idioms you list has its place and uses. They are just a way of structuring code for different abstractions.

Re: Modern C++ Programming Course

#215

Post by gpderetta »

rramadass wrote: post #214
gpderetta wrote: post #211

Earlier quoted context omitted.

By "negative" idioms I'm mostly referring to stdio, string.h (except for memcpy/memmove of course), goto-based cleanup, void* based generics, overuse of macros and a certain fondness for global mutable state in a lot of classic C codebases.

Disagree here. Given the language's limitations, everyone of the idioms you list has its place and uses. They are just a way of structuring code for different abstractions.

In C maybe, but not C++.

Re: Modern C++ Programming Course

#216

Post by [deleted] »

aa-jv wrote: post #208
maldev wrote: post #143

Earlier quoted context omitted.

Yes! 100% Right, can't believe I left that out. One of the big things is to make sure to use ConstEval if you can do a new verson of c++(20), since ConstExpr isn't guaranteed and can leave stuff in the binary that can hurt size or obfuscation. For example one thing I see alot is lookup tables for hashing who use constexpr and hide some key data in there, but it "may" just randomly do it, and can cause alot of issues.

How does the use of ConstEval address this issue?

[deleted]

Re: Modern C++ Programming Course

#217

Post by [deleted] »

ska wrote: post #176
maldev wrote: post #96

Earlier quoted context omitted.

It depends on what you target. I do alot of Kernel and really low level C++, and it's a completely different style than even app dev, so you have to be sure you don't go down the completely wrong route. For my target space, there's a few rules for c++. Footguns: A. No STL, it causes to much bloat when binary size is critical. B. (almost) No inheritance or virtual functions. Again, it causes some bloat and adds in som…

I think you missed exceptions often being a problem in low level and embedded targets. That knocks out most of STL anyway. I also think you are a bit harsh on virtual functions - it introduces a single indirection, yes, but sometimes that is fully justified. RTTI on the other hand... of course depends a bit on target characteristics. Perhaps controversial, I've also found (especially bare) lambdas and even std::funct…

[deleted]

Re: Modern C++ Programming Course

#218

Post by rramadass »

gpderetta wrote: post #215
rramadass wrote: post #214

Earlier quoted context omitted.

Disagree here. Given the language's limitations, everyone of the idioms you list has its place and uses. They are just a way of structuring code for different abstractions.

In C maybe, but not C++.

That's not what i was saying (it's a given). After all C++ was invented to provide programmers with a large number of features that would allow them to express abstractions naturally and directly rather than building them up with all the basic plumbing that you would need to do in C.

However there is a huge amount of C code and programmers who would like to move to C++ and it is for them that the techniques of C coexisting with C++ are very relevant. There can be no wholesale rewrite of the code into C++ but a gradual rewrite module by module and as needed. Using C++ as a "better C" is the path here.

Re: Modern C++ Programming Course

#219

Post by collyw »

gbin wrote: post #156
collyw wrote: post #130

What is the C++ job market like? I do mostly Python / web app developmnt, but I don't like the churn.

If you are strong in C++ you can get pretty good jobs in robotics, trading, game engines. But TBH at that point it might be more interesting to learn Rust that is on the rise across the industry.

No not strong, just considering making the switch.

Re: Modern C++ Programming Course

#220

Post by synergy20 »

ska wrote: post #176
maldev wrote: post #96

Earlier quoted context omitted.

It depends on what you target. I do alot of Kernel and really low level C++, and it's a completely different style than even app dev, so you have to be sure you don't go down the completely wrong route. For my target space, there's a few rules for c++. Footguns: A. No STL, it causes to much bloat when binary size is critical. B. (almost) No inheritance or virtual functions. Again, it causes some bloat and adds in som…

I think you missed exceptions often being a problem in low level and embedded targets. That knocks out most of STL anyway. I also think you are a bit harsh on virtual functions - it introduces a single indirection, yes, but sometimes that is fully justified. RTTI on the other hand... of course depends a bit on target characteristics. Perhaps controversial, I've also found (especially bare) lambdas and even std::funct…

newest MISRA for c++ just came out, though it's based on c++17
Post reply on HN