http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Hot sale ED Hardy Boots, Chanel Boots, Dior Boots, Fendi Boots, Coach Boots
free shipping (www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/39c577e99995010d?hl=en
* Exception Misconceptions: Exceptions are for unrecoverable errors. - 12
messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
* Q: Free compiler for 64 bit Windows 7? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/5f665081d6a6b15e?hl=en
* How to learn software design - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/3904738778c6ce86?hl=en
* Math/CompSci Interview Question - Thoughts? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a1cffd71c99a2dd0?hl=en
* about pointers on class' members - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/47ea85e4040fbd50?hl=en
* Exception Misconceptions - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cbcc4582e3daf8ee?hl=en
* How do I create an instance of a composite templated upon a different type? -
1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b487fd0198c68359?hl=en
==============================================================================
TOPIC: Hot sale ED Hardy Boots, Chanel Boots, Dior Boots, Fendi Boots, Coach
Boots free shipping (www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c++/t/39c577e99995010d?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Dec 22 2009 10:25 am
From: yoyotrade
Cheap Wholesale Gucci Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale GUCCI Boots
Cheap Wholesale Lacoste Shoes
Cheap Wholesale LV Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale LV Boots
Cheap Wholesale Prada Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Timberland Shoes
Cheap Wholesale D&G Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale D&G Boots
Cheap Wholesale Puma Shoes
Cheap Wholesale Puma AAA (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale UGG Boots Shoes
Cheap Wholesale Bikkem Bergs Shoes (free shipping)
Cheap Wholesale Mauri Shoes Man
Cheap Wholesale Versace Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Versace Boots
Cheap Wholesale Paul Smith Shoes (free shipping)
Cheap Wholesale BOSS Shoes
Cheap Wholesale Burberry Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Dsquared shoes
Cheap Wholesale Dior Shoes (free shipping)
Cheap Wholesale Dior Boots
Cheap Wholesale ED Hardy Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale ED Hardy Boots
Cheap Wholesale ED Hardy Shoes Man (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Fendi Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Fendi Boots
Cheap Wholesale AFF Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Evisu Shoes (free shipping)
Cheap Wholesale 4US Shoes
Cheap Wholesale Sebago Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Supra Shoes
Cheap Wholesale Hight Converse Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Coach Boots
Cheap Wholesale Coach Shoes
Women Christian Louboutin (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Chanel Shoes
Cheap Wholesale Chanel Boots (free shipping)
Cheap Wholesale Bape Shoes
Cheap Wholesale Adidas Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Adicolor (free shipping)
Cheap Wholesale Adidas 35TH (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Adidas NBA
Cheap Wholesale Adidas Running (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Adidas Y3
Cheap Wholesale Soccer Shoes (paypal payment)
(www.vipchinatrade.com )
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================
== 1 of 12 ==
Date: Tues, Dec 22 2009 10:26 am
From: "dragan"
"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:exceptions-20091222164313@ram.dialup.fu-berlin.de...
> "dragan" <spambuster@prodigy.net> writes:
>>Saying "Exceptions are for unrecoverable errors" seems to
>>imply that they are to be used only or mostly in such
>>situations.
>
> BTW: Who did actually say this?
Someone in c.l.c++.m said something like what is in quotes above (pretty
much exactly). I got the thus-far-presented misconceptions from that NG.
== 2 of 12 ==
Date: Tues, Dec 22 2009 10:29 am
From: "dragan"
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:hgqoqj$srf$1@news.eternal-september.org...
>* dragan:
>> Futher discussion of the application of exceptions is appreciated. Keep
>> in mind that while there are SOME general vague "principles" of the
>> application of exceptions, mostly the scenarios need to be defined for
>> fruitful discussion. Please keep the examples simple but realistic and
>> note the assumptions you make.
>
> Hm, I failed to see the question in there, sorry.
That there were no question marks in the entire OP means there were no
questions in it. For your reference, this is what a question mark looks
like: ?
;)
== 3 of 12 ==
Date: Tues, Dec 22 2009 10:29 am
From: "dragan"
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:hgqoqj$srf$1@news.eternal-september.org...
>* dragan:
>> Futher discussion of the application of exceptions is appreciated. Keep
>> in mind that while there are SOME general vague "principles" of the
>> application of exceptions, mostly the scenarios need to be defined for
>> fruitful discussion. Please keep the examples simple but realistic and
>> note the assumptions you make.
>
> Hm, I failed to see the question in there, sorry.
That there were no question marks in the entire OP means there were no
questions in it. For your reference, this is what a question mark looks
like: ?
;)
== 4 of 12 ==
Date: Tues, Dec 22 2009 1:25 pm
From: tanix@mongo.net (tanix)
In article <hgqoqj$srf$1@news.eternal-september.org>, "Alf P. Steinbach" <alfps@start.no> wrote:
>* dragan:
>> Saying "Exceptions are for unrecoverable errors" seems to imply that they
>> are to be used only or mostly in such situations. Whereas the exception
>> machinery in C++ was developed primarily to handle and RECOVER from more
>> errors more elegantly than was possible without exceptions, the statement is
>> highly suspect.
>Yes.
>> Those "unrecoverable errors" are probably the things that
>> assertion checking weeds out during development time rather than being an
>> application for exception machinery. "Unrecoverable error": throw up a
>> dialog for the developer and exit (or crash to keep the call stack in view
>> in the debugger). Exceptions, are more appropriately used where there is a
>> likelihood of recovering from the error condition rather than being just for
>> "unrecoverable errors".
>
>C++ unfortunately lacks any concept exceptions that won't be caught by ordinary
>
>catch(...). Therefore, in current C++ you should preferentially not use
>exceptions for unrecoverable failures, not to speak of unrecoverable errors!
>Just log and terminate.
In Java, there is a separation betwen exceptions and errors.
Exceptions could be used on a very fine grained level, such
as numeric string parsing, and in case there is a non digit
present, you simply catch the exception and replace the
result with default value. Works like a champ.
In fact, you MUST use try/catch block to do these conversion.
Otherwise, your code won't even compile.
With error, you are dead. You can not even recover from them.
>> Futher discussion of the application of exceptions
>> is appreciated. Keep in mind that while there are SOME general vague
>> "principles" of the application of exceptions, mostly the scenarios need to
>> be defined for fruitful discussion. Please keep the examples simple but
>> realistic and note the assumptions you make.
>Hm, I failed to see the question in there, sorry.
Some people just feel they need to dominate, like THEIR word
is "the word of God". They tend to fail to comprehend that
THEIR view is just that, THEIR view. Nothing more than that.
>Cheers & hth.,
>- Alf
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 5 of 12 ==
Date: Tues, Dec 22 2009 1:26 pm
From: tanix@mongo.net (tanix)
In article <tg8Ym.93148$We2.79541@newsfe09.iad>, "dragan" <spambuster@prodigy.net> wrote:
>
>"Alf P. Steinbach" <alfps@start.no> wrote in message
>news:hgqoqj$srf$1@news.eternal-september.org...
>>* dragan:
>>> Futher discussion of the application of exceptions is appreciated. Keep
>>> in mind that while there are SOME general vague "principles" of the
>>> application of exceptions, mostly the scenarios need to be defined for
>>> fruitful discussion. Please keep the examples simple but realistic and
>>> note the assumptions you make.
>>
>> Hm, I failed to see the question in there, sorry.
>
>That there were no question marks in the entire OP means there were no
>questions in it. For your reference, this is what a question mark looks
>like: ?
Impressive.
>;)
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 6 of 12 ==
Date: Tues, Dec 22 2009 1:34 pm
From: tanix@mongo.net (tanix)
In article <exceptions-20091222164313@ram.dialup.fu-berlin.de>, ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>"dragan" <spambuster@prodigy.net> writes:
>>Saying "Exceptions are for unrecoverable errors" seems to
>>imply that they are to be used only or mostly in such
>>situations.
>
> BTW: Who did actually say this?
>
>>Whereas the exception machinery in C++ was developed
>>primarily to handle and RECOVER from more errors more
>>elegantly than was possible without exceptions, the statement
>>is highly suspect.
>
> More elegantly? Actually, for correct and secure C++ code,
> all functions need to be written to be »exception safe«,
Correct.
Almost everything you do will generate some kind of exception,
at least in modern languages, and it is good it does.
> but
> only a minority of C++ programmers does so or even is aware
> of it.
>
>>Those "unrecoverable errors" are probably the things that
>>assertion checking weeds out during development time rather
>>than being an application for exception machinery.
>
> These are distinct concepts for me: An unrecoverable error
> can occur when a program needs 10 Bytes of allocated
> storage, but this storage is not available. The program can
> not generate more storage, so the error is not recoverable,
> but it also can not be weeded out during developement time.
>
>>Futher discussion of the application of exceptions is
>>appreciated.
>
> I prefer error results to exceptions. So all I would write
> about exceptions would start with »If I was forced to use a
> language that would force me to use exceptions ...«
>
> The applications of error results is as follows:
>
>if( attempt( to_do_something ))
>{ case 0: /* ok, continue */ ... break;
> case 1: /* oops, handle */ ... break;
> ... }
Well, there are two styles of coding.
One is: as soon as you can return the correct result,
return it.
If you ever get to code that was past the end of all
your good returns, everything you are dealing with
from then on is errors.
The second style is just the opposite:
Handle all errors first. When you handled ALL of them,
and I mean ALL, then you are home free.
These two approaches define your logic eventually.
It is quite a different logic.
With 2nd approach, you tend to get a more robust code
because it forces you to think about all sorts of problems,
you may not pay attention to otherwise.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 7 of 12 ==
Date: Tues, Dec 22 2009 1:49 pm
From: tanix@mongo.net (tanix)
In article <hgqqon$osi$1@news.albasani.net>, Vladimir Jovic <vladaspams@gmail.com> wrote:
>Stefan Ram wrote:
>[snip]
>>
>> More elegantly? Actually, for correct and secure C++ code,
>> all functions need to be written to be »exception safe«, but
>> only a minority of C++ programmers does so or even is aware
>> of it.
>>
>
>Why?
>I thought only the code in the catch blocks have to be exception safe.
>Might be new exception misconception ;)
The code in your catch block is not necessarily exception safe.
It all depends what are you going to do to recover from the
original exception. You MAY get yet another exception when
trying to recover from the original one.
In some places in my code, I have nested exceptions.
Acutlly in quite a few MOST important places.
That is why this thing runs like a tank.
You can just turn the power switch on in the middle of the
most important and critical and time consuming operation.
>[snip]
>>> Futher discussion of the application of exceptions is
>>> appreciated.
>>
>> I prefer error results to exceptions. So all I would write
>> about exceptions would start with »If I was forced to use a
>> language that would force me to use exceptions ...«
>>
>> The applications of error results is as follows:
>>
>
>This should have probably been "switch" instead of "if" :
>
>> if( attempt( to_do_something ))
>> { case 0: /* ok, continue */ ... break;
>> case 1: /* oops, handle */ ... break;
>> ... }
>Back to return value vs exceptions.
>
>1)
>What happens if you can not handle the error in this method?
Correct, and it is not such an uncommon thing.
Because, first of all, the error is local.
Your routine does not necessarily know what is the most
logical thing to do on the HIGHER levels.
So, what is the solution then?
If you just return an error code, then the higher level
code has to examine it, and do different things, which simply
translates in additional and unnecessary complications in
your program logic, a "spaghetti effect".
You may have 5 levels deep stack, and on EACH level, you
have to test every single return code. Else your program
is incorrect.
So, you tend to forever deal with small and insignificant
things in the scheme of things, all of which, regardless
of how many levels deep on the stack it happened, could
be handled in bulk, with a single exception at the
appropriate higer level, that gives you sufficient
granularity to make a LOGICAL decision on what can be
done to recover the operation as such, and not some low
level funk, which is nothing more than a logic noise.
I am trying to use as little of logic as possible.
My slogan is: take it easy on your logic,
or you are bound to end up with grand headache,
no matter from what standpoint you look at it.
It will simply make your code more difficult to read.
How many decisions does you mind have to make, if it
forever worries about whether some return code was
handled correctly, of was handled in the right place
or what kinds of problems it might cause to the higher
level code.
Program logic = load on the mind.
>Or in the method that called this method?
>Or in the method that called the method that called the method where the
>error happened?
>etc
>
>2) How do you handle errors in constructors?
You don't. Because you can not construct the object.
Your program is incorrect, and I doubt you can recover
from this kind of thing in principle in most cases.
>3) Simple example : how would you create a method (or a function) that
>reads a value (some random integer) from a file and returns that value?
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 8 of 12 ==
Date: Tues, Dec 22 2009 1:50 pm
From: James Kanze
On Dec 22, 3:15 pm, "dragan" <spambus...@prodigy.net> wrote:
> Saying "Exceptions are for unrecoverable errors" seems to
> imply that they are to be used only or mostly in such
> situations.
Maybe, maybe not. It probably depends on what whoever is
saying it means by "unrecoverable". (But I've never heard
anyone say it, so I don't know the context.)
> Whereas the exception machinery in C++ was developed primarily
> to handle and RECOVER from more errors more elegantly than was
> possible without exceptions, the statement is highly suspect.
It depends on the error. At the lowest level, where a simple
retry suffices, exceptions complicate error handling.
> Those "unrecoverable errors" are probably the things that
> assertion checking weeds out during development time rather
> than being an application for exception machinery.
If that's what is meant by "unrecoverable", then exceptions are
certainly not for unrecoverable errors. In such cases, it's
important (in most applications---there are exceptions) to kill
the process as soon as possible, without any stack walkback.
> "Unrecoverable error": throw up a dialog for the developer and
> exit (or crash to keep the call stack in view in the
> debugger).
Exactly. And that's not what exceptions do.
> Exceptions, are more appropriately used where there is a
> likelihood of recovering from the error condition rather than
> being just for "unrecoverable errors".
Again, it depends on what you mean by "recovering". If you just
have to try again (e.g. user input error), then a simple while
loop is a lot simpler than an exception. Exceptions are useful
when you can't really do anything about the error locally.
Which often means that "recovery" is more or less impossible,
since once you've left "locally", you've lost all of the
necessary context to retry.
But maybe you mean something different by "recovering"?
> Futher discussion of the application of exceptions is
> appreciated. Keep in mind that while there are SOME general
> vague "principles" of the application of exceptions, mostly
> the scenarios need to be defined for fruitful discussion.
> Please keep the examples simple but realistic and note the
> assumptions you make.
Concrete example:
//! \pre
//! No current output set up...
void
SomeClass::setupOutput()
{
assert(! myOutput.is_open());
std::string filename = getFilename(); // Dialog with user...
myOutput.open(filename.c_str());
while (! myOutput.is_open()) {
reportErrorToUser();
filename = getFilename();
myOutput.open(filename.c_str());
}
}
Use of exceptions here would only make the code more
complicated. (Try writing it in Java sometime:-). Where
failure to open a file is reported via an exception.)
--
James Kanze
== 9 of 12 ==
Date: Tues, Dec 22 2009 1:58 pm
From: James Kanze
On Dec 22, 3:46 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "dragan" <spambus...@prodigy.net> writes:
> >Whereas the exception machinery in C++ was developed
> >primarily to handle and RECOVER from more errors more
> >elegantly than was possible without exceptions, the statement
> >is highly suspect.
> More elegantly? Actually, for correct and secure C++ code,
> all functions need to be written to be »exception safe«, but
> only a minority of C++ programmers does so or even is aware
> of it.
Just a nit, but the same holds true in any language which
supports exceptions. All code must be written with the fact
that some (or all, in the case of languages like Java) functions
can return via an exception, rather than the normal path.
> >Those "unrecoverable errors" are probably the things that
> >assertion checking weeds out during development time rather
> >than being an application for exception machinery.
> These are distinct concepts for me: An unrecoverable error
> can occur when a program needs 10 Bytes of allocated
> storage, but this storage is not available. The program can
> not generate more storage, so the error is not recoverable,
> but it also can not be weeded out during developement time.
That's a particular definition of "unrecoverable". Is it the
one the original poster meant? I don't know.
Also, you know as well as I do that your example is simplified,
and only speaks of the general case. There are cases where you
attempt to allocate a large amount of memory, but can use a fall
back strategy in case of failure. I'd certainly be very upset
if, on trying to output data to a (non-essential) log, I got a
bad_alloc exception (especially if the logging was taking place
in a destructor, called because I'm unwinding the stack because
of another exception).
> >Futher discussion of the application of exceptions is
> >appreciated.
> I prefer error results to exceptions. So all I would write
> about exceptions would start with »If I was forced to use a
> language that would force me to use exceptions ...«
I prefer to have a number of different tools in my toolbox, and
to use which ever one is most effective for the job at hand.
--
James Kanze
== 10 of 12 ==
Date: Tues, Dec 22 2009 2:09 pm
From: James Kanze
On Dec 22, 4:06 pm, Vladimir Jovic <vladasp...@gmail.com> wrote:
> Stefan Ram wrote:
> [snip]
> > More elegantly? Actually, for correct and secure C++ code,
> > all functions need to be written to be exception safe ,
> > but only a minority of C++ programmers does so or even is
> > aware of it.
> Why?
Because your program doesn't work right otherwise.
Exceptions introduce an additional flow path into your code.
Fundamentally, all "exception safety" really means is ensuring
that the code is correct when this flow path is executed.
Practically, it's a bit more complicated than that, because the
number of additional flow paths soon makes the older,
traditional ways of reasonning about program correction
unmanageable; when C++ programmers speak of exception safety,
they are generally referring to the more recently developed
techniques to make this problem tractable. Effective use of
destructors, for example---I'm not sure you can write correct
code with exceptions unless the language has deterministic
destructors.
> [snip]
> >> Futher discussion of the application of exceptions is
> >> appreciated.
> > I prefer error results to exceptions. So all I would write
> > about exceptions would start with If I was forced to use a
> > language that would force me to use exceptions ...
> > The applications of error results is as follows:
> This should have probably been "switch" instead of "if" :
> > if( attempt( to_do_something ))
> > { case 0: /* ok, continue */ ... break;
> > case 1: /* oops, handle */ ... break;
> > ... }
> Back to return value vs exceptions.
> 1)
> What happens if you can not handle the error in this method?
Then you might prefer an exception.
> Or in the method that called this method?
> Or in the method that called the method that called the method where the
> error happened?
> etc
The further up the stack you go, the more exceptions are called
for. It's important to realize, however, that the alternative
flow paths are still there, and that your code has to be correct
if they're taken.
> 2) How do you handle errors in constructors?
Or overloaded operators, or any other function which can't
return a value, or has its return type imposed.
The case of constructors is particular, however, in that an
exception coming from a constructor means that you don't have an
instance of the object at all. Which means that you don't have
to worry about an invalid instance floating around. This often
justifies exceptions even in cases where you wouldn't normally
use them.
> 3) Simple example : how would you create a method (or a
> function) that reads a value (some random integer) from a file
> and returns that value?
Fallible<int> readInt( std::istream& input );
Although in this case, it's even simpler, because istream
maintains an error state, which should be set if you can't read
the value.
--
James Kanze
== 11 of 12 ==
Date: Tues, Dec 22 2009 2:21 pm
From: James Kanze
On Dec 22, 4:55 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2009-12-22, Vladimir Jovic <vladasp...@gmail.com> wrote:
> > Stefan Ram wrote:
> > [snip]
> >> More elegantly? Actually, for correct and secure C++
> >> code, all functions need to be written to be »exception
> >> safe«, but only a minority of C++ programmers does so or
> >> even is aware of it.
> > Why?
> The above is false. Exception-safe code is needed to write
> code that avoids resource leaks in the face of an exception.
It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false in
so far that if the function calls no other function, or only
calls functions guaranteed not to throw, it doesn't have to be
exception safe.)
> For instance:
> {
> char *p = new char[256];
> f();
> }
> If f throws an exception, this statement block is abandoned,
> and the allocated memory is leaked.
Or not. If the application is using garbage collection, it's
not leaked. If the application immediately terminates (and is
in a hosted environment), it's not leaked.
> Of course other kinds of resources can be leaked, like handles
> to operating system resources such as open files.
And there can be other issues besides leaking. In the end,
you've got to ensure internal consistency for all possible
control flows. When some of the possible control flows are the
result of an exception, then this requirement is called
exception safety.
> Leaking a resource is not automatically incorrect. Firstly, it
> does not violate any C++ language rule. Allocating memory and
> losing the pointer does not trigger undefined behavior.
> Whether it is an issue or not depends on the precise situation
> in which it occurs. Many C++ programs leak resources by
> design simply because they lose references to objects when
> terminating by returning via main.
Or by calling exit. (Calling exit does not unwind the stack,
which means that destructors of local variables are not called.)
> This doesn't matter if the operating system cleans up the
> resources after a program that terminated. Minor resource
> leaks in short-lived programs are often not a problem.
More correctly, if the resource will be cleaned up by the
system, and you return to the system, it's not been leaked.
It's only a leak if you don't return to the system, or if it is
something which won't be cleaned up by the system. (Neither
Unix nor Windows clean up temporary files, for example.)
[...]
> > 2) How do you handle errors in constructors?
> You set a ``successfully constructed'' flag in the object
> which is tested after construction, through some public member
> function.
And has to be asserted in every member function, so that you
don't accidentally use an invalid object. (There are cases
where this is valid, e.g. input or output. But they're not the
majority.)
> > 3) Simple example : how would you create a method (or a
> > function) that reads a value (some random integer) from a
> > file and returns that value?
> There are a few ways. One is to store the integer via a
> pointer or reference parameter and return the success/error
> indication.
Yes. There are better solutions in C++ (at least in certain
cases). But people were writing robust, correct code even
before there were exceptions.
--
James Kanze
== 12 of 12 ==
Date: Tues, Dec 22 2009 2:24 pm
From: James Kanze
On Dec 22, 9:34 pm, ta...@mongo.net (tanix) wrote:
> In article
> <exceptions-20091222164...@ram.dialup.fu-berlin.de>,
> r...@zedat.fu-berlin.de (Stefan Ram) wrote:
[...]
> > More elegantly? Actually, for correct and secure C++ code,
> > all functions need to be written to be »exception safe«,
> Correct.
> Almost everything you do will generate some kind of exception,
> at least in modern languages, and it is good it does.
In order to write exception safe code, at least with value
semantics (and I suspect even without value semantics, but I've
not analysed the question in detail), it's been proven that you
need a certain number of primitives which are guaranteed not to
throw---one of the most classical C++ idioms, for example, only
works if you have a version of swap that doesn't throw.
--
James Kanze
==============================================================================
TOPIC: Q: Free compiler for 64 bit Windows 7?
http://groups.google.com/group/comp.lang.c++/t/5f665081d6a6b15e?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Dec 22 2009 10:49 am
From: Pete Becker
tanix wrote:
> In article <Re2dncsqjrDaXa3WnZ2dnUVZ_tZi4p2d@giganews.com>, Pete Becker <pete@versatilecoding.com> wrote:
>> arunix wrote:
>>>> What about asking in a Windoze newsgroup?
>>> Because its gcc based compiler.
>> Oh, of course: a gcc based compiler for Windows isn't a Windows compiler.
>>
>> Sigh. gcc is just as off-topic as Windows.
>
> What is this "off-topic" bullshit?
>
> Have you heard of cygwin?
>
Yes, I'm familiar with cygwin. It's just as off-topic in this newsgroup
as "gcc" and "Windows compilers".
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
== 2 of 3 ==
Date: Tues, Dec 22 2009 11:27 am
From: Dann Corbit
In article <f8c2d19d-f14a-4776-b13d-51512fdb0d2e@
13g2000prl.googlegroups.com>, arrunix@gmail.com says...
>
> On Dec 21, 8:38�pm, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> > Please excuse me for a dumb question: Are there any
> > free C++ complier running on 64 bit Windows 7?
> >
> > Thanks,
> >
> > M. K. Shen
>
> What about Dev C++?
Web searches will turn up stuff like this:
http://www.thefreecountry.com/compilers/cpp.shtml
http://www.cadforte.com/system64.html
== 3 of 3 ==
Date: Tues, Dec 22 2009 2:16 pm
From: tanix@mongo.net (tanix)
In article <RKKdnft88JlPiazWnZ2dnUVZ_sti4p2d@giganews.com>, Pete Becker <pete@versatilecoding.com> wrote:
>tanix wrote:
>> In article <Re2dncsqjrDaXa3WnZ2dnUVZ_tZi4p2d@giganews.com>, Pete Becker
> <pete@versatilecoding.com> wrote:
>>> arunix wrote:
>>>>> What about asking in a Windoze newsgroup?
>>>> Because its gcc based compiler.
>>> Oh, of course: a gcc based compiler for Windows isn't a Windows compiler.
>>>
>>> Sigh. gcc is just as off-topic as Windows.
>>
>> What is this "off-topic" bullshit?
>>
>> Have you heard of cygwin?
>>
>
>Yes, I'm familiar with cygwin. It's just as off-topic in this newsgroup
>as "gcc" and "Windows compilers".
Who ARE you to dictate things like these to some of the most intelligent
people one can find and whose brains function well above average?
If you think it is "off-topic", here is the best advice I know of
about things like this, directly from the horses mouth,
Russ Allbery. Do you know who he is?
"If you don't like something, do not read it.
Do not follow up on it.
Just forget about it".
Simple, isn't it?
Or you think you are some kind of traffic light here,
and what YOU think or perceive is some kind of standards
all others are to be measured agains?
Do you know what this trip is called?
Well, fascism and totalitarian dictate.
Just enjoy things if you find it interesting here.
If you don't, nobody holds you by your hand and FORCES you
to read anything. It is YOUR choice.
Just go find a "better" or "cleaner" place,
such as those dictatorship outlets, called the "moderated" groups.
That is MUCh healthier for individuals of your kind,
the "blue blooded" "elite".
There is a group, called c.l.c++.m.
Do I have to tell you THESE kinds of things?
In other words, do not insult the intelligence of highly intelligent
people. Very few of them will appreciate this, especially considering
the fact I do not know even who you are and what is YOUR word worth.
Not that I reviewed enough of material on these groups to even
notice you in the scheme of things.
Just a sec. Lemme make sure you get the same treatment.
I put people like you on some lists to make sure you just dissapear
from pg collections so there is not a trace of you left.
Oh, I see, you were on the expert list. Not any longer.
Cya.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
==============================================================================
TOPIC: How to learn software design
http://groups.google.com/group/comp.lang.c++/t/3904738778c6ce86?hl=en
==============================================================================
== 1 of 4 ==
Date: Tues, Dec 22 2009 11:09 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
ram@zedat.fu-berlin.de (Stefan Ram) writes:
>"dragan" <spambuster@prodigy.net> writes:
>>Finally, don't do it my way, do you your way! Good luck.
>What I do, when I do not know how to design:
The idea to do an »up-front design« and then implement
this, actually is the waterfall method.
It is not totally broken, but only works sometimes for
- small or simple projects with a fixed set of requirements or
- projects of the kind one has already done very often
(here »experience« comes in).
== 2 of 4 ==
Date: Tues, Dec 22 2009 12:14 pm
From: Mick
Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> "dragan" <spambuster@prodigy.net> writes:
>>> Finally, don't do it my way, do you your way! Good luck.
>> What I do, when I do not know how to design:
>
> The idea to do an »up-front design« and then implement
> this, actually is the waterfall method.
>
> It is not totally broken, but only works sometimes for
>
> - small or simple projects with a fixed set of requirements or
>
> - projects of the kind one has already done very often
> (here »experience« comes in).
>
While literally correct that Waterfall is one good SDLC method. I
suspect the OP was looking for: "How do I convert this application
concept/idea into working code?".
Rather than "How do I design the entire development process for this
company?".
== 3 of 4 ==
Date: Tues, Dec 22 2009 1:12 pm
From: tanix@mongo.net (tanix)
In article <aE6Ym.72955$de6.54017@newsfe21.iad>, "dragan" <spambuster@prodigy.net> wrote:
>
>"Eric "Böse-Wolf"" <eric@boese-wolf.eu> wrote in message
>news:7p3lqhFfslU1@mid.individual.net...
>>I know it is off topic, but maybe someone could
>> give me a hint for a good book or few tips on
>> learning software design.
>>
>> With software design I mean the step from the requirements
>> to some sort of software architecture.
>
>Many approaches are possible of course. Fundamental knowledge is the
>starting point IMO: read the pattern books and such, study existing systems
>and software from a high level (rather than doing something like loading GCC
>source code in your IDE), use Doxygen to analyze source code at a high
>level, pay attention to how things interact (the "interfaces") rather than
>the things themselves, avoid large team development roles if you can (you'll
>get buried in the details rather than gain high-level perspective), create
>entire application programs but do start with the pen and paper and circles
>and arrows and such, way before writing any code. Do not write a whole book
>of documentation before doing some iteration and feasibility studies, but do
>write important things down in additon to your "circles, boxes and arrows"
>or you will forget your decision-making path come implementation time.
>
>"Jumping in with both feet" is OK, but some amount of study and THINKING
>(design is more thinking than annotating) is prudent. Don't OVER-study the
>commonly tauted "principles" either: you'll get to know the trade-offs and
>when they apply by doing (designing and architecting, that is). Most of the
>"principles" are not documented or available to read about, realize, as
>experienced designers/architects draw from the larger wealth of knowledge
>and experience rather than the much smaller scope that is Information
>Technology.
>
>(This is the most key point IMO: designers/architects are born, not made or
>taught.
Very good. Not far from being right on the money.
> If you are asking how to be one, maybe that is a sign).
People think that sw design is like a skill you aquire in some school,
like a plumber or machist.
Yes, you CAN aquire plenty of knowle, but the whole art of it
will be missing.
> Know
>yourself: designers find it natural to design.
Yep. In fact it is not a "job" to them. It is something they get the
kicks out of. It is some necessity to them, like an oxygen.
> They create the patterns
>rather than go out and look for them.
Correct. When someone talks to me about "design patterns".
I tell them: I CREATE them and I created plenty. So far, did not
see an area where I would not feel comfortable with.
Sure, you can read the patterns from some book and blindly apply
them anywhere you can find a place to stick them on. But all of
it is artificial. It won't necessary be that, which is truly
requiered by your situation.
There are ALL sorts if issues with patterns, down to issues of
debugging. Some time ago, I needed the web crawler. So I found
some nice piece of code that looked promising. It did do most
of what I wanted. But it did have some pretty bad shortcomings.
It was using the visitor pattern.
The code was totally undocumented and I spend WEEKS trying
to understand all the intricacies. When I was debugging it,
it was a nightmare. You are totally event driven and the
environment is totally async. You don't even know where
to set the breakpoints, and even if you single step through
the whole thing, it is such a major headache, that it takes
you at least 10 times more time and effort.
And THAT is the reason I suspect that powerful and beautiful
piece of code was eventually abandoned and author stopped
maintaining and improving it. Becaues we got overloaded with
the complexities of it to the point that it was ubearable.
So, the visitor patern in the async, event driven state machine
is a disaster. And so I saw with other patterns.
People think that patterns is some kind of paradise.
Nowadays, about the fist question you are asked on the
interview is: do you know design patterns?
And if you don't, you are some kind of clueless idiot to them.
You won't have a chance in most places.
What a joke.
> Are you "a picture person"? Or do you
>prefer to read/listen? Some people, perhaps most, are better at filling in
>the details of a good design/architecture. Then again, some people are so
>high level that their designs are not practical (cannot be implemented).
>Practicality vs. extremism seems to be a big problem in SW engineering (I
>think STL is the latter, for example).
Yep, plenty of new "technologies" in the sw business could be classified
as extremism. The overkill and overload with complexities probably not
helps anything at the end, but creates more problems than it solves.
To me, your code should be readable like a news article.
You should be able to understand ANY piece of code within seconds,
and not sit there for hours, trying to comprehend all the nasty
details, going as far as spending minutes if not hours just to
understand the parameters of some method. I saw some code that is
basically unreadable, unless you are willing to spend HOURS,
and even there it is not clear you will see all the intricacies
of it.
People do not have that time nowadays.
On the top of it, those complications essentially do not buy
you anything. The bang for the buck is as low as it gets, and
the costs of code maintenace and expanstion is immense.
Quite often, people create overly complicated things just to
show others how "great" they are, which is basically the result
of complex of inferiority.
>Distinguish between "high-level" design and "low-level" design. The former
>should be pretty much devoid of programming language peculiarities.
One of the things I remember from my early days of programming
was this recepie:
Top down design and bottom up implementation.
That is probably the most valuable overall rule for sw development.
I intuitively use it more often than not.
Once you have your low level stuff worked out and working,
it makes it a breaze to hang higher level stuff on the top of it.
>Build small systems and application programs first. Large systems have
>specialized skill requirements but they are IN ADDITION to the stuff you
>learn from building complete small systems/programs thoroughly. Taking
>programs that you have already developed and "rearchitecting" or
>"refactoring" them is a good starting point, for you are already have a lot
>of useful information about the domains (plural).
Basically, I consider it the issue of modelling.
By creating a model, you will be able to test it and see all sorts
of things that you could not even expect before you started.
And I mean MOST of it, no matter who says what.
Then you can SCULPT your project. I do not program, I SCULPT it
like a sculpture.
From the first days on a project, this thing becomes alive.
So, you never end with doing ALL sorts of things without even
knowing if your entire concept is correct and your house does
not end up "being built on sand", and quite literallly at that.
From the first days, your creation should be alive.
So you can see its freakingess, its weakenesses, its beauty.
It should sing or hum as Rolls Royce, every step of the way.
>Avoid the formal methods
I do agree with this one.
> and stick with pen and paper (or an appropriate
>graphics program). The programming-specific tools and methods are for
>low-level design the ill-fated attempts at creating the proverbial "software
>factory"
Correct. Those "factories" are some of the biggest pain on the
neck that do not necessarily buy you anything, but give you ALL sorts
of headaches and make it more difficult even for you to understand
your code.
> on-the-fly (read, project work/"general SW dev").
>Designing/architecting is a creative process and as such it is not conducive
>to highly-structured "methods" or management (those things stifle
>creativity).
Correct. They simply eat MOST of your energy on constanly worrying
about things, that you never have to worry about.
I can produce immence improvements in my projects in a matter
of days. In few days, I sometimes add some much new functionality,
that it becomes a problem to even verify it all, even thogh it
all works pretty much out of the box.
And debugging and making it more robust becomes more or less
an idle excersize because it flows by itself. No headaches.
That is when you can take a break and take it easy.
Debugging mostly becomes a verification procedure to make sure
ALL the error conditions have been handled without being lazy
or sloppy about something that "can not happen in 'REALITY'".
> Your rate and patterns of creativity are just that: highly
>personal:
Correct.
> you probably can't turn it on and off like a light switch all the
>time. Some days you will be highly motivated and creative and other days you
>will plod along drudgerously.
Well, for me, for MAJOR architectural decistions and design
"patterns", it is a process of MATURING.
This process sometimes takes MONTHS untill it all finally
falls into place. I never try to write a piece of code that I can
put a final dot on it. So, no need to overstress yourself perfecting
something, that is not totally clear from the standpoint of
system as such and ALL sorts of most subtle interactions,
the issues of efficiency, compactness, robustness and you name it.
>Architecting the system doesn't qualify one to manage the project, realize.
>Realize too that it doesn't preclude that: "ownership is nine-tenths of the
>law". I've never seen a project run by someone from a business background
>devoid of technical background be nearly as successful as it could have been
>if someone with an engineering background was running the show (requisite
>management skill are still required of course). Business rule implementation
>sits on top of architectural technical foundation, NOT the other way around.
>
>Finally, don't do it my way, do you your way! Good luck.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 4 of 4 ==
Date: Tues, Dec 22 2009 2:06 pm
From: tanix@mongo.net (tanix)
In article <aE6Ym.72956$de6.43045@newsfe21.iad>, "dragan" <spambuster@prodigy.net> wrote:
>
>"Pete Becker" <pete@versatilecoding.com> wrote in message
>news:vs2dnc3GxOL6pLDWnZ2dnUVZ_vBi4p2d@giganews.com...
>> James Kanze wrote:
>>>
>>> That's an interesting point. I once heard that you should never
>>> employ a programmer who didn't play a musical instrument.
>>> Something about the ability to be creative in a structured
>>> environment.
>> I used to play a musical instrument, but I've found that the thing that's
>> contributed most to my understanding of programming and program design was
>> law school. That's where I learned to cut through the distractions to see
>> what's really there.
>Both allude to what I think are very relevant concepts and not just
>folklore: that the larger scope of someone's experience and knowledge is
>very important in graduating to an advanced level of designing/architecting
>capability.
One of things you learn with music is to deal with abstractions.
Second thing you learn is to trust yourself with improvisation.
That gives you a subconscious hint that things are still possible
even if you don't "know" which note to play next, how long and
loud, with what accentuation, with what sustain and decation,
with what tone and according to what rythm, manifest or implied.
This an immense amount of "information processing".
It is like walking on a mine field, never knowing what your next
step is going to be, a step to life or the end of your trip.
And, some people, miraculously still can walk on the mind field.
In fact it is a daily job for them.
With music, you learn now to construct objects.
It is forever a process of construction.
You also learn the principles of harmony and principles of
melody (the equivalent of sequential logic).
Plus, you learn to be a PART of the whole orchestra
and see how your playing fits into the whole piece of music.
And the grandest thing of all, you learn EXTACY.
Extacy with existance. An orgasmic feeling with life.
Something that feeds your very soul,
gives you a taste of the very JUICE of life.
Without it, you are like a machine, more or less,
programmed with knowlege to follow someone elses path,
but not your own. You never learn the very joy of existence.
In fact, you don't even have time to even recognize it
when it comes, being forever busy, trying to forever jump
higher than your own weanie, without realizing it is simply
an impossibility. Thus frustration. The grandest frustration
of all - not being able to express yourself, accept yourself
as you are and trust yourself as something PERFECTLY valid,
no matter what who says what and no matter how much you
yourself doubt your own validity.
Cool, eh?
:--}
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
==============================================================================
TOPIC: Math/CompSci Interview Question - Thoughts?
http://groups.google.com/group/comp.lang.c++/t/a1cffd71c99a2dd0?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Dec 22 2009 1:07 pm
From: Danio
On Dec 22, 6:23 pm, jbriggs444 <jbriggs...@gmail.com> wrote:
> On Dec 22, 11:16 am, Danio <daniothef...@hotmail.com> wrote:
> > On Dec 20, 11:08 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> > > On Nov 28, 4:07 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > > wrote:
> > > > What solution? The above exhibits undefined behaviour.
>
> > > If you spot a bug you might bother saying what it is. I wrote this
> > > quickly and haven't tested it. Are you referring to the assumption
> > > that int is 32 bit, or is there a typo or some other problem?
> > > -Andrew.
>
> > It looks to me like you missed Phase 1 from the Fischer&Salzberg
> > algorithm, namely
> > arrange the elements so that no two adjacent elements are the same.http://www.cs.yale.edu/publications/techreports/tr252.pdf-Hide quoted text -
>
> > - Show quoted text -
>
> I think you missed the definition of the problem in this thread. It
> is one of the givens of the problem that the array has a strict
> "majority" value that appears in over half ot its entries.
Sorry my mistake - strict majority truned into modal value in my head
in between the original description and the latter discussions in this
thread.
> You go on to claim that the code quoted above gives an answer of 5 but
> that the "bit-counting method" returns 4. What you fail to realize is
> that the code above _is_ the bit-counting method
> and that it returns 4, not 5.
Again a mis-reading of Phil Carmody's quote - assumed that he would be
quoting
the most recent code posting of Andrew's not the initial one.
> I actually ran the code. Did you?
Yes
> In summary, in spite of your accusation of ill-defined behavior, in
> spite of your providing the algorithm with non-compliant input and in
> spite of your claim of incorrect output, the fact of the matter is
> that the algorithm got what you consider to be the right answer.
Well it wasn't my accusation of ill-defined behaviour: that was Phil
Carmody.
I was merely trying to find out what he didn't like about the
algorithm,
unfortunately with a horribly flawed test case and the wrong
algorithm...
==============================================================================
TOPIC: about pointers on class' members
http://groups.google.com/group/comp.lang.c++/t/47ea85e4040fbd50?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Dec 22 2009 1:24 pm
From: Chameleon
στις 22 Δεκ 2009 17:11, O/H Vladimir Jovic έγραψε:
> Chameleon wrote:
>
> [snip]
>> void A::C::no_way_dude()
>> {
>> A *a = 0;
>> B &b = *(B*)(((char*) this) - (char*) &a->c - (char*) &a->b);
>> // DONE!!!
>> }
>
> Take a look at this:
> http://www.google.de/#hl=en&source=hp&q=dereferencing+null+pointer&btnG=Google+Search&aq=f&oq=dereferencing+null+pointer&fp=4fc34adcbfaca52f
>
>
>
> Why don't you move the no_way_dude() method from C to A? Then instead of
> passing objects of type C, pass objects of type A
Yes, this is what I wrote before.
But because A had many many members, I thought to group similar
functions of A in subclasses.
I realize that I am a little bit influenced from Java.
In Java if a subclass is not static can have access to parent class.
== 2 of 2 ==
Date: Tues, Dec 22 2009 1:31 pm
From: Michael DOUBEZ
Le 22/12/2009 18:04, Jeff Flinn a écrit :
> Michael Doubez wrote:
>> On 22 déc, 16:01, Jeff Flinn <TriumphSprint2...@hotmail.com> wrote:
>>> Chameleon wrote:
>>>> στις 22 Δεκ 2009 15:32, O/H Gert-Jan de Vos έγραψε:
>>>>> On Dec 22, 1:51 pm, Chameleon<gessos.p...@yahoo.gr> wrote:
>>>>>> We have this structure:
>>>>>> -----------------------
>>>>>> struct A {
>>>>>> struct B {
>>>>>> ...
>>>>>> } b;
>>>>>> ...
>>>>>> struct C {
>>>>>> void no_way_dude();
>>>>>> } c;};
>>>>>> -----------------------
>>>>>> How can I have access on 'b' from inside of 'no_way_dude()'?
>>>>>> I mean without pass parameters to 'C()' or to 'no_way_dude()'
>>>>> You can't since b and c are unrelated objects. The only relation
>>>>> is that both are members of A. So, the only way to reach one from
>>>>> the other is through an instance of A: a.b or a.c.
>>>>> Both B and C objects can exist as stand-alone objects:
>>>>> A::B A::GetB() const { return B(); }
>>>>> So there can not be a way to reach one from the other.
>>>> void A::C::no_way_dude()
>>>> {
>>>> A *a = 0;
>>>> B &b = *(B*)(((char*) this) - (char*) &a->c - (char*) &a->b);
>>>> // DONE!!!
>>>> }
>>> And what happens when you or someone else tries the following weeks,
>>> months or years later:
>>>
>>> int main()
>>> {
>>> A:C c;
>>>
>>> c.no_way_dude();
>>>
>>> return 0;
>>>
>>> }
>>
>> You can make C constructor protected and A become C's friend.
>
> Or just fix the design.
Since I don't know the problem space of the OP, I could not say anything
about the design. What he is trying to do is a pattern I know under the
name of 'memberspace':
http://accu.org/index.php/journals/1527
And if it fits his needs, he can simply put a comment in the code such as:
\warning this class is intended to be used in class A and nowhere else.
Because, of course, one reads the doc in the header before using a class :)
>>> You basically have a (very) bad design.
>>
>> It could be convenient in some cases if the standard provided more
>> tools to make it work.
>
> In this case convenience makes for brittle code.
It is certainly not something I would do on a daily basis but I don't
see where the robustness is impacted. In a well designed code, the
no_way_dude() would be the only responsibility of class C and there
would be no incentive to reuse it outside A.
--
Michael
==============================================================================
TOPIC: Exception Misconceptions
http://groups.google.com/group/comp.lang.c++/t/cbcc4582e3daf8ee?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Dec 22 2009 1:31 pm
From: James Kanze
On Dec 22, 12:48 am, ta...@mongo.net (tanix) wrote:
> In article
> <a65d3221-02ca-4a18-907f-9027cce07...@c34g2000yqn.googlegroups.com>, James
> Kanze <james.ka...@gmail.com> wrote:
[...]
> >> Well, THEORETICALLY, it can happen even without using
> >> exceptions. In reality, it is just a joke.
> >It's no joke. It's an everyday reality. Most of the phone
> >switches and transmission systems go back to a time before
> >exceptions, and they work. Year in, year out, without
> >interruption.
> Yep. No argument there. Except those apps are infantile
> by todays standards.
They were a good deal more complex than anything I've seen
written recently.
> If you tell me I have to write my code WITHOUT exeptions, I
> won't take your job offer. Sorry.
It would depend on the context. If they had a good reason for
not using exceptions, then OK. Otherwise, no.
> I do not know why some claim the exception mechanism is so
> inefficient even in cases where there are not exceptions, but
> that is another matter.
Memories of early compilers?
> I can only guess that if you want to get TOO sophosticated and
> assure that you can unwind the stack even considering the on
> heap allocations and things like that, and, as a result, have
> to save all sorts of things prepairing to run the exceptions
> bound code, may be.
I'm not sure which side of the issue you're looking at above.
From the language point of view, it's clear what has to be done,
and techniques exist (and are used in most compilers) which have
0 overhead (or almost) in the case when an exception isn't
thrown. From the programmer's point of view: if you have to
write any special handling in C++, you're not writing idiomatic
C++. But one of the more frequent errors I've seen in Java is a
missing finally block, when there are things that have to be
cleaned up, and the author didn't think about exceptions.
> Who knows?
> >> For one thing, without exceptions your code becomes a huge
> >> pile of spegetti code and I know what I am talking about.
> >Apparently not,
> Apparently yes.
I've worked on some very large projects without exceptions, and
the code was not at all a pile of spaghetti. It was, in fact, a
lot cleaner than a lot of code I see today, with exceptions.
> I just wrote too much code to make such a statement. It is
> simply inevitable.
So inevitable that it doesn't take place.
I'm tempted to say the opposite. Exceptions are just another
tool. A very convenient and effective one in specific cases,
but still just a tool. If you can't write clean code without
them, then you can't write it with them. Like any tool, they
don't change your native ability; all they do is make some
things (that you could do anyway) easier and less effort.
> > because I've worked on very large code bases,
> >without exceptions,
> Again, this is a general purpose statement that does not
> prove anything.
It's the exception that disproves your claim. (Obviously, I
can't post the code here, because it was propriatory. And
because it was several million lines of code, which would make
for a pretty large posting.)
> Either you do test of your return codes, or you don't.
> If you decide to do, and your logic runs to check all the
> codes, then your code size and the amount of spagetti is
> probably at least 30% bigger.
That's only if you don't know how to write code.
> With exceptions, you do not check ANY return code
> more or less. Clear to a 5 year old what it means.
Yes. That you're not handling a lot of errors the way they
should be. There aren't that many errors which warrent
exceptions. Most should be processed immediately.
[...]
> >> Sorry. I can not agree with you on this one.
> >> I think you are somehow predisposed AGAINST exceptions.
> >Not at all.
> Yes you are. I have seen some of your posts.
Then you know that I'm not against exceptions. That I use them
when appropriate.
[...]
> > and we still managed to write robust and
> >maintainable applications.
> Well. I am not saying it is not possible in PRINCIPLE.
> I am saying it is a royal pain on the neck.
It's more effort, that's for sure. But there are a lot of
other things with even more impact.
> In fact, I will make this claim:
> If you do NOT use exceptions, you are just a lazy bum.
Or you're working in a context where they aren't appropriate,
for some reason. (On a really small embedded system, for
example.) But I do use exceptions. I also use return codes,
assertion failure, and deferred error checking (as in iostream
or IEEE floating point). I have more than one tool in my tool
kit, and I use which ever one is most effective for the job at
hand.
--
James Kanze
==============================================================================
TOPIC: How do I create an instance of a composite templated upon a different
type?
http://groups.google.com/group/comp.lang.c++/t/b487fd0198c68359?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Dec 22 2009 2:27 pm
From: "mat"
I am creating composite objects from various building blocks. This is best
described with an example.
template <class T>
class Behavior
{
public:
virtual void DoSomething(T& t) = 0;
virtual void AddChild(Behavior<T>* child){}
};
//------------------------------------------------------------------
template <class T>
class CompositeBehavior : public Behavior<T>
{
list<Behavior<T> > children;
public:
virtual void DoSomething(T& t) = 0;
virtual void AddChild(Behavior<T>* child){children.push_back(child);}
};
//-------------------------------------------------------------------
template <class T>
class SelectBehavior : public Composite<T>
{
void DoSomething(T& t) ;
};
//-------------------------------------------------------------------
template <class T>
class ConcreteBehavior : public Behavior<T>
{
void DoSomething(T& t) ;
};
So I create a composite out of these building blocks.
Behavior<Dog>* pDogRoot = new SelectBehavior<Dog>();
pDogRoot ->AddChild(new ConcreteBehavior<Dog>());
pDogRoot ->AddChild(new ConcreteBehavior<Dog>());
I'd like to be able to create an instance of this composite as though it was
created using a different type, say a Cat, but without going through the
process of creating it all over again by hand (the composites can get
complex). Ideally I'd like to be able to pass some function pRoot and it
return an instance created for the specified type.
Behavior<Cat>* pCatRoot = MakeInstance<Cat>(pDogRoot);
How could i go about doing this? What design patterns might be relevent? (is
it even possible?)
Many thanks for any help.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment