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

C++ Core Guidelines

github.com

Post reply on HN
Print view View original

41–50 of 115 posts

Re: C++ Core Guidelines

#41

Post by oblio »

pjmlp wrote: post #30
112233 wrote: post #28

Earlier quoted context omitted.

> Use an IDE. Explain.

IDEs provide graphical debuggers and colorization to show which code actually gets compiled. For example on Visual Studio, paths not taken on conditional code get grayed out.

You disappoint me pjmlp, you're not a true graybeard unless you use Vim or Emacs :o)

The slightly more serious question: is there anything like this in Vim or Emacs-land? I somehow doubt it... I, for one, have never seen something like it outside of the big IDEs (Visual Studio, IntelliJ, etc.)

Re: C++ Core Guidelines

#42

Post by jcelerier »

112233 wrote: post #37
jcelerier wrote: post #36

Earlier quoted context omitted.

> I cannot use STL as it is now, even with custom allocators. if you are ready to take the runtime hit you could use the polymorphic allocator support and pass your allocator object down the chain. See http://en.cppreference.com/w/cpp/memory/polymorphic_allocato... ; http://en.cppreference.com/w/cpp/container/vector ; http://en.cppreference.com/w/cpp/container/map . I don't understand why you are making a distinction…

> I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators. Because for map in general I cannot know how much allocations and of what size will it need to store 1000 elements. I might glean it for particular implementation of STL, but not via any api. Doing anything bearssl-like, "No dynamic allocation whatsoever", just does not work with STL. > yo…

> Exactly. Most C++ libraries are not made with the idea of allowing you to police resource allocation

I was saying this from the point of view of the library author, not the code. e.g. for instance I spent some weeks optimizing allocations in a library that I'm working on, and am then making assumptions in the rest of the code according to the optimizations I made. If I did let users of the library change the allocation policy, I would have to introduce costly runtime checks everywhere to ensure that the invariants I set do still hold, that I really have enough memory to do what I must, and abort / throw in case such an invariant is broken. All of these situations are less desirable than enforcing my allocation policy in my code.

Re: C++ Core Guidelines

#43

Post by pjmlp »

oblio wrote: post #41
pjmlp wrote: post #30

Earlier quoted context omitted.

IDEs provide graphical debuggers and colorization to show which code actually gets compiled. For example on Visual Studio, paths not taken on conditional code get grayed out.

You disappoint me pjmlp, you're not a true graybeard unless you use Vim or Emacs :o) The slightly more serious question: is there anything like this in Vim or Emacs-land? I somehow doubt it... I, for one, have never seen something like it outside of the big IDEs (Visual Studio, IntelliJ, etc.)

I am an ex-XEmacs user, and used vi on Xenix, DG/UX if that makes you happy. :)

Always been an IDE fan since Turbo Pascal 6.0 with its Turbo Vision based IDE.

Re: C++ Core Guidelines

#44

Post by quotemstr »

_xzxj wrote: post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

I strongly disagree with you. I think too few people use exceptions. They're great for making code more expressive, and it's only through exceptions that you can avoid two-phase initialization of classes and make constructors actually useful. It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Avoiding these constructs severely restricts the language. And for what? The arguments against exceptions appear to mostly arise from misunderstanding or some kind of weird aesthetic sense that I don't have.

Error codes also generally discard context and encourage a "just abort" mentality, especially with respect to memory exhaustion. That, or they become so general, mechanized, and macro-ized that they might as well be exceptions, but worse in almost every way.

Exceptions are your friends.

Re: C++ Core Guidelines

#45

Post by quotemstr »

dullgiulio wrote: post #40
krylon wrote: post #38

Earlier quoted context omitted.

Well, strictly speaking, Go has panic() which is very similar to exceptions. But it also has a culture that strongly discourages using it unless things go very wrong.

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors). You can handle Segmentation Fault, but you need to know what you are doing. In Go it's the same.

Panic is _semantically_ the same as throw. That Go culture treats panic like evil voodoo doesn't change how the language construct works.

Re: C++ Core Guidelines

#46

Post by quotemstr »

snarfy wrote: post #31
_xzxj wrote: post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

Exceptions are a mistake, plain and simple. They should have never been added to the language. They break the notion of programming as a sequence of events. With exceptions, now you have two sequences, the happy path and the 'wherever the hell the exception is caught' path. No matter how you slice it, exceptions are still a goto under the covers. If they are truly exceptional, you might as well call exit() too. Go go…

> They break the notion of programming as a sequence of events.

It's never been that way. What's a page fault?

> No matter how you slice it, exceptions are still a goto under the covers.

"break" is also a goto. What's your point?

> If they are truly exceptional, you might as well call exit() too.

That's completely unacceptable for robust software. Programs can recover from almost all errors and make forward progress, usually via staging some kind of rollback. Tearing down a whole process in response to error is a ridiculous extreme that works only in a few narrow domains.

> Exceptions are a mistake, plain and simple.

Is that why almost every language ends up adopting them in some way? Even languages that start out vehemently anti-exception, like Go and Rust, end up with the full try-and-catch exception toolkit. That's because, despite protestations, exceptions are extremely useful.

Re: C++ Core Guidelines

#47

Post by lasagnaphil »

quotemstr wrote: post #44
_xzxj wrote: post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

I strongly disagree with you. I think too few people use exceptions. They're great for making code more expressive, and it's only through exceptions that you can avoid two-phase initialization of classes and make constructors actually useful. It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Avoiding these constructs severely restricts the language. And for wha…

About the dependency between constructors and inheritance, I like how rust handled the situation. In rust you do not have any constructors, but instead you can make a factory method that returns an Option or Result, so no need for any exceptions while construction. You can also do this in C++, but you still have to declare constructors anyway, along it being a bit inconsistent with other idiomatic C++ code...

Re: C++ Core Guidelines

#48

Post by [deleted] »

quotemstr wrote: post #46
snarfy wrote: post #31

Earlier quoted context omitted.

Exceptions are a mistake, plain and simple. They should have never been added to the language. They break the notion of programming as a sequence of events. With exceptions, now you have two sequences, the happy path and the 'wherever the hell the exception is caught' path. No matter how you slice it, exceptions are still a goto under the covers. If they are truly exceptional, you might as well call exit() too. Go go…

> They break the notion of programming as a sequence of events. It's never been that way. What's a page fault? > No matter how you slice it, exceptions are still a goto under the covers. "break" is also a goto. What's your point? > If they are truly exceptional, you might as well call exit() too. That's completely unacceptable for robust software. Programs can recover from almost all errors and make forward progress,…

[deleted]

Re: C++ Core Guidelines

#50

Post by elbows »

oblio wrote: post #41
pjmlp wrote: post #30

Earlier quoted context omitted.

IDEs provide graphical debuggers and colorization to show which code actually gets compiled. For example on Visual Studio, paths not taken on conditional code get grayed out.

You disappoint me pjmlp, you're not a true graybeard unless you use Vim or Emacs :o) The slightly more serious question: is there anything like this in Vim or Emacs-land? I somehow doubt it... I, for one, have never seen something like it outside of the big IDEs (Visual Studio, IntelliJ, etc.)

rtags for Emacs does this, as well as completion, highlighting syntax errors, and various other IDE-like features.
Post reply on HN