Exception Misconceptions
dragan
clc++m. Please add any commonly held/observed misconceptions about C++
exceptions or exceptions in general. Both mechanism and condition
misconceptions are fine. I'll start...
"Exceptions invoke all destructors while unwinding the stack."
I think that is probably incorrect, though I'm not a compiler writer so
can't say with high certainty that it is a misconception. I hypothesize that
the compiler introduces some kind of "jumps to the closing brace" and lets
the normal destruction of stack class objects happen. An explicit mechanism
that is part of the exception machinery that calls destructors? I don't
think so.
Armel
o2LTm.61979$de6....@newsfe21.iad...
brace" is not what you want to do: the return intruction would then be
executed, returning to the normal flow of program. you don't want that;
unless you have a special end of function testing if in normal or "exception
rewind" mode. most compilers will not want the penalty of this test.
if you want more insight on this question, you could ask on comp.compilers.
Regards
Armel
Bart van Ingen Schenau
And how does the mechanism that you describe fail to invoke the
destructors of the relevant stack-allocated objects?
The requirement is that all the objects that go out of scope as a
result of the jump from the throw statement to the catch handler must
be properly destructed. It does not matter what hoops the compiler
writer has to jump through to fulfill the requirement.
This could be a separate piece of code that consists only of
destructor calls (which means that for every object, there are at
least two sites from which the destructor can be called), or a scheme
like you describe. It is the end-result that matters.
Bart v Ingen Schenau
James Kanze
> I got the idea and material for this thread from the
> "high-class" ( ;) ) ng clc++m. Please add any commonly
> held/observed misconceptions about C++ exceptions or
> exceptions in general. Both mechanism and condition
> misconceptions are fine. I'll start...
> "Exceptions invoke all destructors while unwinding the stack."
> I think that is probably incorrect,
Well, certainly not all destructors. Just those of variables
which go out of scope.
> though I'm not a compiler writer so can't say with high
> certainty that it is a misconception. I hypothesize that the
> compiler introduces some kind of "jumps to the closing brace"
> and lets the normal destruction of stack class objects happen.
> An explicit mechanism that is part of the exception machinery
> that calls destructors? I don't think so.
You hypothesize wrong. The usual implementation (except maybe
for Microsoft) is to generate tables mapping code addresses to
clean up functions; the exception propagation code (in the
library) finds the frame pointer from the stack, uses the table
to find the clean up code, and calls it, for each stack frame.
I think some earlier compilers generated additional code in the
constructor to "register" the class, but the table method is
generally considered preferable, as it has almost no runtime
overhead until the exception is thrown.
--
James Kanze
dragan
> On Dec 9, 11:33 am, "dragan" <spambus...@prodigy.net> wrote:
>> I got the idea and material for this thread from the "high-class" (
>> ;) ) ng clc++m. Please add any commonly held/observed misconceptions
>> about C++ exceptions or exceptions in general. Both mechanism and
>> condition misconceptions are fine. I'll start...
>>
>> "Exceptions invoke all destructors while unwinding the stack."
>>
>> I think that is probably incorrect, though I'm not a compiler writer
>> so can't say with high certainty that it is a misconception. I
>> hypothesize that the compiler introduces some kind of "jumps to the
>> closing brace" and lets the normal destruction of stack class
>> objects happen. An explicit mechanism that is part of the exception
>> machinery that calls destructors? I don't think so.
>
> And how does the mechanism that you describe fail to invoke the
> destructors of the relevant stack-allocated objects?
It doesn't do it explicitly with a mechanism separate from the mechanism(s)
that are used even in the no-throw function.
>
> The requirement is that all the objects that go out of scope as a
> result of the jump from the throw statement to the catch handler must
> be properly destructed. It does not matter what hoops the compiler
> writer has to jump through to fulfill the requirement.
To YOU it doesn't matter you mean. Enquiring minds wanna know!
> This could be a separate piece of code that consists only of
> destructor calls (which means that for every object, there are at
> least two sites from which the destructor can be called), or a scheme
> like you describe. It is the end-result that matters.
To YOU it is all that matters. Try stepping out of your own skin sometime.
dragan
> On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
>> I got the idea and material for this thread from the
>> "high-class" ( ;) ) ng clc++m. Please add any commonly
>> held/observed misconceptions about C++ exceptions or
>> exceptions in general. Both mechanism and condition
>> misconceptions are fine. I'll start...
>
>> "Exceptions invoke all destructors while unwinding the stack."
>
>> I think that is probably incorrect,
>> certainty that it is a misconception. I hypothesize that the
>> compiler introduces some kind of "jumps to the closing brace"
>> and lets the normal destruction of stack class objects happen.
>> An explicit mechanism that is part of the exception machinery
>> that calls destructors? I don't think so.
>
> You hypothesize wrong. The usual implementation (except maybe
> for Microsoft) is to generate tables mapping code addresses to
> clean up functions; the exception propagation code (in the
> library) finds the frame pointer from the stack, uses the table
> to find the clean up code, and calls it, for each stack frame.
> I think some earlier compilers generated additional code in the
> constructor to "register" the class, but the table method is
> generally considered preferable, as it has almost no runtime
> overhead until the exception is thrown.
What is the mechanism and how does it work in the no-throw function case?
James Kanze
The mechanism is more or less what I described: for each
distinct set of objects to clean up, the compiler generates a
clean-up function, and puts its address in a table along with
the code addresses for which this function is valid. (This code
can be destructors or catch blocks. In the latter case, the
compiler also provides information concerning the types for
which the try block is valid.) When an exception is thrown, the
compiler calls code which walks back up the stack. For each
return address it finds, it looks up in the table what it has to
do, and does it.
Typically, the case of nothrow is treated by generating the same
code as if the function were wrapped in a try block, and
handling the error in a catch.
Other solutions are possible. Microsoft, for example, seems to
generate code which is executed in the case where the exception
isn't thrown, although I don't know what it's exact role is.
--
James Kanze
aku ankka
> Bart van Ingen Schenau wrote:
>
>
>
>
>
> > On Dec 9, 11:33 am, "dragan" <spambus...@prodigy.net> wrote:
> >> I got the idea and material for this thread from the "high-class" (
> >> ;) ) ng clc++m. Please add any commonly held/observed misconceptions
> >> about C++ exceptions or exceptions in general. Both mechanism and
> >> condition misconceptions are fine. I'll start...
>
> >> "Exceptions invoke all destructors while unwinding the stack."
>
> >> I think that is probably incorrect, though I'm not a compiler writer
> >> so can't say with high certainty that it is a misconception. I
> >> hypothesize that the compiler introduces some kind of "jumps to the
> >> closing brace" and lets the normal destruction of stack class
> >> objects happen. An explicit mechanism that is part of the exception
> >> machinery that calls destructors? I don't think so.
>
> > And how does the mechanism that you describe fail to invoke the
> > destructors of the relevant stack-allocated objects?
>
> It doesn't do it explicitly with a mechanism separate from the mechanism(s)
> that are used even in the no-throw function.
>
>
>
> > The requirement is that all the objects that go out of scope as a
> > result of the jump from the throw statement to the catch handler must
> > be properly destructed. It does not matter what hoops the compiler
> > writer has to jump through to fulfill the requirement.
>
> To YOU it doesn't matter you mean. Enquiring minds wanna know!
This is implementation specific detail, if you know how it works in,
for example, GCC 4.5 doesn't say anything about how it works in the
Visual Studio 2010. What matters, is that the compiler is conforming
to the standard.
Enquiring minds can use /Faout.asm or -S out.s compiler switch (or
equivalent) but that is compiler/toolchain specific knowledge.
>
> > This could be a separate piece of code that consists only of
> > destructor calls (which means that for every object, there are at
> > least two sites from which the destructor can be called), or a scheme
> > like you describe. It is the end-result that matters.
>
> To YOU it is all that matters. Try stepping out of your own skin sometime.-
That's correct. He was speaking for himself and the statement is 100%
accurate. Wow, you can read; that's very impressive!
=)
dragan
That is understood. That doesn't stop me wanting to know how it works
though. Don't you have something better to do that to try to curb someone's
appetite for knowledge?
> What matters, is that the compiler is conforming
> to the standard.
To YOU. Why don't you start your own threads about stuff you wanna know and
stay out of mine? Because you add no value!
>
> Enquiring minds can use /Faout.asm or -S out.s compiler switch (or
> equivalent) but that is compiler/toolchain specific knowledge.
Luckily, JK was cordial enough to answer the question instead of starting a
tirade of what is "on holy topic" and the like in this NG. :P
>
>
>>
>>> This could be a separate piece of code that consists only of
>>> destructor calls (which means that for every object, there are at
>>> least two sites from which the destructor can be called), or a
>>> scheme like you describe. It is the end-result that matters.
>>
>> To YOU it is all that matters. Try stepping out of your own skin
>> sometime.-
>
> That's correct. He was speaking for himself and the statement is 100%
> accurate. Wow, you can read; that's very impressive!
Just go away you big baby!
dragan
Are you saying that there then is NOT a distinct mechanism for exceptions
that does unwinding?
> for each
> distinct set of objects to clean up, the compiler generates a
> clean-up function, and puts its address in a table along with
> the code addresses for which this function is valid.
I hypothesized that there was no mechanism, separate from the case where
there are no exception elements in the code, (read NOT TWO mechanisms) to do
unwind explicitly for exceptions and tied explicitly ('distinctly' may be a
better word) to the exception machinery. Is that hypothesis right or wrong?
> (This code
> can be destructors or catch blocks. In the latter case, the
> compiler also provides information concerning the types for
> which the try block is valid.) When an exception is thrown, the
> compiler calls code which walks back up the stack. For each
> return address it finds, it looks up in the table what it has to
> do, and does it.
>
> Typically, the case of nothrow is treated by generating the same
> code as if the function were wrapped in a try block, and
> handling the error in a catch.
>
> Other solutions are possible. Microsoft, for example, seems to
> generate code which is executed in the case where the exception
> isn't thrown, although I don't know what it's exact role is.
It sounds like I was right then.
Nick Keighley
> James Kanze wrote:
> > On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
> >>> On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
> >>>> I got the idea and material for this thread from the
> >>>> "high-class" ( ;) ) ng clc++m. Please add any commonly
> >>>> held/observed misconceptions about C++ exceptions or
> >>>> exceptions in general. Both mechanism and condition
> >>>> misconceptions are fine. I'll start...
you'd find life smoother if you lost a bit of attitude...
> >>>> "Exceptions invoke all destructors while unwinding the stack."
>
> >>>> I think that is probably incorrect, though I'm not a
> >>>> compiler writer so can't say with high certainty that it is
> >>>> a misconception.
just read the standard then you'd know what an implementation is
required to do. The dtors for all objects that go out of scope must be
invoked.
> >>>> I hypothesize that the compiler introduces
> >>>> some kind of "jumps to the closing brace" and lets the
> >>>> normal destruction of stack class objects happen. An
> >>>> explicit mechanism that is part of the exception machinery
> >>>> that calls destructors? I don't think so.
I fail to see the difference. How does your mechanism handle this:
void photon (int x)
{
Fred fred (x);
fred.process(); /* this throws */
George g;
g.process();
}
why isn't g's destructor invoked?
> >>> You hypothesize wrong. The usual implementation (except
> >>> maybe for Microsoft) is to generate tables mapping code
> >>> addresses to clean up functions; the exception propagation
> >>> code (in the library) finds the frame pointer from the
> >>> stack, uses the table to find the clean up code, and calls
> >>> it, for each stack frame. I think some earlier compilers
> >>> generated additional code in the constructor to "register"
> >>> the class, but the table method is generally considered
> >>> preferable, as it has almost no runtime overhead until the
> >>> exception is thrown.
>
> >> What is the mechanism
as described above?
> >> and how does it work in the no-throw
> >> function case?
no destructors are invoked in the nothrow case?
> > The mechanism is more or less what I described:
>
> Are you saying that there then is NOT a distinct mechanism for exceptions
> that does unwinding?
there is a description in the standard that specifies in what
circumstances unwinding is done. How the implementor achieves this is
up to him. Most programming languages work like this.
b = a * 2;
might use an add instruction. Or it might use a shift. You don't care
so long as it gets the right answer.
Since Bjarne Stroustrup was a practical man he didn't specify things
that were unimplementable. I think pretty well everyone does virtual
functions the same way, though the standard doesn't mandate it. I
understand there is more variety in the implementation of exceptions.
I you want assembler you know where to find it!
> > for each
> > distinct set of objects to clean up, the compiler generates a
> > clean-up function, and puts its address in a table along with
> > the code addresses for which this function is valid.
>
> I hypothesized that there was no mechanism, separate from the case where
> there are no exception elements in the code, (read NOT TWO mechanisms) to do
> unwind explicitly for exceptions and tied explicitly ('distinctly' may be a
> better word) to the exception machinery. Is that hypothesis right or wrong?
there is no madatory mechanism defined by the standard. Some
implementations use what you call "a mechanism". I don't understand
why you care or what you are tryign to make.
> > (This code
> > can be destructors or catch blocks. In the latter case, the
> > compiler also provides information concerning the types for
> > which the try block is valid.) When an exception is thrown, the
> > compiler calls code which walks back up the stack. For each
> > return address it finds, it looks up in the table what it has to
> > do, and does it.
>
> > Typically, the case of nothrow is treated by generating the same
> > code as if the function were wrapped in a try block, and
> > handling the error in a catch.
>
> > Other solutions are possible. Microsoft, for example, seems to
> > generate code which is executed in the case where the exception
> > isn't thrown, although I don't know what it's exact role is.
>
> It sounds like I was right then.
hasn't he just described "a mechanism"? Doesn't that mean you were
wrong?
--
Nick Keighely
James Kanze
What do you mean by "distinct mechanism"? Every compiler (or
sometimes the platform ABI) defines a mechanism to be used.
What has to happen is specified by the standard; how the
compiler achieves this is unspecified.
> > for each distinct set of objects to clean up, the compiler
> > generates a clean-up function, and puts its address in a
> > table along with the code addresses for which this function
> > is valid.
> I hypothesized that there was no mechanism, separate from the
> case where there are no exception elements in the code, (read
> NOT TWO mechanisms) to do unwind explicitly for exceptions and
> tied explicitly ('distinctly' may be a better word) to the
> exception machinery. Is that hypothesis right or wrong?
$ don't understand what you're hypothesising. The compiler has
to generate something to handle exceptions in order to be
conform. The standard says what the observable behavior must
be, not what the compiler does to achieve that.
> > (This code
> > can be destructors or catch blocks. In the latter case, the
> > compiler also provides information concerning the types for
> > which the try block is valid.) When an exception is thrown, the
> > compiler calls code which walks back up the stack. For each
> > return address it finds, it looks up in the table what it has to
> > do, and does it.
> > Typically, the case of nothrow is treated by generating the same
> > code as if the function were wrapped in a try block, and
> > handling the error in a catch.
> > Other solutions are possible. Microsoft, for example, seems to
> > generate code which is executed in the case where the exception
> > isn't thrown, although I don't know what it's exact role is.
> It sounds like I was right then.
Right about what? You said that you thought "Exceptions invoke
all destructors while unwinding the stack" was probably
incorrect---if you meant "all destructors of objects which cease
to be in scope", the statement is correct, and you're wrong.
You hypothesized that the compiler introduces some kind of
`jumps to the closing brace' and lets the normal destruction of
stack class objects happen": this hypothesis is wrong, at least
for the compilers I know. You also said "An explicit mechanism
that is part of the exception machinery that calls destructors?
I don't think so." I'm not sure what you mean by that, but the
compiler definitely does generate code which is specific to
exception handling, and it is that code which calls the
destructors.
--
James Kanze
dragan
> On 11 Dec, 08:57, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
>>>> James Kanze wrote:
>>>>> On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
>
>
>>>>>> I got the idea and material for this thread from the
>>>>>> "high-class" ( ;) ) ng clc++m. Please add any commonly
>>>>>> held/observed misconceptions about C++ exceptions or
>>>>>> exceptions in general. Both mechanism and condition
>>>>>> misconceptions are fine. I'll start...
>
> you'd find life smoother if you lost a bit of attitude...
??? What are you talking about?
>
>
>>>>>> "Exceptions invoke all destructors while unwinding the stack."
>>
>>>>>> I think that is probably incorrect, though I'm not a
>>>>>> compiler writer so can't say with high certainty that it is
>>>>>> a misconception.
>
> just read the standard then you'd know what an implementation is
> required to do. The dtors for all objects that go out of scope must be
> invoked.
Though the one who I quoted was thinking, surely, at the standard level, I
was relating it to the implementation/mechanism level and is still where the
focus of discussion is. All else is is off-topic for it is not relevant to
the "question" posed. Do you see?
>
>
>>>>>> I hypothesize that the compiler introduces
>>>>>> some kind of "jumps to the closing brace" and lets the
>>>>>> normal destruction of stack class objects happen. An
>>>>>> explicit mechanism that is part of the exception machinery
>>>>>> that calls destructors? I don't think so.
>
> I fail to see the difference.
Me too. That's why I hypothesize that there is no separate mechanism tied to
the exception machinery (unless you want to call the exception machinery the
lower level concept). When using a compiler switch to turn off exceptions,
what happens under the covers?
> How does your mechanism handle this: [example omitted]
(Joke spared, but it was waaay funny!). (OK, I was about to write: "_I_
don't have a mechanis...", and then I had to package it differently.) (See,
it never ends! he he he he! ). (Waaay funny IMO).
Seriously now, I'm not a compiler writer so if such a thing as I IMAGINED
exists, you'll have to ask the one who implemented it.
>
>>>>> You hypothesize wrong. The usual implementation (except
>>>>> maybe for Microsoft) is to generate tables mapping code
>>>>> addresses to clean up functions; the exception propagation
>>>>> code (in the library) finds the frame pointer from the
>>>>> stack, uses the table to find the clean up code, and calls
>>>>> it, for each stack frame. I think some earlier compilers
>>>>> generated additional code in the constructor to "register"
>>>>> the class, but the table method is generally considered
>>>>> preferable, as it has almost no runtime overhead until the
>>>>> exception is thrown.
>>
>>>> What is the mechanism
>
> as described above?
You can't extract just that portion of the sentence and get the same
meaning. Why did you do that? It is REQUIRED to read to the sentence
terminator to comprehend the thought. Periods and other sentence terminators
are not there only for decorative purposes, you know.
>
>
>>>> and how does it work in the no-throw
>>>> function case?
>
> no destructors are invoked in the nothrow case?
When stack class objects go out of scope, their destructors are called. You
know that. I know you do. (Don't you?).
>
>
>>> The mechanism is more or less what I described:
>>
>> Are you saying that there then is NOT a distinct mechanism for
>> exceptions that does unwinding?
>
> there is a description in the standard that specifies in what
> circumstances unwinding is done.
The topic is the underlying mechanisms of implementation, NOT the
standard-level operation. You must have missed that very important element:
the topic of discussion. (It could be my bad English?).
>
> I you want assembler you know where to find it!
And if you have nothing to say that is relevant to the discussion, you know
what not to do.
>
>
>>> for each
>>> distinct set of objects to clean up, the compiler generates a
>>> clean-up function, and puts its address in a table along with
>>> the code addresses for which this function is valid.
>>
>> I hypothesized that there was no mechanism, separate from the case
>> where there are no exception elements in the code, (read NOT TWO
>> mechanisms) to do unwind explicitly for exceptions and tied
>> explicitly ('distinctly' may be a better word) to the exception
>> machinery. Is that hypothesis right or wrong?
>
> there is no madatory mechanism defined by the standard.
The "question" had nothing to do with the standard. Hello?
> Some
> implementations use what you call "a mechanism". I don't understand
> why you care or what you are tryign to make.
JK was doing a fine job at describing the underpinnings of a typical
implementation. I think this is an area where you should bow out and let JK
continue, for he has the requisite knowledge and information being sought:
aka, "the answer".
>
>>> (This code
>>> can be destructors or catch blocks. In the latter case, the
>>> compiler also provides information concerning the types for
>>> which the try block is valid.) When an exception is thrown, the
>>> compiler calls code which walks back up the stack. For each
>>> return address it finds, it looks up in the table what it has to
>>> do, and does it.
>>
>>> Typically, the case of nothrow is treated by generating the same
>>> code as if the function were wrapped in a try block, and
>>> handling the error in a catch.
>>
>>> Other solutions are possible. Microsoft, for example, seems to
>>> generate code which is executed in the case where the exception
>>> isn't thrown, although I don't know what it's exact role is.
>>
>> It sounds like I was right then.
>
> hasn't he just described "a mechanism"? Doesn't that mean you were
> wrong?
Until I see 2 distinct mechanisms, I am right.
dragan
Oh you too now?? The question at hand IS the mechanisms, NOT an operational
standard. And you know this because your prior post shows that you do
because you gave a description of the mechanism: tables, cleanup functions,
etc. The hypothesis is that all that stuff you mentioned is the
implementation of how classes work when leaving a scope and that there is no
separate machinery to do that for exceptions.
>
>>> for each distinct set of objects to clean up, the compiler
>>> generates a clean-up function, and puts its address in a
>>> table along with the code addresses for which this function
>>> is valid.
>
>> I hypothesized that there was no mechanism, separate from the
>> case where there are no exception elements in the code, (read
>> NOT TWO mechanisms) to do unwind explicitly for exceptions and
>> tied explicitly ('distinctly' may be a better word) to the
>> exception machinery. Is that hypothesis right or wrong?
>
> $ don't understand what you're hypothesising.
See above. You seemed pretty sure that I was hypothesizing wrongly though
just a few posts ago. "Things that make you say 'hmmm'".
> The compiler has
> to generate something to handle exceptions in order to be
> conform. The standard says what the observable behavior must
> be, not what the compiler does to achieve that.
The standard has only remote association to the issue at hand.
>
>>> (This code
>>> can be destructors or catch blocks. In the latter case, the
>>> compiler also provides information concerning the types for
>>> which the try block is valid.) When an exception is thrown, the
>>> compiler calls code which walks back up the stack. For each
>>> return address it finds, it looks up in the table what it has to
>>> do, and does it.
>
>>> Typically, the case of nothrow is treated by generating the same
>>> code as if the function were wrapped in a try block, and
>>> handling the error in a catch.
>
>>> Other solutions are possible. Microsoft, for example, seems to
>>> generate code which is executed in the case where the exception
>>> isn't thrown, although I don't know what it's exact role is.
>
>> It sounds like I was right then.
>
> Right about what?
My hypothesis.
> You said that you thought "Exceptions invoke
> all destructors while unwinding the stack" was probably
> incorrect
Yes, but the key concept of the hypothesis is that there is no separate
mechanism to do the unwinding tied to the exception machinery.
> ---if you meant "all destructors of objects which cease
> to be in scope", the statement is correct, and you're wrong.
> You hypothesized that the compiler introduces some kind of
> `jumps to the closing brace' and lets the normal destruction of
> stack class objects happen"
That was just an imagined thing. I noted that I am not a compiler writer.
That did scare me off from venturing a WAG on how it is done. And that is
not important to the hypothesis, nor is it the hypothesis, but I get the
feeling you would like to try to make it seem like it was? The childish
antics in language groups are phenomenal! They never cease to amaze me.
> : this hypothesis is wrong, at least
> for the compilers I know. You also said "An explicit mechanism
> that is part of the exception machinery that calls destructors?
> I don't think so." I'm not sure what you mean by that,
How convenient for you, since that IS the hypothesis.
> but the
> compiler definitely does generate code which is specific to
> exception handling, and it is that code which calls the
> destructors.
I guess at this point, nothing else will do except a side-by-side comparison
analysis of the actual processes and mechanisms of an implementation (or a
few implementations). Thanks for trying to explain it though.
aku ankka
> > Enquiring minds can use /Faout.asm or -S out.s compiler switch (or
> > equivalent) but that is compiler/toolchain specific knowledge.
>
> Luckily, JK was cordial enough to answer the question instead of starting a
> tirade of what is "on holy topic" and the like in this NG. :P
I'm sorry I am not going to divulge any intellectual property /
patentable technology, but if you want to see how a specific compiler
does it you can check the compiler output. You will see easily how the
exception handling is implemented.
> >>> This could be a separate piece of code that consists only of
> >>> destructor calls (which means that for every object, there are at
> >>> least two sites from which the destructor can be called), or a
> >>> scheme like you describe. It is the end-result that matters.
>
> >> To YOU it is all that matters. Try stepping out of your own skin
> >> sometime.-
>
> > That's correct. He was speaking for himself and the statement is 100%
> > accurate. Wow, you can read; that's very impressive!
>
> Just go away you big baby!- Hide quoted text -
What's more impressive is that you also seem to be able to write!
aku ankka
> I guess at this point, nothing else will do except a side-by-side comparison
> analysis of the actual processes and mechanisms of an implementation (or a
That's the whole point. From the language/standard point of view the
topic is not relevant or interesting. You can discuss the mechanism in
context of some specific implementation. Until the specific
implementation is established the best you or anyone else can do is
to discuss what the exceptions should do.
The c++ has exceptions. Yes/No?
They are supposed to work as specified. True/False?
In absense of any specific compiler or toolchain mentioned, you choose
to completely ignore the fact that you can find out yourself by
inspecting the compiler's output.
James Kanze
> James Kanze wrote:
> > On Dec 11, 8:57 am, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
[...]
> > : this hypothesis is wrong, at least
> > for the compilers I know. You also said "An explicit mechanism
> > that is part of the exception machinery that calls destructors?
> > I don't think so." I'm not sure what you mean by that,
> How convenient for you, since that IS the hypothesis.
> > but the compiler definitely does generate code which is
> > specific to exception handling, and it is that code which
> > calls the destructors.
>I guess at this point, nothing else will do except a
>side-by-side comparison analysis of the actual processes and
>mechanisms of an implementation (or a few implementations).
>Thanks for trying to explain it though.
The real problem I'm having, I think, is in understanding what
you mean by "an explicit mechanism". Within the compiler (and
the compiler's runtime library), there is a lot of code which
deals exclusively in exceptions: the tables generated in my
explination are only used in exception handling, the code
which walks back the stack, looking for the return addresses in
the tables is only used for exception handling, and the separate
clean-up routines called by that code are only used for
exception handling. To me, that's a "mechanism", and it is
explicitly used for exceptions. But maybe you're thinking of
something else with regards to "mechanism".
--
James Kanze
Squeamizh
> Nick Keighley wrote:
> > On 11 Dec, 08:57, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
> >>> On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
> >>>> James Kanze wrote:
> >>>>> On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
>
> >>>>>> I got the idea and material for this thread from the
> >>>>>> "high-class" ( ;) ) ng clc++m. Please add any commonly
> >>>>>> held/observed misconceptions about C++ exceptions or
> >>>>>> exceptions in general. Both mechanism and condition
> >>>>>> misconceptions are fine. I'll start...
>
> > you'd find life smoother if you lost a bit of attitude...
>
> ??? What are you talking about?
He means you're a total douchebag, and he's right. I do think the
responses that actually answer your question are interesting and
worthwhile, however.
dragan
Yes, you understand "mechanism" the same way as I used it (and no need to
get into the plural of the term, as this is not an English language learning
newsgroup though at times it sure feels like it). "Umpteen" posts ago, you
told of that mechanism and I asked then what is the mechanism and processing
like in the case where there are no exceptions, say the compiler switch that
turns off exception handling is on. So far, we have the one mechanism
"defined" (for some whatever implementation) and now I'm in search of the
other one for comparison. I meant "explicit" as "separate from the mechanism
that calls destructors and controls program flow in the case where there are
no exceptions". 'explicit' was probably a bad word choice, though how what
info was being sought couldn't be clear given all the context, baffles me.
(Aside: "mechanism" applied to software code may be a bit of a stretch for
some minds uninitiated to anything other than the narrow world of software
development. Another hypothesis in the making.)
Jorgen Grahn
Your first posting started out with mentioning "commonly held/observed
misconceptions" so I guess most of us assumed you were talking about
the things that matter when *using* the language. That's why you got
the kinds of answers you got.
I also don't see how you can interpret those answers as attempts to
curb your appetite for knowledge.
...
> To YOU. Why don't you start your own threads about stuff you wanna know and
> stay out of mine? Because you add no value!
...
> Just go away you big baby!
I don't have time for this.
*PLONK*
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Nick Keighley
If I'd meant it I'd have said it. Please don't over-interpet what I
say
Nick Keighley
> Nick Keighley wrote:
> > On 11 Dec, 08:57, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
> >>> On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
> >>>> James Kanze wrote:
> >>>>> On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
> >>>>>> I got the idea and material for this thread from the
> >>>>>> "high-class" ( ;) ) ng clc++m. Please add any commonly
> >>>>>> held/observed misconceptions about C++ exceptions or
> >>>>>> exceptions in general. Both mechanism and condition
> >>>>>> misconceptions are fine. I'll start...
>
> > you'd find life smoother if you lost a bit of attitude...
>
> ??? What are you talking about?
you seem to switch from technical discussion to insult at the drop of
a hat. And sometimes treat people who have a genuine disagreement with
you as if they were idiots. See later in this post...
> >>>>>> "Exceptions invoke all destructors while unwinding the stack."
>
> >>>>>> I think that is probably incorrect, though I'm not a
> >>>>>> compiler writer so can't say with high certainty that it is
> >>>>>> a misconception.
>
> > just read the standard then you'd know what an implementation is
> > required to do. The dtors for all objects that go out of scope must be
> > invoked.
>
> Though the one who I quoted was thinking, surely, at the standard level, I
> was relating it to the implementation/mechanism level
yes, but the implementation must implement the standard. So if you
want to know what destructirs are invoked you read the standard! If an
implementation can be detected doing something different then it isn't
an implementaion of C++. Java for instance may trigger its
"destructors" long after the object has gone out of scope.
> and is still where the
> focus of discussion is.
I thinkyou are wrong to be obsessed with implementation.Perhaps you
should phrase your question "how do you typically implement
exceptions" rather than "what destructors should be invoked when
objects go out of scope".
> All else is is off-topic for it is not relevant to
> the "question" posed. Do you see?
nope
> >>>>>> I hypothesize that the compiler introduces
> >>>>>> some kind of "jumps to the closing brace" and lets the
> >>>>>> normal destruction of stack class objects happen. An
> >>>>>> explicit mechanism that is part of the exception machinery
> >>>>>> that calls destructors? I don't think so.
>
> > I fail to see the difference.
a jump to the end of the function *is* a "mechanism" in my book. And
too simple to boot.
<snip>
> > How does your mechanism handle this: [example omitted]
you don't think the example illustrated a point (that jumping to the
end of a function isn't enough)
> (Joke spared, but it was waaay funny!). (OK, I was about to write: "_I_
> don't have a mechanis...", and then I had to package it differently.) (See,
> it never ends! he he he he! ). (Waaay funny IMO).
this isn't attitude? Actually it's just rudeness.
> Seriously now, I'm not a compiler writer so if such a thing as I IMAGINED
> exists, you'll have to ask the one who implemented it.
>
> >>>>> You hypothesize wrong. The usual implementation (except
> >>>>> maybe for Microsoft) is to generate tables mapping code
> >>>>> addresses to clean up functions; the exception propagation
> >>>>> code (in the library) finds the frame pointer from the
> >>>>> stack, uses the table to find the clean up code, and calls
> >>>>> it, for each stack frame. I think some earlier compilers
> >>>>> generated additional code in the constructor to "register"
> >>>>> the class, but the table method is generally considered
> >>>>> preferable, as it has almost no runtime overhead until the
> >>>>> exception is thrown.
>
> >>>> What is the mechanism
>
> > as described above?
>
> You can't extract just that portion of the sentence and get the same
> meaning.
>
> Why did you do that? It is REQUIRED to read to the sentence
> terminator to comprehend the thought. Periods and other sentence terminators
> are not there only for decorative purposes, you know.
>
I don't think breaking your sentence at a conjuction seriously mangled
its meaning. I certainly didn't intend to misrepresent you. The
previous poster described how exceptions are typically implemented.
That really does look a "mechanism" to *me*.
> >>>> and how does it work in the no-throw function case?
>
> > no destructors are invoked in the nothrow case?
>
> When stack class objects go out of scope, their destructors are called. You
> know that. I know you do. (Don't you?).
I'm not getting your point. In the nopthrow case dtors are invoked
when itemgoout of scope, yes.
> >>> The mechanism is more or less what I described:
>
> >> Are you saying that there then is NOT a distinct mechanism for
> >> exceptions that does unwinding?
he seems to be saying that in many cases there is a special mechanism
to invoke dtors in the case of a exception.
> > there is a description in the standard that specifies in what
> > circumstances unwinding is done.
>
> The topic is the underlying mechanisms of implementation, NOT the
> standard-level operation. You must have missed that very important element:
> the topic of discussion. (It could be my bad English?).
but you seem tobe asking which dtors are invoked and when and *that*
is answwered by the standard.
> > I you want assembler you know where to find it!
>
> And if you have nothing to say that is relevant to the discussion, you know
> what not to do.
>
> >>> for each
> >>> distinct set of objects to clean up, the compiler generates a
> >>> clean-up function, and puts its address in a table along with
> >>> the code addresses for which this function is valid.
>
> >> I hypothesized that there was no mechanism, separate from the case
> >> where there are no exception elements in the code, (read NOT TWO
> >> mechanisms) to do unwind explicitly for exceptions and tied
> >> explicitly ('distinctly' may be a better word) to the exception
> >> machinery. Is that hypothesis right or wrong?
>
> > there is no madatory mechanism defined by the standard.
>
> The "question" had nothing to do with the standard. Hello?
yes it does. We are are descending towards pantomime mode... "Look out
behind you!"
> > Some
> > implementations use what you call "a mechanism". I don't understand
> > why you care or what [point] you are trying to make.
>
> JK was doing a fine job at describing the underpinnings of a typical
> implementation.
ok
> I think this is an area where you should bow out and let JK
> continue, for he has the requisite knowledge and information being sought:
> aka, "the answer".
I think you changed the question part way through. But you may have a
point in that I am no longer adding useful information to the thread.
> >>> (This code
> >>> can be destructors or catch blocks. In the latter case, the
> >>> compiler also provides information concerning the types for
> >>> which the try block is valid.) When an exception is thrown, the
> >>> compiler calls code which walks back up the stack. For each
> >>> return address it finds, it looks up in the table what it has to
> >>> do, and does it.
>
> >>> Typically, the case of nothrow is treated by generating the same
> >>> code as if the function were wrapped in a try block, and
> >>> handling the error in a catch.
>
> >>> Other solutions are possible. Microsoft, for example, seems to
> >>> generate code which is executed in the case where the exception
> >>> isn't thrown, although I don't know what it's exact role is.
>
> >> It sounds like I was right then.
>
> > hasn't he just described "a mechanism"? Doesn't that mean you were
> > wrong?
>
> Until I see 2 distinct mechanisms, I am right.-
what? Microsoft's and most other people's?
Nick Keighley
you speak of "multiple mechanisms" by this do you mean
1. the code invoked when objects go out of scope in the "normal
fashion", that is by reaching the end of the enclosing block or
executing a return statement (probably a few more like gotos and
breaks)
2. the code invoked when objects go out of scope due to an exception
being thrown
And your hypothesis is that 1 and 2 are the same code.
It appears that most current compilers use different code (mechanisms)
for 1 and 2. C-front may have done it your way and MS may do it your
way but GCC probably doesn't.
Is that a fair summary of your position (and a response to it?)
dragan
Oh. After all this time, we are back at the first posting? "What's wrong
with this picture?".
> started out with mentioning "commonly held/observed
> misconceptions"
And don't think I don't have follow up things. I was soliciting other
peoples' observations, but maybe it isn't accessible enough of a question
FOR PEOPLE WITH IQs OVER 120! ;) :P
> so I guess most of us assumed you were talking about
> the things that matter when *using* the language.
Hmm. I'd have to go back and reread my OP to see if it was not obvious that
I was on the IMPLEMENTATION (HOW IT WORKS) track. Or maybe you can tell me
if it says that when YOU go back and reread it? I already said that the
passage I quoted could have been, and probably was, from that perspective,
but the quoted passage is ambiguous/incorrect no matter how you assimilate
it (or so I remember). (And yes, I avoid going back in time. "Forward young
man!". or... "Go West young man! Go West!").
>That's why you got
> the kinds of answers you got.
Not at all. JK was on the right track immediately. So if all the other
responses were what you are referring to (by "virtue" of their volume), you
have no explanation to convey.
>
> I also don't see how you can interpret those answers as attempts to
> curb your appetite for knowledge.
You're taking quite a "liberty" to extrapolate one tiny passage to the whole
thread in general. I'm like a junkyard dog: someone corners me, I bite.
("junkyard dog": I'm not good with "your" "this is like..." things, but I'm
getting better at them and understanding them, but it's somewhat close. Is
there a thesaurus-like book/site for such?).
dragan
> On 11 Dec, 10:41, "dragan" <spambus...@prodigy.net> wrote:
>> Nick Keighley wrote:
>>> On 11 Dec, 08:57, "dragan" <spambus...@prodigy.net> wrote:
>>>> James Kanze wrote:
>>>>> On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
>>>>>> James Kanze wrote:
>>>>>>> On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
>
>
>>>>>>>> I got the idea and material for this thread from the
>>>>>>>> "high-class" ( ;) ) ng clc++m. Please add any commonly
>>>>>>>> held/observed misconceptions about C++ exceptions or
>>>>>>>> exceptions in general. Both mechanism and condition
>>>>>>>> misconceptions are fine. I'll start...
>>
>>> you'd find life smoother if you lost a bit of attitude...
>>
>> ??? What are you talking about?
>
> you seem to switch from technical discussion to insult at the drop of
> a hat.
Examples please (in private please, this isn't a chatroom).
> And sometimes treat people who have a genuine disagreement with
> you as if they were idiots.
You think? "It ain't me".
> See later in this post...
Cool: A USENET post "hyperlink"! (Only "slightly" less effective than the
HTML kind ;) ). Will there be a commercial break before each "cliff hanger"?
I actually "watch" some TV now that I can skip over the commercials via my
PC DVR. :) (Aside).
>
>>>>>>>> "Exceptions invoke all destructors while unwinding the stack."
>>
>>>>>>>> I think that is probably incorrect, though I'm not a
>>>>>>>> compiler writer so can't say with high certainty that it is
>>>>>>>> a misconception.
>>
>>> just read the standard then you'd know what an implementation is
>>> required to do. The dtors for all objects that go out of scope must
>>> be invoked.
>>
>> Though the one who I quoted was thinking, surely, at the standard
>> level, I was relating it to the implementation/mechanism level
>
> yes, but the implementation must implement the standard.
Please, just stop. Are you trying to "push my buttons"? Just stop it.
> So if you
> want to know what destructirs are invoked you read the standard!
I said stop it.
> If an
> implementation can be detected doing something different then it isn't
> an implementaion of C++. Java for instance may trigger its
> "destructors" long after the object has gone out of scope.
"The Templars of the C++ Standard"?
>
>> and is still where the
>> focus of discussion is.
>
> I thinkyou are wrong to be obsessed with implementation.
Oh, I'm "obsessed" now. Interesting.
> Perhaps you
> should phrase your question "how do you typically implement
> exceptions" rather than "what destructors should be invoked when
> objects go out of scope".
"The thing is", now, that "this is now and that was then". You KNOW I'm not
going to entertain childish antics. I didn't post a question at the start.
(Was there a question mark in the OP?). If there is a question NOW, surely
it will escape all those just learning the English language. But, you
knowing the English language.. OK, that isn't enough. The ability to
assimilate information and ... blah, blah. You're making me feel "bad"... I
always HATED being discriminated against via labelers: "technical person"
just because my BS degree is of Science.
>> All else is is off-topic for it is not relevant to
>> the "question" posed. Do you see?
>
> nope
Then sit back and observe the thread and not interject noise, thank you. Is
this your thread? No, it is mine. All "ancillaries" are just noise. you
don't really wanna be noise do you? Do you post in every thread? Why? Why
not?
>
>
>>>>>>>> I hypothesize that the compiler introduces
>>>>>>>> some kind of "jumps to the closing brace" and lets the
>>>>>>>> normal destruction of stack class objects happen. An
>>>>>>>> explicit mechanism that is part of the exception machinery
>>>>>>>> that calls destructors? I don't think so.
>>
>>> I fail to see the difference.
>
> a jump to the end of the function *is* a "mechanism" in my book. And
> too simple to boot.
Let's analyze this. I "baby-ishly" said something very definitively and
purposefully naively and you're all on this remote, tiny irrelevant series
of words instead of the main point. Childish Antic No. 9? (No. 9, No. 9. No.
9....).
>
> <snip>
>
>>> How does your mechanism handle this: [example omitted]
>
> you don't think the example illustrated a point (that jumping to the
> end of a function isn't enough)
You are snipping-n-pasting weirdly. Who are you asking and what are you
asking? If it's not important (it's not), stop making NOISE.
>
>> (Joke spared, but it was waaay funny!). (OK, I was about to write:
>> "_I_ don't have a mechanis...", and then I had to package it
>> differently.) (See, it never ends! he he he he! ). (Waaay funny IMO).
>
> this isn't attitude? Actually it's just rudeness.
Show me. I don't know what you are talking about. Tell me. Explain. How is
what you quoted me saying rude? Please respond to just this in a separate
post, because this I am interested in. (Here in group, not in private). (Was
this the "USENET post hyperlink"? I think it is!).
>
>
>> Seriously now, I'm not a compiler writer so if such a thing as I
>> IMAGINED exists, you'll have to ask the one who implemented it.
>>
>>>>>>> You hypothesize wrong. The usual implementation (except
>>>>>>> maybe for Microsoft) is to generate tables mapping code
>>>>>>> addresses to clean up functions; the exception propagation
>>>>>>> code (in the library) finds the frame pointer from the
>>>>>>> stack, uses the table to find the clean up code, and calls
>>>>>>> it, for each stack frame. I think some earlier compilers
>>>>>>> generated additional code in the constructor to "register"
>>>>>>> the class, but the table method is generally considered
>>>>>>> preferable, as it has almost no runtime overhead until the
>>>>>>> exception is thrown.
>>
>>>>>> What is the mechanism
>>
>>> as described above?
>>
>> You can't extract just that portion of the sentence and get the same
>> meaning.
>>
>> Why did you do that? It is REQUIRED to read to the sentence
>> terminator to comprehend the thought. Periods and other sentence
>> terminators are not there only for decorative purposes, you know.
>>
>
> I don't think breaking your sentence at a conjuction seriously mangled
> its meaning.
What you "think" (quotes required) and what is true are chasms apart then,
surely. I'm not going to play childish antics with you. Newsgroups posts are
not source code. (I may be on to something here with that!). I know what I
said. I'm not going back in time. Stop pushing my buttons.
> I certainly didn't intend to misrepresent you.
You don't represent me at all.
> The
> previous poster described how exceptions are typically implemented.
> That really does look a "mechanism" to *me*.
You're way behind "the times". JK is tasked with explaining the contrasting
case. He presented one "mechanism". Of course, he said NOTHING, untill he
shows the OTHER one. I don't think he'd want you as a lawyer though. (Are
you a thug?). :P
>
>>>>>> and how does it work in the no-throw function case?
>>
>>> no destructors are invoked in the nothrow case?
>>
>> When stack class objects go out of scope, their destructors are
>> called. You know that. I know you do. (Don't you?).
>
> I'm not getting your point.
Patience. I believe JK has the knowledge or can get the info, and I don't
care from where it comes. I don't care if JK sees a problem to be solved and
utilizes all the resources at his disposal (unless they are other people) to
craft an answer. I sent out an RFP and the only one to get a second look was
JK. Do you understand that you have already been eliminated?
> In the nopthrow case dtors are invoked
> when itemgoout of scope, yes.
You have other stuff. You didn't get this contract, and you probably won't
get others if you keep going after ones that you are not qualified for.
>
>>>>> The mechanism is more or less what I described:
>>
>>>> Are you saying that there then is NOT a distinct mechanism for
>>>> exceptions that does unwinding?
>
> he seems to be saying
Did he assign you his spokesperson? If not, shut up.
>>> there is a description in the standard that specifies in what
>>> circumstances unwinding is done.
>>
>> The topic is the underlying mechanisms of implementation, NOT the
>> standard-level operation. You must have missed that very important
>> element: the topic of discussion. (It could be my bad English?).
>
> but you seem tobe asking which dtors are invoked and when and *that*
> is answwered by the standard.
"You're fired". JK is not hired though. Wanna know why? Because I am leading
him to the answer. That he can get it is one thing, that I have to lead him
there is quite another. At this point, I am indeed "building it myself" (no
offense JK).
>
>>> I you want assembler you know where to find it!
>>
>> And if you have nothing to say that is relevant to the discussion,
>> you know what not to do.
>>
>>>>> for each
>>>>> distinct set of objects to clean up, the compiler generates a
>>>>> clean-up function, and puts its address in a table along with
>>>>> the code addresses for which this function is valid.
>>
>>>> I hypothesized that there was no mechanism, separate from the case
>>>> where there are no exception elements in the code, (read NOT TWO
>>>> mechanisms) to do unwind explicitly for exceptions and tied
>>>> explicitly ('distinctly' may be a better word) to the exception
>>>> machinery. Is that hypothesis right or wrong?
>>
>>> there is no madatory mechanism defined by the standard.
>>
>> The "question" had nothing to do with the standard. Hello?
>
> yes it does.
No, read the RFP.
>> I think this is an area where you should bow out and let JK
>> continue, for he has the requisite knowledge and information being
>> sought: aka, "the answer".
>
> I think you changed the question part way through.
I know you failed to keep up with the client's (me) need. VERY few are "cut
out" to be consultants. I'm not eliminating you out of the realm, but you
have to stay well within your level of capability (and I ENCOURAGE people to
"offer their wares"). It's just business.
dragan
Are you soliciting a Consultant? :)
[snipped further inquiries]
This is a "PAINFUL" thread (and I had OTHER "misconceptions" to follow!).
Joshua Maurice
implemented do not matter. In the real world, how things are
implemented matter. I care whether or not my functions are expanded
inline, and how exceptions are implemented.
To clarify dragan's interest, I think he's curious if it's commonly
implemented like the following. Specifically, if there are multiple
execution paths, one for exception thrown, one not, aka multiple call
sites to the destructor of a local stack object.
//original code
{
A x;
B y;
C z;
}
//pseudo code
{
new (address_of_x) A;
if (no pending exception)
{
new (address_of_y) B;
if (no pending exception)
{
new (address_of_z) C;
if (no pending exception)
{
address_of_z->~C();
}
address_of_y->~B();
}
address_of_x->~A();
}
}
//
However, ideally, exceptions should not be implemented this way. It
was originally intended to offer (near) zero overhead when the
exception is not thrown. The above translation is a lot of overhead
(and probably not even how Microsoft win32 does it either).
Instead, something like the following was intended: The Program
Counter register, or PC, is a register that most processors have. Its
sole purpose is to hold the location of the next instruction to
execute. On a good implementation, a throw statement will save the PC
to another location, and jump to another section of code defined at
compile / link time, a giant lookup table, mapping PC values to
exception handlers, where the exception handlers will clean up the
local objects, then pass control to another exception handler or to a
user-written catch block. Specifically, if you know exactly where in
the code you threw an exception, and you know your current stack, then
you know precisely how to unwind the stack. You know all of the local
objects you need to destroy, and in what order, and you know where to
put control back to user written code.
James Kanze
OK. In that case, the mechanism I explained is explicit. In
all of the compilers I've seen, destructors are simply called at
the end of scope when no exceptions are raised. Exactly as they
were before exceptions were added to the language. The extra
tables and the associated stack walkback only comes into play
when an exception is thrown.
The goal here is "you don't pay for what you don't use". As
long as no exception is thrown, the code executes as fast as if
exceptions weren't in the language (or almost---added control
flow paths may affect optimization, and the additional tables
may affect locality).
Not all compilers use this technique. G++ does, as does Sun CC,
but Microsoft does seem to insert some extra calls here and
there (although I've not studied its mechanism enough to know
exactly how it works).
Basically, at least with Sun CC (and except for the optimizer
considering the additional flow paths), code is generated
exactly as if exceptions didn't exist. Plus the additional
tables are generated. When you throw an exception, the compiler
generates special code to allocate memory in a reserved area and
copy the exception into it, then calls a special runtime
function which does the stack walkback. Which can be relatively
expensive in runtime, because of all of the table lookup's it is
doing. (I don't know off hand whether it has to do a linear
search each time, of if the tables are sorted, and it can do a
binary search.)
--
James Kanze
dragan
"James Kanze" <james...@gmail.com> wrote in message
news:e09665be-4d56-4e93...@m38g2000yqd.googlegroups.com...
I wonder if a much simpler implementation is possible if not being
"hell-bent" on _zero_ overhead. One that reuses the same destructor
call/stack walk as in the non-exceptional case. I would proceed in that
direction first, if I was implementing the language.
> As
> long as no exception is thrown, the code executes as fast as if
> exceptions weren't in the language (or almost---added control
> flow paths may affect optimization, and the additional tables
> may affect locality).
>
> Not all compilers use this technique. G++ does, as does Sun CC,
> but Microsoft does seem to insert some extra calls here and
> there (although I've not studied its mechanism enough to know
> exactly how it works).
>
> Basically, at least with Sun CC (and except for the optimizer
> considering the additional flow paths), code is generated
> exactly as if exceptions didn't exist. Plus the additional
> tables are generated. When you throw an exception, the compiler
> generates special code to allocate memory in a reserved area and
> copy the exception into it, then calls a special runtime
> function which does the stack walkback. Which can be relatively
> expensive in runtime, because of all of the table lookup's it is
> doing. (I don't know off hand whether it has to do a linear
> search each time, of if the tables are sorted, and it can do a
> binary search.)
So overall, the answer is that in practice compiler implementors opt for the
zero-overhead goal which may require or make lucrative machinery that is
separate from the machinery used in the normal processing case, but other
simpler schemes are probably possible. Since there is nothing inherently
tying exceptions to dedicated/explicit mechanisms, any statement worded such
that it implies that, is wrong (a misconception).
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:e09665be-4d56-4e93...@m38g2000yqd.googlegroups.com...
> > On Dec 12, 10:05 am, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
> >> > On Dec 11, 11:05 am, "dragan" <spambus...@prodigy.net> wrote:
> >> >> James Kanze wrote:
> >> >>> On Dec 11, 8:57 am, "dragan" <spambus...@prodigy.net> wrote:
> >> >>>> James Kanze wrote:
> >> > [...]
> > OK. In that case, the mechanism I explained is explicit. In
> > all of the compilers I've seen, destructors are simply called at
> > the end of scope when no exceptions are raised. Exactly as they
> > were before exceptions were added to the language. The extra
> > tables and the associated stack walkback only comes into play
> > when an exception is thrown.
> > The goal here is "you don't pay for what you don't use".
> I wonder if a much simpler implementation is possible if not being
> "hell-bent" on _zero_ overhead. One that reuses the same destructor
> call/stack walk as in the non-exceptional case. I would proceed in
> that direction first, if I was implementing the language.
I'm not sure what you're describing here? That every function have an
additional, hidden return value, which is tested on return from every
function?
Other mechanisms are possible. I believe some earlier compilers did
use
a system of objects automatically registering themselves on
construction, and deregistering themselves on destruction (with try
blocks registering and deregistering their catch clauses as well).
The
registry is organized more or less as a stack, and the exception
handler
just pops until it encounters a catch clause which handles the
exception.
Such mechanisms have a very noticeable impact on performance in the
case
where an exception isn't thrown. Probably acceptable in most
applications, but certainly not in all.
The machinery isn't that complicated. After all, you need to be able
to
walk back the stack in other cases as well (e.g. in a debugger---and
what compiler doesn't come with a debugger). The alternatives are
relatively expensive, and some people do choose their compiler based
on
benchmark results (and those benchmarks rarely test the performance
when
an exception is thrown). For better or worse, performance is an issue
for compiler vendors---lower performance means less sales.
--
James Kanze
dragan
> On Dec 17, 2:51 pm, "dragan" <spambus...@prodigy.net> wrote:
>> "James Kanze" <james.ka...@gmail.com> wrote in message
>
>> news:e09665be-4d56-4e93...@m38g2000yqd.googlegroups.com...
>>> On Dec 12, 10:05 am, "dragan" <spambus...@prodigy.net> wrote:
>>>> James Kanze wrote:
>>>>> On Dec 11, 11:05 am, "dragan" <spambus...@prodigy.net> wrote:
>>>>>> James Kanze wrote:
>>>>>>> On Dec 11, 8:57 am, "dragan" <spambus...@prodigy.net> wrote:
>>>>>>>> James Kanze wrote:
>
>>>>> [...]
>>> OK. In that case, the mechanism I explained is explicit. In
>>> all of the compilers I've seen, destructors are simply called at
>>> the end of scope when no exceptions are raised. Exactly as they
>>> were before exceptions were added to the language. The extra
>>> tables and the associated stack walkback only comes into play
>>> when an exception is thrown.
>
>>> The goal here is "you don't pay for what you don't use".
>
>> I wonder if a much simpler implementation is possible if not being
>> "hell-bent" on _zero_ overhead. One that reuses the same destructor
>> call/stack walk as in the non-exceptional case. I would proceed in
>> that direction first, if I was implementing the language.
>
> I'm not sure what you're describing here?
Nothing specific because I'm not currently programming such stuff. Having
never implemented such stuff, I would try to find one design first before
conceding to 2 separate mechanisms that do "the same thing".
> That every function have an
> additional, hidden return value, which is tested on return from every
> function?
Where that came from is baffling.
>
> Other mechanisms are possible. I believe some earlier compilers did
> use
> a system of objects automatically registering themselves on
> construction, and deregistering themselves on destruction (with try
> blocks registering and deregistering their catch clauses as well).
> The
> registry is organized more or less as a stack, and the exception
> handler
> just pops until it encounters a catch clause which handles the
> exception.
>
> Such mechanisms have a very noticeable impact on performance in the
> case
> where an exception isn't thrown. Probably acceptable in most
> applications, but certainly not in all.
I wonder if there are papers on such. I haven't been an ACM member for a
long time. It may be worth it to join again.
Something I'll have to look at in the future maybe (as if there wasn't other
stuff I should be doing!). I'd rather read about it in papers though if
there are some/any. I'd be interested in the early implementations and how
they evolved and why ("geez Louise", I'm getting geekier by the minute!).
Brian
When buying a car I care about how fast it goes from
0 to 60. There's flexibility about the range for that
with me, but if a car is two to three times slower
than others in that regard, it's a big red flag --
http://webEbenezer.net/comparison.html
Brian Wood
http://webEbenezer.net
James Kanze
> On Dec 17, 12:27 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
> > The machinery isn't that complicated. After all, you need to be
> > able to walk back the stack in other cases as well (e.g. in a
> > debugger---and what compiler doesn't come with a debugger). The
> > alternatives are relatively expensive, and some people do choose
> > their compiler based on benchmark results (and those benchmarks
> > rarely test the performance when an exception is thrown). For
> > better or worse, performance is an issue for compiler
> > vendors---lower performance means less sales.
> When buying a car I care about how fast it goes from
> 0 to 60. There's flexibility about the range for that
> with me, but if a car is two to three times slower
> than others in that regard, it's a big red flag
So you won't consider cars like the VW Golf, since a Ferrari does
accelerate two or three times fasters.
Actually, I'm sure you didn't think that statement out. Performance
is
only one of many issues---I'd guess that correctness would be the most
important one (but even there---correctness is only important for the
features you use). Or even availability: early implementations of
exceptions used the slower mechanism because they could get the
implementation out the door quicker that way. And so on.
--
James Kanze
tanix
>On Dec 17, 8:11 pm, Brian <c...@mailvault.com> wrote:
>> On Dec 17, 12:27 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> [...]
>> > The machinery isn't that complicated. After all, you need to be
>> > able to walk back the stack in other cases as well (e.g. in a
>> > debugger---and what compiler doesn't come with a debugger). The
>> > alternatives are relatively expensive, and some people do choose
>> > their compiler based on benchmark results (and those benchmarks
>> > rarely test the performance when an exception is thrown). For
>> > better or worse, performance is an issue for compiler
>> > vendors---lower performance means less sales.
>
>> When buying a car I care about how fast it goes from
>> 0 to 60. There's flexibility about the range for that
>> with me, but if a car is two to three times slower
>> than others in that regard, it's a big red flag
>
>So you won't consider cars like the VW Golf, since a Ferrari does
>accelerate two or three times fasters.
Well, what to do if you are zombified with this "power" trip since
the craddle. "Power" is the only thing that counts to most biorobots,
most of whom are complex inferiority driven and zombified with violence
since the craddle. Long story.
>Actually, I'm sure you didn't think that statement out. Performance
>is only one of many issues
Yep, important one, but not the MOST important one in the scheme of things.
>---I'd guess that correctness would be the most
>important one (but even there---correctness is only important for the
>features you use).
Well, correctness is a vague concept overall.
Correctness of what?
Correctness of your powerful and flexible logging and program state
monitoring system that dynamically displays the intermediate states your
program takes while doing some timely and important operations?
Correctness of your user interface design that turns out to be one of
the most important characteristics of any program because it allows you
to do the maximum number of things with the most of ease and conceptually
clear user interface design?
Correctness in terms of being able to recover from any kind of error
and continue on some time expensive operations?
Or simply dumb correctness of the low level algorithms, that are
even being correct, still make your program suck big time overall
as it is totally unintuitive, cumbersome and you name it?
"Correctness" of your documentation and making it available on all
user interface panels, dialog boxes, etc. as a context sensitive
help buttons, clearly describing you the functionality of any GUI
element or well tagged and interlink documentation, describing
your program with a fine enough degree of detail, while, at the
same time not overloading you with tons of crap, just like almost
all the Microsoft documentation does?
Or just describing you things that take at least a couple of good
paragraphs to describe in a single sentence? Again, just like
Microsoft does? Those things can not be describe in a single
sentence, and yet, that is all you get.
Is THAT correctness?
Or, the program being compatible for generations and runs
on any version of o/s, no matter what they invent more or less?
Does THAT count as "correctness"?
Does ANY kind of error handling and reporting count as "correctness"?
> Or even availability: early implementations of
>exceptions used the slower mechanism because they could get the
>implementation out the door quicker that way. And so on.
Well, I thought the early versions of exceptions were the fastest
possible, even in principle, because they utilized the setjmp,
longjmp design and would simply abandon the stack below certain
depth by simply long jumping several levels up the stack to
setjmp label.
Interesting aspect on exception performance I saw on these thread
is the issue of exceptions "being expensive" in terms of processing
overhead. Well, it does count in exceptions of the string to number
conversion and things like that, not even clear it matters that
much because the very conversion itself is very expensive.
But my opinion is that the exception processing overhead is a non
issue since your program runs without exceptions in 99.999% of cases.
But once you do hit some exception, what does it matter how much
of a performance of exeption processing do you get, if your program
is basically screwed at that point, and about the most critical
and most important issue would be an informational aspect of it,
to give the user as much and as clear information about it, as
possible, presenting this error in a listbox of running status,
that could be scolled back to see what happened to your program
even hours ago.
Plus automatic error logging into rotating log files, that are
automatically updated and time stamped ad infinitum.
I think using exceptions in a way that they become a normal flow
of your code is a misuse of exceptions. You should not rely on
exceptions to do program logic. Otherwise the very notion of
ecxeption becomes totally distorted.
Once you hit ANY exception, take as much time as you want
to do anything you want, even going out to disk, error informing,
or anything like that. The more thoughrough job you do processing
exceptions, the better. If you can manage deallocate the heap
memory, great, it matters in C++. Luckily, in Java, it does not
matter. Because the heap deallocation is automatic and really
fine grained and optimized for local scope. So its performance
is non issue.
It is surprising to see that to this day, there is no gc in C++.
In any kind of more or less complex program the chance of memory
leaks is so high, that I doubt there are that many programs that
do not leak memory.
The same thing with threading, gui and other things, C++ is so
missing even after generations.
It's a pitty, Sun decided to take upon Microsoft with their JVM
legal case. That simply killed Java because Microsoft just dropped
it totally from their product line and stopped ANY development
with anything that even sounds Java-ish.
That is probably the biggest tragedy in the software industry,
because the non-dynamically scoped lanugages that are the bread
and butter of software industry, are not being developed.
C++ is a dead end as it stands right now in my opinion.
Today, with all dynamically scoped languages there is no issue
of portability. Take Python, PHP, Ruby, SQL that are running
the world more or less. There is no issue with "does it run
on Linux and Windows"?
And look at this pathetic C++ with all these bizarre syntax
complications. How many people in their clear mind, writing
those Egyptian hieroglyphs with templates think that anyone
else, looking at their code would be willing to spend half
an hour trying to understand that most unintuitive meaning
of those 3 mile long template definitions and all the side
effects of it?
People have milliseconds to look at some code.
I was using Java for several years and, because Microsoft
does not support anything beyond JDK 1.3, which is at leat
10 years old, you can not use generics (templates equivalent
of C++ more or less), or you can not use even swing
functionality (GUI stuff).
But, the best development environment I know of is MS
Visual Studion, and I mean BY FAR. As a result, I was forced
not to ever use generics and to this day, I have not seen
ANY problems with not using them. Yes, casting is not nice,
but in the scheme of things, at least from the stand point
of code clarity, it is MUCH better to use casting than
templates or generics. First of all, I can understand the
code in milliseconds. Try to understand someone elses code,
written by "smart" egghead, who is basically a pervert,
trying to make the simpliest looking thing, look like
a grand unifying theory.
Just look at 3 things that make Java what it is:
1) Built in threads - TOP notch idea. Helps portability
like nothing else.
2) Built-in GC. - TOP notch idea. Memory leaks will prevent
any program from running more than a couple of days in one
go.
3) Built-in GUI. Outstanding idea.
4) Binary compatibility. - The MOST important criteria for me,
BY FAR.
I don't want to write several versions of my programs to be
able to run it on ANY O/S. First of all, all that stuff is
out of the window nowadays becasue dynamically scoped languages
are already taking up the majority of sw business.
WHO in his clear mind would like to EVEN BOTHER about maintaining
all this non portable crap?
And what I am seeing is these C++ purists are sitting here and
running their mealy mouths about "purity of language" to the
point of obscene, chasing away even guys who would like to
discuss the threading, GUI or all other issues on this group.
What are you guys doing here? Trying to dig yourself down
into the ground as fast as you can manage? Digging your own
grave with a back hoe?
Do you want me to talk on 5 different groups about C++
based programming issues? And what does THAT buy you?
Fragmentation of discussions and issues?
Schitsophrenic view on system design?
Totally non-portable code?
Never being able to write a single GUI code for any O/S?
Never being able to run a binary compatible code,
while ALL dynamically scoped languages do it all day long,
ALL over the place?
Wasting weeks on cleaning up the memory leaks?
I have wasted MONTHS on trying to catch all the subtle memory
leaks in a sophisticated async based program because of some
network availability issues make you maintain all sorts of
queues, depending on user interaction, causing such headaches,
that you can not even begin to imagine from the standpoint
of memory leaks.
And still, to this day, I do have a few memory leaks.
Nothing major really, and no one will even notice it even
restarting program several times. But still, there should be
no memory leaks PERIOD.
How do you do it with C++?
Either you wake up, or smell the flowers on the graveyard.
That is the verdict for you, C++ "gurus", writing the most
convoluted crap and presenting it as a particle science
and a grand unifying theory.
It makes me puke seeing most of your code.
Every time I have to deal with someone elses code,
it makes me shiver. Because I know your cunningness and your
complex of inferiority. You'd waste hours writing some most
confusing spagetti, just to make sure it is going to take them
days to understand your code and will make you one of the
"irreplaceable". Job security trip.
Instead of writing the simpliest code that does exactly the same
thing and can be understood within milliseconds by anyone who
knows what he is doing.
Is THAT a progress?
Just look at all these "inventions" and "improvements" in C++?
Where do you think it is going to take you?
And the bottom line, with all that "great" improvement,
your programs still suck balls in vast majority of cases.
What a pitty.
--
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.
Brian
I'm not arguing with that, just saying that with the software
in question, both are free. If price/cost isn't a factor,
I'd definitely take a Ferrari. This reminds me of something
C. S. Lewis said: "We are half-hearted creatures, fooling
about with drink and sex and ambition when infinite joy is
offered us, we are like ignorant children who want to
continue making mud pies in a slum because we cannot imagine
what is meant by the offer of a vacation at the sea. We are
far too easily pleased.” To some extent I think users of
some well-known serialization libraries are making mud pies
in the slums.
Brian Wood
http://webEbenezer.net
tanix
>On Dec 18, 2:29=A0am, James Kanze <james.ka...@gmail.com> wrote:
>> On Dec 17, 8:11 pm, Brian <c...@mailvault.com> wrote:
>>
>> > On Dec 17, 12:27 pm, James Kanze <james.ka...@gmail.com> wrote:
>>
>>
>> > > The machinery isn't that complicated. =A0After all, you need to be
>> > > able to walk back the stack in other cases as well (e.g. in a
>> > > alternatives are relatively expensive, and some people do choose
>> > > their compiler based on benchmark results (and those benchmarks
>> > > better or worse, performance is an issue for compiler
>> > > vendors---lower performance means less sales.
>> > When buying a car I care about how fast it goes from
>> > with me, but if a car is two to three times slower
>> > than others in that regard, it's a big red flag
>>
>> So you won't consider cars like the VW Golf, since a Ferrari does
>> accelerate two or three times fasters.
>>
>> is
>> only one of many issues---I'd guess that correctness would be the most
>> important one (but even there---correctness is only important for the
>> exceptions used the slower mechanism because they could get the
>>
>
>I'm not arguing with that, just saying that with the software
>in question, both are free. If price/cost isn't a factor,
>I'd definitely take a Ferrari.
And I'd take Cadillac Seville.
Do you mind?
I would not take Ferrari even if you pay me.
I'd sell it for all its worth.
What a sick zombie machine!
Have you ever driven a Cadillac Seville 1991?
> This reminds me of something
>C. S. Lewis said: "We are half-hearted creatures, fooling
>about with drink and sex and ambition when infinite joy is
>offered us, we are like ignorant children who want to
>continue making mud pies in a slum because we cannot imagine
>what is meant by the offer of a vacation at the sea. We are
>far too easily pleased.=94 To some extent I think users of
>some well-known serialization libraries are making mud pies
>in the slums.
>
>Brian Wood
>http://webEbenezer.net
--
io_x
"tanix" <ta...@mongo.net> ha scritto nel messaggio
news:hgg839$ot7$1...@news.eternal-september.org...
> In article
> <3eacbb7a-4318-4fed...@s20g2000yqd.googlegroups.com>, James
> Kanze <james...@gmail.com> wrote:
> Wasting weeks on cleaning up the memory leaks?
> I have wasted MONTHS on trying to catch all the subtle memory
> leaks in a sophisticated async based program because of some
> network availability issues make you maintain all sorts of
> queues, depending on user interaction, causing such headaches,
> that you can not even begin to imagine from the standpoint
> of memory leaks.
do you know, exist wrapper for malloc, that at end of the program
check if there are "memory leak" and report the result to the screen
so memory leak can not be one problem if one use these special "malloc"
functions (like i use always with all bell that sound)
Saluti
James Kanze
> In article
> <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>,
> James Kanze <james.ka...@gmail.com> wrote:
[...]
> >---I'd guess that correctness would be the most important one
> >(but even there---correctness is only important for the
> >features you use).
> Well, correctness is a vague concept overall.
> Correctness of what?
Of the compiler, since that's the tool we're talking about. If
the code generated by the compiler doesn't do what the language
says it should, then you have a very big program. It's a low
level correctness, but it's still an essential one.
(I won't bother replying to the rest. The problems of the
poster should be obvious to any reasonably mature person who
reads it.)
--
James Kanze
James Kanze
> "tanix" <ta...@mongo.net> ha scritto nel
> messaggionews:hgg839$ot7$1...@news.eternal-september.org...
> > In article
> > <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>, James
> > Kanze <james.ka...@gmail.com> wrote:
> > Wasting weeks on cleaning up the memory leaks?
> > I have wasted MONTHS on trying to catch all the subtle
> > memory leaks in a sophisticated async based program because
> > of some network availability issues make you maintain all
> > sorts of queues, depending on user interaction, causing such
> > headaches, that you can not even begin to imagine from the
> > standpoint of memory leaks.
> do you know, exist wrapper for malloc, that at end of the
> program check if there are "memory leak" and report the result
> to the screen
If the program ends, it doesn't leak memory, and practically,
there's no way any tool can tell whether there is a leak or not.
(Well, they can tell that some things are definitively leaked.
If there are no pointers to the memory, for example, it has
leaked.) What the tools do is suggest possible leaks.
With regards to the first statement, of course: I've worked on a
fairly large number of applications which didn't leak. Some of
them, you may have used, without knowing it, since many of the
programs I've worked on aren't visible to the user---they do
things like routing your telephone call to the correct
destination. (And the proof that there isn't a leak: the
program has run over five years without running out of memory.)
> so memory leak can not be one problem if one use these special
> "malloc" functions (like i use always with all bell that
> sound)
I'll say it again: there's no silver bullet. In the end, good
software engineering is the only solution. Thus, for example, I
prefer using garbage collection when I can, but it's a tool
which reduces my workload, not something which miraculously
elimninates all memory leaks (and some of the early Java
applications were noted for leaking, fast and furious).
--
James Kanze
James Kanze
> > [...]
You don't have three children:-). I wouldn't mind having a
Ferrari, either, but for day to day use, there are more
practical cars. Regardless of price. With three children and
two dogs, a van beats a Ferrari hands down. If you really live
out in the wilderness, with only dirt roads, you'll probably
prefer a Jeep. And if you have to drive and park a lot in
Paris or London, you'll want something small. As with software,
there's no silver bullet.
With regards to exception handling and C++ (to get back on
subject), if some of the early implementations of exceptions
used slower mechanisms than is considered necessary today, it's
generally because it was a question of supporting exceptions now
with the slower mechanism, or supporting them in two years time
with an optimal mechanism.
Similarly, with regards to optimizing application code: you've
only got so much time to write it in, so it's often a question
of making it take 5 milliseconds less time (over an hour), or
adding a feature. I think all really competent computer
scientists are purists, and would like for every line to be
"optimal" (foremostly in elegance and readability, but also in
terms of performance). I also think that all really competent
software engineers know how and when to make engineering trade
offs.
--
James Kanze
tanix
>
>"tanix" <ta...@mongo.net> ha scritto nel messaggio
>news:hgg839$ot7$1...@news.eternal-september.org...
>> In article
>> <3eacbb7a-4318-4fed...@s20g2000yqd.googlegroups.com>, James
>> Kanze <james...@gmail.com> wrote:
>
>> Wasting weeks on cleaning up the memory leaks?
>> I have wasted MONTHS on trying to catch all the subtle memory
>> leaks in a sophisticated async based program because of some
>> network availability issues make you maintain all sorts of
>> queues, depending on user interaction, causing such headaches,
>> that you can not even begin to imagine from the standpoint
>> of memory leaks.
>
>do you know, exist wrapper for malloc, that at end of the program
>check if there are "memory leak" and report the result to the screen
Well, I AM getting the leak dumps at the end of the program.
The problem is that we have an issue of the same object being
passed around and saved into several queeues and it is not easy
to say who exactly did not do deallocation. There are several
customers.
I had to add the specific stamp to stamp the packet information,
allocated by the driver interface code. So, when buffer is placed
on unknown packet list and it is not possible to process it until
the user decides what you want to do with it, there is nothing
I can do. The unknown packet dialog is an async code. We can not
block until the user decides to respond to unknown packet.
We have to allow other non issue traffic and allow user to
continue on with ANYTHING related to the program, even if he does
not know what to do with that packet for quite a while,
including the need to issue a whois from the same program and
to see wether he wants to allow this traffic now and in the future.
And that means potential delays in processing for upto minutes.
What if the user went to the kitchen meanwhile and someone
attacks his box? The unknown packet dialog is up, and not only
it is up, but there may be the entire queue of packets that
are waiting to be processed if you are being attacked.
On the top of it, all the processing is asynchronous.
So, the packet buffer, and we carry the whole packet buffer
because user may want do dump the packet buffer to see specifics
of the buffer, has to be carried around and either be attached
to the monitor listbox, or held pending.
And all these mechanisms are not and can not be common.
So, WHO did not release the buffer, when and why?
Try to figure out in totally async environment with several
consumers.
Finally, when I stamped the buffers with the allocator ID tag,
i was able to get read of those memory leaks.
But the whole point is that it wooks months to even decide to
go after this issue and it took days to rewrite the code,
including the NDIS driver before the solution was finally there.
You see the issue?
And I NEVER EVER saw the issue of this kind with Java.
One heavy duty program I wrote in Java works like a champ
for years without a SINGLE issue with memory leak and gc is
so efficient that it is not far from automatic stack deallocation.
And to me, personally, the memory leak issues are some of the
top priority items and it is very unfortunate that this issue
is not resolved to this day in C++.
Sure, you don't have the JVM or MVM to rely upon and the whole
thing becomes quite a trip. But these kinds of things eventually
kill the language for all practical purposes.
Take for example the issue with writing a portable GUI code.
It is a nightmare in C++ environment. Microsoft does it their
way, Linux/Unix does it their way, all sorts of graphit toolkits
do it their way. It is a literal nightmare.
With Java, it is a non issue. And GUI power is one of the most
important criterias in determining the program "correctness".
I do not take a notion of program correctness to be the
formal correctness. Formal correctness can only be proven
mathematically. So, for vast majority of programs out there,
it is nothing more than a pipe dream.
And I am not even using the swing version of GUI.
AWT is just fine for what I am doing and the user interface
is probably the best you can imagine in the wildest dreams.
I could care less about swing. Everything is just fine.
But, because I can use VC, even though it does not support
the "latest and gratest" JDK, I can crank out my code
several times faster than they can do with other development
environments. Plus I can run on any O/S without even recompiling,
and in one case, when my window box got rooted to the point
I could not use it for more than a month because that rootkit
was the most sophisticated thing I even knew exists, that
saved my skin. I just switched to Linux and copied some config
files from win version and restarted the operations at the
same exact point where I lost my windows.
How much does THAT kind of thing count to you?
Well, don't know about you, but this is the number one criteria
for me, and I mean number one, not two or three.
And it is a pitty that C++ can not satisfy either of these morst
critical elements for me.
And I saw plenty of posts by different people and their opinions
on it, and it basically lead nowhere. No progress so far that
I know of in none of the most critical areas of modern programming
languages. Even stinky Javascript does not have as many portability
prblems as C++. What a pitty!
>so memory leak can not be one problem if one use these special "malloc"
>functions (like i use always with all bell that sound)
Not do worry, I did all of that.
The point is how much time and energy you have to waste to bother
with stoopid things like memory leaks?
>Saluti
tanix
>On Dec 18, 3:45 pm, ta...@mongo.net (tanix) wrote:
>> In article
>> <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>,
>> James Kanze <james.ka...@gmail.com> wrote:
>
> [...]
>> >---I'd guess that correctness would be the most important one
>> >(but even there---correctness is only important for the
>> >features you use).
>
>> Well, correctness is a vague concept overall.
>> Correctness of what?
>
>Of the compiler, since that's the tool we're talking about.
Well, I thought you are talking about correctness of code,
or formal correctness of your program. To me, I could care
less if compiler exists. It should just compile. That is ALL
I care about, and if we start talking about correctness of
COMPILERS, it tells me there are issues with language itself.
Long subject.
>If
>the code generated by the compiler doesn't do what the language
>says it should, then you have a very big program. It's a low
>level correctness, but it's still an essential one.
I do not argue this point.
It is very unfortunate the issues like these even arise,
even though they forever do in a "real world" situations.
>(I won't bother replying to the rest. The problems of the
>poster should be obvious to any reasonably mature person who
>reads it.)
:--}
To tell you the truth, you were one of my personal favorite
experts on C++ related collection. I always enjoyed reading your
posts because they were not simply dumb. But had depth, some
freshness and insight to them. In other words, a pretty pleasing
favor.
But...
The love affair forever comes to an end. So is the nature of things.
When I met you eye to eye, it was a totally different person.
You bother to reply or you don't "bother" to reply,
it is a matter of intellectual and scientific honesty
and the depth of your insight and a few other things.
It does not matter to me one iota.
It is YOUR choice wethere like to investigate deeper into issues
or remain as a coward, carrying a "holier than thou" mask on your
face. I could care less.
MY choise is to investigate ANY issues I am dealing with, until
no stone is left unturned.
So, I can talk to you until your nose goes blue, unless you lock
up as you just did, which simply means to me my original post
was right on the money, if you flipped out so bad.
So, be thankful to people like me giving you a chance to see
some things about yourself that you suppressed all your life,
carrying that "holier than though" phony mask on your face.
Cause we'll take that mask down in no time and we will see the
raw nature of who you are within the first steps, and that is:
1) Intellectual dishonesty.
2) Scientific dishonesty.
3) Arrogance of "holier than though".
4) Theoretical crap that has very little to do with reality,
as reality, in this particular case, is the issue of C++
basically dying and being replaced in more and more areas
and appications with languages that do not have these kinds
of problems, and some of you "experts" simply refuse to
look into it and realize your house is on fire.
Things like that.
If you do not appreciate all this, not a problem at all.
Balog Pal
> Finally, when I stamped the buffers with the allocator ID tag,
> i was able to get read of those memory leaks.
>
> But the whole point is that it wooks months to even decide to
> go after this issue and it took days to rewrite the code,
> including the NDIS driver before the solution was finally there.
>
> You see the issue?
Not really. You must use some pretty weird design in coding, that
contradicts all suggestions made for some 10-15 years. Then no wonder you
have such issues.
> And I NEVER EVER saw the issue of this kind with Java.
I never had problems with memory leaks in C++. (not like with C). Many
people here have the same experience. Yes, writing programs including
smilar to that you described. Just use a manager, like a smaprt pointer
consistently with every allocation. No leaks possible. (And if you need
to keep blocks unreleased an indefinite time waiting user interaction --
that is not a leak issue, but consequence of a general design decision.)
> One heavy duty program I wrote in Java works like a champ
> for years without a SINGLE issue with memory leak and gc is
> so efficient that it is not far from automatic stack deallocation.
Cool. And *all* I signed off for deployment work the same, and wrt not only
memory but files, locks, and any other stuff that requires cleanup. In C++.
Using the same, quite trivial approach.
> And to me, personally, the memory leak issues are some of the
> top priority items and it is very unfortunate that this issue
> is not resolved to this day in C++.
To my, and probably a big bunch of people this issue is considered as soled
and non-issue for extremely long. If it still hits you there must be some
other issue in the background. And beyond RAII, garbage collection is
also an option to be plugged in, if one really think it is needed or is the
solution for a particular problem.
> Sure, you don't have the JVM or MVM to rely upon and the whole
> thing becomes quite a trip. But these kinds of things eventually
> kill the language for all practical purposes.
LOL. Nice proof.
> Take for example the issue with writing a portable GUI code.
Is there such a thing?
> It is a nightmare in C++ environment.
Quite so. And in any other if you actually mean portability. Then if you
limit it sufficiently, you may reach down to a solution. If you define the
limitation in a special way, sure, that may get similar to a some stock
solution tied with some language too.
> Microsoft does it their
> way, Linux/Unix does it their way, all sorts of graphit toolkits
> do it their way. It is a literal nightmare.
> With Java, it is a non issue.
I saw a couple of projects that switched to java for that property (or
switched the interface, calling out for "work" written in whatever else),
experience shows the picture is far from that bright.
And the "success" stories I saw have a really simple, and uncool
interface -- that looks pretty alien on at least one platform, if not on all
of them.
"non issue" is an easy claim that is prevalent in hype and forums, but
that's it.
> And I am not even using the swing version of GUI.
> AWT is just fine for what I am doing and the user interface
> is probably the best you can imagine in the wildest dreams.
> I could care less about swing. Everything is just fine.
Great. So the next question is what on earth you do in this forum then?
Instead on living the happy life with java and AWT?
> And it is a pitty that C++ can not satisfy either of these morst
> critical elements for me.
Why should C++ do anything when you already found your silver environment?
Why turn C++ to clone an existing and established thing?
> And I saw plenty of posts by different people and their opinions
> on it, and it basically lead nowhere. No progress so far that
> I know of in none of the most critical areas of modern programming
> languages. Even stinky Javascript does not have as many portability
> prblems as C++. What a pitty!
Another mega-LOL. Can't imagine why half of the code fights to determine
what browser it runs on.
And again portabili=ty in your view looks meaning like 2 system sets and
that is it.
While in fact C++ reaches to a massively wider set. With some requirements
on the user, and with attached cost. While other languages made the choice
up fronmt to limit where they work. TANSTAAFL.
>>so memory leak can not be one problem if one use these special "malloc"
>>functions (like i use always with all bell that sound)
>
> Not do worry, I did all of that.
> The point is how much time and energy you have to waste to bother
> with stoopid things like memory leaks?
My measure is 0 in simple situations, and "not worth mentioning" where the
design is complex.
tanix
I am not going to comment on exceptions.
This issue is done to me. I know EXACTLY how to architect
and strucuture my code so that it works like a tank,
no matter what happens. It is a subtle mix of return codes
and exception mechanism, but there IS a solution, and it
is all implemented in one of my Java programs, the main
program I use.
>Similarly, with regards to optimizing application code: you've
>only got so much time to write it in, so it's often a question
>of making it take 5 milliseconds less time (over an hour), or
>adding a feature.
Well, to me, optimization is indeed one of the major criteria,
except I view optimization from the stand point of architecture.
There are different ways to structure your code,
or architect the system.
The major criteria for me are:
1) Minimization of the size of executable,
which indirectly translates into correctness of your code
and flexibility of your structure and program architecture.
2) System architecture.
Structuring the program is more important to me than
tweaking some routines to get the most bang for a buck.
3) Expandability and extensibility.
No matter what you write, you will have to forever expand it,
add more features and bells and whistles.
If your architecure is not "correct",
it is going to be a royal pain on your rear end to add
something QUICKLY.
I can add totally new functionality to my code within minutes,
no matter what i want. Typically, a MAJOR restructuring
takes several hours. At most a day or two.
So, I can expand my code as fast as I get some new idea
or feature.
4) Portability.
A tough one. Forget about it in the C++ world.
Such a major headache, that it is realistically undoable
unless you maintain several code bases.
With Java - a pice o cake. Non issue.
5) Robustness.
And THAT is where these nasty exceptions come in handy.
You'll never be able to write a stable code, and I mean
TRULY stable, if you do not use exceptions.
Otherwise, your code is going to be such a huge file of
conditional spagetti, that only God, omniscient, will be
able to see the net result.
Exceptions are a MUST.
But...
No need to get wild on it.
Exceptions should not be a part of your logic.
After all, what guides your program in 99.999% of all cases
is those nasty ifs and buts and not "something does not work".
So, exceptions should not be a part of your underlying logic.
They are your defense system against ANY kinds of problems.
You can NEVER assume that ANY operation is going to complete
without problems. In the middle of some routine, you may
loose power, just for the sake of argument.
That means, that once you restart your program, and it was
in the middle of doing some heavy duty processing, you should
be able to recover and continue on, if at all possible,
even in principle.
6) Never, under ANY condition, ignore ANY errors, even if
it looks like it will never happen and your code works fine
as it is.
Unless you handle the most inconceivable thing,
such as seemingly utterly meaningless return code,
your program eventually and inevitably will crash
one of these days.
7) Always complete your code.
Once something is written, it should be written to the state
of completeness. Meaning. You should be able to rely on that
code no matter what happens and no matter what kind of crazy
thing you may invent in the future with your system.
The complete code is easy to extend and restructure.
8) Program is a system.
This is probably the #1 item on the list.
Any more or less useful program is a SYSTEM.
It is not just a pile of code.
a) The most important system parameter is what?
Well, stability.
If system can EVER crash, you are dead and your program
isn't work a dime more or less.
b) The system is not a dissasociated set of ideas,
methods and routines.
It is an organism, alive, just like anything else on this
physical plain.
Any system has subsystems, performing diferent sub-tasks
to accomodate the living whole.
Subsystems, in their turn are also systems.
There needs to be a well thought out architecure
to minimize the number of subsystems and maximize the
bang for a buck.
Subsystems need to communicate with each other
and provide "sockets" for relating with other subsystems
or the master system. The best way to assure that is to
do all the communications via master system, which
is the main module of your program.
Every subsystem is guaranteed to know one thing
and one thing only: there IS a master system it serves.
It can rely on existance of it.
All interfaces should be constructed via master system.
No subsystem should attempt to communicate with the other
subsystem, or even know of its existence, if at all possible.
This way, your program architecture and structuring
of your code will be automatically optimized in most
cases and situations.
Do not worry about performance first. But keep it in mind
no matter what you write.
The original ideas need to be fundamental enough to
provide a significan enough benefit to even bother about
implementing it. From that standpoing, the modelling is
the most critical thing at this junction.
Once you implement your model and test it to sufficient
degree, then you will be able to see the weak points
and those things you did not think about initially.
At that point, you can start thinking about optimization.
But not before it.
Never start writing the most optimized code from the
fist take. Becaue it is not even clear it will become
a bottleneck in the final system.
Just tweaking things for the sake of "performance",
is the same thing as blind leading the blind.
The end result is the abyss.
> I think all really competent computer scientists are purists,
Good. Keep them in museums then.
If someone has time to look at that stuff before the
end of times, and we have about 2 generations to go
before REAL hell will rage on the planet Earth,
abused to the hilt.
Get the hint, mr. "expert"?
> and would like for every line to be
>"optimal" (foremostly in elegance and readability, but also in
>terms of performance).
Fine and dandy.
In THEORY.
In reality there is such a thing as "bang for the buck".
The "economics" of anything created.
The "purity" of code is more or less a mental masturbation
excersize, and I am not trying to be insultive.
I also keep in mind the code purity.
What I can tell is is this.
The 3-5 meg programs I wrote do pretty much the same thing,
if not better, than a typica half a gig sized bloatware,
written by "top guns".
That is ALL I need to say about "optimization"
or "purity of code", or "correctness", no matter what you
imply by it, and what scope you are referring to.
> I also think that all really competent
>software engineers know how and when to make engineering trade
>offs.
I have to agree on this one.
Enjoy the ride.
:--}
tanix
>"tanix" <ta...@mongo.net>
>
>> Finally, when I stamped the buffers with the allocator ID tag,
>> i was able to get read of those memory leaks.
>>
>> But the whole point is that it wooks months to even decide to
>> go after this issue and it took days to rewrite the code,
>> including the NDIS driver before the solution was finally there.
>>
>> You see the issue?
>
>Not really. You must use some pretty weird design in coding, that
>contradicts all suggestions made for some 10-15 years. Then no wonder you
>have such issues.
Cool. You are the kind of person I like to talk to then.
The only issue is I could describe you the situation,
but it is going to be a long post. But let me try and see
if you can suggest something "better".
Ok, the situation is this:
I have a monitoring firewwall app, that is the number one program
for me, no matter what. That is the first thing I install once
I install a new operating system.
What it does is this:
There is a monitor window, that shows all the network packets
that are not a normal and safe traffic.
There are several rule sets: stealth, trusted, policy and per adapter.
The program supports as many network adapters as you wish.
When normal traffic occurs, you don't see anything. It just all works.
When you are attacked, or there is some fishy traffic,
the unknown packet dialog box pops up, if you click on "prompt"
checkbox in the main program window.
When some packet arrives, the driver checks all appropriate rule sets,
and if it does not have a rule for that packet, it places it on its
NDIS intermediate driver queue and sends the packet and all relevant
info to the user app.
Once the user app gets a funky traffic indication, what can it
possibly do? Well, if no "prompt for unknown traffic" checbox
is checked, it simply quietly drops that traffic.
But if it IS checked, then what can you possibly do?
First of all, all such traffic is automatically displayed in the
listbox in the monitor view. So, what you have is a buffer
allocated for the entire packet and for other service information,
so that the app can do all sorts of things and make all sorts of
decisions.
If, hours later, you decide to look at the actual packet data
for any packet int he monitor window, all you have to do is to
click on some packet in the monitor window and the click on
"show packet" button in the main window.
Two mouse clicks in toto to see ANYTHING that is fishy going on,
going back in time as long as you want.
Now. Since the listbox has a pointer to a buffer, allocated to
that packet, it is reponsible for releasing that buffer once the
monitor window reaches the max number of monitor entires you
are interested in seeing in the future. That may be seconds,
minutes or even days into the future.
But what if you have "prompt for unknow" checkbox enabled?
Well, a lil tough one. In order for you to inform the driver
about one of funky packets on its pending queue, you need
to create a rule for such packets: either allow or deny them,
or do nothing, meaning if such a packet happens in the future,
you'll start from the top.
So, do you need to know abut that packet if user goes to his
kichen to get a cup of tea?
Sure you do.
It is all pending until user finally clicks of some checkbox
in the unknow packet.
The processing of unknown packets is thus asyncronous.
Furthermore, you may have a NUMBER of those packets on a queue,
in case you are being attacked.
Zo...
How do you design such a thing?
ANY clue?
Gimmme your rough model and we'll see whose code is designed
"better".
>> And I NEVER EVER saw the issue of this kind with Java.
>
>I never had problems with memory leaks in C++.
I bow down to you, or immortal!
Except my lips are smiling.
What a fool they say in combination with my brain.
> (not like with C). Many
>people here have the same experience. Yes, writing programs including
>smilar to that you described. Just use a manager, like a smaprt pointer
>consistently with every allocation. No leaks possible. (And if you need
>to keep blocks unreleased an indefinite time waiting user interaction --
>that is not a leak issue, but consequence of a general design decision.)
Well, may be. If I ever find time to look at the design again,
who knows, I may even consider your "smart pointer" suggestion.
>> One heavy duty program I wrote in Java works like a champ
>> for years without a SINGLE issue with memory leak and gc is
>> so efficient that it is not far from automatic stack deallocation.
>Cool. And *all* I signed off for deployment work the same, and wrt not only
>memory but files, locks, and any other stuff that requires cleanup. In C++.
>Using the same, quite trivial approach.
:--}
You must be trully great. What a pleasure.
Let me see if you are on an expert filter list.
Uuups. You are not. Well, now you are.
Welcome to programmer's golmine world.
Now your articles are guaraneed to be seen by the cream of the
crop around the world, the biggest names in industry and ANY
industry for that matter, including the leaging universities,
libraries, the biggest names in sw industry and you name it.
From now on, whatever you write is going to be presented in
a highly fitlered expert section on all major issues with C++
language, tools, mechanisms, methods, programming techniques
and you name it.
Btw, since I am spending a few days around on this group,
if any of you, experts (those, that know what they are talking
about) have any idesa, proposals, new chapter requests,
filter specifications, be my guest. You can email your feedback
to preciseinfo at mail dot ru.
From now on, you are a part of global information system,
providing the top quality, to the point information on C++
for generations to come.
Once you write something, we don't have to deal with that issue
any longer, if your writing is up to snuff.
From then on, there is no need to suffer in the buffer for days,
trying to see what is wrong and where or how do you do this and
that.
Dig?
>> And to me, personally, the memory leak issues are some of the
>> top priority items and it is very unfortunate that this issue
>> is not resolved to this day in C++.
>
>To my, and probably a big bunch of people this issue is considered as soled
>and non-issue for extremely long.
I am glad to hear that.
Unfortunately, I don't know you enough to see how much
what is you say is worth. ALL I know is it is solved for what
I am doing in Java, which is my preferred language for several
years, and I am happy to hear that you think it is solved in C++
also, even though I have my doubts.
> If it still hits you there must be some
>other issue in the background. And beyond RAII, garbage collection is
>also an option to be plugged in, if one really think it is needed or is the
>solution for a particular problem.
Cool. I did not know that. Not that I much care about it now.
Again, I am working in Java lately. Do not have much hope for
C++ and would not invest a penny into writing any new code in C++,
unless it is absolutely necessary, which I do not see so far.
>> Sure, you don't have the JVM or MVM to rely upon and the whole
>> thing becomes quite a trip. But these kinds of things eventually
>> kill the language for all practical purposes.
>
>LOL. Nice proof.
:--}
I am glad to hear that!!!
>> Take for example the issue with writing a portable GUI code.
>
>Is there such a thing?
Yep. Ther IS. Believe it or not.
It is called AWT or modern version is called swing.
Gives you 100% portable GUI code.
Sure, the fine details of the LOOk of some visual components
are going to be rendered slightly differently, especially in
light of Microsofts pattent issues. But the overall functionality
of your GUI is going to work 100% on any platform wher you can
install the JVM. Simple as that.
Beyond that, it is a non issue in Java.
Because of that JVM idea, which is the equivalent of MVM,
except of totally sick limitations placed by Microsoft on
making it as simple and as straightforward to implement
and deliver as a single app.
The nice thing about Microsoft MVM is that is has about twice
better performance than Suns JVM, which is what I really
appreciate. Because when I do my processing, archive updates
and site generation, jobs run into hours, if not days.
>> It is a nightmare in C++ environment.
>Quite so. And in any other if you actually mean portability.
Yes, I actually DO mean portability.
And it is a non issue with Java.
Sorry to tell you that.
And I mean BINARY compatibility.
Meaning you can run your executable code without even recompiling
on ANY O/S where you can install a JVM, which is free, no string
attached virtual layer on the top of O/S, which shields you from
memory leaks, GUI, threading issues, and ALL sorts of things,
including the language syntax, which is FAR superior to C++
in my opinion.
It is like a hand in glove for me now.
When I had to fix some bugs in my monitoring firewall, written
i C++, it was like a headache in comparison to anything I wrote
in Java. It was like visiting some ancient fortress, filled
with spider webs all over.
Sorry to tell you that.
Even stoopid and clumsy PHP looks more exciting to me,
with ALL its limitations and weirness.
Yes, it is because of things I am doing lately.
But during the last several years, I had not a single urge
to write some code in C++.
Sure, lots of water has flown down the river and I did see
some stuff you guys write here, except it is too late.
The train has left the station for me.
> Then if you
>limit it sufficiently, you may reach down to a solution. If you define the
>limitation in a special way, sure, that may get similar to a some stock
>solution tied with some language too.
>
>> Microsoft does it their
>> way, Linux/Unix does it their way, all sorts of graphit toolkits
>> do it their way. It is a literal nightmare.
>
>> With Java, it is a non issue.
>
>I saw a couple of projects that switched to java for that property (or
>switched the interface, calling out for "work" written in whatever else),
>experience shows the picture is far from that bright.
Well don't know where you get it from.
But it is bright enough for what I am interested in.
In fact, I'd say it is far superior to all the Microsoft ugly
hacks in GUI design, that cause nothing more than goose bumps
when I even think of it. I can implement a much better functionality
of GUI in Java in about 2 to 10 times less of a time,
doing ANYTHING I can imagine as far as GUI goes.
>And the "success" stories I saw have a really simple, and uncool
>interface -- that looks pretty alien on at least one platform, if not on all
>of them.
Too bad. I don't happen to share your opinion.
But again, I am interested in thing I am doing,
and not just some abstract theory of perfection.
So, who knows, you might have some point here,
except lil do I care. I am fine as is right now.
>"non issue" is an easy claim that is prevalent in hype and forums, but
>that's it.
Sorry. I stand by what I say.
When I say non issue that is what it means literally.
There is no issue that I see.
And I am not peddling Java here. Too bad everyone seems to be
abandoning it in a hurry. The traffic on Java collections of mine
are about 10 times as small as for MFC.
And, interestingly enough, C++ traffic is no more than
a half of MFC/VC/ATL/STL collection, which tells ME something.
Not sure if it tells YOU something though.
>> And I am not even using the swing version of GUI.
>> AWT is just fine for what I am doing and the user interface
>> is probably the best you can imagine in the wildest dreams.
>> I could care less about swing. Everything is just fine.
>
>Great. So the next question is what on earth you do in this forum then?
>Instead on living the happy life with java and AWT?
Do you mind?
:--}
To tell you the truth, I do not know.
I just came here a couple of days ago for some small things.
One thing leads to another.
I saw some posts on programming issues.
So...
I think the issue of exceptions is significant enough,
and when someone asks for an opinion, do you mind if I have an
opinion? Or you have nothing better to do in your life besides
poking your nose into affairs of others and questioning their
integrity?
:-}
>> And it is a pitty that C++ can not satisfy either of these morst
>> critical elements for me.
>
>Why should C++ do anything when you already found your silver environment?
>Why turn C++ to clone an existing and established thing?
Ok, enough for this one.
Looks like a hopeless case indeed.
I don't deal with people, biased out of their head.
Cya.
>> And I saw plenty of posts by different people and their opinions
>> on it, and it basically lead nowhere. No progress so far that
>> I know of in none of the most critical areas of modern programming
>> languages. Even stinky Javascript does not have as many portability
>> prblems as C++. What a pitty!
>
>Another mega-LOL. Can't imagine why half of the code fights to determine
>what browser it runs on.
>
>And again portabili=ty in your view looks meaning like 2 system sets and
>that is it.
>
>While in fact C++ reaches to a massively wider set. With some requirements
>on the user, and with attached cost. While other languages made the choice
>up fronmt to limit where they work. TANSTAAFL.
>
>>>so memory leak can not be one problem if one use these special "malloc"
>>>functions (like i use always with all bell that sound)
>>
>> Not do worry, I did all of that.
>> The point is how much time and energy you have to waste to bother
>> with stoopid things like memory leaks?
>
>My measure is 0 in simple situations, and "not worth mentioning" where the
>design is complex.
--
Balog Pal
> Ok, the situation is this:
[whole story can be replaced with "you have to keep info on arbitrary number
of incoming network packets for arbitrary long time"]
That much was clear from previous posts. And it has little to do with memory
leaks or their prevention.
I see no problem to create your thing without leaks, as for every packet
there is a clear set of conditions when to keep and when to let go.
OTOH your requirements provide no upper limit resource usage, so if the
program just does keep the stuff around, it will fill the memory, or the
disk, or anything, just keep that checkbox checked and walk away.
If you actually want help with leaks, better describe what you do and how
you got them. (Though you said you already got rid of them, it is hardly
your aim, probably you just test how much posts people here read before
plonk or something... )
> How do you design such a thing?
> ANY clue?
>
> Gimmme your rough model and we'll see whose code is designed
> "better".
>>> And I NEVER EVER saw the issue of this kind with Java.
Better explain why java turns out to manage infinite amount of resources
better. ;-)
Is it like Chuck Norris, who did count to infinity? Twice! ?
>>I never had problems with memory leaks in C++.
>
> I bow down to you, or immortal!
>
(***) > Except my lips are smiling.
> What a fool they say in combination with my brain.
Guess if you saved up the trolling time to study well-known methods, you'd
be out of the swamp long ago. For sure, whining and blaming is easier.
>> (not like with C). Many
>>people here have the same experience. Yes, writing programs including
>>smilar to that you described. Just use a manager, like a smaprt pointer
>>consistently with every allocation. No leaks possible. (And if you
>>need
>>to keep blocks unreleased an indefinite time waiting user interaction --
>>that is not a leak issue, but consequence of a general design decision.)
>
> Well, may be. If I ever find time to look at the design again,
> who knows, I may even consider your "smart pointer" suggestion.
Just curious, you DID hear about existance of std::string, std::vector,
std::tr1:shared_ptr?
> Dig?
next thing on my stack is
http://programmer.97things.oreilly.com/wiki/index.php/Edited_Contributions
and CERT's C++ section...
>>> And to me, personally, the memory leak issues are some of the
>>> top priority items and it is very unfortunate that this issue
>>> is not resolved to this day in C++.
>>
>>To my, and probably a big bunch of people this issue is considered as
>>soled
>>and non-issue for extremely long.
>
> I am glad to hear that.
> Unfortunately, I don't know you enough to see how much
> what is you say is worth.
I'm sure. Your recent post suggest you hardly consirer anyone worth
listening to, including Sutter, Abrahams, so I'm not eager to fight for your
approval.
> ALL I know is it is solved for what
> I am doing in Java, which is my preferred language for several
> years, and I am happy to hear that you think it is solved in C++
> also, even though I have my doubts.
Java can collect only memory, with other resources you're almost as hosed as
in C. Well, you have finally to replace goto shutdown, still far from nice
and safe.
>> If it still hits you there must be some
>>other issue in the background. And beyond RAII, garbage collection is
>>also an option to be plugged in, if one really think it is needed or is
>>the
>>solution for a particular problem.
>
> Cool. I did not know that. Not that I much care about it now.
> Again, I am working in Java lately. Do not have much hope for
> C++ and would not invest a penny into writing any new code in C++,
> unless it is absolutely necessary, which I do not see so far.
So you admit that your presence here and the lengthy posts are just
trolling. ;)
>>> Take for example the issue with writing a portable GUI code.
>>
>>Is there such a thing?
>
> Yep. Ther IS. Believe it or not.
> It is called AWT or modern version is called swing.
> Gives you 100% portable GUI code.
> Sure, the fine details of the LOOk of some visual components
> are going to be rendered slightly differently, especially in
> light of Microsofts pattent issues. But the overall functionality
> of your GUI is going to work 100% on any platform wher you can
> install the JVM. Simple as that.
"generally portable" and "where JVM exists" is quite a diference.
> The nice thing about Microsoft MVM is that is has about twice
> better performance than Suns JVM, which is what I really
> appreciate. Because when I do my processing, archive updates
> and site generation, jobs run into hours, if not days.
>
>>> It is a nightmare in C++ environment.
>
>>Quite so. And in any other if you actually mean portability.
>
> Yes, I actually DO mean portability.
You just admitted you do not a few lines ago.
> And it is a non issue with Java.
Sure. All you need is an already ported Java, and a big deal of resources.
I know java is preferred by many programmers -- I also know that the result
is so often hated by users. Even those having resources in abundance.
> Sorry to tell you that.
You actually think I'm unaware what java can and can't do?
>>I saw a couple of projects that switched to java for that property (or
>>switched the interface, calling out for "work" written in whatever else),
>>experience shows the picture is far from that bright.
>
> Well don't know where you get it from.
> But it is bright enough for what I am interested in.
> In fact, I'd say it is far superior to all the Microsoft ugly
> hacks in GUI design, that cause nothing more than goose bumps
> when I even think of it. I can implement a much better functionality
> of GUI in Java in about 2 to 10 times less of a time,
> doing ANYTHING I can imagine as far as GUI goes.
Just for a sanity check, you know what common cotrold are in Windows, and
what the listview control is?
>>And the "success" stories I saw have a really simple, and uncool
>>interface -- that looks pretty alien on at least one platform, if not on
>>all
>>of them.
>
> Too bad. I don't happen to share your opinion.
If all you have is a hammer everything looks like a nail. ;-)
> And I am not peddling Java here. Too bad everyone seems to be
> abandoning it in a hurry. The traffic on Java collections of mine
> are about 10 times as small as for MFC.
>
> And, interestingly enough, C++ traffic is no more than
> a half of MFC/VC/ATL/STL collection, which tells ME something.
> Not sure if it tells YOU something though.
What traffic?
>>> And I am not even using the swing version of GUI.
>>> AWT is just fine for what I am doing and the user interface
>>> is probably the best you can imagine in the wildest dreams.
>>> I could care less about swing. Everything is just fine.
>>
>>Great. So the next question is what on earth you do in this forum then?
>>Instead on living the happy life with java and AWT?
>
> Do you mind?
> :--}
Not really, just never understood the approach. I don't like java, but
express that by simply staying away. Not by going to java forums and start
flames. Either on made-up issues the real practicioners there know better
to be a non-issue, or real pains, that they also know ways better.
When I'm confident, I don;t need to prove it to anyone.
> To tell you the truth, I do not know.
> I just came here a couple of days ago for some small things.
> One thing leads to another.
> I saw some posts on programming issues.
> So...
> I think the issue of exceptions is significant enough,
> and when someone asks for an opinion, do you mind if I have an
> opinion?
Me? Absolutely not. ;) Opinions are like assholes, everyone has one, and
not very interested in others'...
> Or you have nothing better to do in your life besides
> poking your nose into affairs of others and questioning their
> integrity?
see (***) ?
>>> And it is a pitty that C++ can not satisfy either of these morst
>>> critical elements for me.
>>
>>Why should C++ do anything when you already found your silver environment?
>>Why turn C++ to clone an existing and established thing?
>
> Ok, enough for this one.
> Looks like a hopeless case indeed.
> I don't deal with people, biased out of their head.
> Cya.
LOL.
tanix
>"tanix" <ta...@mongo.net>
>
>> Ok, the situation is this:
>
>[whole story can be replaced with "you have to keep info on arbitrary number
>of incoming network packets for arbitrary long time"]
I know, I know. I had to deal with one liner mentality for quite a while.
But you see, if you write these one liners, you are basically dealing
with bio robots.
There is no fun of a story in one liners.
That is why I suggested on other thread that before you get into
programming, first learn about beauty. Then learn about music.
And ONLY THEN we are going to have any luck talking to people like you.
I do not happen to communicate in one liners of a type
"coca cola is good. drink coca cola".
Because I perceive it as programming instructions for zombies
and biorobots.
Do you mind?
>That much was clear from previous posts. And it has little to do with memory
>leaks or their prevention.
Uhu. I am glad to see another smart guy on my way in life.
What DOES have it to do with?
Who knows, I might even think of changing some things in that
app if I see some revolutionary breakthroughs and some deep
you know what insights from the guys like you.
>I see no problem to create your thing without leaks, as for every packet
>there is a clear set of conditions when to keep and when to let go.
Nope, sire. I don't think you even BEGIN to comprehend the set of issues.
I guess I have to write an article twice as big as the original one.
But sorry, I am not in the mood right now. Plus there are other things
in my life.
>OTOH your requirements provide no upper limit resource usage, so if the
>program just does keep the stuff around, it will fill the memory, or the
>disk, or anything, just keep that checkbox checked and walk away.
Nope. Not even in the picture.
There is no such a problem.
You just did not read the original post carefully enough.
There IS an upper limit on resource useage and it is determined
by the max size of the monitor entry list. Typically, you don't need
to keep > 1000 entries in the monitor list cause that will keep enough
history for you to go back several days, if not months.
And it is a configurable parameter from the control panel.
I typically run with 200 entries upper limit.
Once this limit is exceeded, the memory is deallocated in the
monitor view list control.
As far as pending "unknown packet" queues, there are limits also.
As far as intermediate NDIS driver goes, there are limits on
pending queues also. Plus there are time outs.
Zo...
We are in a good shape. This is a non issue.
Sorry not to be able to write it all out in one liner
to please people like you, lil do I care if you even exist though
in the scheme of things...
:--}
>If you actually want help with leaks, better describe what you do and how
>you got them.
Sorry. I have no more time to spend on it.
I'd have to waste several hours to describe things in sufficient
details and things like that.
If you have an idea from what I already wrote, fine.
Be my guest. You don't? Fine. Not a problem at all. Just enjoy
the trip of life.
> (Though you said you already got rid of them, it is hardly
>your aim, probably you just test how much posts people here read before
>plonk or something... )
You are really a royal waste of time, Jack.
Cya.
James Kanze
> "tanix" <ta...@mongo.net>
[concerning memory leaks...]
> > And I NEVER EVER saw the issue of this kind with Java.
> I never had problems with memory leaks in C++. (not like with
> C).
Interesting. I can't remember ever having had any problems with
memory leaks in C. I do remember one in C++, recently. Due to
a compiler error resulting in the compiler not calling a
destructor. (But it wasn't in code I'd written. Had the code
been slightly cleaner, it wouldn't have triggered the compiler
error. But VC++ has problems with getting the destructor calls
right if you return in the middle of a loop.) But most of the
leaks I've seen have been in Java. Not because of the language,
but because of people trying to get the code out the door too
quickly, making the classic error of skipping on the design,
because "that's not what we're delivering".
The secret, of course, is good up front design. It's true that
it requires more work to avoid all leaks in C than it does in
C++, and (slightly) more work in C++ than in Java, but if you're
organization doesn't do good up front design (and design and
code reviews, and unit tests, and all the rest), you will have
problems (and Java won't solve them), and if it does, then you
won't have memory leaks. The advantage of things like garbage
collection isn't that they solve problems you wouldn't solve
otherwise---they don't. The only advantage is that they reduce
the total amount of work necessary in the solution.
> Many people here have the same experience. Yes, writing
> programs including smilar to that you described. Just use a
> manager, like a smaprt pointer consistently with every
> allocation. No leaks possible.
And that's the kind of comment which gives C++ a bad name.
There are no silver bullets, and in well designed code, you
typically don't have that many smart pointers. (Although I'm
pretty sure it depends on the application domain---there are
probably domains where boost::shared_ptr solves 90% of your
memory management problems. I've certainly not worked in such a
domain, however.)
> (And if you need to keep blocks unreleased an indefinite time
> waiting user interaction -- that is not a leak issue, but
> consequence of a general design decision.)
The classical case of a leak is when you "register" a session in
a map, mapping it's id to the session object, and forget to
deregister when the session ends. At least, something along
those lines accounts for most of the leaks I've seen.
> > One heavy duty program I wrote in Java works like a champ
> > for years without a SINGLE issue with memory leak and gc is
> > so efficient that it is not far from automatic stack
> > deallocation.
Note that this is very application dependent. Actual allocation
with a copying collector is about the same as alloca in terms of
performance, and if you can arrange for all of the runs of the
garbage collector to be in otherwise dead time, you'll likely
significantly outperform a system using manual allocation. But
there are a couple of if's in there---for most applications I've
seen, the performance difference between garbage collection and
manual allocation won't be significant, and there are
applications where garbage collection is significantly slower,
or simply can't be used.
> Cool. And *all* I signed off for deployment work the same,
> and wrt not only memory but files, locks, and any other stuff
> that requires cleanup. In C++. Using the same, quite trivial
> approach.
I'll repeat: there's no silver bullet. And I've yet to see a
smart pointer which solved all of the memory management issues
without significant additional work.
[...]
> > Take for example the issue with writing a portable GUI code.
> Is there such a thing?
For any reasonable definition of "portable". (No GUI code can
be made to work on an embedded system without a terminal, for
example.) One of the advantages of Java is that Swing is
actually fairly well designed. From what little I've seen of
the C++ GUI libraries (where unlike Java, you do have a choice),
they weren't as well designed. But they're likely sufficient
for a lot of applications---I know that I use GUI applications
(e.g. Firefox) which are written in C or C++, and they more or
less work.
--
James Kanze
James Kanze
> In article <hgkcfk$1kg...@news.ett.com.ua>, "Balog Pal"
> <p...@lib.hu> wrote:
> >"tanix" <ta...@mongo.net>
> >> Ok, the situation is this:
> >[whole story can be replaced with "you have to keep info on
> >arbitrary number of incoming network packets for arbitrary
> >long time"]
> I know, I know. I had to deal with one liner mentality for
> quite a while.
> But you see, if you write these one liners, you are basically
> dealing with bio robots.
> There is no fun of a story in one liners.
> That is why I suggested on other thread that before you get
> into programming, first learn about beauty. Then learn about
> music. And ONLY THEN we are going to have any luck talking to
> people like you.
Well, I find his version more beautiful than yours. It's
obviously not complete, but it does sum up the issues for one
part of the application in a very clear and concise manner.
(And as my high school English teacher used to say: "Good
writing is clear and concise.")
> I do not happen to communicate in one liners of a type "coca
> cola is good. drink coca cola". Because I perceive it as
> programming instructions for zombies and biorobots.
> Do you mind?
Yes. You seem to prefer long, drawn out descriptions which jump
back and forth between issues. That's not what I'd consider
good writing.
Note that I'm not saying that such things shouldn't occur. But
you're description sounded like a first brainstorming session,
when you really don't know yet what the application should do.
Balog's is, of course, too simple, in that it only addresses one
aspect of the problem. But he has gotten over the first design
issue: breaking the problem up into simpler problems, which can
each be addressed by a simple statement.
My first reaction to your description is that you obviously need
two processes: one doing the filtering, and another to manage
the GUI. With a queue between them. In this case, from
experience, I'd say that two processes are a must, because you
want the filtering to maintain as small a footprint and use as
few resources as possible. Which means, BTW, that I would do it
in C++, and that I wouldn't use garbage collection, since
garbage collection does have a significant memory overhead (and
in such filtering applications, unlike a lot of other
applications, doesn't really buy you that much). For the GUI,
I'd use Java, because I know Swing, and I don't know any of the
C++ GUI libraries.
For the queue itself, I'd try to use something provided by the
system, because writing robust and rapid queue management in
Java is a pain. (You need to access system services to do it
efficiently.) Lacking something in the system, I'd write the
queue management in C++, and use JNI to interface with it on the
Java side.
--
James Kanze
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
[...]
> >Similarly, with regards to optimizing application code:
> >you've only got so much time to write it in, so it's often a
> >question of making it take 5 milliseconds less time (over an
> >hour), or adding a feature.
> Well, to me, optimization is indeed one of the major criteria,
> except I view optimization from the stand point of
> architecture.
> There are different ways to structure your code, or architect
> the system.
> The major criteria for me are:
> 1) Minimization of the size of executable,
> which indirectly translates into correctness of your code and
> flexibility of your structure and program architecture.
That's interesting, because memory use is one of the big costs
for garbage collection. I've actually used garbage collection
in C++ at times, and I know how to write C++ code which uses the
Boehm collector, but for the application you described
else-thread, I wouldn't do it, because the memory overhead of
garbage collection is just too high (and because for that
particular problem, garbage collection just doesn't buy you that
much anyway).
> 4) Portability.
> A tough one. Forget about it in the C++ world.
> Such a major headache, that it is realistically undoable
> unless you maintain several code bases.
> With Java - a pice o cake. Non issue.
My experience is exactly the opposite. Java's portability is
limited to machines which have a good JVM. Which isn't many.
C++ works on pretty much everything.
> 5) Robustness.
> And THAT is where these nasty exceptions come in handy.
> You'll never be able to write a stable code, and I mean TRULY
> stable, if you do not use exceptions.
Explain how applications have been running for years, without
interruption, and without using exceptions. (The application in
question was written before C++ supported exceptions.)
Exceptions are a useful tool, for certain things, but like all
tools, you can do without (at some development cost) if you have
to.
[...]
> So, exceptions should not be a part of your underlying logic.
> They are your defense system against ANY kinds of problems.
> You can NEVER assume that ANY operation is going to complete
> without problems. In the middle of some routine, you may
> loose power, just for the sake of argument.
In which case, you won't be able to process an exception.
> That means, that once you restart your program, and it was in
> the middle of doing some heavy duty processing, you should be
> able to recover and continue on, if at all possible, even in
> principle.
So you need persistent transactions. You're not the first
person to need them, and a lot of applications use them,
including applications written long before anyone had ever heard
of exceptions.
[...]
> > I think all really competent computer scientists are purists,
> Good. Keep them in museums then.
Nothing like taking a quote out of context, is there?
--
James Kanze
Balog Pal
>> Many people here have the same experience. Yes, writing
>> programs including smilar to that you described. Just use a
>> manager, like a smaprt pointer consistently with every
>> allocation. No leaks possible.
>
> And that's the kind of comment which gives C++ a bad name.
I don;t see much difference between my comment and yours -- we do similar
things (proper design and match it in code) and have the same result (no
leaks).
> There are no silver bullets, and in well designed code, you
> typically don't have that many smart pointers.
I said "manager" that is *like* a smart pointer. string, vector, list is a
manager, and is not a smart pointer. I certainly agree that stts on a
regular program would find ust a few smart pointers compared to anything
else.
But safe coding have consistent manager usage, replacing "raw" stuff. Just
like you wrote before, that dynamic allocation is not left in a raw pointer,
but put in a smart one, and .release() it at return or transferuing to
another manager.
Even if it looks like done "immediately" with just one line between. ;-)
> (Although I'm
> pretty sure it depends on the application domain---there are
> probably domains where boost::shared_ptr solves 90% of your
> memory management problems. I've certainly not worked in such a
> domain, however.)
Me neither. Still I think it is a good forum reference.
>> (And if you need to keep blocks unreleased an indefinite time
>> waiting user interaction -- that is not a leak issue, but
>> consequence of a general design decision.)
>
> The classical case of a leak is when you "register" a session in
> a map, mapping it's id to the session object, and forget to
> deregister when the session ends. At least, something along
> those lines accounts for most of the leaks I've seen.
Yeah, we discussed it a few weeks ago. This has nothing to do with coding
or any language -- a flaw in design/reqs that will hit in any possible
implementation.
>> > One heavy duty program I wrote in Java works like a champ
>> > for years without a SINGLE issue with memory leak and gc is
>> > so efficient that it is not far from automatic stack
>> > deallocation.
>
> Note that this is very application dependent. Actual allocation
> with a copying collector is about the same as alloca in terms of
> performance, and if you can arrange for all of the runs of the
> garbage collector to be in otherwise dead time, you'll likely
> significantly outperform a system using manual allocation. But
> there are a couple of if's in there---for most applications I've
> seen, the performance difference between garbage collection and
> manual allocation won't be significant, and there are
> applications where garbage collection is significantly slower,
> or simply can't be used.
To start with the memory footprint starts as 2-3x as big. Actually did
anyone heard a reporting firewall implemented in java?
>> Cool. And *all* I signed off for deployment work the same,
>> and wrt not only memory but files, locks, and any other stuff
>> that requires cleanup. In C++. Using the same, quite trivial
>> approach.
>
> I'll repeat: there's no silver bullet. And I've yet to see a
> smart pointer which solved all of the memory management issues
> without significant additional work.
Well, my mistake, I planned to write a summary of the last discussion to sum
up the point where misunderstanding remains -- then decided they must be
evident.
Trivial approach here applies to transfering design to code, not solution in
general. The hard part is to have an abstract design that matches/solves
the problem. That includes the flow of information, and makes clear which
pieces are needed at which point.
My experience that the work to code it in a leak-free way is piece of cake
in comparision, when the flow is complicated. And when it is
straightforward you can do it with eyes closed.
> [...]
>> > Take for example the issue with writing a portable GUI code.
>
>> Is there such a thing?
>
> For any reasonable definition of "portable". (No GUI code can
> be made to work on an embedded system without a terminal, for
> example.) One of the advantages of Java is that Swing is
> actually fairly well designed.
Can't comment on that.
One of my current project picked java UI with Swing because it has
auto-layout. What sounds like a cool idea when you must issue the app in a
dozen languages. And you can just have a ranslation table for the UI
strings, the rest will work.
Well, in practice it wasn't all that bright, and the auto property turned to
create a big deal of issues when translated stuff had a different size...
On windows I still keep stumbling into programs that spoil the interface
just because I have "big font" setting. (using 1280x1024 res was far from
common back in '98 but I thought today lowes should be strange...)
The point is, I see examples that GUI gets spoiled even on the same
platform, using its natural features -- either having the items fixed or
auto-moving.
That keeps me generally sceptic wrt GUI portability. Without a big deal of
manual work at the QA dept and coding too...
> From what little I've seen of
> the C++ GUI libraries (where unlike Java, you do have a choice),
> they weren't as well designed.
Well, at elast the libraries for windows do use the Windows UI the natural
way, and give you access to common controls. So at least can solve the
situation where the req says to work on Windows, but there correctly,
intuitively and user-friendly.
Portability to other platforn is not something everyone seeks, and if so do
not want to sacrifice anything for unused generality.
tanix
>On 19 Dec, 21:39, "Balog Pal" <p...@lib.hu> wrote:
>> "tanix" <ta...@mongo.net>
>
> [concerning memory leaks...]
>> > And I NEVER EVER saw the issue of this kind with Java.
>
>> I never had problems with memory leaks in C++. (not like with
>> C).
>
>Interesting. I can't remember ever having had any problems with
>memory leaks in C.
Ok, I am going to take this one up just one more time.
Beyond it, sorry, could care less.
> I do remember one in C++, recently. Due to
>a compiler error resulting in the compiler not calling a
>destructor.
I bow down to you, oh, holey ghost.
> (But it wasn't in code I'd written.
Sure. Understood. How COULD it be, considering how great
you are?
> Had the code
>been slightly cleaner, it wouldn't have triggered the compiler
>error. But VC++ has problems with getting the destructor calls
>right if you return in the middle of a loop.)
There are problems up to your gazoo in a more or less complex
app, at least from what I know, not you.
> But most of the
>leaks I've seen have been in Java.
WHAT?
Is it some kind of insult?
Are you going to fall THAT low?
> Not because of the language,
>but because of people trying to get the code out the door too
>quickly, making the classic error of skipping on the design,
>because "that's not what we're delivering".
Does not matter in Java more or less within the reasonable
set of limitations.
In Java memory leaks ARE possible. But THEORETICALLY.
Not practically. If you understand how gc works, you would
NEVER make such a statement.
Could you give me an example of the situation that will cause
a memory leak in Java? I'd be curious to see that one.
And I can give you an example of memory leaks in C++,
that will crack your scull trying to avoid them,
especially in async environment.
>The secret, of course, is good up front design.
Blah, blah, blah.
That is NOT how real world works.
Do you think you waste half a year on your great "design"
in real life?
Nope. You have a functionality requirements in most situations
I had to deal with. The "design" is driven by the sales and
marketing department.
"We want this and this and that".
And we want it NOW.
Actually, we want it YESTERDAY.
You have about 2 weeks to do a job that should normally
take at least 2 months to a competent programmer.
And THAT is how it works in the silicon valley at least.
I have NEVER EVER seen a SINGLE company that does
"good design". I am not even sure they know what it means
to begin with.
Because it is so expensive that most of them can not even
BEGIN thinking in those terms.
> It's true that
>it requires more work to avoid all leaks in C than it does in
>C++, and (slightly) more work in C++ than in Java,
WHAT?
Is this some kind of insult?
SLIGHTLY more than in Java?
I would defietely like to see some substantiation of this
argument, even though I already know the end of the story.
> but if you're
>organization doesn't do good up front design
And WHICH organization does that kind of thing?
You mean Intel?
- nah.
You mean HP?
- nah
You mean SGI?
- nah
You mean Fujitsu?
- nah.
You man Amdahl, for god's sake, the competitors of no one
less than IBM?
- nah.
WHO then?
Well, no one I know of. Sorry to tell you.
"Good design" is the kind of crap they brainwash you wit
at computer school.
It does not exist, unless you do your own project at home
and could care less how much is it going to "cost" you
or hoe much time is it going to take.
But, putting aside the fun part of it,
it is actually a FUNDAMENTAL issue.
What is "good design" by definition?
Well, it is something that does not exist!
Why?
Well, becaue how do you create something?
Well, initially you have some idea to create a product that
does this and that.
At THAT stage, you only have a pin sized view on ALL sorts
of issues that may or may not arise as you start implementing
some of this stuff and start seeing the situations you did
not even expect to have when you had your initial idea.
Yes, no question about it. If you are "smart" and have enough
of experience and are not simply hacking away at it, you DO
know how to walk the mine field and how to avoid the most of
pitfalls. But that is the ART part of programming. Not science,
necessarily.
If you do appreciate beauty and to appreciate the music,
as it is about the most abstract and most fundamental aspect
of comprehending what the structures are, then yes, you will
be able to design and code your stuff much better than if you
don't.
But...
At the end, what is FOREVER happening is that you never know
what is going to happen tomorrow. You may be just called into
a salesman's office and he will tell you something that will
make your hairs raise.
You may never know how exactly do you want to make some of
your GUI panels look like and what kind of program parameters
do you want to expose to user, or what kind of logging system
you are going to implement.
Are you going to waste some heavy duty time to write some
"general purpose, omnipotent logging system" in ANY project?
Why?
How much is it going to cost you?
How portable is it going to be if in one environment you might
have log4j and in another evnironment there is no such a thing?
And what about robustness?
Do you know all the exceptions in your future project?
Oh, you mean you are going to take a two year sabbatical
and lay back on some beach on one of the virgin islands
and do your great design there?
Do you even begin to comprehend what good design is worth?
Well, first of all, it has to be done by the systems architect
level guys, just to make sure.
How much do you pay those guys?
Well, at LEAST $150/hr. and that is a CHEAP one.
Can you multiply some numbers?
Well, I can tell you witout calculator, for any more or less
complex program that is even worth mentioning, you are talking
high end 5 or 6 figure numbers.
Simple as that.
And that is for a SINGLE person.
And on and on and on.
> (and design and code reviews,
Screw those. About the sickest idea I had to deal with.
WHO is going to "review" YOUR code?
They are upto hilt with THEIR code?
WHAT kind of thing they are going to do on YOUR code?
Well, they are going to find some trick and some totally
meainingless lil piece of crap they can find, just to
discredit you and make you feel guilty. So everyone on
a "code review panel" could see how "great" THEY are,
not you.
Do you understand?
If you call me on a code review to see someone elses code,
how much of a chance do I have to see some of the most
subtle tricks in HIS code by simply looking at it for a half
an hour, which is what you have most of the time?
How much time do you think I have to review YOUR code
and then someone elses code, and then someone elses?
You want me to spend half of my time doing YOUR "code review"?
Are you a lunatic?
Do you live in a world of pipe dreams?
> and unit tests,
Yes, AND unit tests,
AND system tets,
and ANY tests you can imagine.
The more, the better.
> and all the rest), you will have
>problems (and Java won't solve them),
Are you a pervert by ANY chance?
What I see is this sadistic pleasure on your end.
You see, if you said such a thing on a java group,
they'd tare you to pieces, if they even cared to bother
about it. At best, they'd make you look like fool,
and laugh their arses off you.
You must be some "moron" to them if you even conceive
saying things like that. Becaues this is about the highest
order insult to Java as a concept.
Because these things are some of the CENTRAL concepts
in the whole Java world.
> and if it does, then you won't have memory leaks.
Who does what?
Java won't solve them?
And if it does, you won't have memory leaks?
What kind of logic is this, sire?
Never heard of anything like this?
Too much work without sleep?
> The advantage of things like garbage
>collection isn't that they solve problems you wouldn't solve
>otherwise---
Bullshit.
That is EXACTLY what they are meant to do.
Otherwise, just hack away, trying to waste upto 10-30% of your
time forever worrying about memory deallocation issues.
Oh, you mean that "smart pointer" paradise?
Well, sorry to tell you, I haven't looked at that thing yet,
and unfortunately have no plans to ever do.
But... I do have my reservations about it.
Not that I do not trust what you are saying outright.
>they don't.
Oh yes they do.
I have have as hard of an evidence as it gets
and I process such immense amounts of data and so many different
allocations of so many different object types, that I am not sure
it is going to be easy for you something even more stretching,
unless you are a major world bank or a government, doing billions
of records processing.
> The only advantage is that they reduce
>the total amount of work necessary in the solution.
Not only reduce. They simply eliminate it.
Yes, I do prefer to explicitly deallocate most of objects
by resetting the "pointers" to null so that gc kicks in as
soon as it can.
Because, first of all, I have such amounts of allocated memory,
that even after I stop some major operation, there may be tens
if not hundreds of megs still sitting idle and not being
deallocaed by gc because i am holding those pointers.
And the reason I am holding those pointers is that if you are
interested in looking at some of your results in various program
dialogs, you still have ALL of the most important information
available, even AFTER the operation is totally completed
and success status has been reported, shown to you in your active
dialog and logged into a perpetual rotating log file, down to
quite a minute details of your entire operation or a job,
within the reasonable granularity.
>> Many people here have the same experience.
The same as what?
>> Yes, writing
>> programs including smilar to that you described. Just use a
>> manager, like a smaprt pointer consistently with every
>> allocation. No leaks possible.
Well, again. Sorry to tell you. But I have not looked at an
issue of "smart pointers". I can not argue this one.
ALL I can say: great.
If I ever have time, I'll look at it and may be, you never
know, may be, will find some time to convert my code to use the
"smart pointer". Even though I doubt very much I'll be able
to find some time to waste on this. Because by now it is
quite acceptable as is and I am about the only one, who is
even aware of this issue. Because it does not matter at all.
You can run this program for years and as long as you don't
restart it, you won't have the memory leaks. Well, I AM a
bit stretching it, just for the sake of arugument.
Just to show the relative significance of it.
And, if you are going to tell me that there is no memory
leaks problems with C++, or they are not much more difficult
to handle than in Jave, sorry, I do have my reservations.
>And that's the kind of comment which gives C++ a bad name.
>There are no silver bullets, and in well designed code, you
>typically don't have that many smart pointers.
Well, I am quite happy with my design. But there are intricacies.
> (Although I'm
>pretty sure it depends on the application domain---there are
>probably domains where boost::shared_ptr solves 90% of your
>memory management problems.
Sorry, I don't want to hear the word boost, unless it is
totally compatible with Visual Studio compiler without me
moving a finger more or less.
What I DO want to hear is the trick you are going to show
me that will make the memory leaks go away by using a
standard, off the shelf environment under windows,
and the name of that envirionment is Visual Studio.
That is ALL I want to hear, no matter how great anybody's
compiler or development environment is.
Sorry to tell you this.
> I've certainly not worked in such a
>domain, however.)
Too bad. Try to deal with driver related issues.
That helps.
>> (And if you need to keep blocks unreleased an indefinite time
>> waiting user interaction -- that is not a leak issue, but
>> consequence of a general design decision.)
I did not say infinite.
But, I DO have an option of keeping some information
for a more or less infinite time, considering the scope
of practical events. After all, what was the oldest packet
are you interested in seeing trying to check when was the
last time your box was attacked or you saw some funky packet
just now and are interested in seeing when was the last time
you might see it before?
Well, not more than 24 hrs. more or less.
And that is "infinite" in the scheme of things.
Now, I DO have that packet held for you and you CAN look at
it in the packet display window and you can take all the time
you want to do that kind of thing. And I will hold that and
ANY other fishy packet for you at least for hours.
And THAT is the kind of design I like.
I mean TOTAL flexibility. As much as total can be applied
to anything on the physical domain.
>The classical case of a leak is when you "register" a session in
>a map, mapping it's id to the session object, and forget to
>deregister when the session ends. At least, something along
>those lines accounts for most of the leaks I've seen.
>
>> > One heavy duty program I wrote in Java works like a champ
>> > for years without a SINGLE issue with memory leak and gc is
>> > so efficient that it is not far from automatic stack
>> > deallocation.
>
>Note that this is very application dependent.
Yes, no argument on that one.
> Actual allocation
>with a copying collector is about the same as alloca in terms of
>performance, and if you can arrange for all of the runs of the
>garbage collector to be in otherwise dead time, you'll likely
>significantly outperform a system using manual allocation.
You don't "arrange" ANYTHING as far as garbage collector goes.
It does its thing and you can not even force to garbage collect
even though there is a call to gc(). But that call is not
guaranteed to garbage collect. It is hist a hint to gc that
it MAY collect this stuff.
GC is a pretty sophisticated algorithm.
I have not looked at the source, but from what I heard about
it from the top level experts, it IS definetely an impressive
piece of code and I am glad it is there.
I did watch the memory deallocation issue quite carefully.
Becaues I am dealing with terabytes of data allocation/deallocation
in millions of allocations. So, if ANYTHING just sneases,
this whole thing is going to get screwed up beyond belief
and I may loose so much time, that I am not even interested
in tell you how much this is. It may turn out to be days,
if not weeks if something fishy happens.
> But
>there are a couple of if's in there---for most applications I've
>seen, the performance difference between garbage collection and
>manual allocation won't be significant, and there are
>applications where garbage collection is significantly slower,
>or simply can't be used.
I do not agree on that one.
From what I saw and tested and verified and a pretty memory
intensive situations is that I can hardly even notice gc exists.
First of all, what do you think happens if you deallocate memory
manually? Well, what happens on the O/S level, this buffer has
to be returned to a memory pool. If this buffer happens to be
an ajacent to some other memory region, it has to be merged
so the allocator can find the best fit existing buffer.
Which means? Well, which means that no matter wether you have
gc or not, the underlying mechanisms are pretty much similar
to what gc does and the net effect as far as overall system
performance is not that significant. Probably in the range
of 5% of your performance, even though I am pulling this
number out of the hat.
>> Cool. And *all* I signed off for deployment work the same,
>> and wrt not only memory but files, locks, and any other stuff
>> that requires cleanup. In C++. Using the same, quite trivial
>> approach.
>
>I'll repeat: there's no silver bullet. And I've yet to see a
>smart pointer which solved all of the memory management issues
>without significant additional work.
Oh, I see. So those "smart pointers" are not exactly the
kind of magic you guys are selling it to be?
Well, that is exactly what I suspected before I even looked at it.
In fact, I do not believe in this magic to the least.
> [...]
>> > Take for example the issue with writing a portable GUI code.
>
>> Is there such a thing?
Why did you stip my response?
One more time: YES, there IS such a thing!
>For any reasonable definition of "portable". (No GUI code can
>be made to work on an embedded system without a terminal,
Huh?
Ok. good enough for now?
> for
>example.) One of the advantages of Java is that Swing is
>actually fairly well designed. From what little I've seen of
>the C++ GUI libraries (where unlike Java, you do have a choice),
>they weren't as well designed. But they're likely sufficient
>for a lot of applications---I know that I use GUI applications
>(e.g. Firefox) which are written in C or C++, and they more or
>less work.
>
--
tanix
Too bad.
Not interested.
Cya.
--
tanix
>On 19 Dec, 21:42, ta...@mongo.net (tanix) wrote:
>> In article
>> <668a7a4b-a2ee-4999-b3bc-5020bdac1...@k4g2000yqb.googlegroups.com>,
>> James Kanze <james.ka...@gmail.com> wrote:
>
> [...]
>> >Similarly, with regards to optimizing application code:
>> >you've only got so much time to write it in, so it's often a
>> >question of making it take 5 milliseconds less time (over an
>> >hour), or adding a feature.
>
>> Well, to me, optimization is indeed one of the major criteria,
>> except I view optimization from the stand point of
>> architecture.
>
>> There are different ways to structure your code, or architect
>> the system.
>
>> The major criteria for me are:
>
>> 1) Minimization of the size of executable,
>> which indirectly translates into correctness of your code and
>> flexibility of your structure and program architecture.
>
>That's interesting, because memory use is one of the big costs
>for garbage collection.
Forget about garbage collection on this thread I suggest.
I don't have that problem at the moment.
I have a different problem now. And that is win 7 related
problem of a perfectly good app with perfectly good, well
written NDIS device driver not working as advertized under
win 7. For one thing, it reports 2 more network adapters
than the XP reports. The names of those adapters are totally
diffetent than what XP reports. A major pain on the butt.
So, win 7 is no go for me. Because THAT app is the only
app I care about if I ever run windows of any kind.
Screw win 7. Does not worth it. Just becasue Microsoft want
to make another trillion bux and wasted at least 5 years on
developing this totally dead end win 7, does not mean I
have to buy into their trip.
> I've actually used garbage collection
>in C++ at times,
Wut?
> and I know how to write C++ code which uses the
>Boehm collector,
Good for you. I am impressed.
Cause I don't!
:--}
> but for the application you described
>else-thread, I wouldn't do it, because the memory overhead of
>garbage collection is just too high (and because for that
>particular problem, garbage collection just doesn't buy you that
>much anyway).
I am not sure about this. But I trust your word on it.
I'd have to take half of the day to even think about it.
Sorry, can not afford it at this time.
>> 4) Portability.
>> A tough one. Forget about it in the C++ world.
>> Such a major headache, that it is realistically undoable
>> unless you maintain several code bases.
>
>> With Java - a pice o cake. Non issue.
>My experience is exactly the opposite.
WHAT?
Why are you trying to continuously insult my intelligence?
Not nice!
:--}
> Java's portability is
>limited to machines which have a good JVM.
Correct.
> Which isn't many.
Well, about 90% of total market from what I know.
Good enough for a poor guy like me.
>C++ works on pretty much everything.
True. No argument on that one.
Except of some REALLY nasty details.
>> 5) Robustness.
>> And THAT is where these nasty exceptions come in handy.
>> You'll never be able to write a stable code, and I mean TRULY
>> stable, if you do not use exceptions.
>
>Explain how applications have been running for years, without
>interruption, and without using exceptions.
Well, THEORETICALLY, it can happen even without using exceptions.
In reality, it is just a joke.
For one thing, without exceptions your code becomes a huge pile
of spegetti code and I know what I am talking about.
So, it simply becomes more difficult to even see the subtle points
in your code because there is so much informational noise if you
do not use the exception mechanism.
You see, with exceptions, you have a rougher granularity of your
logic. For the applications I have to deal with right now it
translates into things like you have several levels deep in your
execution. If ANY kind of error happens on ANY of those levels,
you have a chance to hangle it on a local bulk level, vs.
checking every single call return result, which is really not
necessary.
Say, for example, you are establishing the network connection.
It does not much matter what kind of error you are going to get
even if you have to execute several methods to do that,
such as authentication or what have you.
All that matters is that you could have not established a
connection. Yes, you DO want to know why, but that can be
handled with a single exception. This is just an overall idea.
The same thing if you are downloading something from the
network. Even if you unplug the network wire in the middle
of no matter which level deep on the stack, you get at most
2 levels of exceptions. One is the lowest level network,
and the 2nd one is logical level of doing some operation.
Now, if you look at how many calls had to be made and how
many return codes you'd have to examine, it may be tens
if not hundreds, depending on what exactly you are doing
So, with exceptions you have only two things that trigger,
and if you user return codes, your code size and your
program logic becames twices as big and trice as complicated
with all those conditional spagetti code.
I do not know what kind of argument I can possibly provide
if you are so biased AGAINST exceptions. Sorry.
It is a psychology trip. Not a programing issue to me.
> (The application in
>question was written before C++ supported exceptions.)
>Exceptions are a useful tool, for certain things, but like all
>tools, you can do without (at some development cost) if you have
>to.
Sorry. I can not agree with you on this one.
I think you are somehow predisposed AGAINST exceptions.
If that is the case, we will be arguing here untill our noses
go blue with no benefit that I can see.
> [...]
>> So, exceptions should not be a part of your underlying logic.
>> They are your defense system against ANY kinds of problems.
>> You can NEVER assume that ANY operation is going to complete
>> without problems. In the middle of some routine, you may
>> loose power, just for the sake of argument.
>
>In which case, you won't be able to process an exception.
True. But...
The trick is the program state logging.
You see. I can just turn off the power switch on my UPS off,
and after I reboot and restart the program, I am GUARANTEED
to continue on from the same exact point.
Why?
Well, because the very last successful logical operation
that resulted in the file update was logged and all the IDs
of relevant elements were saved. Yes, it IS a lil overhead.
About 1-2% I estimated. But the benefit can not be underestimated,
at least in MY situation.
Sure, if a nuclear war starts out, forget about those stinky
computers!
>> That means, that once you restart your program, and it was in
>> the middle of doing some heavy duty processing, you should be
>> able to recover and continue on, if at all possible, even in
>> principle.
>So you need persistent transactions.
Correct.
> You're not the first
>person to need them, and a lot of applications use them,
>including applications written long before anyone had ever heard
>of exceptions.
So what?
I know for fact that what I do works MUCH better with exceptions.
You know why?
Well, because I originall had this code without exceptions.
But when I fully implemented the exception mechanism, I was able
to get read of probably 30% of my code, if not more,
and reliability probably went up a number of times.
I do not even know how to estimate it.
At this point, it is like a tank.
Unless you loose your entire hard disk, it is going to work
not matter what and not matter who says what for or against it.
I am just as pretty sitting with it as it gets.
> [...]
>> > I think all really competent computer scientists are purists,
>
>> Good. Keep them in museums then.
>
>Nothing like taking a quote out of context, is there?
Well, there are ALL sorts of things in life.
Depends on what turns you on.
But to hear such a thing from YOU?
tanix
Oh. Now that you mentioned it, just for the kicks of it,
I might conside rewriting the code in Java so it can run under
Linux/Unix cause linux firewall suck so bad, I can not even
begin to tell you.
The only problem I have is low level driver.
Under windows, I have a NDIS inermediate driver,
which simply translates into fact that my drier sits as close
to the wire as it gets. Just above the minipor, which is your
netowork card driver. This means that I can intercept ANY
traffic, even traffic from other firewalls, installed simultaneously
on the same box.
And my firewall is the only one I know of that does not conflict
with any other network related apps that use low level kernel
drivers. Because all others use totally ugly hacks of intercepting
the data structure in the kernel with all sorts of hooks.
You can not install 2 different firewalls on the same box.
You'll have a blue screen orgasm.
Why do you want to install > 1 firewall?
Well, because first of all, most of them are bluff.
They let any questionable traffic through and you don't get the
security out of it as you think you do. Secondly, all of them
have their strong points and weak points.
So, I run 2 firewalls on my box. The number one is my own,
which is a monitoring firewall. Meaning, I can see ANY funky
network traffic. NOTHING escapes me. There is no firewall
I know of that can do that kind of thing, even though I did
not look at the firewall market for a couple of years.
So, as far as rewriting this thing in Java, that is not
a big deal. I think it can be done in a couple of months.
But... There is a low level driver.
What do you do with it on Linux?
I did not investigate it, but looks like a lil problem there.
But, thanx for a hint. I WILL consider rewriting it in Java.
I see no problems whatsoever besites the low end of it, the
O/S interface.
>>> Cool. And *all* I signed off for deployment work the same,
>>> and wrt not only memory but files, locks, and any other stuff
>>> that requires cleanup. In C++. Using the same, quite trivial
>>> approach.
>>
>> I'll repeat: there's no silver bullet. And I've yet to see a
>> smart pointer which solved all of the memory management issues
>> without significant additional work.
>
>Well, my mistake, I planned to write a summary of the last discussion to sum
>up the point where misunderstanding remains -- then decided they must be
>evident.
>
>Trivial approach here applies to transfering design to code, not solution in
>general. The hard part is to have an abstract design that matches/solves
>the problem. That includes the flow of information, and makes clear which
>pieces are needed at which point.
>
>My experience that the work to code it in a leak-free way is piece of cake
>in comparision,
I feel jealous!
:--}
> when the flow is complicated. And when it is
>straightforward you can do it with eyes closed.
Maaan. I wish I could afford to hire you as consultant.
But I am afraid to even ask for your rate...
>> [...]
>>> > Take for example the issue with writing a portable GUI code.
>>
>>> Is there such a thing?
>>
>> For any reasonable definition of "portable". (No GUI code can
>> be made to work on an embedded system without a terminal, for
>> example.) One of the advantages of Java is that Swing is
>> actually fairly well designed.
>
>Can't comment on that.
And I can. Because I wrote more GUI code than most of you combined
I bet.
Yes. You CAN write a portable GUI code.
>One of my current project picked java UI with Swing because it has
>auto-layout.
My favorite layout is Gridbag, as screwed up as it is
and with all inconsistency of its behavior,
it beats all others hands down.
I don't even care to get some non standard layout all sorts of
people sell. I like it standard. No hacks allowed, no matter
how pretty they might look on paper.
> What sounds like a cool idea when you must issue the app in a
>dozen languages. And you can just have a ranslation table for the UI
>strings, the rest will work.
>Well, in practice it wasn't all that bright, and the auto property turned to
>create a big deal of issues when translated stuff had a different size...
Well, fonts are a different world alltogether.
Combined with localization issues, forget about it.
You can not even guarantee that using the same most basic
English verions, you are going to get it rendered the same on
a different platform.
I just give users an option to reconfigure ANYTHING they want.
Fonts, colors, buttons and you name it.
So, if they like some font, but it renders differently on their
platform, be my guest. Change it in a single config file.
I do not even care to give them a luxury to do it in a sexy, GUI way.
There is a text configuration file. Open it in your favorite text
editor and change those things till your nose goes blue.
It is all self explanatory. If you can not figure it out,
too bad. You need a lobotomy work done.
:--}
>On windows I still keep stumbling into programs that spoil the interface
>just because I have "big font" setting.
Agreed. The windows granularity of "small", "medium" and "big"
is just for the morons. Actually, I do not know what kind of
idiot could even conceive such an idea.
Big to someone who has poor eye sight is small to someone who has
a good one.
Fonts do not have "big" or "small" attributes.
They have font sizes and those are the only things that are
standartized.
I have the same problem with my new screen.
I'd like to make fonts about 20-30% bigger.
But when I switch to next bigger font size,
it jumps proably 50% in size.
Disgusting.
And you are talking about these purist ideas about
"good software design" when the biggest and baddest players
in the industry shit right into your face with screwups of
THIS level of dumbness?
> (using 1280x1024 res was far from
>common back in '98 but I thought today lowes should be strange...)
>The point is, I see examples that GUI gets spoiled even on the same
>platform, using its natural features -- either having the items fixed or
>auto-moving.
Correct. Even with Java, if you run a JMV vs. MVM, the rendering of
your GUI is totally different. Even scrollbars and buttons look
totally different. But you can not expect THIS level of granularity.
Not in foreceable future I bet.
>That keeps me generally sceptic wrt GUI portability. Without a big deal of
>manual work at the QA dept and coding too...
Well. I don't take that.
The issue of portability to me is the issue of being able to run
the same thing on a different platofrm. It is not the issue of how
GOOD it may look or how fast it may run.
Yes, the performance of MVM is better than JVM at least twice.
But you can still run it.
The rendering is not the same, even on the same O/S.
But you can still run it and it all works.
>> From what little I've seen of
>> the C++ GUI libraries (where unlike Java, you do have a choice),
>> they weren't as well designed.
>Well, at elast the libraries for windows do use the Windows UI the natural
>way, and give you access to common controls. So at least can solve the
>situation where the req says to work on Windows, but there correctly,
>intuitively and user-friendly.
>Portability to other platforn is not something everyone seeks, and if so do
>not want to sacrifice anything for unused generality.
But I thought that is what portability means.
Never mind.
Have fun.
Brian
It might make sense to learn one of those C++ GUI libs since
then the filtering could be done in a thread.
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
io_x
> In article <4b2d02b2$0$1111$4faf...@reader2.news.tin.it>, "io_x"
> <a...@b.c.invalid> wrote:
>>
>>"tanix" <ta...@mongo.net> ha scritto nel messaggio
>>news:hgg839$ot7$1...@news.eternal-september.org...
>>> In article
>>> <3eacbb7a-4318-4fed...@s20g2000yqd.googlegroups.com>, James
>>> Kanze <james...@gmail.com> wrote:
>>
>>> Wasting weeks on cleaning up the memory leaks?
>>> I have wasted MONTHS on trying to catch all the subtle memory
>>> leaks in a sophisticated async based program because of some
>>> network availability issues make you maintain all sorts of
>>> queues, depending on user interaction, causing such headaches,
>>> that you can not even begin to imagine from the standpoint
>>> of memory leaks.
>>
>>do you know, exist wrapper for malloc, that at end of the program
>>check if there are "memory leak" and report the result to the screen
>
> Well, I AM getting the leak dumps at the end of the program.
> The problem is that we have an issue of the same object being
> passed around and saved into several queeues and it is not easy
> to say who exactly did not do deallocation. There are several
> customers.
i don't know for your difficult problem; my easy problem for leak was
"from one pointer address
print in the screen like leak
to find where in the code
was the problem"
if i remember well
i restart (run always in a debugger)
the program with the same input and trace
using the debugger who
reserve the memory of that pointer
when i know where is the code not free it,
all the rest was very easy
io_x
"James Kanze" <james...@gmail.com> ha scritto nel messaggio
news:4f3858fa-d8e2-4c92...@s31g2000yqs.googlegroups.com...
> On Dec 19, 4:51 pm, "io_x" <a...@b.c.invalid> wrote:
>> "tanix" <ta...@mongo.net> ha scritto nel
>> messaggionews:hgg839$ot7$1...@news.eternal-september.org...
>
>> > In article
>> > <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>, James
>> > Kanze <james.ka...@gmail.com> wrote:
>> > Wasting weeks on cleaning up the memory leaks?
>> > I have wasted MONTHS on trying to catch all the subtle
>> > memory leaks in a sophisticated async based program because
>> > of some network availability issues make you maintain all
>> > sorts of queues, depending on user interaction, causing such
>> > headaches, that you can not even begin to imagine from the
>> > standpoint of memory leaks.
>
>> do you know, exist wrapper for malloc, that at end of the
>> program check if there are "memory leak" and report the result
>> to the screen
>
> If the program ends, it doesn't leak memory, and practically,
> there's no way any tool can tell whether there is a leak or not.
if there is "no way any tool can tell whether there is a leak or not"
that programming language has one all you call "designed error"
because can eat memory more than is sufficient
because all you can not have the controll on memory
> (Well, they can tell that some things are definitively leaked.
> If there are no pointers to the memory, for example, it has
> leaked.) What the tools do is suggest possible leaks.
>
> With regards to the first statement, of course: I've worked on a
> fairly large number of applications which didn't leak.
so in the first statemt you say:
"there's no way any tool can tell whether there is a leak or not"
in the other you say
"I've worked on a
fairly large number of applications which didn't leak."
so do how you can be sure?
if pass some of your programs with some "leak print at end" program
possibily find some leak (or you OS-compiler allow to see if one program
has some leak (not free all memory) )
for my little programs in my enviroment i'm sure for the memory
of the malloc wrapper (not for the memory released from "new" (i never use
it but should be used from the compiler or for static object if
i rember well))
> Some of
> them, you may have used, without knowing it, since many of the
> programs I've worked on aren't visible to the user---they do
> things like routing your telephone call to the correct
> destination. (And the proof that there isn't a leak: the
> program has run over five years without running out of memory.)
possibily the leak is small and/or in some corner case
>> so memory leak can not be one problem if one use these special
>> "malloc" functions (like i use always with all bell that
>> sound)
>
> I'll say it again: there's no silver bullet.
the silver bullet exist in all
> In the end, good
> software engineering is the only solution. Thus, for example, I
> prefer using garbage collection
> when I can, but it's a tool
> which reduces my workload, not something which miraculously
> elimninates all memory leaks (and some of the early Java
> applications were noted for leaking, fast and furious).
are you sure is it good for think less?
are you sure is it good for not doing formal
correct memory allocation-deallocations?
> --
> James Kanze
tanix
Here is a piece of writing for you.
See if you can beat it:
http://preciseinfo.org/Convert/We_are_here_to_change_the_world_01.html
And if I ever talk to you again, remember:
THAT is where we stand.
Cya.
>> I do not happen to communicate in one liners of a type "coca
>> cola is good. drink coca cola". Because I perceive it as
>> programming instructions for zombies and biorobots.
>> Do you mind?
>Yes. You seem to prefer long, drawn out descriptions which jump
>back and forth between issues. That's not what I'd consider
>good writing.
Too bad.
Not interested.
Cya.
--
tanix
That'd be cool if it was a realistic situation.
But things are much more involved. Long story.
>if i remember well
>i restart (run always in a debugger)
>the program with the same input and trace
>using the debugger who
>reserve the memory of that pointer
>when i know where is the code not free it,
>all the rest was very easy
Yep. We know all that.
But thanx for the input.
tanix
>
>"James Kanze" <james...@gmail.com> ha scritto nel messaggio
>news:4f3858fa-d8e2-4c92...@s31g2000yqs.googlegroups.com...
>> On Dec 19, 4:51 pm, "io_x" <a...@b.c.invalid> wrote:
>>> "tanix" <ta...@mongo.net> ha scritto nel
>>> messaggionews:hgg839$ot7$1...@news.eternal-september.org...
>>
>>> > In article
>>> > <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>, James
>>> > Kanze <james.ka...@gmail.com> wrote:
>>> > Wasting weeks on cleaning up the memory leaks?
>>> > I have wasted MONTHS on trying to catch all the subtle
>>> > memory leaks in a sophisticated async based program because
>>> > of some network availability issues make you maintain all
>>> > sorts of queues, depending on user interaction, causing such
>>> > headaches, that you can not even begin to imagine from the
>>> > standpoint of memory leaks.
>>
>>> do you know, exist wrapper for malloc, that at end of the
>>> program check if there are "memory leak" and report the result
>>> to the screen
>>
>> If the program ends, it doesn't leak memory, and practically,
>> there's no way any tool can tell whether there is a leak or not.
Well, flip some bits in Visual Studio IDE and you'll get
a dump of ALL your memory leaks when the program terminates.
Not exactly a nuclear science. But some things are not as simple
as it looks. Sure, if you are willing to waste days on it,
assuming those leaks are bad enough to make you worrry about it,
you can design some things to exactly identify the situation.
But there are times when you pass the same buffer around
to several methods and hold a reference to in on various queues
for efficiency reasons for example. In those cases, your buffer
may be releasable by several different routines and in the async
environment, you don't have a luxury of seeing a sequential
allocation and deallocation within more or less same scope of
events.
You may allocate it in one place. Then, depending on what kinds
of things happen, deallocate it DAYS later for that matter,
and from SEVERAL different places. Not just one, and I could
care less what anybody has to say on "good design" issue.
So, considering the fact there are several clients, which one has
a bug?
Yes, memory deallocations are non issues in trivial applications.
But if you do not have a gc equvalent mechanism, no matter how
you cut it, it is going to be a headache one way or another.
>if there is "no way any tool can tell whether there is a leak or not"
Well, there ARE ALL sorts of tools and methods.
It is a matter of "bang for a buck", or "return on investment",
a matter of economics and priorities.
How long is it going to take you to even get into it?
Can you afford to spend DAYS?
Hours?
Well, depends on the size of the stack on your table
and relative priorities.
Yes, it is nice to hear there is such a thing as a "good design"
paradise. But that is like politicians telling you and
promising you ALL sorts of things you never seem to get at
the end.
There is this thing called reality.
>that programming language has one all you call "designed error"
>because can eat memory more than is sufficient
>because all you can not have the controll on memory
>> (Well, they can tell that some things are definitively leaked.
>> If there are no pointers to the memory, for example, it has
>> leaked.) What the tools do is suggest possible leaks.
>> With regards to the first statement, of course: I've worked on a
>> fairly large number of applications which didn't leak.
>so in the first statemt you say:
>"there's no way any tool can tell whether there is a leak or not"
>in the other you say
>"I've worked on a
>fairly large number of applications which didn't leak."
>
>so do how you can be sure?
>
>if pass some of your programs with some "leak print at end" program
>possibily find some leak (or you OS-compiler allow to see if one program
>has some leak (not free all memory) )
Unfortunately, if you do a raw malloc() type of calls and not
new(), what you get in the dump of your memory leaks at the end
of execution is something that does not tell you WHO did the
allocation, so you have no idea who MUST have done DE allocation.
And if you have all sorts of objects allocated on the heap,
the whole things becomes a nightmare.
So, I resorted to conditional compilation in some situations
and sacrifice some efficiency for the sake of debugging.
And there are tradeoffs in those "design decisions".
You do want the performance.
You do want the efficiency of resource useage.
You do want robustness.
You do want compacntess.
And you do want ALL sorts of other things.
The question is how do you have it all at once?
The answer: ONLY in paradise!
And not on the pysical domain on the planet Earth.
So...
>for my little programs in my enviroment i'm sure for the memory
>of the malloc wrapper (not for the memory released from "new" (i never use
>it but should be used from the compiler or for static object if
>i rember well))
Well, you can have an alloc wrapper.
What I did in my last version for one of the most critical
and massive allocation related methods is to ID stamp the
allocations. The buffers are allocated at a single place,
a driver interface. Once they are allocated, they are stamped
with ID of 0.
Once you start processing and pass those buffers around
and incorporate them into different objects, you increase the
processing ID.
Once you terminate the program and get your memory leak dump
from VC, the 1st byte of buffer is that ID. So you can see
exactly what routines had that buffer and could or should have
released it. That took care of some of the nastiest deallocation
issues I had that could potentially lead to MASSIVE leaks
under certain conditions.
>> Some of
>> them, you may have used, without knowing it, since many of the
>> programs I've worked on aren't visible to the user---they do
>> things like routing your telephone call to the correct
>> destination. (And the proof that there isn't a leak: the
>> program has run over five years without running out of memory.)
>
>possibily the leak is small and/or in some corner case
Even considering 5 YEARS?
:--}
>>> so memory leak can not be one problem if one use these special
>>> "malloc" functions (like i use always with all bell that
>>> sound)
>>
>> I'll say it again: there's no silver bullet.
>
>the silver bullet exist in all
>
>> In the end, good
>> software engineering is the only solution. Thus, for example, I
>> prefer using garbage collection
>
>> when I can, but it's a tool
>> which reduces my workload, not something which miraculously
>> elimninates all memory leaks (and some of the early Java
>> applications were noted for leaking, fast and furious).
>
>are you sure is it good for think less?
>are you sure is it good for not doing formal
>correct memory allocation-deallocations?
>
>> --
>> James Kanze
--
io_x
in the case i think, there is a place where the buffer born, and
a place where the buffer die
malloc/realloc has to do all the "efficiency work" (if possible)
> In those cases, your buffer
> may be releasable by several different routines
this can not exist, for what i write up, and double allocation
of the same pointer without free is not allow
> and in the async
> environment, you don't have a luxury of seeing a sequential
> allocation and deallocation within more or less same scope of
> events.
> You may allocate it in one place. Then, depending on what kinds
> of things happen, deallocate it DAYS later for that matter,
> and from SEVERAL different places. Not just one, and I could
> care less what anybody has to say on "good design" issue.
>
> So, considering the fact there are several clients, which one has
> a bug?
>
> Yes, memory deallocations are non issues in trivial applications.
> But if you do not have a gc equvalent mechanism, no matter how
> you cut it, it is going to be a headache one way or another.
it is not one headache if all the functions to debug
has one place (at start) where all memory is created
and what place (at end) where all memory is free
then there would be something, that when the function end
and there is some leak for pointer allocated in that function,
for debug reason,
program stop and
print the line of the function and the pointer that is never free
in not a multithread environment, i could ask to some malloc function
the size of all the memory
allocated for the program in the start of the function
and check that in the end of that function the memory is the same
something like
unsigned z;
z=All_malloc_memory();
f(a,b,c,c,s);
x=All_malloc_memory();
if(x!=z) {printf("Memory problem for f line=%u \n", 1111); exit(0); }
Vladimir Jovic
> Why do you want to install > 1 firewall?
> Well, because first of all, most of them are bluff.
> They let any questionable traffic through and you don't get the
> security out of it as you think you do. Secondly, all of them
> have their strong points and weak points.
>
> So, I run 2 firewalls on my box. The number one is my own,
> which is a monitoring firewall. Meaning, I can see ANY funky
> network traffic. NOTHING escapes me. There is no firewall
> I know of that can do that kind of thing, even though I did
> not look at the firewall market for a couple of years.
>
Have you tried peerguardian?
tanix
Yep, at least in theory AND in SYNCHRONOUS environment.
>malloc/realloc has to do all the "efficiency work" (if possible)
Nope. Does not work. The buffer size varies with the packet size.
The buffer generation is pertty much a random event.
One buffer has no relations to any other buffer for related
classes. They all exist on their own and there is nothing common
between them except of the fact that they are of the same
class. But WHO will eventually be a client or "consumer"
depends on ALL sorts of things. Those buffers may become
a part of one class or another. There may be several different
complex objects that would hold those buffers for various reasons.
The only time the buffers are released is either when you
run over the limits to a number of monitor entries, or you
exit the program.
At all other times, these buffers may be temporarily held
until the user decides what he wants to do, in which cause
the references from some queues are released, but even there,
there may exist a copy of that buffer on a monitor view
list box.
The solution, finally adopted was to specifically make
a copy of the buffer so that there is no "competition"
for the same buffer.
The buffer deallocation in this situation is one of the
nastiest things you can imagine.
As far as logical design of the system, to this day,
I am not aware of a better way to design it as it is
probably the most efficient way to accomodate for ALL
sorts of different situations.
Unless this magic "smart pointer" works and is not a royal
pain on the neck to even bother about and it really does
its "automatic" whatever to make sure there is not
leaks possible, which I doubt, you have about the toughest
memory management situation you can imagine.
>> In those cases, your buffer
>> may be releasable by several different routines
>
>this can not exist, for what i write up, and double allocation
>of the same pointer without free is not allow
It is not a DOUBLE allocation.
The allocation is single.
But the buffer may be temporarily owned by a different
subsystem. Those subsystems are independent and are not even
aware of each other.
Depending on logical operation, which ultimately is determined
by the user's choice, the buffer may be passed to a different
subsystem and, in some cases, may be released instantly,
in some cases it may be released at a predictable point,
and in other cases it may be held for "indefinetely" long
period of time within the scope of realistic events.
>> and in the async
>> environment, you don't have a luxury of seeing a sequential
>> allocation and deallocation within more or less same scope of
>> events.
>> You may allocate it in one place. Then, depending on what kinds
>> of things happen, deallocate it DAYS later for that matter,
>> and from SEVERAL different places. Not just one, and I could
>> care less what anybody has to say on "good design" issue.
>>
>> So, considering the fact there are several clients, which one has
>> a bug?
>>
>> Yes, memory deallocations are non issues in trivial applications.
>> But if you do not have a gc equvalent mechanism, no matter how
>> you cut it, it is going to be a headache one way or another.
>
>it is not one headache if all the functions to debug
>has one place (at start) where all memory is created
>and what place (at end) where all memory is free
Except when you have thousands if not millions of allocations
and deallocation does not happen in ALL cases more or less
immediately. Try to debug that one. Or even log it.
Would you like to look at 10 mile long logs?
>then there would be something, that when the function end
>and there is some leak for pointer allocated in that function,
>for debug reason,
>program stop and
>print the line of the function and the pointer that is never free
That would be nice if it was THAT simple.
:--}
But you are talking about SYNCHRONOUS environment.
A different animal altogether.
You can not simply single step this issue in async environment.
Yes, you CAN log things into some log file.
But when you start analyzing it, you'll get a 3 mile long log.
How do you even LOOK for something in that log?
Well, DAYS of work.
>in not a multithread environment, i could ask to some malloc function
>the size of all the memory
>allocated for the program in the start of the function
>and check that in the end of that function the memory is the same
>something like
Not a good idea. To do your own memory management is WAY
too ineficient and simply does not make sense.
The end result though looks nice.
Because you know you only have one buffer, which you can
easily deallocate at the end.
But then you have to worry about ALL sorts of side effects.
You see, there IS already a system for memory management
for you on the O/S level. Do you think you can manage memory
MORE efficiently than the O/S does?
Well, people spent YEARS on designing those mechanisms.
It may take you YEARS to make it finally work,
after you see those nasty special cases, hitting your like
a brick.
The problem could be solved by buffer duplication.
That is. You could make a copy of the buffer for a different
subsystem. So, each subsystem knows it is an owner of the
buffer and no matter what happens with other subsystem,
it is guaranteed to be able to deallocate the buffer
whenever it decides to do so.
But...
If the number of those allocations is huge,
you will be consuming at least double the amount of memory
by your program and will overload the O/S unnecessarily
with essentially idle things that do not have to exist
in vast majority of cases.
That is why this program is probably one of the leanest
programs you can see in your windows task manager.
It consumes about 10-20 megs. in toto, no matter what
happens. Compare it to hundreds of megs taken by just
about any modern program.
Sure, I COULD swallow a couple of hundreds megs just like
anybody else does and I COULD solve this problem in a
matter of hours if I decided to be sloppy, just like
everybody else. But hey, it is no fun that way.
I can pretty much guarantee you:
You won't find a more efficient program, more leaner
program and more robust program for ANY money, more or
less, within the reasonable limitations.
Just take ANY firewall out there, and most of them
simply create an ILLUSION that you are protected
while silently passing some of the nastiest and most
dangerous traffic without even knowing you do.
Because some of that traffic happens to be on remote
port 80, whichs your web browser. One of the most lethal
and potent rootkit versions operates a global network.
If your box is infected, it will send out a packet
on remote port 80 to their root host. No firewall
program will even notice it.
Now, once that packet is sent out, your box will be
essentially attacked by a number of hosts on their
network, and some of those boxes belong to people,
who do not even know their boxes are used in a global
most lethal network known to mankind.
So, some of those hosts may send you the ICMP type 4
packets to probe if your box is responsive.
Some other hosts may send you viruses and trojans
of the latest version.
All these things are done either in temp port range
that no firewall will even attempt to block, or in
high port range.
The bottom line is that when you use most of the firewalls
out there, you are like blindfolded.
One of the things I have in my firewall is the traffic
indication lights. As soon as I suspect something, I just
click on icon and simply look at the traffic light.
If I am not doing anything and see those lights flashing,
then something funky may be going on. At THAT point, I
may just push a single checkbox and it will display me
every single packet my box is dealing with. If I right
click on any of those packets and push a single button,
my firewall will perform a whois request from all the
major world's servers and will automatically filter
the server results and display it in the window.
That is another set of buffers. Also fully async.
There are also the DNS buffers. The forward/backward
DNS requests are performed automatically for ANY
funky pakcet, so when I look at the monitor listbox,
it shows me not only the remote IP, but remote host name.
The DNS requests are fully async and will automatically
update the monitor entries as soon as DNS server
sends me the data.
There are trace buffer, raw socket buffers, and you
name it.
When some jack says he has a magic solution for me,
I just say: go to hell.
Ok, Cya.
>unsigned z;
>z=All_malloc_memory();
>f(a,b,c,c,s);
>x=All_malloc_memory();
>if(x!=z) {printf("Memory problem for f line=%u \n", 1111); exit(0); }
Cool.
:--}
I wish it would be THAT simple!
tanix
Nope. What is that?
LR
I'm sorry for the OT post but I didn't think that I could, in good
conscience, let this pass.
> Here is a piece of writing for you.
> See if you can beat it:
>
> http://preciseinfo.org/Convert/We_are_here_to_change_the_world_01.html
Like other bigots Anti-Semites write the worst sort of drivel but I
think yours ought to win some sort of award for sheer inanity.
> And if I ever talk to you again, remember:
> THAT is where we stand.
No, that is where you stand. I prefer to, and will, stand somewhere
else. Somewhere more logical.
> Cya.
I very sincerely hope not.
Please don't bother to respond to me as you've been filtered.
LR
Vladimir Jovic
> In article <hgnk7s$k62$1...@news.albasani.net>, Vladimir Jovic <vlada...@gmail.com> wrote:
>> tanix wrote:
>>> Why do you want to install > 1 firewall?
>>> Well, because first of all, most of them are bluff.
>>> They let any questionable traffic through and you don't get the
>>> security out of it as you think you do. Secondly, all of them
>>> have their strong points and weak points.
>>>
>>> So, I run 2 firewalls on my box. The number one is my own,
>>> which is a monitoring firewall. Meaning, I can see ANY funky
>>> network traffic. NOTHING escapes me. There is no firewall
>>> I know of that can do that kind of thing, even though I did
>>> not look at the firewall market for a couple of years.
>>>
>> Have you tried peerguardian?
>
> Nope. What is that?
>
Uses p2p block list, and you get connections to your computer - you can
block them or do what you like.
io_x
> In article <4b2f4d16$0$1109$4faf...@reader4.news.tin.it>, "io_x"
> <a...@b.c.invalid> wrote:
>>in not a multithread environment, i could ask to some malloc function
>>the size of all the memory
>>allocated for the program in the start of the function
>>and check that in the end of that function the memory is the same
>>something like
>
> Not a good idea. To do your own memory management is WAY
> too ineficient and simply does not make sense.
it seems to me it is eficient
> The end result though looks nice.
> Because you know you only have one buffer, which you can
> easily deallocate at the end.
> But then you have to worry about ALL sorts of side effects.
> You see, there IS already a system for memory management
> for you on the O/S level. Do you think you can manage memory
> MORE efficiently than the O/S does?
don't know, but for my programs the speed is good
> Well, people spent YEARS on designing those mechanisms.
> It may take you YEARS to make it finally work,
i use the malloc found in the K&R book
with some modifications (the ones for find
bouds errors, memory leak, etc)
it seems i remember that i wrote something for allow
that malloc function to be fast on stack allocation
p1=malloc(1255);
p2=malloc(4555);
p3=malloc(2555);
....
free(p3);
free(p2);
free(p1);
has few clock size for free; don't remember if for write
that i change all the malloc function and
structure type heavy
what was a little more hard was to write the realloc function
using what CBFalconer said, in assembly
[ if realloc(alloked+x)
alloked free
-------|__________________________ =>
alloked+ x free
---------------|__________________
]
i wrote all in asm because for these operation
assembly is my language of choice
> after you see those nasty special cases, hitting your like
> a brick.
the malloc function ask to the OS memory function some memory
so that memory is for my programme, i not see
nasty special cases if not count issues for aligned data
The days first all this malloc function,
my little programs for bignums
written in C and assembly and in "C++"
not work at all, the program goes to segfalut one minute yes
the other minute too
after that, no problem, no seg fault, no write out of bound
or memory leak or too much memory used
but my experience is little,
the difficult error i fixed were of the kind
why the big num
(0,0, 0xf78f898f, 0x73893838, 0x893038333, 0x73893838)
* or /
(0xf78f898f, 0x73893838)
have a wrong result
or find who write "out of the array bounds" of
some bignum array of unsigned
for find that i used what i said above
for example
h fname(a,b,c)
{
writeToTheArray("fname");
// in the start of function
// it write its name in a 'rotating' array
// then allocate memory with malloc (in class too)
// for the "fname" function, at the end of that function
// free all array of malloc (checking if some
// out of bound error too); if some out of bound is find
// print the static array of all calls and exit(0);
// and eventually use some function for see
// where is the problem inside the function
// eg
if(!isInThisPlaceAllMemoryWithBoudsOk())
{printf("The error is above here\n"); exit(0);}
}
what it print was one array of the kind
f1||f2||f3+|f0+-fy+-etcetc
and i did know that in f3 there was one error
of some out of bound written array
but it seems now, not so useful because it seems
i do less error and few memory leak, and few wrong array
write
tanix
I see. Well, I have everything I need in my firewall.
These are called rules, and I can have as many as I want.
Takes a couple of mouse clicks to create a new one or modify
and existing one even in the middle of heavy duty attack.
Pretty flexible.
But thanx for your feedback.
If you think it is something really cool and you can post a link
to it, I promise to look at it.
tanix
>
>"tanix" <ta...@mongo.net> ha scritto nel messaggio
>news:hgno7a$7hu$1...@news.eternal-september.org...
>> In article <4b2f4d16$0$1109$4faf...@reader4.news.tin.it>, "io_x"
>> <a...@b.c.invalid> wrote:
>>>in not a multithread environment, i could ask to some malloc function
>>>the size of all the memory
>>>allocated for the program in the start of the function
>>>and check that in the end of that function the memory is the same
>>>something like
>>
>> Not a good idea. To do your own memory management is WAY
>> too ineficient and simply does not make sense.
>
>it seems to me it is eficient
Well, Ok. I CAN comprehend that.
The only thing is there are some NASTY memory management
details if you are going to manage your own pools of memory.
I happen to have deal with things like that in the past.
At the moment, my position on everything more or less is this:
use standard, off the shelf, components subsystems, etc.
Do not try to oversmart the O/S. It won't pay at the end.
In a fully multithreaded environment, ESPECIALLY in async mode,
be as careful as you can manage. There is no need to reinvent
the wheel. Some of that code, you may be trying to bypass,
took YEARS to perfect, and there are ALL sorts of reasons
it is as it is. Yes, one of those reasons is backward
compatibility and some things end up being not as efficient
if it was not the case. But overall, you are most shielded
from the revision issues in the O/S, your IDE, language
fashions and you name it.
Basically, your code should work not only today, but
for generations to come on any future version of O/S,
more or less, if at all possible.
Some of the programs I ran were written 15 years ago,
and they are STILL the best I know of. The most flexible,
the most powerful, etc. And YES, they do have bugs,
because they are THAT old, and some things may even
cause crashes of the whole program, just like it happened
a couple of minutes ago.
But...
After looking at PLENTY of other programs that do pretty
much the same kind of things, I still return to them,
and never regretted. It is like a hand in glove.
The porst "portable" way of doing it.
The most intitive way of doing it.
The simpliest way of doing it.
And the list goes on.
Even if I loose my box, I am still in a good shape.
Nothing has been lost. At most a few hours of work.
And that is good enough for a poor guy like me.
>> The end result though looks nice.
>> Because you know you only have one buffer, which you can
>> easily deallocate at the end.
>> But then you have to worry about ALL sorts of side effects.
>> You see, there IS already a system for memory management
>> for you on the O/S level. Do you think you can manage memory
>> MORE efficiently than the O/S does?
>
>don't know, but for my programs the speed is good
Could be. I can not possibly argue that.
We'd have to discuss your program, and I'd have to spend at least
a few hours on it. Sorry, can not afford that at the moment.
>> Well, people spent YEARS on designing those mechanisms.
>> It may take you YEARS to make it finally work,
>i use the malloc found in the K&R book
>with some modifications (the ones for find
>bouds errors, memory leak, etc)
Well, the interesting thing about C is that it is STILL
the most active group on usenet. The traffic on C groups
is even higher than on C++ group.
And, from what I know, C is probably the REAL "revolution"
in the programming languages and it was the one, used
to create the most long standing operating system.
And, after GENERATIONS, it is still there. Full blast.
That is not only "good" design.
It is MONUMENTAL design.
And with ALL its limitations, you can still rely on it
like you can not rely on anything else in the sw world.
>it seems i remember that i wrote something for allow
>that malloc function to be fast on stack allocation
>
>p1=malloc(1255);
>p2=malloc(4555);
>p3=malloc(2555);
>.....
>free(p3);
>free(p2);
>free(p1);
>
>has few clock size for free; don't remember if for write
>that i change all the malloc function and
>structure type heavy
>
>what was a little more hard was to write the realloc function
>using what CBFalconer said, in assembly
>[ if realloc(alloked+x)
>alloked free
>-------|__________________________ =>
>alloked+ x free
>---------------|__________________
>]
>
>i wrote all in asm because for these operation
>assembly is my language of choice
Hey. I like that stuff. I reminded me Forth experience.
What a fun that was. Did not last that long, but it WAS fun!
:--}
>> after you see those nasty special cases, hitting your like
>> a brick.
>
>the malloc function ask to the OS memory function some memory
>so that memory is for my programme, i not see
>nasty special cases if not count issues for aligned data
Well, OK. Let me see if I understand what you are trying
to say.
Are you saying that you want to make a huge memory request
and the try to have your own equivalent of .alloc() functions,
where you get a piece of memory from that original chuck
of memory you allocated?
If THAT is the case, then you are for some nasty surprises,
trying to manage memory by yourself. These things are not
that simple.
Say, for example, you have MANY allocations and deallocations.
Each allocation is not of a fixed size. It can be anything.
So, assume you requested a chunk of memory from your own
memory management system.
Then you requested an arbitrary number of other chunks.
Then, some of them can be released.
So what do you do?
How do you release it?
You have a memory fragmentation problem.
You'd have to keep the lists of free chunks or unallocated
holes in your memory region.
What if you have many free holes, but the block you are
trying to request is bigger than any single hole you have?
Well, you simply conc out, you simply die. Because there
is nothing you can do at that point, unless you keep
merging the ajacent memory regeions during the release phase
and do ALL sorts of nasty memory management things.
It is such a royal headache, I can not even begin to describe it.
Maaaan. I feel jealous of you. It must be such a fun
to dig into this stuff at the point where you are!
Enjoy the trip.
James Kanze
> "James Kanze" <james.ka...@gmail.com> ha scritto nel
> messaggionews:4f3858fa-d8e2-4c92...@s31g2000yqs.googlegroups.com...
> > On Dec 19, 4:51 pm, "io_x" <a...@b.c.invalid> wrote:
> >> "tanix" <ta...@mongo.net> ha scritto nel
> >> messaggionews:hgg839$ot7$1...@news.eternal-september.org...
> >> > In article
> >> > <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>, James
> >> > Kanze <james.ka...@gmail.com> wrote:
> >> > Wasting weeks on cleaning up the memory leaks? I have
> >> > wasted MONTHS on trying to catch all the subtle memory
> >> > leaks in a sophisticated async based program because of
> >> > some network availability issues make you maintain all
> >> > sorts of queues, depending on user interaction, causing
> >> > such headaches, that you can not even begin to imagine
> >> > from the standpoint of memory leaks.
> >> do you know, exist wrapper for malloc, that at end of the
> >> program check if there are "memory leak" and report the
> >> result to the screen
> > If the program ends, it doesn't leak memory, and
> > practically, there's no way any tool can tell whether there
> > is a leak or not.
> if there is "no way any tool can tell whether there is a leak
> or not" that programming language has one all you call
> "designed error" because can eat memory more than is
> sufficient because all you can not have the controll on memory
Determining whether there is a leak or not is comparable to the
stopping problem. It's been more or less proven that it can't
be computed.
> > (Well, they can tell that some things are definitively
> > leaked. If there are no pointers to the memory, for
> > example, it has leaked.) What the tools do is suggest
> > possible leaks.
> > With regards to the first statement, of course: I've worked
> > on a fairly large number of applications which didn't leak.
>
> so in the first statemt you say:
> "there's no way any tool can tell whether there is a leak or
> not" in the other you say "I've worked on a fairly large
> number of applications which didn't leak."
> so do how you can be sure?
After the code has run five or more years in a low memory
environment, you can feel pretty sure.
But yes, there's a strict sense that you can never been 100%
sure.
Note that I'm not against using tools. The fact that they can't
find 100% of the leaks doesn't mean that they're without value.
(On the other hand, typically, the tools I've used, like
Rational Rose, have shown that dangling pointers are more of a
problem than leaks.)
> if pass some of your programs with some "leak print at end"
> program possibily find some leak (or you OS-compiler allow to
> see if one program has some leak (not free all memory) )
> for my little programs in my enviroment i'm sure for the
> memory of the malloc wrapper (not for the memory released from
> "new" (i never use it but should be used from the compiler or
> for static object if i rember well))
Note that some of the programs are very inaccurate. (This does
not hold for valgrind or Rational Rose, which are careful to
document exactly what they've found, and what it might or might
not mean.)
> > Some of them, you may have used, without knowing it, since
> > many of the programs I've worked on aren't visible to the
> > user---they do things like routing your telephone call to
> > the correct destination. (And the proof that there isn't a
> > leak: the program has run over five years without running
> > out of memory.)
> possibily the leak is small and/or in some corner case
Possibly. Or possibly, we used good design, and careful design
and code review, and there really aren't any leaks.
[...]
> > In the end, good software engineering is the only solution.
> > Thus, for example, I prefer using garbage collection when I
> > can, but it's a tool which reduces my workload, not
> > something which miraculously elimninates all memory leaks
> > (and some of the early Java applications were noted for
> > leaking, fast and furious).
> are you sure is it good for think less?
Who said anything about thinking less?
> are you sure is it good for not doing formal
> correct memory allocation-deallocations?
It's certainly good to have less lines of code to write and
to debug. And to be able to use the time that would be
otherwise required for those lines of code to do something else,
like more intensive testing, or adding a feature.
--
James Kanze
James Kanze
> In article <4b2f3095$0$1110$4fafb...@reader3.news.tin.it>,
> "io_x" <a...@b.c.invalid> wrote:
> >"James Kanze" <james.ka...@gmail.com> ha scritto nel messaggio
> >news:4f3858fa-d8e2-4c92...@s31g2000yqs.googlegroups.com...
> >> On Dec 19, 4:51 pm, "io_x" <a...@b.c.invalid> wrote:
> >>> "tanix" <ta...@mongo.net> ha scritto nel
> >>> messaggionews:hgg839$ot7$1...@news.eternal-september.org...
> >>> > In article
> >>> > <3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>, James
> >>> > Kanze <james.ka...@gmail.com> wrote:
> >>> > Wasting weeks on cleaning up the memory leaks? I have
> >>> > wasted MONTHS on trying to catch all the subtle memory
> >>> > leaks in a sophisticated async based program because of
> >>> > some network availability issues make you maintain all
> >>> > sorts of queues, depending on user interaction, causing
> >>> > such headaches, that you can not even begin to imagine
> >>> > from the standpoint of memory leaks.
> >>> do you know, exist wrapper for malloc, that at end of the
> >>> program check if there are "memory leak" and report the
> >>> result to the screen
> >> If the program ends, it doesn't leak memory, and
> >> practically, there's no way any tool can tell whether there
> >> is a leak or not.
> Well, flip some bits in Visual Studio IDE and you'll get a
> dump of ALL your memory leaks when the program terminates.
Except that from what little I've seen of it, it reports a lot
of things as leaks that aren't, and missing some important
leaks.
--
James Kanze
James Kanze
> On Dec 20, 7:06 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
> > My first reaction to your description is that you obviously need
> > two processes: one doing the filtering, and another to manage
> > the GUI. With a queue between them. In this case, from
> > experience, I'd say that two processes are a must, because you
> > want the filtering to maintain as small a footprint and use as
> > few resources as possible. Which means, BTW, that I would do it
> > in C++, and that I wouldn't use garbage collection, since
> > garbage collection does have a significant memory overhead (and
> > in such filtering applications, unlike a lot of other
> > applications, doesn't really buy you that much). For the GUI,
> > I'd use Java, because I know Swing, and I don't know any of the
> > C++ GUI libraries.
> It might make sense to learn one of those C++ GUI libs since
> then the filtering could be done in a thread.
In this particular case, I think a separate process would be
preferable. But that doesn't mean that I shouldn't learnone of
those C++ GUI libs. In case I get a different job, where
threads would be more appropriate.
--
James Kanze
tanix
>On Dec 20, 8:40 pm, Brian <c...@mailvault.com> wrote:
>> On Dec 20, 7:06 am, James Kanze <james.ka...@gmail.com> wrote:
>
> [...]
>> > My first reaction to your description is that you obviously need
>> > two processes: one doing the filtering, and another to manage
>> > the GUI.
Correct. Except not processes, but threads I would think
And the reason for it is that you don't want your GUI thread
to lock up because of some processing hang in other threads.
Your GUI MUST be, AT ALL TIMES, responsive.
No matter what happens.
>> > With a queue between them. In this case, from
>> > experience, I'd say that two processes are a must, because you
>> > want the filtering to maintain as small a footprint and use as
>> > few resources as possible.
Has nothing to do with "small footprint".
But sorry, I have not much time to really dig into this stuff.
Cya.
>> > Which means, BTW, that I would do it
>> > in C++, and that I wouldn't use garbage collection, since
>> > garbage collection does have a significant memory overhead (and
>> > in such filtering applications, unlike a lot of other
>> > applications, doesn't really buy you that much). For the GUI,
>> > I'd use Java, because I know Swing, and I don't know any of the
>> > C++ GUI libraries.
>
>> It might make sense to learn one of those C++ GUI libs since
>> then the filtering could be done in a thread.
>
>In this particular case, I think a separate process would be
>preferable. But that doesn't mean that I shouldn't learnone of
>those C++ GUI libs. In case I get a different job, where
>threads would be more appropriate.
>
--
James Kanze
> "James Kanze" <james.ka...@gmail.com>
> >> Many people here have the same experience. Yes, writing
> >> programs including smilar to that you described. Just use a
> >> manager, like a smaprt pointer consistently with every
> >> allocation. No leaks possible.
> > And that's the kind of comment which gives C++ a bad name.
> I don;t see much difference between my comment and yours -- we
> do similar things (proper design and match it in code) and
> have the same result (no leaks).
But I don't claim that there's any one coding solution that will
solve all my problems. The only thing I'm objecting to in your
posting is "*JUST* use a manager[...]". That's not a silver
bullet; if proper design says to use a manager or a smart
pointer for some things, then it is good. But we don't want to
see the tail wagging the dog. And even the ultimage memory
manager, garbage collection, doesn't result in no leaks.
> > There are no silver bullets, and in well designed code, you
> > typically don't have that many smart pointers.
> I said "manager" that is *like* a smart pointer. string,
> vector, list is a manager, and is not a smart pointer. I
> certainly agree that stts on a regular program would find ust
> a few smart pointers compared to anything else.
Something got garbled in your last sentence, and I'm unable to
parse it. But in practice, I find that with proper OO design,
*in* *C++*, you really don't need a manager, a smart pointer, or
garbage collection that often. Most objects which can't manage
themselves have value semantics, and aren't allocated on the
heap to begin with. (Of course, applications may vary, and I've
seen applications where extensive use of smart pointers was
justified. It's just not a general rule.)
> But safe coding have consistent manager usage, replacing "raw"
> stuff. Just like you wrote before, that dynamic allocation is
> not left in a raw pointer, but put in a smart one, and
> .release() it at return or transferuing to another manager.
> Even if it looks like done "immediately" with just one line
> between. ;-)
Not usually. First, C++ uses a lot less dynamic allocation to
begin with than languages like Java. And secondly, it's usually
preferable (albeit not always possible) to ensure that your
objects are fully capable of managing themselves before
returning from the constructor.
[...]
> >> (And if you need to keep blocks unreleased an indefinite
> >> time waiting user interaction -- that is not a leak issue,
> >> but consequence of a general design decision.)
> > The classical case of a leak is when you "register" a
> > session in a map, mapping it's id to the session object, and
> > forget to deregister when the session ends. At least,
> > something along those lines accounts for most of the leaks
> > I've seen.
> Yeah, we discussed it a few weeks ago. This has nothing to do
> with coding or any language -- a flaw in design/reqs that will
> hit in any possible implementation.
Yes. I mention it because one poster suggested that memory
leaks were impossible in Java, because of garbage collection.
And because early versions of Swing had just such a leak. (Note
that competent Java programmers don't make such dubious claims.
And that Sun did recognize it as a leak.)
> >> > One heavy duty program I wrote in Java works like a champ
> >> > for years without a SINGLE issue with memory leak and gc
> >> > is so efficient that it is not far from automatic stack
> >> > deallocation.
> > Note that this is very application dependent. Actual
> > allocation with a copying collector is about the same as
> > alloca in terms of performance, and if you can arrange for
> > all of the runs of the garbage collector to be in otherwise
> > dead time, you'll likely significantly outperform a system
> > using manual allocation. But there are a couple of if's in
> > there---for most applications I've seen, the performance
> > difference between garbage collection and manual allocation
> > won't be significant, and there are applications where
> > garbage collection is significantly slower, or simply can't
> > be used.
> To start with the memory footprint starts as 2-3x as big.
Yes. For a lot of applications, it really doesn't matter. From
what he's described, however, I think that it would in this one.
In which case, garbage collection probably isn't appropriate.
> Actually did anyone heard a reporting firewall implemented in
> java?
I think I've seen one. It tends to occupy over a GB, and takes
90% of the CPU.
> > [...]
> One of my current project picked java UI with Swing because it
> has auto-layout. What sounds like a cool idea when you must
> issue the app in a dozen languages. And you can just have a
> ranslation table for the UI strings, the rest will work.
> Well, in practice it wasn't all that bright, and the auto
> property turned to create a big deal of issues when translated
> stuff had a different size...
Handling different languages is difficult, regardless of the
language. But I found that the "auto-layout" in Java simplified
the task. (Admittedly, I ended up writing a couple of custom
layout managers. But it wasn't that big a job.)
[...]
> That keeps me generally sceptic wrt GUI portability. Without
> a big deal of manual work at the QA dept and coding too...
Like everything, it requires up front design.
--
James Kanze
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
[...]
> > Java's portability is
> >limited to machines which have a good JVM.
> Correct.
> > Which isn't many.
> Well, about 90% of total market from what I know.
Our markets may not be the same, or perhaps we have different
definitions of a "good JVM". And Sun has, I believe, made
considerable progress. But when I was working in Java, about
the only implementation I'd have considered passably good was
the one for Windows; the others (including the one for Solaris)
were really very basic interpreters, with really excessive
runtime overhead. And in the markets I've worked in in the
past, Windows is a non-runner.
> >> 5) Robustness.
> >> And THAT is where these nasty exceptions come in handy.
> >> You'll never be able to write a stable code, and I mean
> >> TRULY stable, if you do not use exceptions.
> >Explain how applications have been running for years, without
> >interruption, and without using exceptions.
> 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.
> For one thing, without exceptions your code becomes a huge
> pile of spegetti code and I know what I am talking about.
Apparently not, because I've worked on very large code bases,
without exceptions, and without any spaghetti. Exceptions do
make certain things easier, but you can live without them.
> >(The application in question was written before C++ supported
> >exceptions.) Exceptions are a useful tool, for certain
> >things, but like all tools, you can do without (at some
> >development cost) if you have to.
> Sorry. I can not agree with you on this one.
> I think you are somehow predisposed AGAINST exceptions.
Not at all. But I was programming long before they were
generally available, and we still managed to write robust and
maintainable applications.
--
James Kanze
tanix
>On Dec 20, 2:30 pm, "Balog Pal" <p...@lib.hu> wrote:
>> "James Kanze" <james.ka...@gmail.com>
>
>> >> Many people here have the same experience. Yes, writing
>> >> programs including smilar to that you described. Just use a
>> >> manager, like a smaprt pointer consistently with every
>> >> allocation. No leaks possible.
>
>> > And that's the kind of comment which gives C++ a bad name.
>
>> I don;t see much difference between my comment and yours -- we
>> do similar things (proper design and match it in code) and
>> have the same result (no leaks).
>
>But I don't claim that there's any one coding solution that will
>solve all my problems. The only thing I'm objecting to in your
>posting is "*JUST* use a manager[...]". That's not a silver
>bullet; if proper design says to use a manager or a smart
>pointer for some things, then it is good. But we don't want to
>see the tail wagging the dog. And even the ultimage memory
>manager, garbage collection, doesn't result in no leaks.
:--}
Not true. Well THEORETICALLY true.
But I have not seen it in practice, at least in my code.
But...
You are making some progress and I do appreciate it.
Cya.
--
tanix
>On Dec 20, 3:39 pm, ta...@mongo.net (tanix) wrote:
>> In article
>> <35f3b2ed-8303-4249-8b12-3f85b4907...@s31g2000yqs.googlegroups.com>,
>> James Kanze <james.ka...@gmail.com> wrote:
>
> [...]
>> > Java's portability is
>> >limited to machines which have a good JVM.
I don't know what is "good JVM".
Yes, the JVM as released by microsoft a way back,
that supported JDK 1.1 or 1.2 from what I recall
was not "good JVVM". Just WAy too many bugs.
>> Correct.
>> > Which isn't many.
>
>> Well, about 90% of total market from what I know.
>
>Our markets may not be the same, or perhaps we have different
>definitions of a "good JVM". And Sun has, I believe, made
>considerable progress. But when I was working in Java, about
>the only implementation I'd have considered passably good was
>the one for Windows;
Correct. Performance wise, MVM runs 2 times faster than
JVM from Sun for me, and that REALLY counts. The difference
on big jobs is days and nights.
> the others (including the one for Solaris)
>were really very basic interpreters, with really excessive
>runtime overhead. And in the markets I've worked in in the
>past, Windows is a non-runner.
>> >> 5) Robustness.
>> >> And THAT is where these nasty exceptions come in handy.
>> >> You'll never be able to write a stable code, and I mean
>> >> TRULY stable, if you do not use exceptions.
>
>> >Explain how applications have been running for years, without
>> >interruption, and without using exceptions.
>
>> 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.
If you tell me I have to write my code WITHOUT exeptions,
I won't take your job offer. Sorry.
Period.
There is no ifs and buts on this one for me.
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.
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.
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 just wrote too much code to make such a statement.
It is simply inevitable.
> because I've worked on very large code bases,
>without exceptions,
Again, this is a general purpose statement that does not
prove anything.
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.
With exceptions, you do not check ANY return code
more or less. Clear to a 5 year old what it means.
>and without any spaghetti. Exceptions do
>make certain things easier, but you can live without them.
You can live without anything except water for more than
3 days and food for more than 40 days and things of that level.
This is the LAW, and not philosophy:
You MUST use exceptions to take care of your error conditions
in more cases than not.
>> >(The application in question was written before C++ supported
>> >exceptions.) Exceptions are a useful tool, for certain
>> >things, but like all tools, you can do without (at some
>> >development cost) if you have to.
>
>> 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.
It seems like a matter of principle to you.
I just don't understand what could possibly be a reason
for it.
> But I was programming long before they were
>generally available,
Understood. No problems with that one.
"It is hard to teach an old dog new tricks".
An old dog knows at least one thing: how to survive.
That is why he is an OLD dog.
Otherwise, he'd be dead by now, like most of other
dogs he knew.
If something works for you, you don't need to forever
chase the "fasion". Who cares what color of trousers
they think are MUST nowadays?
You have your trousers that are comfortable
and you don't feel restricted by this never ending
fashion trip.
So, why would you want to run to some store and
waste some money on something totally useless,
just because they say on the idiot box that the latest
fasihion is this and that?
You are fine as you are.
Your code runs like a tank.
Someone invents some fasion grade goubledy gook.
Do you run to the store like a zombie, just because
everybody else is running?
I don't.
In fact, I appreciate that time.
Because these zombies are busy, crawling on the top
of each other, waiting since last night when the store
opens so they can get their zombification machine
called Sony Playstation v. whatever.
At that time, you can have a break from this madness.
Because everyone is so busy running for that latest
version of zombification machine, that no one has any
time to even bother about you.
Cool.
> 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.
In fact, I will make this claim:
If you do NOT use exceptions, you are just a lazy bum.
That is ALL there is to it.
Enjoy, you old wolfe.
Vladimir Jovic
[snip]
>
> It's certainly good to have less lines of code to write and
> to debug. And to be able to use the time that would be
> otherwise required for those lines of code to do something else,
> like more intensive testing, or adding a feature.
Or in another words:
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
(forgot who said it)
tanix
>(forgot who said it)
Well, true to some extent.
The argument though is this:
If you write a "good code", you won't have to debug it as much.
If your design is "correct", then you don't have to debug it much.
And again, remember what Denis Ritchie said about logging
(not a literal quote)
People get lost in the local scope with debuggers and can not
see the forest from the trees. They keep looking at the values
of local variables and small things like that and end up spending
10 times more time on debugging.
Instead, he proposed to use a well designed logging system.
That way, you can identify problems with your code probably
10 times as fast as with debuggers.
What an insight!
tanix
>In article <hgooqb$lke$3...@news.eternal-september.org>, ta...@mongo.net (tanix)
> wrote:
>>In article <4b2f924e$0$16146$cc2e...@news.uslec.net>, LR
> <lr...@superlink.net>
>> wrote:
>>>tanix wrote:
>>>
>>>I'm sorry for the OT post but I didn't think that I could, in good
>>>conscience, let this pass.
>>>
>>>> See if you can beat it:
>>>>
>>>> http://preciseinfo.org/Convert/We_are_here_to_change_the_world_01.html
>>>Like other bigots
>>BIGOTS? WHO?
>>You mean YOU?
>>> Anti-Semites
>>Most of my best friends, I am mean BEST,
>>are Jews.
>>Secondly, Jews are not semites.
They are Khazars, the Turko-Finnic tribes,
that never stepped with their toe on the "holy lands".
Their king adopted Jeudoism and, as a result,
they became "Jews".
And here is the real kicker:
"We need a program of psychosurgery and
political control of our society. The purpose is
physical control of the mind. Everyone who
deviates from the given norm can be surgically
mutilated.
The individual may think that the most important
reality is his own existence, but this is only his
personal point of view. This lacks historical perspective.
Man does not have the right to develop his own
mind. This kind of liberal orientation has great
appeal. We must electrically control the brain.
Some day armies and generals will be controlled
by electrical stimulation of the brain."
-- Dr. Jose Delgado
(MKULTRA experimenter who demonstrated a
radio-controlled bull on CNN in 1985)
Director of Neuropsychiatry, Yale University
Medical School.
Congressional Record No. 26, Vol. 118, February 24, 1974
James Kanze
> 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
tanix
>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.
Well, I did not mean it to be an insult. Trust me.
But just to put things in perspective.
The rate of coding is orders of magnitude higher nowadays
and complexities also.
And I will never agree with you on exceptions,
even though it is not a matter of principle for me.
I just saw WAY too many benefits of it and WAY too many cases
where they made things MUCH simpliers, much more predictable,
and much more structured.
My "granularity" argument still stands.
You don't need to get lost in the forest by dealing with
never ending collections of trees in front of you.
I can call it a "granularity benefit", whether it makes sense
for you or not.
>> 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.
Well, I would simply feel uncomfortable doing ANY job,
unless it is a kernel mode driver, where rules of the game
are quite different.
But I would feel like I am working in "unclean" environment,
and I would intuitively feel horrified with ALL sorts of
crappy code and orders of magnitude more load on my brain
just because I have to deal with every single return code
on every single non significant level.
Once you decide to go with return codes, that's it.
You have to test EVERY SINGLE return code.
You can not make ANY assumptions.
If I EVER find something that does not need to return the
return code, because, for example, I solved it differently,
I immediately rewrite the called routine so it does not
return any return codes, just for the purity of code's sake.
>> 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?
Well, I am probably not seeing the picture YOU are seeing.
But I am just curious: what is the essense of argument
that the exception processing, under non exception conditions,
can possibly incure a significant enough overhead to even
bother about it?
Is it a memory allocation/deallocation issue?
Sorry to mentioni Java again, but since I started working with
Java as my primary language, I just do not recall a single case
where exceptions were inefficient.
I do keep a constant watch for performance issues, because those
are VERY critical in my case because most of the "jobs" I run
run for hours, if not days. Just saving a couple of hours of
job processing time, it helps quite a bit.
>> 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.
That's IT then. That is ALL I want to hear.
In my case, once exception is THROWN, then fine, take ALL the
time you need and use ANY resources you need to make it as
informative as you can manage, if it is a major operation
and user might not know the state of the whole thing and
have to waste hours if not days to recover.
All the other lil exceptions, such as string to number conversion,
simply become a part of the flow. The exception handling overhead
is totally insignificant. Because, first of all, those things
happen EXTERMELY rarely, and if they do, an you have to deliver
a defalut value because your conversion failed, which is slow
enough as it, then it is a totally non issuse. Nothing even worth
mentioning.
> 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,
Well, that is true. I do agre on this one.
I do try to keep an eye on these kinds of things for vast majority
of cases and never let it slide.
Actually, I use the "finally" quite extensively,
because I need to keep a good handle on my memory allocations/
deallocations issues. Cause I may end up holding hundreds of
gigs of memory unnecessarily for unnecessarily long periods of
time.
> when there are things that have to be
>cleaned up, and the author didn't think about exceptions.
Well, that comes as a skill. Sooner or later they will learn,
or loose their job. THEN they WILL learn for sure.
>> 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.
Well, to tell you the truth I am not prepaired to argue this
point right now. It seems to me to be self evident.
Just a simple fact:
Do you have MORE logic in your program if you use return codes?
Or LESS?
How much MORE logic do you have?
Well, I estimate AT LEAST 30% of your code, if not 300% for the
sake of artument, has to handle that code. Otherwise you are
just a fool that created codes that are useless since you are
not using them.
I could probably spend a few minutes of my time to give you
a pretty typical piece of code with exceptions and the same
exact code without exceptions.
It'll look like night and day in terms of code clarity
and the size of that code.
But I am getting too much wrapped up into this "exceptions"
or "no exceptions" trip. I AM wasting too much time and
energy on it.
Why do I even need to try to prove anything to someone,
who thinks otherwise?
Stoopid of me indeed.
>> I just wrote too much code to make such a statement. It is
>> simply inevitable.
>
>So inevitable that it doesn't take place.
:--}
Yep, I know your style by now.
Enjoy.
Cya.
--
io_x
> In article <hgpvos$bo1$1...@news.albasani.net>, Vladimir Jovic
> <vlada...@gmail.com> wrote:
>>James Kanze wrote:
> Instead, he proposed to use a well designed logging system.
> That way, you can identify problems with your code probably
> 10 times as fast as with debuggers.
could be 1000 times
could be i do it for hobby, but i like to follow what
really does one function after it is written, when born
io_x
"io_x" <a...@b.c.invalid> ha scritto nel messaggio
news:4b2fb5f7$0$1120$4faf...@reader3.news.tin.it...
>
>
> or find who write "out of the array bounds" of
> some bignum array of unsigned
>
> for find that i used what i said above
> for example
> h fname(a,b,c)
> {
> writeToTheArray("fname");
> // in the start of function
> // it write its name in a 'rotating' array
> // then allocate memory with malloc (in class too)
> // for the "fname" function, at the end of that function
> // free all array of malloc (checking if some
> // out of bound error too); if some out of bound is find
> // print the static array of all calls and exit(0);
>
>
> // and eventually use some function for see
> // where is the problem inside the function
> // eg
> if(!isInThisPlaceAllMemoryWithBoudsOk())
> {printf("The error is above here\n"); exit(0);}
> }
>
> what it print was one array of the kind
> f1||f2||f3+|f0+-fy+-etcetc
> and i did know that in f3 there was one error
> of some out of bound written array
i reread the code i change something (no rotating array)
h fname(a,b,c)
{
// then allocate memory with malloc
.... // function code
// free all memory of malloc
// and ceck if some array has some
// write in the end, if yes stop the
// program and print the address of the
// fname and the pointer to with there is
// a write in one of 2 array bound
tanix
Who does not?
The source code debuggers was one of the most important innovations.
It allowed to increase the speed and complexity of programs by
orders of magnitude.
This brings up an interesting issue about design.
There are two alternatives:
1) You do "good" design, meaning use all sorts of charts, diagrams
or what have you. Then specify things down to such a low level
that you even know all your return codes and all the arguments.
2) Intuitively see the overall structure and your idea.
Then, use this "top down design and bottom up implementation"
trick and lay down the lowest level, most fundamental "worker"
code, keeping in mind expandability issue and universality
of your code.
You see, whatever code you need to write, there will always
be this code that needs to deal with basic things, such
as file system access, network access, your basic structure
of data record or your low level video or sound functionality.
You'd have to do that no matter how you design what.
If you design an audio app, no matter what you do, you'd need
to have the lowest level code that deals with device drivers
and assures you can play whatever you need to play.
So, defining that low level code that you can immediately
use to test at least something, is probably the most profitable
investment of your energy into that project.
Then, you can go higher with your design and design some
code that sits on the top of low level stuff, keeping in mind
your overall architecture, that is still vague at this point,
even though you know what you are basically interested in
doing.
And so you SCULPT your program, instead of spending tremendous
amount of time during the initial desing. Because at that time
you hardly can see all the subtle interactions and have to
unnecessarily waste lots of energy trying to see what kind
of potential issues you might have in the future.
I had an experience once with one guy, who was extremist,
evangelical type. He just kept forcing everyone he had to
deal with to first spend months on design, without doing
a single line of code writing. So you forever grope in the
darkness.
There was one project we had to do. What HE did, was sitting
there for monts, scratching his head and writing down tons
of things in his grand design.
After a few months, he had a bible size book. When I looked
inside, I had goose bumps. Because the whoel thing was
"designed" down to exact algorithms, parameters and you
name it.
His idea was this: it may take me half a year on design.
But then it will take me 15 minutes to code that stuff.
How many people around would agree with that approach?
We had another project and I was the only one around that
could handle it. It was a relatively large database
application. When the bosses asked "how long do you think
it is going to take you to get something workable"?
I said: well, about a month.
The did not believe it. The said: ok, go ahead.
My programmer friend, who happened to be under influence
of that grand architect, said: you must be crazy.
You won't be able to do it even in two months,
and even if you WILL be able to get something to work,
I can break your code in seconds.
I said: OK. Let us see.
Within a month I had it working, pretty much to the day.
When I showed it to him and he wanted to humiliate me,
implying that my program is full of bugs and wont survive
for few seconds of heavy punishment, he sai:
Well, for me to break your program, I don't even have to
do much. I simply sit you a keyboard and simuplaneously
push ALL sorts of buttons non stop until your program
completely concs out, and so he did.
Yes, there was one moment when things stopped responding
just because he jammed so much shit into all the buffers
than even O/S could lock up.
But, after a couple of seconds we saw program giving you
a prompt again. Everything was working even under this
kind of abuse. He got pale on his face. He could not
believe it.
Now, that grand architect would probably take AT LEAST
6 months of doing it and I am not sure what he would
produce at the end, was not a subject to revision
even before he finished coding his 1st version.
The bottom line: it is a matter of personal style.
I, personally, like to see something alive pretty much
from the day one, and I do debug that thing from any
conceivable angle, pretty much from the start.
So yes, debuggers do help.
:--}
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
> >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:
> > [...]
> The rate of coding is orders of magnitude higher nowadays
> and complexities also.
Actually, I think in a lot of cases, the reverse is true. The
applications I see today are generally a lot simpler than those
of yesterday. For one thing, there's true runtime support for a
lot more functionality, so you don't have to implement it in the
application. And there are a lot of applications doing very
simple things---computers are cheap enough that you don't have
a complex operation to justify using one.
But both now and in previous times, there is a large interval
between the extremes. It wouldn't surprise me if the most
complex applications today were more complex than in previous
times. The least complex are certainly less complex. About all
I'd say is that the average application is less complex than
previously.
> >> 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.
> Well, I would simply feel uncomfortable doing ANY job,
> unless it is a kernel mode driver, where rules of the game
> are quite different.
Kernel mode drivers were one of the cases I was thinking about.
I've also written for embedded processors with only 2 KB of ROM,
and 64 bytes of RAM. That was a long time agom but I'm sure
that there are still embedded processors with very limited
resources (many of which probably don't even have a C++
compiler---just C).
For an application on a general purpose machine, I'd have
serious doubts about a company which used C, or banned
exceptions in C++. But there's a lot more out there than just
general purpose machines.
[...]
> Once you decide to go with return codes, that's it.
> You have to test EVERY SINGLE return code.
That is definitely true. (Provided the "return code" returns
something useful or important. I wouldn't normally bother with
checking the return code of printf, for example, because it's
really meaningless.)
> You can not make ANY assumptions.
> If I EVER find something that does not need to return the
> return code, because, for example, I solved it differently,
> I immediately rewrite the called routine so it does not
> return any return codes, just for the purity of code's sake.
The possible problem here is virtual functions: if one of the
derived classes can fail, all of the derived classes need a
return value (or to be able to throw an exception, or whatever).
[...]
> But I am just curious: what is the essense of argument
> that the exception processing, under non exception conditions,
> can possibly incure a significant enough overhead to even
> bother about it?
That it once did, for some primorial compiler? I don't know,
otherwise. It's certainly false today.
> Is it a memory allocation/deallocation issue?
> Sorry to mentioni Java again, but since I started working with
> Java as my primary language, I just do not recall a single
> case where exceptions were inefficient.
Exceptions are easier to make efficient when you don't have
value semantics, and objects with non-trivial destructors. It's
also easier to write incorrect code in such cases---as I said
elsewhere, one of the most common errors in Java is a missing
finally block. Still, except for some very early, experimental
implementations, I don't know of a case where an exception that
wasn't thrown has caused performance problems in C++ either.
It's also possible to misuse exceptions, so that they get thrown
in the normal logic of program execution. I've heard of such
cases (although I've never seen them in code I've had to deal
with).
Still, any argument against exceptions based on performance is
simply FUD, at least IMHO.
> >when there are things that have to be cleaned up, and the
> >author didn't think about exceptions.
> Well, that comes as a skill. Sooner or later they will learn,
> or loose their job. THEN they WILL learn for sure.
The problem is that they don't necessarily learn. Since the
problem only occurs in "exceptional" cases, and a lot of people
neglect testing those.
It's interesting to note that in the Java runtime, when opening
a file fails, they run garbage collection and try again.
Because a lot of people forget a finally block when they've
opened a file, and in case of an exception, never close it.
(Whereas in my code, most of the time, if it's an output file,
and there is an exception, I not only close the file, but delete
it. So there's no inconsistent file lying around after the
program has run.)
[...]
> Do you have MORE logic in your program if you use return codes?
> Or LESS?
You have the same amount of logic. Or else there's an error
somewhere. The only difference is that with exceptions, some of
the logic isn't visible, and doesn't have to be manually
written. (It does still have to be considered when analysing
program correctness.)
Don't confuse logic with lines of code.
--
James Kanze
tanix
>On Dec 22, 10:53 pm, ta...@mongo.net (tanix) wrote:
>> In article
>> <fc93ba82-f199-40b3-a7fd-71c24c7d2...@u7g2000yqm.googlegroups.com>,
>> James Kanze <james.ka...@gmail.com> wrote:
>
>> >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:
>
>> > [...]
>> The rate of coding is orders of magnitude higher nowadays
>> and complexities also.
>
>Actually, I think in a lot of cases, the reverse is true.
I know, I know. That is your style after all.
:--}
Zo... Let us see here the next jewel.
> The
>applications I see today are generally a lot simpler than those
>of yesterday.
Wut?
That bites, I tellya!
> For one thing, there's true runtime support for a
>lot more functionality,
True, which means?
> so you don't have to implement it in the
>application.
Kinda.
> And there are a lot of applications doing very
>simple things---computers are cheap enough that you don't have
>a complex operation to justify using one.
Huh?
I'll skip that one. Just don't get what you are talking about.
>But both now and in previous times, there is a large interval
>between the extremes. It wouldn't surprise me if the most
>complex applications today were more complex than in previous
>times. The least complex are certainly less complex. About all
>I'd say is that the average application is less complex than
>previously.
Well, sorry, I'd have to spend way too much time arguing this.
Seems like you are stretching things WAY too far for my taste.
>> >> 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.
>
>> Well, I would simply feel uncomfortable doing ANY job,
>> unless it is a kernel mode driver, where rules of the game
>> are quite different.
>Kernel mode drivers were one of the cases I was thinking about.
>I've also written for embedded processors with only 2 KB of ROM,
>and 64 bytes of RAM.
Hey, what a time that was!
When you have to write the most compact code for your BIOS.
Otherwise it won't fit into a 4 K ROM!
:--}
THOSE were the times!
> That was a long time agom but I'm sure
>that there are still embedded processors with very limited
>resources (many of which probably don't even have a C++
>compiler---just C).
Sure, for some reason, C is STILL the most popular language
around, at least looking at the amount of traffic on C groups.
>For an application on a general purpose machine, I'd have
>serious doubts about a company which used C, or banned
>exceptions in C++.
I said that just for the sake of argument.
Not that anyone in his clear mind would go as far
as BANNING exceptions code, even though I have seen things
not to far from it.
> But there's a lot more out there than just
>general purpose machines.
> [...]
>> Once you decide to go with return codes, that's it.
>> You have to test EVERY SINGLE return code.
>That is definitely true. (Provided the "return code" returns
>something useful or important. I wouldn't normally bother with
>checking the return code of printf, for example, because it's
>really meaningless.)
Yep, some of them are funny.
But what about scanf? :--}
>> You can not make ANY assumptions.
>> If I EVER find something that does not need to return the
>> return code, because, for example, I solved it differently,
>> I immediately rewrite the called routine so it does not
>> return any return codes, just for the purity of code's sake.
>
>The possible problem here is virtual functions: if one of the
>derived classes can fail, all of the derived classes need a
>return value (or to be able to throw an exception, or whatever).
>
> [...]
>> But I am just curious: what is the essense of argument
>> that the exception processing, under non exception conditions,
>> can possibly incure a significant enough overhead to even
>> bother about it?
>That it once did, for some primorial compiler? I don't know,
>otherwise. It's certainly false today.
Cool. Makes me feel better. That is ALL I want to hear
about this issue.
>> Is it a memory allocation/deallocation issue?
>
>> Sorry to mentioni Java again, but since I started working with
>> Java as my primary language, I just do not recall a single
>> case where exceptions were inefficient.
>Exceptions are easier to make efficient when you don't have
>value semantics, and objects with non-trivial destructors.
Oh, don't tell me about those non-tivial destructors.
It makes me shiver! :--}
> It's
>also easier to write incorrect code in such cases---as I said
>elsewhere, one of the most common errors in Java is a missing
>finally block. Still, except for some very early, experimental
>implementations, I don't know of a case where an exception that
>wasn't thrown has caused performance problems in C++ either.
See?
Then my argument stands.
And that is, once the exception IS hit,
take as much time as you want to do as good of a job of
handling or reporting it as you can imagine.
Because, first of all, it is going to happen in about 0.00001%
of all cases and the overall impact of it is less than you
know what by know hopefully.
Even in some local exceptions I try to do error reporting
and logging to the point where you know EXACTLY at which
exact point happened what and what were the "wrong" paramters
or values of what.
In my main app, I designed a pretty cool mechanism
of error reporting.
What it does is this:
The main class, which is the master of everything,
had a listbox, displayed at the bottom of the main program
window. And there is a checkbox for error reporting that
triggers finer granularity of reporting.
Every single operation that is performed by ANY modules
is passed to the main class via interface.
It is automatically shown in the history listbox.
The contents of this box is automatically logged into
perpetual logs, with file names time stamped to the day.
Which means what?
Well, which means that if I ever find something funky,
not only I can see it immediately in the history box,
but I can even dig those logs, going MONTHS back and
see if some of this funk already happened in the past.
Now, the way things are logged is that you have the
leading characters and keywords that allow you to basically
find anything you want by opening a history log for
your current session and search for those lil hooks,
or things like *** Error: .....
The history listbox has about 1000 entries history,
configurable to anything you want by simply modifying
your main program config file.
So, you can scroll back in history and see ALL sorts
of nice things, such as performance of your program,
the amount of records processed, the time it took,
the amounts of duplicates you found, the amount of
records you had to skip and ALL sorts of "nice to know"
things.
That is probably the best solution I saw to day
that utilizes the concept of logging vs. debugging
and makes your logs as clear and as simple do work with,
as you can imagine. So far, have not had to regret
this design even once. Probably one of the most
powerful aspects of the whole program and I was able
to get more help out of it, than even if I had to debug
this thing for days.
You like that one? :--}
>It's also possible to misuse exceptions, so that they get thrown
>in the normal logic of program execution.
Well, again, my classic example of string to number conversion.
The conversion error is quite "normal" flow
and exception simply replaces the result with default value.
I did see one guy, who is a super programmer,
or world class programmer, who even designed the whole
language that used exceptions as an equivalent of return code
in the language he wrote.
I don't want to tell you his name or the name of that language
But the whole thing looked a bit insane to me.
His language was event driven language.
Jeeez!
Yep, I'd have to agree with you on that one.
Using exceptions in this way is a bit sick.
> I've heard of such
>cases (although I've never seen them in code I've had to deal
>with).
Lucky you! :--}
>Still, any argument against exceptions based on performance is
>simply FUD, at least IMHO.
That is what I thouht. I was just curious.
Who knows, they might have invented some trans gallactic
exception mechanism that allows you FULLY recover all the
intermediate what have you once the exception is hit.
>> >when there are things that have to be cleaned up, and the
>> >author didn't think about exceptions.
>> Well, that comes as a skill. Sooner or later they will learn,
>> or loose their job. THEN they WILL learn for sure.
>The problem is that they don't necessarily learn. Since the
>problem only occurs in "exceptional" cases, and a lot of people
>neglect testing those.
Well, then who knows, that manager may loose his job.
During severl years, when I was cranking a lot of code out,
in the middle of major development phase, I had some situations
when I basically wrote the code to the point where
"it should never happen", while handling some weird errors.
It ran fine for a day or two, and then BOOM!
I had to go back and handle that "impossible to happen" thing.
And this thing happened to me several times during the next
few months. And EVERY SINGLE TIME when I thought, hey this
thing works like a champ, BOOM!
Since then, I never try to forget about some funky
condition I was too lazy to handle or was to itchy just to
get the whole thing to work. But hey, it is more pleasure
to see the whole thing working than to deal with all those
nasty lil lice that get under your skin.
Zo...
There is a fine balance, a tradeoff.
You want to get the kicks out of seeing your thing working?
Then write the major stuff and look at how it runs.
But remember one thing: design your code in such a way,
that there are nice hooks left so that you can easily
plugin the exception or error handling code in without
needing to rewrite some major pieces of code.
Otherwise, you are screwed for good,
and it is going to cost you 10 times more time and effort
to finally make it all hum like Bentley.
>It's interesting to note that in the Java runtime, when opening
>a file fails, they run garbage collection and try again.
Actually, I am impressed with Java gc.
It turns out that it garbage collects your local scope
allocations almost as efficiently as your normal stack unwind
code.
And it garbage collects on ajacent stack slots almost as
fast.
I, personally, think C++ BADLY needs this.
Just to make sure you don't have even theoretical leaks,
all you have to do is to set some object "pointer" to null
at the end, in that finally block or at the end of your code,
which should ALWAYS have a try/catch/finally blocks if that
code is ANY good.
ALL my major code has it. Several levels deep.
NEVER had to regret it.
Outstanding logging and error reporting is a piece o cake
with this design for one thing.
>Because a lot of people forget a finally block when they've
>opened a file, and in case of an exception, never close it.
Interesting thing about finally block is that it is executed
no matter what, even if there is no exceptions.
Nice.
>(Whereas in my code, most of the time, if it's an output file,
>and there is an exception, I not only close the file, but delete
>it. So there's no inconsistent file lying around after the
>program has run.)
Well, I do not bother to go THAT far.
When operation STARTS, that is where I need to know all my
files are good if they are input.
I can not just delete the output file if some error occurs.
Because that file already has several hundred of perfeclty
good data, and even if it is damaged as a result of some
funk, the file is a text file. I don't use any other stuff.
A matter of principle.
So what I do instead is to have the archive maintenance
module, that is as powerful as it gets. It allows you
to do magic with your files, including sorting the records,
removing duplicates, normalizing the structure to increase
the processing efficiency, filtering the archive with the
most sophisticate filters, merging archives, appending
archives and verifying the archive integrity.
If some record, even in the middle of archive, is damaged,
we report and log where exactly did it happen, so it is
a matter of seconds to find the exact place and manually
fix the record or delete it if it screwed up beyond
repair.
So, after I run the archive clean operation,
I am guaranteed to have the cleanest data you can imagine
in your wildest dreams. Even clearner than it was in the
original, non error input, that sometimes still has
errors becuase of some funky servers serving some funky
non RFC compliant data.
Cool eh?
:--}
We are sitting pretty here with this thing.
> [...]
>> Do you have MORE logic in your program if you use return codes?
>> Or LESS?
>You have the same amount of logic.
Not true. But I know you are going to come up with something
kinky. Let us see here.
> Or else there's an error
>somewhere.
I'd like to see a more substantial argument on this.
> The only difference is that with exceptions, some of
>the logic isn't visible, and doesn't have to be manually
>written. (It does still have to be considered when analysing
>program correctness.)
You ARE a pervert! :--}
But fine, I appreciate THIS kind of thing.
>Don't confuse logic with lines of code.
Well, I bet this argument is SO subtle,
that you'll crack your scull sooner than you can prove it.
:--}
Enjoy the trip.
io_x
> And here is the real kicker:
>
> "We need a program of psychosurgery and
> political control of our society. The purpose is
> physical control of the mind. Everyone who
> deviates from the given norm can be surgically
> mutilated.
>
> The individual may think that the most important
> reality is his own existence, but this is only his
> personal point of view. This lacks historical perspective.
>
> Man does not have the right to develop his own
> mind. This kind of liberal orientation has great
> appeal. We must electrically control the brain.
> Some day armies and generals will be controlled
> by electrical stimulation of the brain."
Something like this is already happen first of II war world
in Germany(hittler), in Italy(mussolini), where all people
are like one
and all people think the same,
and repeat that like parrots
what the people of power said.
the voice of people that were not agree was turned off
the voice of comedians that speak again the power people were
turned off
the words were "credere, obbedire, combattere"
if who has the power is a good guy all shoudl go well;
but if he is one imbecile like hittler or mussolinie above
are millions of dead!
------------
and this is like what happen here in italy now;
when one only person here control
3 national public tv
and
has like own
3 national private tv
and control newspapers too
the same guy control all the "digitale terrestre" too
the public tv thru the parliament
and the private tv are all of that people
(in what i can understand)
people on tv repeat and repeat always the same thing.
in these tv someone can hear only one political party
the one that own all TV-newspaper in all the same party.
people of art like "Beppe Grillo" or "I Guzzanti" has no space in this
the same for "Di Pietro" (party IDV) no space,
and many other parties-comedians the same.
The old people are in their same line and repeat with them,
the people with no study repeat in chorus with them,
without doing questions.
the questions and the answer are all the same
in all interview it seems the questions are know from who
has to answer first of the tv video.
but i understand and believe in no one thing they say
they are for me all liars
for me, "journalists" here speak all the same not because they
think something, but because someone else said
they have to say only what they have to say.
> -- Dr. Jose Delgado
> (MKULTRA experimenter who demonstrated a
> radio-controlled bull on CNN in 1985)
> Director of Neuropsychiatry, Yale University
hope that the world not became one dictatorship
and there is a way, using PCs to hear not always
the same voice, or more angles to see the reality
(if possible in anonimity too because of dictotorship)
Ian Collins
> James Kanze <james...@gmail.com> wrote:
>> On Dec 22, 10:53 pm, ta...@mongo.net (tanix) wrote:
>>> The rate of coding is orders of magnitude higher nowadays
>>> and complexities also.
>> Actually, I think in a lot of cases, the reverse is true.
>
> I know, I know. That is your style after all.
> :--}
>
>> The
>> applications I see today are generally a lot simpler than those
>> of yesterday.
>
> Wut?
> That bites, I tellya!
>
>> For one thing, there's true runtime support for a
>> lot more functionality,
>
> True, which means?
>
>> so you don't have to implement it in the
>> application.
>
> Kinda.
>
>> And there are a lot of applications doing very
>> simple things---computers are cheap enough that you don't have
>> a complex operation to justify using one.
>
> Huh?
> I'll skip that one. Just don't get what you are talking about.
Oh come on, even you must realise there are millions or tiny CPUs in all
sorts of trivial gadgets these days.
<ramblings snipped.
>> Don't confuse logic with lines of code.
>
> Well, I bet this argument is SO subtle,
> that you'll crack your scull sooner than you can prove it.
Bullshit. Try implementing automatic object destruction in C and see
how many lines of code that adds that you don't have to write in C++.
> --
Your sig delimiter is broken.
--
Ian Collins