Advice from Bjarne Stroustrup

[Richard]

[Please do not mail me a copy of your followup]

At the end of each chapter in "The C++ Programming Language", 4th
edition, Bjarne Stroustrup has a list of advice. I found the advice
very helpful and decided that the advice should be online somewhere.

Initially I put this together as a PPT presentation, but oh my lord,
it was too long. Instead, I made a page in my user space on the
cppreference.com wiki:
<http://en.cppreference.com/w/User:Legalize/Advice_from_Bjarne_Stroustrup>

This let me link to other pages on the wiki describing specific
language features where possible.

Hopefully you will find it useful.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[woodb...@gmail.com]

On Monday, October 6, 2014 1:46:14 PM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> At the end of each chapter in "The C++ Programming Language", 4th
> edition, Bjarne Stroustrup has a list of advice. I found the advice
> very helpful and decided that the advice should be online somewhere.
>

He knows how to put things on line himself. If I had written
that book, I wouldn't appreciate your taking it upon yourself
to put part of the book on line. I suggest you remove the
content.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[seeplus]

On Tuesday, October 7, 2014 5:46:14 AM UTC+11, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> At the end of each chapter in "The C++ Programming Language", 4th
> edition, Bjarne Stroustrup has a list of advice. I found the advice
> very helpful and decided that the advice should be online somewhere.
>

On the second page of my 2004 edition it has one of the most encompassing notices you will ever find.

You cannot even breathe on that stuff without infringing the copyright.

[Juha Nieminen]

Richard <legaliz...@mail.xmission.com> wrote:
> [Please do not mail me a copy of your followup]

Why would I mail you a copy of my followup?

> Initially I put this together as a PPT presentation, but oh my lord,
> it was too long. Instead, I made a page in my user space on the
> cppreference.com wiki:
> <http://en.cppreference.com/w/User:Legalize/Advice_from_Bjarne_Stroustrup>

And you got permission for this from the property owners?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Richard]

[Please do not mail me a copy of your followup]

Update: I've removed the page, pending permission from Addison-Wesley.
Bjarne is not opposed to the idea, but A-W owns the copyright.
Hopefully we'll get permission. If not, buy the book :-), it's full
of good advice.

[Stuart]

On 10/08/14, Richard wrote:
> Update: I've removed the page, pending permission from Addison-Wesley.
> Bjarne is not opposed to the idea, but A-W owns the copyright.
> Hopefully we'll get permission. If not, buy the book :-), it's full
> of good advice.

Hopefully you don't have to pay a fine. A buddy of mine put some
pictures of Lyonel Feininger on his homepage (he lives in the town that
got painted by Feininger quite frequently). After half a year he got a
letter from the copyright owner who claimed 500€/month/picture, and my
buddy had 6 pictures on his page. Luckily the copyright owner could only
prove that the pictures were to be seen for a single month, so he got
away with 3.000€ ... :-(

Best luck,
Stuart

[glen stark]

On Mon, 06 Oct 2014 18:46:01 +0000, Richard wrote:

> [Please do not mail me a copy of your followup]
>
> At the end of each chapter in "The C++ Programming Language", 4th
> edition, Bjarne Stroustrup has a list of advice. I found the advice
> very helpful and decided that the advice should be online somewhere.
>
> Initially I put this together as a PPT presentation, but oh my lord,
> it was too long. Instead, I made a page in my user space on the
> cppreference.com wiki:
> <http://en.cppreference.com/w/User:Legalize/
Advice_from_Bjarne_Stroustrup>
>
> This let me link to other pages on the wiki describing specific language
> features where possible.
>
> Hopefully you will find it useful.

This thread has been an excellent example of the "chilling effect" of
copyright law. In my (non-legal) opinion, what you did was perfectly
ethical, and covered under fair-use contingency of copyright law.

Unfortunately fair-use has been dangerously eroded, so you were probably
wise to follow the conservative advice of the other posters, but I
consider it a minor injustice, and would encourage you to question
copyright:

www.questioncopyright.org

[David Brown]

On 22/10/14 10:50, glen stark wrote:
> On Mon, 06 Oct 2014 18:46:01 +0000, Richard wrote:
>
>> [Please do not mail me a copy of your followup]
>>
>> At the end of each chapter in "The C++ Programming Language", 4th
>> edition, Bjarne Stroustrup has a list of advice. I found the advice
>> very helpful and decided that the advice should be online somewhere.
>>
>> Initially I put this together as a PPT presentation, but oh my lord,
>> it was too long. Instead, I made a page in my user space on the
>> cppreference.com wiki:
>> <http://en.cppreference.com/w/User:Legalize/
> Advice_from_Bjarne_Stroustrup>
>>
>> This let me link to other pages on the wiki describing specific language
>> features where possible.
>>
>> Hopefully you will find it useful.
>
>
> This thread has been an excellent example of the "chilling effect" of
> copyright law. In my (non-legal) opinion, what you did was perfectly
> ethical, and covered under fair-use contingency of copyright law.

One big problem with "fair use" is that the legal definition varies
wildly from country to country, and some countries have no "fair use"
clause at all.

An even bigger problem is that non-lawyers usually haven't the faintest
clue as to what "fair use" means legally, even within their country.
People often seem to think it means "I can't copy /everything/, but it's
okay to copy bits that I want and do what I like with them". That's
pretty much the only interpretation that "allows" this particular
example of copyright abuse. It should be pretty obvious, but this is
certainly not "fair use" in any country's definition.

"Fair use" /usually/ allows for /brief/ quotations, when the source
clearly marked. It allows for longer extracts to be used for
educational purposes (such as quoting a book in a school essay - but
/not/ photocopies of pages handed out to students). It allows for small
extracts in reviews of the original work (so that the copyright owner
cannot stop negative reviews). And it allows for parodies which are
clearly distinct from the "real" work.

I don't see how blanket copying of a range of useful tips and advice
from a book is "fair use". If you want advice from Bjarne Stroustrup,
then buy his books, or read his online publications (which includes a
great deal of useful tips and information, which /he/ has chosen to
share publicly).

>
> Unfortunately fair-use has been dangerously eroded, so you were probably
> wise to follow the conservative advice of the other posters, but I
> consider it a minor injustice, and would encourage you to question
> copyright:
>
> www.questioncopyright.org
>

Yes, "fair use" has often been dangerously eroded. But it does not help
matters to encourage rampant abuse of it.

[Richard]

[Please do not mail me a copy of your followup]

In the meantime, you can view a slide presentation I created around
2008 with advice that is similar to (but not copied from) Bjarne's
advice in his book. It's not as comprehensive, but it is a good
starting point:
<http://www.slideshare.net/LegalizeAdulthood/c-traps-and-pitfalls-for-c-programmers>

I plan to update that advice for C++11 in the near future.

[Wouter van Ooijen]

Richard schreef op 27-Oct-14 8:25 PM:

> [Please do not mail me a copy of your followup]
>
> In the meantime, you can view a slide presentation I created around
> 2008 with advice that is similar to (but not copied from) Bjarne's
> advice in his book. It's not as comprehensive, but it is a good
> starting point:
> <http://www.slideshare.net/LegalizeAdulthood/c-traps-and-pitfalls-for-c-programmers>
>
> I plan to update that advice for C++11 in the near future.
>

IMO the title suggest that it is advice for C++ programmers who are
forced to program in C, but it is the opposite: advice for C-style
programmers who must learn to use C++ (especially the 'better C' part).

Sheet 8 states "new should only appear in constructors". What about an
assignment that must do a deep copy?

Wouter van Ooijen

[Victor Bazarov]

On 10/27/2014 5:02 PM, Wouter van Ooijen wrote:
>[..]

> Sheet 8 states "new should only appear in constructors". What about an
> assignment that must do a deep copy?

Why would you need 'new' in that? Memberwise assignment should work
just fine. Instead of

this->some_ptr = other.some_ptr; // default behavior

you should do

*this->some_ptr = *other.some_ptr; // deep copy-assignment

thus invoking the assignment of objects, not their pointers.

V
--
I do not respond to top-posted replies, please don't ask

[Martijn Lievaart]

On Mon, 27 Oct 2014 22:02:48 +0100, Wouter van Ooijen wrote:

> Sheet 8 states "new should only appear in constructors". What about an
> assignment that must do a deep copy?

Once you know the rules, you know when they don't apply. :-) However, a
clone function is a kind of constructor.

M4

[Wouter van Ooijen]

Victor Bazarov schreef op 27-Oct-14 10:18 PM:

> On 10/27/2014 5:02 PM, Wouter van Ooijen wrote:
>> [..]
>> Sheet 8 states "new should only appear in constructors". What about an
>> assignment that must do a deep copy?
>
> Why would you need 'new' in that? Memberwise assignment should work
> just fine. Instead of
>
> this->some_ptr = other.some_ptr; // default behavior
>
> you should do
>
> *this->some_ptr = *other.some_ptr; // deep copy-assignment
>
> thus invoking the assignment of objects, not their pointers.

If the pointed-to object is an array of let's say chars that can have a
different length this won't work very well.

Wouter

[Wouter van Ooijen]

Martijn Lievaart schreef op 27-Oct-14 10:24 PM:

> On Mon, 27 Oct 2014 22:02:48 +0100, Wouter van Ooijen wrote:
>
>> Sheet 8 states "new should only appear in constructors". What about an
>> assignment that must do a deep copy?
>
> Once you know the rules, you know when they don't apply.

Not completely true. If you know how it works you know what to do: you
don't need a rule.

If you need a rule, you need it because on your own you would not always
do the right thing, so it better be a perfect rule (which it can
approach by stating its limits).

> :-) However, a
> clone function is a kind of constructor.

I think the normal interpretation of the word constructor does not
include the assignment operator.

Personally I'd say it is more like a destructor + constructor.

(And in a lot of cases I'd prefer a blocked assignment operator over a
well-implemented one, which makes this discussion unnesesarry.)

Wouter van Ooijen

[Öö Tiib]

Such pointer is typically inside 'std::vector<char>' member that does
itself deep copy correctly. Only on extreme cases when even
initialization done by vector is too much nanoseconds wasted it
may be is 'std::unique_ptr<char[]>'. Then the allocation is inside 'std::make_unique<char[]>' or if it is missing then in
'boost::make_unique<char[]>' ... and we have to copy the contents
manually unlike with 'vector'.

Anyway there are no reasons to write 'new' ever in C++ unless we
have to use quite old compilers or have to do some deep tricks
with placement 'new'.

[Richard]

[Please do not mail me a copy of your followup]

Wouter van Ooijen <wou...@voti.nl> spake the secret code
<544eb2f4$0$6963$e4fe...@dreader36.news.xs4all.nl> thusly:

>Sheet 8 states "new should only appear in constructors". What about an
>assignment that must do a deep copy?

I had you on mute because you were feeding trolls on the religious
thread.

You shouldn't ever need naked new or naked delete anywhere except
c'tors/d'tors for resource handling classes.

This implies that you don't have any raw pointers that indicate
ownership of resources, except in such resource handling classes.

If you follow that advice, then deep copy is simply member-wise
assignment and that is by definition the compiler generated copy
c'tor.

[Richard]

[Please do not mail me a copy of your followup]

Wouter van Ooijen <wou...@voti.nl> spake the secret code

<544ec5a6$0$6917$e4fe...@dreader36.news.xs4all.nl> thusly:

>> Why would you need 'new' in that? Memberwise assignment should work
>> just fine. Instead of
>>
>> this->some_ptr = other.some_ptr; // default behavior
>>
>> you should do
>>
>> *this->some_ptr = *other.some_ptr; // deep copy-assignment
>>
>> thus invoking the assignment of objects, not their pointers.
>
>If the pointed-to object is an array of let's say chars that can have a
>different length this won't work very well.

Use std::vector<char> and it's fine.

You shouldn't have naked pointers to indicate ownership, unless you
are writing a resource managing class like std::vector<>,
std::shared_ptr<>, etc.

[Richard]

[Please do not mail me a copy of your followup]

Wouter van Ooijen <wou...@voti.nl> spake the secret code

<544ec6f1$0$6917$e4fe...@dreader36.news.xs4all.nl> thusly:

>Martijn Lievaart schreef op 27-Oct-14 10:24 PM:
>> On Mon, 27 Oct 2014 22:02:48 +0100, Wouter van Ooijen wrote:
>>
>>> Sheet 8 states "new should only appear in constructors". What about an
>>> assignment that must do a deep copy?
>>
>> Once you know the rules, you know when they don't apply.
>
>Not completely true. If you know how it works you know what to do: you
>don't need a rule.

It's advice, not a rule. Avoiding this advice will cause yourself
needless pain.

Seriously, this advice has been in books by Stroustrup and others, as
well as general advice in newsgroups, for at least 20 years.

Whenever I see people whinging about how difficult C++ is and how it's
a source of bugs, it's because THEY DIDN'T FOLLOW THE ADVICE.

You can take the advice and make it a rule and you'd be much better
off, but plain and simple Stroustrup doesn't set himself up as a
dictator and neither do I. We offer advice based on the experience of
seeing people over and over again ignore the advice and code themself
up a bucket of snakes. If you want to shoot yourself in the foot, be
my guest.

[woodb...@gmail.com]

On Friday, October 31, 2014 11:44:37 AM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <544eb2f4$0$6963$e4fe...@dreader36.news.xs4all.nl> thusly:
>
> >Sheet 8 states "new should only appear in constructors". What about an
> >assignment that must do a deep copy?
>

> You shouldn't ever need naked new or naked delete anywhere except
> c'tors/d'tors for resource handling classes.
>

I get the impression that some here don't like it in even
these cases. I'm fine with it there.

I've compared these two lines:

auto req=::std::unique_ptr<cmw_request>(::new cmw_request(localbuf));

auto req=::std::make_unique<cmw_request>(localbuf);


On clang 3.3, the make_unique version increases the size
of a text segment by 112 bytes. I think I've tried it
on some newer compilers and found similar results.

Brian
Ebenezer Enterprises - Create in me a clean heart, O G-d,
And renew a steadfast spirit within me. Psalms 51:10

http://webEbenezer.net

[Öö Tiib]

On Friday, 31 October 2014 21:29:51 UTC+2, woodb...@gmail.com wrote:
> On Friday, October 31, 2014 11:44:37 AM UTC-5, Richard wrote:
> > [Please do not mail me a copy of your followup]
> >
> > Wouter van Ooijen <wou...@voti.nl> spake the secret code
> > <544eb2f4$0$6963$e4fe...@dreader36.news.xs4all.nl> thusly:
> >
> > >Sheet 8 states "new should only appear in constructors". What about an
> > >assignment that must do a deep copy?
> >
>
> > You shouldn't ever need naked new or naked delete anywhere except
> > c'tors/d'tors for resource handling classes.
> >
>
> I get the impression that some here don't like it in even
> these cases. I'm fine with it there.
>
> I've compared these two lines:
>
> auto req=::std::unique_ptr<cmw_request>(::new cmw_request(localbuf));
>
> auto req=::std::make_unique<cmw_request>(localbuf);
>
>
> On clang 3.3, the make_unique version increases the size
> of a text segment by 112 bytes. I think I've tried it
> on some newer compilers and found similar results.

What the 112 bytes can possibly contain?
Didn't you make something odd there (like comparing "debug"
versions, or forbidding inlining)?

[Richard]

[Please do not mail me a copy of your followup]

woodb...@gmail.com spake the secret code
<2737c2da-8fe1-411b...@googlegroups.com> thusly:

>On clang 3.3, the make_unique version increases the size
>of a text segment by 112 bytes. I think I've tried it
>on some newer compilers and found similar results.

A test on MSVC 2012 revealed an increase in the size of the debug
executable, but the release executable size was identical. Dumpbin
revealed the same "size of code" value.

[woodb...@gmail.com]

On Saturday, November 1, 2014 5:33:58 PM UTC-5, Öö Tiib wrote:
>
> What the 112 bytes can possibly contain?
> Didn't you make something odd there (like comparing "debug"
> versions, or forbidding inlining)?

I used the same makefile for both builds

http://webEbenezer.net/misc/makefile .

The only thing that changed is that line.
I'm not at my office now, but I'll check into
what is in those 112 bytes later.

[Tony Jen]

Currently the page says the page is not loading pending permission from Bjarne.