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

Bjarne Stroustrup – The Essence of C++ [video]

channel9.msdn.com

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Bjarne Stroustrup – The Essence of C++ [video]

#81

Post by jasomill »

moron4hire wrote: post #32
pyrtsa wrote: post #22

Earlier quoted context omitted.

But you'll need to document it very visibly that "Thou shalt call resource.close() whatever happened." C++ makes it possible for the library writer to take care of freeing the resources automatically.

A class implementing IDisposable is that documentation. You shouldn't need more documentation than the fact that IDisposable is there.

An annoying fly in this ointment is cases where objects assume the responsibility for calling Dispose on caller-provided disposable objects. While it should always be okay to "double-dispose", this is only a guideline, and can't be enforced by the language, so, to maximize future compatibility with classes outside your control, you should probably defensively avoid calling Dispose on an object that will have already been disposed by other means.

Re: Bjarne Stroustrup – The Essence of C++ [video]

#82

Post by fauigerzigerk »

fhd2 wrote: post #68
fauigerzigerk wrote: post #62

Earlier quoted context omitted.

I disagree. You have to be absolutely certain at all times whether you're holding on to a reference to a shared data structure or you have your own copy, unless the object is immutable. This is not just a performance thing.

You mean that it's not clear if copying the handle will copy the data or just create another reference? At least in the STL that's kinda clear: vector will copy its elements (if they are pointers, it'll copy the pointers. if they are values it'll copy all the data), shared_ptr will copy the handle pointing to the same shared object, unique_ptr is not copyable and so on. But agreed, it's opaque when working with third…

>You mean that it's not clear if copying the handle will copy the data or just create another reference?

Exactly. In the STL, if it looks like a value copy it is a value copy, but the handle pattern that Stroustrup prefers gives you no clue whatsoever as to what's going to happen. You have to figure it out one class at a time.

Re: Bjarne Stroustrup – The Essence of C++ [video]

#83

Post by userulluipeste »

daxelrod wrote: post #34
userulluipeste wrote: post #23

Earlier quoted context omitted.

These are problems that pop out from a bad design choices. One of the first things I remember from OOP learning is that constructors should be as safe as they can be, which means no allocations, partial or not. Of course it is tempting to misuse the language features out of personal commodity and blame someone else. I think we can agree that a few design changes would solve the ambiguous cases. Also, for the "remembe…

> constructors should be as safe as they can be, which means no allocations, partial or not. Can you expand upon what you mean by "safe" here? If you mean "unable to fail", I vehemently disagree. Constructors should validate what is passed into them and fail if that is invalid. The alternative is to construct a zombie object that can't actually be used. Objects like this subvert the type system and lead to lots of un…

"safe" like nullifying pointers and dummy-initialization for objects. This kind of initialization has a small footprint on performance, but it was made optional nevertheless, due to language's performance aims (you can skip them if you don't need that). You can make a little bit more complex operations in constructors that involve data validation, but it should only default to blank initialization if something doesn't pass the checks. The initialization that can fail (and the failure must be taken in account) should be done outside constructors. If an object is or isn't considered valid after a dummy initialization is a design decision, and likewise an adjustment in design can avoid excessive "if (object.is_valid())" kind of checks.

Re: Bjarne Stroustrup – The Essence of C++ [video]

#84

Post by eru »

bsaul wrote: post #5

really interesting to see classes as ressource manager above all, instead of concept incarnation. I was almost convinced to go back to C++ until the slide with auto range and all, combining new features of C++, at which point i remembered why i didn't want ro have a look at C++ code again. but hey, i'm not a system programmer so i can afford it :)

And even system programmers have other choices, as demonstrated by the linux kernel.

Re: Bjarne Stroustrup – The Essence of C++ [video]

#85

Post by FurrBall »

pjmlp wrote: post #65
FurrBall wrote: post #55

Earlier quoted context omitted.

Pasting a response: Blocks are an improvement, but not the same as RAII. A block is literally converted to a try-finally by the compiler. It is the same thing with a cleaner syntax. There is no safety added to the old Java way. A programmer can forget to put his stuff in a block and leak the resource the same as he forgets to use a try-finally. The onus is on the consumer, not the library writer. With C++ RAII the on…

As long as the object is stack allocated or a member variable.

Well you do have to ban raw pointers. Heap allocation is safe with smart pointers.
Post reply on HN