Friday, December 5, 2014

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Chicken Mcnuggets <chicken@mcnuggets.com>: Dec 05 12:20PM

I've kinda been following the Google C++ style guide (well not all of it
but I thought it would be a good foundation to build on) and they
recommend two things that I wanted to clarify.
 
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Doing_Work_in_Constructors
 
The first is never to do complex work in the constructor and instead to
use an init() method to do all the work. This allows you to return C
style error codes using an int to specify exactly what error occurred so
that the caller can respond in an appropriate way.
 
The down side of this is that calling an init() function is ugly and is
just one more thing for the caller to remember. I'm not sure how best to
get around that ugliness.
 
This is mainly in the style guide because Google forbid the use of
exceptions in their code and therefore there is no way to signal an
error in a constructor that does heavy work that can fail. This leads on
to my second question.
 
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Exceptions
 
The second is never to use exceptions. This is the one I'm most thinking
about. I recently got More Effective C++ and item 15 was talking about
the costs of using exceptions.
 
My code may not be that great but as I learn this code is going to be
used in an environment that has to deal with numerous simultaneous TCP
network connections without breaking a sweat. I'm concerned that if I
use exceptions from the start that my code will suffer later on when I
need to put it in a high load environment. I don't want to have to turn
around is 6 to 12 months time and remove the majority of exception
handling code because I found it was causing issues when the code was
profiled.
 
So should I carry on following these items in the Google C++ style guide
or should I ignore them?
 
In fact a more general question is what C++ style guide do you use and
is it published on the web so I can read it? I'm interested in reading
about how other people use C++ in production.
 
Thanks.
mad-crapper <madcrapper@toilet.com>: Dec 05 01:16PM

On Fri, 05 Dec 2014 12:20:47 +0000, Chicken Mcnuggets wrote:
 
 
> The down side of this is that calling an init() function is ugly and is
> just one more thing for the caller to remember. I'm not sure how best to
> get around that ugliness.
 
 
The payoff of an init() method is when you have multiple constructors
defined that all must share common processing. Nothing wrong with an init
() method as long as it doesn't become part of your religion.
 
 
 
> The second is never to use exceptions. This is the one I'm most thinking
> about. I recently got More Effective C++ and item 15 was talking about
> the costs of using exceptions.
 
 
I guess I'll add that to my ever growing list of why I mistrust google.
Nothing wrong with using exceptions. They area wonderful secondary
program flow mechanism. In fact I think it preferable to use them to
determine error conditions when trying to create an object, instead of
the old error return code methodology.
 
At the risk of starting a flame war, I think the "cost of exceptions"
argument is promulgated by old-farts who don't know or understand
exceptions. Granted, there was a time when the minimal memory and cpu
power of embedded systems made is costly to used exceptions in code, but
(especially in embedded systems), I prefer the higher level of process
abstraction and OO methodology to help me design solid code. I once
worked on a medical device using vxWorks and a special internal "team"
had designed a development C++ toolkit around vxWorks that we were to use
in making our control code. This toolkit displayed a lot of those legacy
phobias because the designers were old C programmers, not OO guys. So in
the end our code was buggier and harder to validate...and I myself am an
old-fart, but not afraid to learn new stuff.
 
 
> around is 6 to 12 months time and remove the majority of exception
> handling code because I found it was causing issues when the code was
> profiled.
 
If the addition of exceptions causes poor performance on a loaded system
then the hardware wasn't spec-ed properly in the first place. IMHO
Bo Persson <bop@gmb.dk>: Dec 05 02:55PM +0100

On 2014-12-05 13:20, Chicken Mcnuggets wrote:
> the costs of using exceptions.
 
> So should I carry on following these items in the Google C++ style guide
> or should I ignore them?
 
Google have a problem with TONS of legacy C++ code written before people
really started to think about exception safety. Thus, they cannot use
exceptions even if they wanted to.
 
So, their style guide is not about how to write great code, but about
how you HAVE TO write code if you work for Google. If you don't, you can
ignore a lot of the rules.
 
Just wish Google had taken the time to mark the rules as generally
applicable ("because we want to") and Google local rules ("because we
have to").
 
 
 
Bo Persson
Thomas Richter <thor@math.tu-berlin.de>: Dec 05 03:09PM +0100

Am 05.12.2014 um 13:20 schrieb Chicken Mcnuggets:
 
> The second is never to use exceptions. This is the one I'm most thinking
> about. I recently got More Effective C++ and item 15 was talking about
> the costs of using exceptions.
 
Honestly, if you write C++ code today and you can pick your environment,
do yourself a pleasure and ignore such recommendations. Off-loading work
into init() is error prone because you have to remember to call init().
Not using exceptions avoids an elegant error reporting mechanism that
can save your day.
 
This said, there are, however, situations where you have to adapt to
such a coding style. It is less the "cost of exceptions", but rather
"the implications it has on the run time when using them". The cost of
exceptions is minimal, and it is less than the cost when you have to
work by any other mechanism (cost in the sense of: code size, and amount
of debugging necessary to get it right).
 
The problem with exceptions is that on some platforms it requires
support by additional run-time libraries, and there are legacy
environments where this cost cannot be afforded simply because the run
time of the compiler is not available. Windows 32 bit is a typical
example. If you want to create a .dll as a stand-alone library without
further dependencies on other code, you cannot use exceptions. You
cannot use the STL either, of course. Maybe this sounds silly, but I've
worked on projects where this has been necessary due legacy project
dependencies.
 
IOW, if you can define your tools and your environment, please don't
follow this advice and use exceptions to report exceptional situations.
 
Greetings,
Thomas
"Öö Tiib" <ootiib@hot.ee>: Dec 05 09:18AM -0800

On Friday, 5 December 2014 14:21:00 UTC+2, Chicken Mcnuggets wrote:
> The second is never to use exceptions. This is the one I'm most thinking
> about. I recently got More Effective C++ and item 15 was talking about
> the costs of using exceptions.
 
That is bullshit advice. My profiling shows that when the situation
is exceptional (like 1 from 50000) then the exceptions beat all other
kinds of corner case handling in performance. Also the code is lot more
readable when it does not deal with reporting every exceptional situation
up stack.
Christopher Pisz <nospam@notanaddress.com>: Dec 05 11:38AM -0600

On 12/5/2014 11:18 AM, 嘱 Tiib wrote:
> kinds of corner case handling in performance. Also the code is lot more
> readable when it does not deal with reporting every exceptional situation
> up stack.
 
My name is Christopher Pisz and I support this message.
Always prefer exceptions over error codes. I have such an easier time of
maintaining code where others used exceptions, the team decided on a
common base exception type, and handling has been thought about and put
in the correct places.
JiiPee <no@notvalid.com>: Dec 05 06:08PM

On 05/12/2014 13:16, mad-crapper wrote:
> The payoff of an init() method is when you have multiple constructors
> defined that all must share common processing. Nothing wrong with an init
> () method as long as it doesn't become part of your religion.
 
The naming recommendation I read was to use "initialize" instead of "init"
legalize+jeeves@mail.xmission.com (Richard): Dec 05 06:09PM

[Please do not mail me a copy of your followup]
 
Chicken Mcnuggets <chicken@mcnuggets.com> spake the secret code
 
>http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Doing_Work_in_Constructors
 
>The first is never to do complex work in the constructor and instead to
>use an init() method to do all the work.
 
If you decide to follow this advice, then I would make the c'tor
private and force people to go through a factory method that does the
construction followed by the init. Then you are enforcing the
guarantee that constructed objects are always properly initialized.
If you need to call a virtual function to ensure proper construction,
then this is the only way to achieve that without forcing people to
remember to call init.
 
However, this generally means that such objects must always be
allocated on the heap because there isn't a way for a factory function
to operate on the caller's local stack (AFAIK), only it's local stack.
 
>http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Exceptions
 
>The second is never to use exceptions.
 
If I worked at google, I would do this. Otherwise, I find exceptions
to be worth more than they cost.
--
"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>
Paavo Helde <myfirstname@osa.pri.ee>: Dec 05 01:33PM -0600

Chicken Mcnuggets <chicken@mcnuggets.com> wrote in
 
> Subject: Exceptions - should I use them?
 
Yes. All normal C++ code should use RAII and exceptions unless there are
very specific reasons to not to.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 05 07:53PM

On Fri, 2014-12-05, Paavo Helde wrote:
 
>> Subject: Exceptions - should I use them?
 
> Yes. All normal C++ code should use RAII and exceptions unless there are
> very specific reasons to not to.
 
Seconded. That's really all you need to say on the subject.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bix <spam@nothing.invalid>: Dec 05 08:55PM +0100


> So should I carry on following these items in the Google C++ style
> guide or should I ignore them?
 
I'm using exception for exceptional condition, and to me error condition
are not so exceptional.
 
Bix.
woodbrian77@gmail.com: Dec 05 12:11PM -0800

On Friday, December 5, 2014 1:53:52 PM UTC-6, Jorgen Grahn wrote:
 
> > Yes. All normal C++ code should use RAII and exceptions unless there are
> > very specific reasons to not to.
 
> Seconded. That's really all you need to say on the subject.
 
If I translate that to this:
C++ code should use RAII and exceptions unless there are
reasons not to.
-----------------------
The obvious question is what are some reasons not to.
 
And please don't swear here. That's not directed to
Jorgen, but other poster in this thread.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Dombo <dombo@disposable.invalid>: Dec 05 11:08PM +0100

Op 05-Dec-14 18:18, 嘱 Tiib schreef:
>> about. I recently got More Effective C++ and item 15 was talking about
>> the costs of using exceptions.
 
> That is bullshit advice.
 
"More Effective C++" was written 18 years ago; some advice, especially
performance related, should be taken with a grain of salt. Note that
item 15 in this book does not recommend against using exceptions, it
just says exceptions have a cost both performance- and memory wise. It
also explicitly states that at the time of its writing [18 years ago]
support for exceptions by the C++ compilers of the day is [was] still in
its infancy and that your mileage may vary.
 
18 years ago exceptions were quite new and not every C++ compiler
supported it or did so only poorly. I remember that back in the day
'new' didn't throw an exception but just returned NULL if it could not
allocate memory. Very few libraries used exceptions back then, so you
could easily get by without exceptions. Nowadays exceptions have been an
integral part of the C++ language for a long time and many libraries
(including the standard library) rely on them. Avoiding exceptions
severely limits your options and is often impractical.
 
> kinds of corner case handling in performance. Also the code is lot more
> readable when it does not deal with reporting every exceptional situation
> up stack.
 
People concerned about the cost of exceptions often neglect the cost of
_not_ using exceptions. For a fair comparison one should also consider
the cost of the alternative. Checking return values (or whatever other
method is used to communicate the exceptional condition back to the
caller), propagating the relevant information (which maybe more than
just an int) and cleanup at every point in the call stack has a runtime
cost as well. And then there is the cost of programmer time...
 
I agree with the others here that one should use exceptions and RAII
unless one has very good reasons not to use them.
Ian Collins <ian-news@hotmail.com>: Dec 06 11:11AM +1300

> reasons not to.
> -----------------------
> The obvious question is what are some reasons not to.
 
Code that might get called from C is one of the few I'm aware of. If a
C++ library has a C interface, exceptions should be caught and converted
to error code in the extern "C" interface functions.
 
> And please don't swear here.
 
No one has.
 
--
Ian Collins
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 05 10:28PM

On 05/12/2014 22:11, Ian Collins wrote:
> to error code in the extern "C" interface functions.
 
>> And please don't swear here.
 
> No one has.
 
"mad-crapper" used the word "fart" perhaps that was it?
 
"Can I get any of you cunts a drink?" - Ed
 
/Flibble
Christopher Pisz <nospam@notanaddress.com>: Dec 05 04:42PM -0600

On 12/5/2014 4:11 PM, Ian Collins wrote:
 
> Code that might get called from C is one of the few I'm aware of. If a
> C++ library has a C interface, exceptions should be caught and converted
> to error code in the extern "C" interface functions.
 
This is all the more reason to promote the distinction between C and
C++, but too many both in management and in development think they are
one C++\C language and should magically coexist in the same module.
 
>> And please don't swear here.
 
> No one has.
 
I saw the cussword. He is referring to Oo Tiib's (Don't have the correct
characters for his name) reply. Naughty boy!
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 05 10:50PM

On 05/12/2014 22:42, Christopher Pisz wrote:
 
>> No one has.
 
> I saw the cussword. He is referring to Oo Tiib's (Don't have the correct
> characters for his name) reply. Naughty boy!
 
Ah yes the classic, reliable "bullshit".
 
"Fuck you, asshole." - T-800
 
/Flibble
ram@zedat.fu-berlin.de (Stefan Ram): Dec 05 12:50PM

>The second is never to use exceptions. This is the one I'm most thinking
>about. I recently got More Effective C++ and item 15 was talking about
>the costs of using exceptions.
 
Then, this would advise to prefer
 
vector[ 2 ]
 
to
 
vector.at( 2 )
 
, because IIRC the latter »uses exceptions«.
 
>In fact a more general question is what C++ style guide do you use and
>is it published on the web so I can read it? I'm interested in reading
>about how other people use C++ in production.
 
IIRC, there once was a book »C++ coding standards« by Sutter
and Alexandrescu. The names of those authors sound good!
 
I guess, that Sutter today would not advise against exceptions,
but to learn about execptions guarantees and exception safety
and C++ resource management (including C14 auto pointers).
 
The G. style guide you mention might hint at the use of
C++ as a »better C«, but possibly wanting to actually code
in C, possibly with some more type safety.
ram@zedat.fu-berlin.de (Stefan Ram): Dec 05 01:42PM

>At the risk of starting a flame war, I think the "cost of exceptions"
>argument is promulgated by old-farts who don't know or understand
>exceptions.
 
Some questions about C++ exceptions, so that readers can
find out whether they »know and understand« exceptions:
 
how many execution paths could there be in the following
code?
 
String EvaluateSalaryAndReturnName( Employee e )
{
if( e.Title() == "CEO" || e.Salary() > 100000 )
{
cout << e.First() << " " << e.Last()
<< " is overpaid" << endl;
}
return e.First() + " " + e.Last();
}
 
(IIRC, Question by Herb Sutter)
 
What is
 
the no-throw guarantee?
 
strong exception safety?
 
basic exception safety?
 
How are these accomplished in code?
 
Which kinds of exception specifications for function
definitions are recommended in C++ and which kinds are
deprecated?
 
How do smart pointers help to make C++ code
exception-safe? Which kind of smart pointer is
recommended for which scenario and how is it to be used?
 
How many persons who have learned »C++ programming« as a
part of some kind of education (school, college, ...)
are able to correctly answer the above questions and
thus use exceptions in C++ in the safe and recommandable way?
Melzzzzz <mel@zzzzz.com>: Dec 05 10:07AM +0100

On Thu, 04 Dec 2014 22:04:33 +0100
> "real" plain arrays but the size were passed in as a size_t (instead
> of unsigned, as it should I think), the same would happen. (And this
> make the cross-posting to comp.lang.c not completely irrelevant.)
 
You are absolutely right. If I change function
to:
int testNormal(const int* ghs, const int* lhs,size_t sz) {
int max = 0;
int tempMax;
for (unsigned k = 0; k < sz; k++) {
tempMax = lhs[k] + ghs[k];
if (max < tempMax) {
max = tempMax;
}
}
return max;
}
 
it *does not* vectorize as well!
 
> compilers makes me reasonably sure the problem lies somewhere there. I
> maintain what I said, but of course if James or anybody else has a
> better explanation I would love to read it.
 
Your explanation fits what happens with the code. It has to do
with unsigned is smaller then size_t and can overflow.
 
 
Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Dec 05 10:42AM +0100

Melzzzzz <mel@zzzzz.com> writes:
 
[...]
> return max;
> }
 
> it *does not* vectorize as well!
[...]
> Your explanation fits what happens with the code. It has to do
> with unsigned is smaller then size_t and can overflow.
 
Good, we have understood something. BTW, if you are using vectors, you
can probably keep using size() as the bound, and use a counter of type
vector<int>::size_type (size_t in C):
 
for ( vector<int>::size_type k = 0 ; k<ghs.size() ; k++ )
....
 
Or in C with plain arrays, like above:
 
for ( size_t k = 0 ; k<sz ; k++ )
....
 
The compiler should be able to not call size() repeatedly.
 
 
TL;DR: array/vector sizes are of type size_t/vector<T>::size_type, and
loops iterating over arrays should use counters of type size_t/....
 
-- Alain.
Melzzzzz <mel@zzzzz.com>: Dec 05 11:29AM +0100

On Fri, 05 Dec 2014 10:42:22 +0100
> vector<int>::size_type (size_t in C):
 
> for ( vector<int>::size_type k = 0 ; k<ghs.size() ; k++ )
> ....
 
Yes, that is definitely. Compilers are now able to vectorize.
So for int, it worked because compilers assume undefined behavior
on overflow, but on unsigned, behavior is defined, so
it restricts optimizations?
So moral is that one has to be careful what to use for index variable ;)
red floyd <no.spam@its.invalid>: Dec 04 03:43PM -0800

On 12/4/2014 11:14 AM, Geoff wrote:
 
>> #include<exception> was omitted [...]
 
> [snip]
 
> <exception> is a Microsoft header. <stdexcept> is the standard header.
 
No it isn't MS only. It's part of the Standard.
 
See ISO/IEC 14882:2003 18.6 [lib.support.exception]
"Öö Tiib" <ootiib@hot.ee>: Dec 05 12:11AM -0800

On Thursday, 4 December 2014 03:31:20 UTC+2, Luca Risolia wrote:
 
> All the above tells me you are using the VS C++ compiler.
 
> For the above reasons, I suggest that you change your compiler and try
> to be less arrogant next time.
 
Some standard C++ (or some other standard like POSIX) headers, functions,
types or classes being different and behaving slightly differently is
typical everyday case for anyone who is using two different versions of
*same* compiler for *same* platform.
 
On the other hand people post here code that compiles nowhere and even if
taken as pseudo-code has serious errors in it.
 
So conjuring a shit-storm out of such a little trivial difference is
perhaps going too far?
Luca Risolia <luca.risolia@linux-projects.org>: Dec 05 11:15AM +0100

Öö Tiib wrote:
 
> *same* compiler for *same* platform.
 
> On the other hand people post here code that compiles nowhere and even if
> taken as pseudo-code has serious errors in it.
 
That's why online compilers come in handy these days to share the same code,
compiler and preferred platform.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)