http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Nested enums, structs & unions defined in a class - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/9dc42291edf325f8?hl=en
* Possible to call a function to "many" times? - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/be1b60b85bd6e81b?hl=en
* Why do some code bases don't use exceptions? - 11 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/c255001068888229?hl=en
* I don't have to tell you... - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
* Math/CompSci Interview Question - Thoughts? - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a1cffd71c99a2dd0?hl=en
* ddraw.h in Linux - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0fa46d75811421c4?hl=en
* DWORD and bool to binary - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3ecc7dd1864c4bea?hl=en
==============================================================================
TOPIC: Nested enums, structs & unions defined in a class
http://groups.google.com/group/comp.lang.c++/t/9dc42291edf325f8?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Nov 25 2009 3:10 pm
From: Stephen Howe
Hi
Are nested enums, structs & unions defined in a class (and I mean defined not declared) subject to the access specifiers?
Thanks
Stephen Howe
== 2 of 2 ==
Date: Wed, Nov 25 2009 3:28 pm
From: Sam
Stephen Howe writes:
> Hi
>
> Are nested enums, structs & unions defined in a class (and I mean defined not declared) subject to the access specifiers?
If by access specifiers you mean public/private/protected, then yes.
==============================================================================
TOPIC: Possible to call a function to "many" times?
http://groups.google.com/group/comp.lang.c++/t/be1b60b85bd6e81b?hl=en
==============================================================================
== 1 of 4 ==
Date: Wed, Nov 25 2009 3:14 pm
From: "carl"
"none" <none@none.none> wrote in message
news:Xns9CCE7815D6F3Enonenonenone@69.16.186.8...
> carl wrote:
>
>> Is it possible to stress a function to much with to many calls?
>
> No, as long as it returns each time.
>
>
>> But when I run the code I get the error:
>>
>> HEAP CORRUPTION DETECTED:after Normal block(#107261) at 0x020A44E0.
>> CRT detected that the application wrote to memory after end of heap
>> buffer.
>
> There is useful information in this error message:
>
> 1) The heap is what's corrupted (not the stack).
> 2) The block number.
> 3) The address (may or may not be useful).
>
> You've allocated something on the heap, probably an array of something,
> and
> your code has walked "off the end" of that thing. There's no 100%
> guarantee that this is what happened, but it's very likely. It's also
> possible that you have some completely bogus pointer that ended up with a
> random value in it, and that random value just happened to be
> "0x020A44E0",
> but I'd assume the other case first.
>
> Other helpful information would be:
>
> - Does your program allocate memory in exactly the same order every time?
> - Does the error message look the same every time (or at least, is the
> block number the same every time)?
>
> If the answer to both is "yes," then you can use that block number
> (107261)
> to catch exactly which allocation is being corrupted. There's a Visual
> Studio macro that will break on a specific heap allocation. I don't
> remember the name of it right now, but Google does.
Ok I found something here (using the variable _crtBreakAlloc):
http://www.tek-tips.com/viewthread.cfm?qid=1366567&page=17
but since the number changes each time (so does the error message) I cannot
really see how I can use that approach. I have tried debugging my way
through the calls but it never happens the same time.
It seems that the only solution is to write my application from scratch
without using any stl container. But before doing that I would be very
interested if someone had alternative plan to find this error.
I am beginning to understand why java is the language used by companies in
the real world!
== 2 of 4 ==
Date: Wed, Nov 25 2009 3:36 pm
From: Daniel Pitts
carl wrote:
>
> "none" <none@none.none> wrote in message
> news:Xns9CCE7815D6F3Enonenonenone@69.16.186.8...
>> carl wrote:
>>
>>> Is it possible to stress a function to much with to many calls?
>>
>> No, as long as it returns each time.
>>
>>
>>> But when I run the code I get the error:
>>>
>>> HEAP CORRUPTION DETECTED:after Normal block(#107261) at 0x020A44E0.
>>> CRT detected that the application wrote to memory after end of heap
>>> buffer.
>>
>> There is useful information in this error message:
>>
>> 1) The heap is what's corrupted (not the stack).
>> 2) The block number.
>> 3) The address (may or may not be useful).
>>
>> You've allocated something on the heap, probably an array of
>> something, and
>> your code has walked "off the end" of that thing. There's no 100%
>> guarantee that this is what happened, but it's very likely. It's also
>> possible that you have some completely bogus pointer that ended up with a
>> random value in it, and that random value just happened to be
>> "0x020A44E0",
>> but I'd assume the other case first.
>>
>> Other helpful information would be:
>>
>> - Does your program allocate memory in exactly the same order every time?
>> - Does the error message look the same every time (or at least, is the
>> block number the same every time)?
>>
>> If the answer to both is "yes," then you can use that block number
>> (107261)
>> to catch exactly which allocation is being corrupted. There's a Visual
>> Studio macro that will break on a specific heap allocation. I don't
>> remember the name of it right now, but Google does.
>
> Ok I found something here (using the variable _crtBreakAlloc):
>
> http://www.tek-tips.com/viewthread.cfm?qid=1366567&page=17
>
> but since the number changes each time (so does the error message) I
> cannot really see how I can use that approach. I have tried debugging my
> way through the calls but it never happens the same time.
>
> It seems that the only solution is to write my application from scratch
> without using any stl container. But before doing that I would be very
> interested if someone had alternative plan to find this error.
>
> I am beginning to understand why java is the language used by companies
> in the real world!
Why without using any STL container? Its likely that your error is
outside the use of the STL container, not because of it.
Make sure that you aren't leaking any memory (every new has a delete,
every new[] has a delete[]), Make sure you aren't overwriting memory
you don't own (pointer arithmatic that might be one-off, using iterators
without checking the end condition, using arrays where you aren't bounds
checking).
HTHs.
== 3 of 4 ==
Date: Wed, Nov 25 2009 3:44 pm
From: "carl"
"Daniel Pitts" <newsgroup.spamfilter@virtualinfinity.net> wrote in message
news:vcjPm.771$y%5.435@newsfe03.iad...
> carl wrote:
>>
>> "none" <none@none.none> wrote in message
>> news:Xns9CCE7815D6F3Enonenonenone@69.16.186.8...
>>> carl wrote:
>>>
>>>> Is it possible to stress a function to much with to many calls?
>>>
>>> No, as long as it returns each time.
>>>
>>>
>>>> But when I run the code I get the error:
>>>>
>>>> HEAP CORRUPTION DETECTED:after Normal block(#107261) at 0x020A44E0.
>>>> CRT detected that the application wrote to memory after end of heap
>>>> buffer.
>>>
>>> There is useful information in this error message:
>>>
>>> 1) The heap is what's corrupted (not the stack).
>>> 2) The block number.
>>> 3) The address (may or may not be useful).
>>>
>>> You've allocated something on the heap, probably an array of something,
>>> and
>>> your code has walked "off the end" of that thing. There's no 100%
>>> guarantee that this is what happened, but it's very likely. It's also
>>> possible that you have some completely bogus pointer that ended up with
>>> a
>>> random value in it, and that random value just happened to be
>>> "0x020A44E0",
>>> but I'd assume the other case first.
>>>
>>> Other helpful information would be:
>>>
>>> - Does your program allocate memory in exactly the same order every
>>> time?
>>> - Does the error message look the same every time (or at least, is the
>>> block number the same every time)?
>>>
>>> If the answer to both is "yes," then you can use that block number
>>> (107261)
>>> to catch exactly which allocation is being corrupted. There's a Visual
>>> Studio macro that will break on a specific heap allocation. I don't
>>> remember the name of it right now, but Google does.
>>
>> Ok I found something here (using the variable _crtBreakAlloc):
>>
>> http://www.tek-tips.com/viewthread.cfm?qid=1366567&page=17
>>
>> but since the number changes each time (so does the error message) I
>> cannot really see how I can use that approach. I have tried debugging my
>> way through the calls but it never happens the same time.
>>
>> It seems that the only solution is to write my application from scratch
>> without using any stl container. But before doing that I would be very
>> interested if someone had alternative plan to find this error.
>>
>> I am beginning to understand why java is the language used by companies
>> in the real world!
> Why without using any STL container? Its likely that your error is outside
> the use of the STL container, not because of it.
>
> Make sure that you aren't leaking any memory (every new has a delete,
> every new[] has a delete[]), Make sure you aren't overwriting memory you
> don't own (pointer arithmatic that might be one-off, using iterators
> without checking the end condition, using arrays where you aren't bounds
> checking).
>
> HTHs.
I am not using new and delete. I am passing objects as references to my
function which has always worked fine.
But now I got a new error message that says:
Debug Assertion Failed!
...
...
File G:\Programs\Microsoft Visual Studio 9.0\VC\include\vector Line: 70
Expression: ("_Pvector == NULL (((_Myvec
*)_Pvector)->_Myfirst <=_Ptr && _Ptr <= ((_Myvec
*)_Pvector)->_Mylast)",0)
If I open this file "vector" in the above VS dir around line 70 looks like
this:
#if _HAS_ITERATOR_DEBUGGING
_Vector_const_iterator(_Tptr _Ptr, const _Container_base *_Pvector)
{ // construct with pointer _Ptr
_SCL_SECURE_VALIDATE(_Pvector == NULL || (((_Myvec *)_Pvector)->_Myfirst
<= _Ptr && _Ptr <= ((_Myvec *)_Pvector)->_Mylast));
this->_Adopt(_Pvector);
_Myptr = _Ptr;
}
But I cannot really make much sense out of this.
== 4 of 4 ==
Date: Wed, Nov 25 2009 3:57 pm
From: "carl"
"carl" <carl@.com> wrote in message
news:4b0dc17c$0$270$14726298@news.sunsite.dk...
>
> "Daniel Pitts" <newsgroup.spamfilter@virtualinfinity.net> wrote in message
> news:vcjPm.771$y%5.435@newsfe03.iad...
>> carl wrote:
>>>
>>> "none" <none@none.none> wrote in message
>>> news:Xns9CCE7815D6F3Enonenonenone@69.16.186.8...
>>>> carl wrote:
>>>>
>>>>> Is it possible to stress a function to much with to many calls?
>>>>
>>>> No, as long as it returns each time.
>>>>
>>>>
>>>>> But when I run the code I get the error:
>>>>>
>>>>> HEAP CORRUPTION DETECTED:after Normal block(#107261) at 0x020A44E0.
>>>>> CRT detected that the application wrote to memory after end of heap
>>>>> buffer.
>>>>
>>>> There is useful information in this error message:
>>>>
>>>> 1) The heap is what's corrupted (not the stack).
>>>> 2) The block number.
>>>> 3) The address (may or may not be useful).
>>>>
>>>> You've allocated something on the heap, probably an array of something,
>>>> and
>>>> your code has walked "off the end" of that thing. There's no 100%
>>>> guarantee that this is what happened, but it's very likely. It's also
>>>> possible that you have some completely bogus pointer that ended up with
>>>> a
>>>> random value in it, and that random value just happened to be
>>>> "0x020A44E0",
>>>> but I'd assume the other case first.
>>>>
>>>> Other helpful information would be:
>>>>
>>>> - Does your program allocate memory in exactly the same order every
>>>> time?
>>>> - Does the error message look the same every time (or at least, is the
>>>> block number the same every time)?
>>>>
>>>> If the answer to both is "yes," then you can use that block number
>>>> (107261)
>>>> to catch exactly which allocation is being corrupted. There's a Visual
>>>> Studio macro that will break on a specific heap allocation. I don't
>>>> remember the name of it right now, but Google does.
>>>
>>> Ok I found something here (using the variable _crtBreakAlloc):
>>>
>>> http://www.tek-tips.com/viewthread.cfm?qid=1366567&page=17
>>>
>>> but since the number changes each time (so does the error message) I
>>> cannot really see how I can use that approach. I have tried debugging my
>>> way through the calls but it never happens the same time.
>>>
>>> It seems that the only solution is to write my application from scratch
>>> without using any stl container. But before doing that I would be very
>>> interested if someone had alternative plan to find this error.
>>>
>>> I am beginning to understand why java is the language used by companies
>>> in the real world!
>> Why without using any STL container? Its likely that your error is
>> outside the use of the STL container, not because of it.
>>
>> Make sure that you aren't leaking any memory (every new has a delete,
>> every new[] has a delete[]), Make sure you aren't overwriting memory you
>> don't own (pointer arithmatic that might be one-off, using iterators
>> without checking the end condition, using arrays where you aren't bounds
>> checking).
>>
>> HTHs.
>
> I am not using new and delete. I am passing objects as references to my
> function which has always worked fine.
>
> But now I got a new error message that says:
>
> Debug Assertion Failed!
>
> ...
> ...
>
> File G:\Programs\Microsoft Visual Studio 9.0\VC\include\vector Line: 70
>
> Expression: ("_Pvector == NULL (((_Myvec
> *)_Pvector)->_Myfirst <=_Ptr && _Ptr <= ((_Myvec
> *)_Pvector)->_Mylast)",0)
>
>
> If I open this file "vector" in the above VS dir around line 70 looks like
> this:
>
> #if _HAS_ITERATOR_DEBUGGING
> _Vector_const_iterator(_Tptr _Ptr, const _Container_base *_Pvector)
> { // construct with pointer _Ptr
> _SCL_SECURE_VALIDATE(_Pvector == NULL || (((_Myvec *)_Pvector)->_Myfirst
> <= _Ptr && _Ptr <= ((_Myvec *)_Pvector)->_Mylast));
> this->_Adopt(_Pvector);
> _Myptr = _Ptr;
> }
>
>
> But I cannot really make much sense out of this.
Hm I think I am getting closer. Now what fails is this function:
void search(MeasurementVectorType & queryPoint, double radius,
NeighborContainerType & neighborsContainer) {
typename TreeType::InstanceIdentifierVectorType neighbors;
tree->Search(queryPoint, radius, neighbors);
Now if I ignore the first argument and just create a local variable that I
pass to the tree->Search() function it no longer get the error!
void search(MeasurementVectorType & queryPoint, double radius,
NeighborContainerType & neighborsContainer) {
typename TreeType::InstanceIdentifierVectorType neighbors;
MeasurementVectorType mv;
tree->Search(mv, radius, neighbors);
//tree->Search(queryPoint, radius, neighbors);
The problem is that I kinda need to pass the argument on to the search
function...
Is it possible from the above very limited code fragments to deduce what
might be wrong?
==============================================================================
TOPIC: Why do some code bases don't use exceptions?
http://groups.google.com/group/comp.lang.c++/t/c255001068888229?hl=en
==============================================================================
== 1 of 11 ==
Date: Wed, Nov 25 2009 3:30 pm
From: "dragan"
James Kanze wrote:
> On Nov 25, 10:46 am, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> On Nov 22, 6:25 am, "dragan" <spambus...@prodigy.net> wrote:
>>>> James Kanze wrote:
>>>>> On Nov 21, 2:57 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>>>> James Kanze <james.ka...@gmail.com> wrote in
>>>>>> news:f37f1e13-cdcc-4144-
>>>>>> b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
>
>>>>>>> On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>>>>>> krel <k...@example.invalid> wrote
>>>>>>>> innews:hduq8e$4f9$1@news.eternal-september.org:
>
>>>>>> and badly designed feature".
>
>>>>>>>> In C++, there are surprisingly few "broken and badly
>>>>>>>> designed features".
>
>>>>>>> That's very arguable. The question isn't so much whether
>>>>>>> C++ does it right; it's usually a question of other
>>>>>>> languages not supporting it at all.
>
>>>>>>>> Non-empty exception specifications are one example,
>
>>>>>>> Broken and badly designed, or simply a more or less good
>>>>>>> solution without a problem?
>
>>>>>> I would say broken and badly designed as they solve even the
>>>>>> perceived problem inadequately (app termination is not an
>>>>>> adequate solution imo, and catch(...) is better than using a
>>>>>> global unexpected handler).
>
>>>>> What is the perceived problem? And why is aborting (as a
>>>>> default behavior) a bad solution?
>
>>>> I've watched these threads before and found that they go
>>>> around and around. The reason is because you all are jumping
>>>> the gun seeking the "one and only" thing instead of being
>>>> patient and doing some research. Error handling is
>>>> application-specific.
>
>>> Even within a single application, different types of errors will
>>> require different types of handling.
>
>> But that was my point: "one and only" mechanism is the
>> "looking for the silver bullet" approach.
>
> So we agree. (On that, at least.)
>
>>> For that matter, the same type of error may require
>>> different handling in different contexts: a write error in a
>>> log file should probably be ignored; a write error in the
>>> program output (e.g. when writing the object file in a
>>> compiler) should probably result in the program terminating
>>> with an error status (after clean-up---I can't think of any
>>> case where a write error should result in an abort).
>
>>>> Without a well-defined problem, discussions get no where
>>>> toward solution and no one learns anything. James, you
>>>> said, "aborting is not necessarily bad". Well, of course
>>>> not. It depends on the application.
>
>>> Which is what I said. Most of the time, aborting is the
>>> appropriate reaction,
>
>> Reaction to what is the question. You must have something(s)
>> specific in mind.
>
> When you detect a coding error (a violation of a precondition,
> for example), aborting is *usually* the most appropriate
> reaction. Not aborting should only be done in explicit cases,
> where you understand the issues and are prepared to cope with
> them.
>
>>> and it is the obvious choice for a default action,
>
>> Along with logging, backtracing, notification, perhaps
>> restarting from checkpoint, maybe rollback, maybe switching to
>> redundant system 3... Application-specific. Perhaps the only
>> place abort is appropriate is in language newsgroups! ;)
>
> Abort is generally the most effective means fo switching to the
> backup system. It's the generally accepted means of reacting to
> software errors. More generally, if a program is doing the
> wrong thing, it generally should be stopped as quickly as
> possible, so that it doesn't do more of the wrong thing.
>
>>> but I'm well aware that there are exceptions: game programs,
>>> for example, and possibly light weight GUI client code.
>
>>>> It is but one of many avenues to take upon detecting
>>>> (detection is a key concept) that a potentially
>>>> "disastrous" thing will occur unless processing doesn't
>>>> take a side road immediately. If you believe what I just
>>>> said, and I believe you do, then you see why I question
>>>> those who consider C++ exceptions as an error management
>>>> strategy. C++ exceptions are JUST a mechanism. NOT a
>>>> solution to the error management problem.
>
>>> I don't think anyone has reasonably argued that exceptions
>>> are an "error managment strategy". First, as you say, they
>>> are a just a mechanism---a tool to implement a strategy, and
>>> not a strategy. And second, they only address one aspect of
>>> error management: reporting.
>
>> They don't do that at all. Exceptions are an error propogation
>> mechanism in C++,
>
> Error propagation, error reporting: same thing, really.
Completely different. Reporting = things like displaying an error dialogbox,
writing to an event log, sending a backtrace to the admin or developer...
Propogation is just that: propogating an error from the detection point to
the handling point. That may be as simple as returning an error code back up
the call stack or as not-simple as jumping to the handler with an error
object off some kind via an exception mechanism.
Reporting is a "handling" strategy. Propogation is more just about
mechanisms.
> Propagation is probably the better word, though; it just slipped
> my mind.
>
>> Reporting comes after exceptions have done their part.
>
> I think we're talking about different things. I was talking
> about "reporting" the error to the location in the code where it
> would be handled.
That isn't reporting. It's propogation. You are using terminology
incorrectly and that is sure to confuse.
>
>>> Error management involves three aspects:
>>> detection, reporting and handling.
>
>> There is also: error definition & categorization and propogation.
>
> Propagation is reporting, at least in the sense I was using the
> word.
That is incorrect.
> Categorization is probably part of detection.
No. Perhaps "classification" is a better word for clarification.
>
>> So I see at least 5 things. If I ponder a bit more here, I may
>> come up with a few more things.
>
> You can certainly define it a lot finer, and there's often a lot
> in each of those words.
It's not a question of more granularity. The issue at hand is recognizing
the larger scope of error management vs. just a subset of the technical
constituents of it.
> My basic idea was that you have to
> think of errors in three contexts: where you're going to detect
> the error (e.g. how, what type of error, etc.), where you're
> going to treat it (log it, retry, etc.), and in between, where
> you have to propagate it from where it was detected to where it
> is to be handled.
>
>> I do know that I wouldn't call simply
>> detection/handling/reporting "error management" though, and
>> that's not what I meant when I used the terms. Documentation,
>> communication and enforcement of the prescribed or chosen
>> strategies and patterns are a few more (see, I came up with a
>> few more in 1 minute). "Error management" as simply
>> detection/handling/reporting? Nah. No way.
>
> At the coding level:-).
Not even at the coding level. To say detect/handle/report is an error of
omission even at the coding level.
> I totally agree, my categorization
> doesn't cover things like documentation and communication (to
> other programmers), and they are very important.
>
>>> Exceptions don't help in detection, nor in handling. They
>>> just simplify reporting when the error must be handled far
>>> up the call stack.
>
>> That's propogation, not reporting.
>
> Two words, same thing.
Not the same at all. Orthogonal.
>
>>> (Which means that they are of no use when the error must be
>>> handled immediately.)
>
>> Catch = handle error
>
> Yes, but having to write a try block, then a catch statement, is
> more complicated than an if, if you want to process the error
> immediately. You can use an exception, but it's about like
> pealing a grape with a butcher's cleaver.
To say "they are of no use at all" is incorrect. Someone may prefer that
style (those who think one mechanism only is nirvana comes to mind).
== 2 of 11 ==
Date: Wed, Nov 25 2009 3:59 pm
From: legalize+jeeves@mail.xmission.com (Richard)
[Please do not mail me a copy of your followup]
"Alf P. Steinbach" <alfps@start.no> spake the secret code
<hejsud$83s$1@news.eternal-september.org> thusly:
>* James Kanze:
>>
>> Yes, but having to write a try block, then a catch statement, is
>> more complicated than an if, if you want to process the error
>> immediately. You can use an exception, but it's about like
>> pealing a grape with a butcher's cleaver.
>
>Off the cuff,
>
>#define CATCHX( result, f, args ) \
> do { \
> try { \
> result = f args; \
> } catch( std::exception const& x ) { \
> result.set_x( x ); \
> } \
> } while( false )
....which is a good example of why macros are evil.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
== 3 of 11 ==
Date: Wed, Nov 25 2009 4:10 pm
From: "Alf P. Steinbach"
* Richard:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alfps@start.no> spake the secret code
> <hejsud$83s$1@news.eternal-september.org> thusly:
>
>> * James Kanze:
>>> Yes, but having to write a try block, then a catch statement, is
>>> more complicated than an if, if you want to process the error
>>> immediately. You can use an exception, but it's about like
>>> pealing a grape with a butcher's cleaver.
>> Off the cuff,
>>
>> #define CATCHX( result, f, args ) \
>> do { \
>> try { \
>> result = f args; \
>> } catch( std::exception const& x ) { \
>> result.set_x( x ); \
>> } \
>> } while( false )
>
> ....which is a good example of why macros are evil.
Mostly macros are evil, but your comment for this case makes no sense to me.
Would you care to elaborate a bit on exactly what you mean (if anything).
Cheers,
- Alf
== 4 of 11 ==
Date: Wed, Nov 25 2009 5:35 pm
From: "dragan"
peter koch wrote:
> On 25 Nov., 12:14, "dragan" <spambus...@prodigy.net> wrote:
>> peter koch wrote:
>>> On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>>
>>> When not using exceptions, you more or less write the hidden error-
>>> returning path explicitly in your code. In my experience, this often
>>> gives a signicifand increase in source-code size
>>
>> Can you give some numbers?
>
> Not any exact ones, but I have been working in places where exceptions
> were not used (due to some code being quite old and no one caring
> about fixing). Code there typically looked something like:
>
> int func(parm p,std::string &result)
> {
> std::string s;
> int error;
>
> result = func_1(parm,s);
> if (error != OK)
> {
> return error;
> }
> error = func_2(s);
> if (error != OK)
> {
> return error;
> }
> result = s;
> return OK;
> }
>
#define ERROR (-1)
#define OK (0)
#define Try(x) if(x != OK) goto unwind;
#define CatchAll unwind:
// Not the same function as you have cuz I
// don't want to figure out what you were
// doing hypothetically. Adequate for illustration.
// Many variations on the below theme exist
// including masking of setjmp/longjmp etc.
//
int func (parm p)
{
std::string s;
Try(func_1(p, s))
Try(func_2(s))
return OK;
CatchAll
// do cleanup, rollback, recovery, etc. as appropriate
return ERROR;
}
Macros are your friend to make the language conform to YOUR preferences! :)
> instead of the much simpler
>
> std::string func(parm)
> {
> return func_2(func_1(parm));
> }
>
> This example is a bit exaggerated, as the function body does not do
> very much, but it not atypical. One side effect of this style was that
> functions typically returned a status, making calling the functions
> more complicated. My guess is that the code length was at least
> doubled this way. The above function has a 10-fold increase in lines
> (disregarding braces), and it is not that easy to figure out what is
> going on.
>
>>
>>> and also obscures the
>>> algorithm.
>>
>> I don't see why. Hide the details with macros.
>
> First that would require you to use macroes, which can lead to more
> errors. Secondly: How would you hide the details in the code above?
>>
>>> This is a source of bugs,
>>
>> Yes, probably, without any formalism such as macros. I guess you
>> could go a step further and write a preprocessor do do some
>> instrumentation for you also.
>
> Yes. You could also use another language. If you get so far out that
> you need to write a preprocessor that proposition might acutally be
> worth following.
>
>>
>>> and the effort required to
>>> explicite the path is normally much larger than the effort used to
>>> write exception safe code.
>>
>> I think that would be the same or maybe harder with exceptions
>> because of the interactions with other C++ stuff (not that I can
>> name that other stuff though). Ensuring cleanup and RAII and call
>> order and the like is an on-going thing no matter what your EH
>> strategies are.
>
> As you, I see no interaction with other C++ stuff. Exceptions fit
> perfectly with C++.
>
> /Peter
== 5 of 11 ==
Date: Wed, Nov 25 2009 5:44 pm
From: "dragan"
James Kanze wrote:
> On Nov 25, 11:03 am, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> On Nov 23, 8:09 pm, "io_x" <a...@b.c.invalid> wrote:
>>>> "dragan" ha scritto nel
>>>> messaggionews:3XINm.36496$Wd1.22761@newsfe15.iad... [...]
>>>> 12. they not have "the written form"
>
>>>> "if(a/b > c) u=z;"
>
>>>> if "a/b" throw one exception
>>>> in the plain text above;
>>>> there is not a single char in
>>>> "if(a/b > c) u=z;"
>>>> that show this chanches
>
>>> That's probably because there is no such chance:-).
>
>>> But seriously, this is the one real problem with exceptions. And
>>> the possibility of exceptions does require some additional
>>> thought. But the problem has been addressed, and we do know
>>> what has to be done.
>
>>>> 13. the "exception header" not "know" the point of code
>>>> where is the problem. Instead returning the error-result of the
>>>> function the program know where is the error
>
>>> That's the whole point of exceptions. They're for the sort of
>>> problems where it doesn't matter where the problem occured; the
>>> handling is the same. If you run out of memory processing a
>>> request, for example, it doesn't matter where you were in the
>>> processing when you ran out; you just abort the request (but not
>>> the process) with an error message, and continue.
>
>> You seem to be big on aborting.
>
> Attention about word use. There's aborting (in the sense of
> calling abort()), and aborting (in the more general sense, of
> immediately terminating some action that you were in the process
> of doing). In this case, I'm using the other sense: say you've
> received a request on your LDAP server, and you run out of
> memory trying to service it (because it requires interpreting
> some obscenely complicated filter expression, for example).
> When you detect the lack of memory, you're down in some really
> deap parsing function, executing operator new. You (or rather
> the system) raises an std::bad_alloc exception, which you catch
> at the top level, and abort the request (not the program),
> returning an error message of "insufficient resources", or the
> like.
Ah. Bad choice of word then to describe that. I think most people who see
"abort" think exit the process or terminate the thread. Even in your example
above though, I wouldn't expect abort to occur unless the situation has been
going on for some time. The server should have preallocated some resources
for use in such situations.
>
>> A very valid pattern is fixing the problem and resuming.
>
> If that's a valid reaction to the error, aborting isn't the
> answer. If the error was a coding error, you can't fix the
> source, recompile the code, and resume, so you abort. If the
> error was insufficient memory due to an overly complicated
> request, you can't simplify the request and resume: you abort
> the operation. (On receiving an "insufficient resources" error,
> of course, the client may try a simpler request.)
>
>> Some version of Windows expands the stack that way: a
>> violation occurs when trying to push beyond the current stack
>> frame and the system catches the error, expands the stack by
>> 4k and continues processing.
>
> (Isn't that how most systems work?
I don't know.
> That's more or less the way
> the old Berkley kernel worked on Sun 3's, and IIRC, PDP-11's
> memory manager unit was designed expressedly to support
> something like this, back in the days before virtual memory.)
>
> I'm not too sure how that's relevant to user code, however. Are
> you saying that if you get std::bad_alloc, you should try to get
> more memory?
See my comment above.
>
> Frankly, out of memory is a special case, and most of the
> programs I've worked on installed a new_handler to abort in such
> cases. Not all, however, and particularly on transaction based
> systems where transactions can require a lot of memory, it often
> makes sense to just abort the transation. I can't think of much
> else you could do: call some system routine to create more
> virtual memory?
Preallocate for use in those times. Could be from an entirely different heap
or something. Or hardware even: a mem card in a PCI-X slot ... possibilities
are endless. EH is application-specific.
> That often requires priviledged access. And
> if the insufficient memory was because you'd used up your
> address space, rather than because the system didn't have any
> more memory to give you, it won't help anyway. And you can do
> it from the new_handler (which provides resumption semantics).
== 6 of 11 ==
Date: Wed, Nov 25 2009 5:44 pm
From: legalize+jeeves@mail.xmission.com (Richard)
[Please do not mail me a copy of your followup]
"Alf P. Steinbach" <alfps@start.no> spake the secret code
<hekgtv$un9$1@news.eternal-september.org> thusly:
>* Richard:
>> [Please do not mail me a copy of your followup]
>>
>> "Alf P. Steinbach" <alfps@start.no> spake the secret code
>> <hejsud$83s$1@news.eternal-september.org> thusly:
>>
>>> * James Kanze:
>>>> Yes, but having to write a try block, then a catch statement, is
>>>> more complicated than an if, if you want to process the error
>>>> immediately. You can use an exception, but it's about like
>>>> pealing a grape with a butcher's cleaver.
>>> Off the cuff,
>>>
>>> #define CATCHX( result, f, args ) \
>>> do { \
>>> try { \
>>> result = f args; \
>>> } catch( std::exception const& x ) { \
>>> result.set_x( x ); \
>>> } \
>>> } while( false )
>>
>> ....which is a good example of why macros are evil.
>
>Mostly macros are evil, but your comment for this case makes no sense to me.
>
>Would you care to elaborate a bit on exactly what you mean (if anything).
Macros hiding loops, returns or try/catch blocks are evil IMO.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
== 7 of 11 ==
Date: Wed, Nov 25 2009 6:26 pm
From: "Alf P. Steinbach"
* Richard:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alfps@start.no> spake the secret code
> <hekgtv$un9$1@news.eternal-september.org> thusly:
>
>> * Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> "Alf P. Steinbach" <alfps@start.no> spake the secret code
>>> <hejsud$83s$1@news.eternal-september.org> thusly:
>>>
>>>> * James Kanze:
>>>>> Yes, but having to write a try block, then a catch statement, is
>>>>> more complicated than an if, if you want to process the error
>>>>> immediately. You can use an exception, but it's about like
>>>>> pealing a grape with a butcher's cleaver.
>>>> Off the cuff,
>>>>
>>>> #define CATCHX( result, f, args ) \
>>>> do { \
>>>> try { \
>>>> result = f args; \
>>>> } catch( std::exception const& x ) { \
>>>> result.set_x( x ); \
>>>> } \
>>>> } while( false )
>>> ....which is a good example of why macros are evil.
>> Mostly macros are evil, but your comment for this case makes no sense to me.
>>
>> Would you care to elaborate a bit on exactly what you mean (if anything).
>
> Macros hiding loops, returns or try/catch blocks are evil IMO.
OK.
Then observe:
* The macro doesn't hide a try-catch block. Its name makes it abundantly
clear that it catches an exception.
* The macro doesn't contain a return.
* The macro doesn't contain a loop. Or well, there is what might look like
a loop, but it's just an old well-known syntactical device, to make the
macro invocation function-like wrt. C++ semicolon rules, especially in
if-else constructions.If you're unfamiliar with this then you've learned
something new! :-)
So, none of your evilness indicators are present.
Cheers & hth.,
- Alf
PS: By the way, much of this macro stuff will be unnecessary in C++0x, which
much better supports argument forwarding.
== 8 of 11 ==
Date: Wed, Nov 25 2009 7:42 pm
From: legalize+jeeves@mail.xmission.com (Richard)
[Please do not mail me a copy of your followup]
We can agree to disagree, but I don't like your macro.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
== 9 of 11 ==
Date: Wed, Nov 25 2009 11:46 pm
From: Paavo Helde
"dragan" <spambuster@prodigy.net> wrote in
news:gXkPm.25025$kY2.2653@newsfe01.iad:
> peter koch wrote:
>> On 25 Nov., 12:14, "dragan" <spambus...@prodigy.net> wrote:
>>> peter koch wrote:
>>>> On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>>>
>>>> When not using exceptions, you more or less write the hidden error-
>>>> returning path explicitly in your code. In my experience, this
>>>> often gives a signicifand increase in source-code size
>>>
>>> Can you give some numbers?
>>
>> Not any exact ones, but I have been working in places where
>> exceptions were not used (due to some code being quite old and no one
>> caring about fixing). Code there typically looked something like:
>>
>> int func(parm p,std::string &result)
>> {
>> std::string s;
>> int error;
>>
>> result = func_1(parm,s);
>> if (error != OK)
>> {
>> return error;
>> }
>> error = func_2(s);
>> if (error != OK)
>> {
>> return error;
>> }
>> result = s;
>> return OK;
>> }
>>
>
> #define ERROR (-1)
> #define OK (0)
If you are happy writing the above two lines, it shows clearly IMO that
you have never done any large scale development in C++. Consequence: you
have no idea what you are talking about when ranting about exceptions. No
offense, I just want to put things in a more correct perspective.
>
> #define Try(x) if(x != OK) goto unwind;
> #define CatchAll unwind:
>
> // Not the same function as you have cuz I
> // don't want to figure out what you were
> // doing hypothetically. Adequate for illustration.
> // Many variations on the below theme exist
> // including masking of setjmp/longjmp etc.
> //
> int func (parm p)
> {
> std::string s;
> Try(func_1(p, s))
> Try(func_2(s))
> return OK;
>
> CatchAll
> // do cleanup, rollback, recovery, etc. as appropriate
> return ERROR;
> }
>
> Macros are your friend to make the language conform to YOUR
> preferences! :)
A Real Programmer (tm) can write Fortran in any language! Seriously, this
is not really C++. A dedicated cleanup block more reminds Java. And it
still has 6 times more lines than the C++ solution.
Paavo
>
>> instead of the much simpler
>>
>> std::string func(parm)
>> {
>> return func_2(func_1(parm));
>> }
== 10 of 11 ==
Date: Thurs, Nov 26 2009 12:12 am
From: Vladimir Jovic
dragan wrote:
> peter koch wrote:
>> On 25 Nov., 12:14, "dragan" <spambus...@prodigy.net> wrote:
>>> peter koch wrote:
>>>> On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>>>> When not using exceptions, you more or less write the hidden error-
>>>> returning path explicitly in your code. In my experience, this often
>>>> gives a signicifand increase in source-code size
>>> Can you give some numbers?
>> Not any exact ones, but I have been working in places where exceptions
>> were not used (due to some code being quite old and no one caring
>> about fixing). Code there typically looked something like:
>>
>> int func(parm p,std::string &result)
>> {
>> std::string s;
>> int error;
>>
>> result = func_1(parm,s);
>> if (error != OK)
>> {
>> return error;
>> }
>> error = func_2(s);
>> if (error != OK)
>> {
>> return error;
>> }
>> result = s;
>> return OK;
>> }
>>
>
> #define ERROR (-1)
> #define OK (0)
>
> #define Try(x) if(x != OK) goto unwind;
> #define CatchAll unwind:
>
> // Not the same function as you have cuz I
> // don't want to figure out what you were
> // doing hypothetically. Adequate for illustration.
> // Many variations on the below theme exist
> // including masking of setjmp/longjmp etc.
> //
> int func (parm p)
> {
> std::string s;
> Try(func_1(p, s))
> Try(func_2(s))
> return OK;
>
> CatchAll
> // do cleanup, rollback, recovery, etc. as appropriate
> return ERROR;
> }
>
A function (or a method) has to have the same crap. This remind more of
C, then C++.
btw take a look at this:
http://www.google.com/search?q=macros+are+evil&btnG=Search+the+C%2B%2B+FAQ&sitesearch=www.parashift.com
Once you really try exceptions, you will laugh at this example.
--
ultrasound www.ezono.com
== 11 of 11 ==
Date: Thurs, Nov 26 2009 12:14 am
From: Vladimir Jovic
Vladimir Jovic wrote:
> dragan wrote:
>> peter koch wrote:
>>> On 25 Nov., 12:14, "dragan" <spambus...@prodigy.net> wrote:
>>>> peter koch wrote:
>>>>> On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>>>>> When not using exceptions, you more or less write the hidden error-
>>>>> returning path explicitly in your code. In my experience, this often
>>>>> gives a signicifand increase in source-code size
>>>> Can you give some numbers?
>>> Not any exact ones, but I have been working in places where exceptions
>>> were not used (due to some code being quite old and no one caring
>>> about fixing). Code there typically looked something like:
>>>
>>> int func(parm p,std::string &result)
>>> {
>>> std::string s;
>>> int error;
>>>
>>> result = func_1(parm,s);
>>> if (error != OK)
>>> {
>>> return error;
>>> }
>>> error = func_2(s);
>>> if (error != OK)
>>> {
>>> return error;
>>> }
>>> result = s;
>>> return OK;
>>> }
>>>
>>
>> #define ERROR (-1)
>> #define OK (0)
>>
>> #define Try(x) if(x != OK) goto unwind;
>> #define CatchAll unwind:
>>
>> // Not the same function as you have cuz I
>> // don't want to figure out what you were
>> // doing hypothetically. Adequate for illustration.
>> // Many variations on the below theme exist
>> // including masking of setjmp/longjmp etc.
>> //
>> int func (parm p)
>> {
>> std::string s;
>> Try(func_1(p, s))
>> Try(func_2(s))
>> return OK;
>>
>> CatchAll
>> // do cleanup, rollback, recovery, etc. as appropriate
>> return ERROR;
>> }
>>
>
> A function (or a method) has to have the same crap. This remind more of
> C, then C++.
Off course, this should have been:
A function (or a method) *that is using this function* has to have the
same crap. This remind more of C, then C++.
--
ultrasound www.ezono.com
==============================================================================
TOPIC: I don't have to tell you...
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Nov 25 2009 5:28 pm
From: Howard Beale
Alf P. Steinbach wrote:
> Jeez, where do you pick up such misconceptions?
What's miconceived?
C++ FAQ [23.5]:
- "When my base class's constructor calls a virtual function on its this
object, why doesn't my derived class's override of that virtual function
get invoked?"
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.5
http://www.artima.com/cppsource/nevercall.html
- "Never Call Virtual Functions during Construction or Destruction"
One could argue that it's good thing for C++ not to allow this, but I'd
simply point out that more recent languages don't have a problem with it:
http://www.andymcm.com/csharpfaq.htm#3.9
Yes, I know that it's recommended (in C#) not to call virtual functions
from constructors / destructors, but it is supported and will work the way
you expect. The danger is just that someone else overriding your virtual
function may unknowingly alter the behavior of construction / destruction.
== 2 of 2 ==
Date: Wed, Nov 25 2009 6:37 pm
From: "Alf P. Steinbach"
* Howard Beale:
> Alf P. Steinbach wrote:
>
>> Jeez, where do you pick up such misconceptions?
>
> What's miconceived?
>
> C++ FAQ [23.5]:
> - "When my base class's constructor calls a virtual function on its this
> object, why doesn't my derived class's override of that virtual function
> get invoked?"
> http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.5
This is good. It's the official C++ FAQ. Since you're using it as authority I
mention that some of that stuff further down originated with me. :-)
> http://www.artima.com/cppsource/nevercall.html
> - "Never Call Virtual Functions during Construction or Destruction"
This, however, is total bullshit.
In the technical sense, that is.
Thanks for pointing it out!
> One could argue that it's good thing for C++ not to allow this, but I'd
> simply point out that more recent languages don't have a problem with it:
>
> http://www.andymcm.com/csharpfaq.htm#3.9
On the contrary, Java and C# have very dangerous problems with virtual calls
from constructors.
It's one of the most common bugs in Java applications (you can get a subclass
method invoked before the subclass object has been initialized).
In C++ virtual calls from constructors are safe, with one exception, namely a
call of a pure virtual.
The FAQ explains how it works in C++, but just if you don't want to spend on
time on finding that:
In C++, during a constructor of type T, the '*this' object is of most derived
type (dynamic type) T -- so everything works as the author of class T expects,
no matter whether this constructor call originated from some subclass.
> Yes, I know that it's recommended (in C#) not to call virtual functions
> from constructors / destructors, but it is supported and will work the way
> you expect. The danger is just that someone else overriding your virtual
> function may unknowingly alter the behavior of construction / destruction.
It's a bit more dangerous that in Java/C#; see above.
Cheers & hth.,
- Alf
==============================================================================
TOPIC: Math/CompSci Interview Question - Thoughts?
http://groups.google.com/group/comp.lang.c++/t/a1cffd71c99a2dd0?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Nov 25 2009 7:28 pm
From: mike3
On Nov 25, 2:33 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> mike3 <mike4...@yahoo.com> writes:
> > On Nov 25, 12:06 am, "John W. Krahn" <some...@example.com> wrote:
> >> Richard Heathfield wrote:
> >> > In
> >> > <805a7a21-f99b-4eb9-abb0-fbde47cb9...@k19g2000yqc.googlegroups.com>,
> >> > mike3 wrote:
>
> >> > <snip>
>
> >> >> Oh yes, and I forgot to add: how does one train the "symbolic"
> >> >> thinking?
>
> >> > Step 1: obtain a pointy stick.
>
> >> Or some fresh fruit.
>
> > What's the point here?
>
> http://www.leftinthedark.org.uk/
>
So what's the pointy stick for, then?
== 2 of 2 ==
Date: Wed, Nov 25 2009 7:36 pm
From: mike3
On Nov 25, 8:28 pm, mike3 <mike4...@yahoo.com> wrote:
> On Nov 25, 2:33 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>
>
> > mike3 <mike4...@yahoo.com> writes:
> > > On Nov 25, 12:06 am, "John W. Krahn" <some...@example.com> wrote:
> > >> Richard Heathfield wrote:
> > >> > In
> > >> > <805a7a21-f99b-4eb9-abb0-fbde47cb9...@k19g2000yqc.googlegroups.com>,
> > >> > mike3 wrote:
>
> > >> > <snip>
>
> > >> >> Oh yes, and I forgot to add: how does one train the "symbolic"
> > >> >> thinking?
>
> > >> > Step 1: obtain a pointy stick.
>
> > >> Or some fresh fruit.
>
> > > What's the point here?
>
> >http://www.leftinthedark.org.uk/
>
> So what's the pointy stick for, then?
To get fruit off the trees? What? Hmm.
==============================================================================
TOPIC: ddraw.h in Linux
http://groups.google.com/group/comp.lang.c++/t/0fa46d75811421c4?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Nov 25 2009 10:44 pm
From: ahso
doouh I can use typedef...
==============================================================================
TOPIC: DWORD and bool to binary
http://groups.google.com/group/comp.lang.c++/t/3ecc7dd1864c4bea?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Nov 25 2009 10:48 pm
From: ahso
Hi
any ideas on what to change?
if (ddsd.ddpfPixelFormat.dwFourCC == FOURCC_DXT1)
{
etc.
I get: "invalid operands of types 'DWORD' and 'bool' to binary
'operator|'"
Many thanks
Michael Sgier
==============================================================================
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