Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Exceptions - should I use them?
126 views
Skip to first unread message
Chicken Mcnuggets
Dec 5, 2014, 7:21:00 AM12/5/14
to
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.
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.
Message has been deleted
mad-crapper
Dec 5, 2014, 8:16:39 AM12/5/14
to
On Fri, 05 Dec 2014 12:20:47 +0000, Chicken Mcnuggets wrote:
> 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.
>
>
> 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.
>
>
> 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.
The payoff of an init() method is when you have multiple constructors
> 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.
defined that all must share common processing. Nothing wrong with an init
() method as long as it doesn't become part of your religion.
> 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.
>
> 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.
> about. I recently got More Effective C++ and item 15 was talking about
> the costs of using exceptions.
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.
> 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.
then the hardware wasn't spec-ed properly in the first place. IMHO
Message has been deleted
Bo Persson
Dec 5, 2014, 8:56:07 AM12/5/14
to
On 2014-12-05 13:20, Chicken Mcnuggets wrote:
> 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.
>
>
> 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.
>
>
> 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.
>
>
>
> 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.
>
>
> 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
> or should I ignore them?
>
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
Dec 5, 2014, 9:09:34 AM12/5/14
to
Am 05.12.2014 um 13:20 schrieb Chicken Mcnuggets:
> I've kinda been following the Google C++ style guide (well not all of it
> I've kinda been following the Google C++ style guide (well not all of it
> 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.
Honestly, if you write C++ code today and you can pick your environment,
> 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.
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
Dec 5, 2014, 12:19:07 PM12/5/14
to
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
> 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.
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
Dec 5, 2014, 12:38:46 PM12/5/14
to
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
Dec 5, 2014, 1:08:33 PM12/5/14
to
On 05/12/2014 13:16, mad-crapper wrote:
> On Fri, 05 Dec 2014 12:20:47 +0000, Chicken Mcnuggets wrote:
>
>> 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.
>>
>>
>> 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.
> 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"
> On Fri, 05 Dec 2014 12:20:47 +0000, Chicken Mcnuggets wrote:
>
>> 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.
>>
>>
>> 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.
> 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.
Richard
Dec 5, 2014, 1:09:48 PM12/5/14
to
[Please do not mail me a copy of your followup]
Chicken Mcnuggets <chi...@mcnuggets.com> spake the secret code
<zqhgw.2$tr...@fx15.am4> thusly:
>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.
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>
Chicken Mcnuggets <chi...@mcnuggets.com> spake the secret code
<zqhgw.2$tr...@fx15.am4> thusly:
>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.
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.
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
Dec 5, 2014, 2:33:31 PM12/5/14
to
Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
news:zqhgw.2$tr...@fx15.am4:
> 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.
news:zqhgw.2$tr...@fx15.am4:
> 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
Dec 5, 2014, 2:53:52 PM12/5/14
to
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bix
Dec 5, 2014, 2:55:43 PM12/5/14
to
Chicken Mcnuggets <chi...@mcnuggets.com> writes:
> 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
> So should I carry on following these items in the Google C++ style
> guide or should I ignore them?
>
are not so exceptional.
Bix.
woodb...@gmail.com
Dec 5, 2014, 3:11:34 PM12/5/14
to
On Friday, December 5, 2014 1:53:52 PM UTC-6, Jorgen Grahn wrote:
> On Fri, 2014-12-05, Paavo Helde wrote:
> > Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
> > news:zqhgw.2$tr...@fx15.am4:
> >
> >> 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.
>
If I translate that to this:
> On Fri, 2014-12-05, Paavo Helde wrote:
> > Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
> > news:zqhgw.2$tr...@fx15.am4:
> >
> >> 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.
>
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
Dec 5, 2014, 5:07:05 PM12/5/14
to
Op 05-Dec-14 18:18, 嘱 Tiib schreef:
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.
> 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.
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.
> 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.
"More Effective C++" was written 18 years ago; some advice, especially
>> 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.
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.
> 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.
_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
Dec 5, 2014, 5:11:20 PM12/5/14
to
woodb...@gmail.com wrote:
> On Friday, December 5, 2014 1:53:52 PM UTC-6, Jorgen Grahn wrote:
>> On Fri, 2014-12-05, Paavo Helde wrote:
>>> Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
>>> news:zqhgw.2$tr...@fx15.am4:
>>>
>>>> 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.
>>
>
> 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.
Code that might get called from C is one of the few I'm aware of. If a
> On Friday, December 5, 2014 1:53:52 PM UTC-6, Jorgen Grahn wrote:
>> On Fri, 2014-12-05, Paavo Helde wrote:
>>> Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
>>> news:zqhgw.2$tr...@fx15.am4:
>>>
>>>> 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.
>>
>
> 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.
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.
--
Ian Collins
Mr Flibble
Dec 5, 2014, 5:28:18 PM12/5/14
to
"Can I get any of you cunts a drink?" - Ed
/Flibble
Christopher Pisz
Dec 5, 2014, 5:42:18 PM12/5/14
to
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.
characters for his name) reply. Naughty boy!
Mr Flibble
Dec 5, 2014, 5:50:29 PM12/5/14
to
"Fuck you, asshole." - T-800
/Flibble
David Harmon
Dec 6, 2014, 5:35:20 PM12/6/14
to
On Fri, 5 Dec 2014 09:18:47 -0800 (PST) in comp.lang.c++, 嘱 Tiib
<oot...@hot.ee> wrote,
But you are assuming that the alternative to exceptions is to handle
errors the old-school hard way. For many people the alternative
they are comparing against is to simply ignore errors and live with
buffer overflows, file failures, and all the normal security bugs
that are all over modern operating systems and the internet. That's
way more efficient than exceptions.
<oot...@hot.ee> wrote,
errors the old-school hard way. For many people the alternative
they are comparing against is to simply ignore errors and live with
buffer overflows, file failures, and all the normal security bugs
that are all over modern operating systems and the internet. That's
way more efficient than exceptions.
Chris M. Thomasson
Dec 6, 2014, 5:43:18 PM12/6/14
to
> "Chicken Mcnuggets" wrote in message news:zqhgw.2$tr...@fx15.am4...
http://www.stroustrup.com/JSF-AV-rules.pdf
;^)
> I've kinda been following the Google C++ style guide
Perhaps take a look at these coding standards:
http://www.stroustrup.com/JSF-AV-rules.pdf
;^)
Daniel
Dec 6, 2014, 9:58:02 PM12/6/14
to
On Saturday, December 6, 2014 5:43:18 PM UTC-5, Chris M. Thomasson wrote:
>
> Perhaps take a look at these coding standards:
>
> http://www.stroustrup.com/JSF-AV-rules.pdf
>
It's interesting that while there are a couple of competing C++ class naming
>
> Perhaps take a look at these coding standards:
>
> http://www.stroustrup.com/JSF-AV-rules.pdf
>
conventions that have a large following, Stroustrup proposes one
that hardly anybody will recognize:
"The first word of the name of a class, structure, namespace, enumeration, or
type created with typedef will begin with an uppercase letter. All others
letters will be lowercase.
Example:
class Diagonal_matrix { ... }; // Only first letter is capitalized;"
Daniel
Öö Tiib
Dec 7, 2014, 12:27:50 AM12/7/14
to
popular among customers than inefficiency. After fixing defects they
will have all the hard way of corner case handling and that is
inefficient.
Nobody
Dec 8, 2014, 5:18:10 PM12/8/14
to
On Fri, 05 Dec 2014 12:20:47 +0000, Chicken Mcnuggets wrote:
> 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.
> but I thought it would be a good foundation to build on) and they
> recommend two things that I wanted to clarify.
> The second is never to use exceptions.
When Google first wrote their style guide, exceptions had a (not entirely
undeserved) reputation as something that popular compilers often got wrong.
ISTR that they have said that if they were writing the style guide today,
that rule wouldn't be there. But they now have a large codebase containing
a large amount of C++ code (and some C code) which doesn't allow for
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.
Most of the cost of exceptions is only incurred if and when they are
> 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.
actually thrown. Allowing for the possibility of exceptions has some cost
(related to foregoing certain optimisations which are only safe in the
absence of exceptions), but not much. It's typically less than the cost of
returning and checking status codes all over the place.
As a rough guide, if failure is common, use a status return. If failure is
exceptional, use an exception.
E.g. if you're testing many candidate options until one succeeds, you want
something which returns a status rather than throwing an exception on
failure.
0 new messages