Re: memory leak in the code?
On 7 Jan., 19:30, Grizlyk <grizl...@yandex.ru> wrote:
peter koch wrote:
As i know, for each program we get at least one (hard to
detect and with random runtime apperance) error due
to improper delete/delete[] usage.
Not in idiomatic C++ where you "never" use operator delete [].
I see the Old lovely topic - a special meaning of std library in the
world :).
Not at all. You did not use the standard library which was what I
hinted you should do.
I suspect, you are speaking about ideal situation, where we do not use
C-style arrays or C-style arrays allocated in heap, because we are
replacing them with the help of appropreate wrappers, don't?
You use the standard elements available, e.g. std::string. This is
very good advice.
I think, we even can go further, and can refuse from explicit raw
memory management with new and delete, and replace all of them with
appropreate wrappers and its messages: wrapper(...), ~wrapper,
wrapper_new(...) etc.
That probably depends on your application, and often I believe you
can. But this was not what we were talking about above.
Let's move discussion about the ideas to some lines below.
For example, the stupid program
(http://grizlyk1.narod.ru/cpp_new/gcc/utils)
for adding source lines into gcc asm output
has 3 levels of patching of detected errors.
It is quite stupid from a C++ viewpoint as it looks
more like C. in this case, You should expect using C,
not C++ style.
"stupid from a C++ viewpoint"
Program can not be stupid due to viewpoint of concrete style or
paradigm. Stupid is just because simple, the program does nothing,
copying some lines from several files into one file.
No. The program is "stupid" because it does not use what is available
but insists on using elements of a coding style that were meant for
more low-level programming.
"looks more like C"?
How will you express the following code from the program with the help
of C and why:
code example
[snip]
end of code example
I am not going to spend my time determining what your code is supposed
to do, but a glimpse shows that your code is basically C, with strcpy,
fprintf and FILE*. The template is an attempt to have a "smart"
pointer to some storage perhaps? I am afraid I fail to see the purpose
of that class.
1. possible memory leakage.
char *const tmp=new char[len+1];
strcpy(tmp,who);
msg_copied=tmp;
}
catch(...){ msg_shared="no memory"; }
"strcpy(tmp,who)" can throw while "tmp" has no owner
This is not possible so far as I know.
strcpy is C and thus does not throw.
Did you write your own strcpy?
I trust C-library in most cases, but for some situation wrappers or
even code replacement required for C-style function in C++ scope. In
the case of "strcpy", that will be comiled into "rep movsl", what kind
of replacement could be done without lost of perfomance?
Did you measure your perceived loss?
Often std::strcpy can produce one of SIGxxx, so the best solution is
if target C++ executable enviroment will work to convert hardware
exception into C++ exception. The other solution is explicit throwing
exception from not_std::strcpy implementation.
A SIG is not a C++ exception. Do not transform hardware exceptions
into C++ exceptions.
Looking at the code, it is impossible to say what kind of strcpy
implementation are used, because the code is independent from any
strcpy implementation. I think the independence is reason of
appearence of any function and especially a library.
Original code is not safe, if exception will be thrown, and modified
code is safe. Both of them can not hold on if power of CPU will be
switched off or program will be terminated by OS during strcpy
execution.
I agree, that the errors appeared due to my negligent work,
this is very bad habbit for programming, but there are many
other people with the same behaviour in the world.
This is constant fact of nature :).
Well... you can't fight bad programming in any language.
Are you think, that good programmer work only with assembler or even
directly with CPU opcodes? I guess you beleive no :). The goal of any
high-level language to reduce number of details, that must be used by
programmer simultaneously, to regroup the details into separated and
independent structures. The details with delete/delete[] look like
variable without type.
The point is that new[] is a "low-level" detail, practically never
needed in a C++ program.
So, the only way to prevent the errors is explicit memory
declarations:
char * ptr; //C-style pointer
auto char * ptr; //can not delete/delete[]
heap char * ptr; //can delete heap/delete
heap[] char * msg_copied; //can delete heap[]/delete[]
other_memory_type char *ptr; //can delete other_memory_type
Maybe it will be added to C++.
Why? We already have std::vector (and std::string). Using either of
these would have avoided your problems.
For example, just because C-arrays are not prohibited. But speaking
seriously, we sometimes need low-level dinamic buffers for simple DTA
and so on, with special behaviour, so we can write wrappers (other
than vector<>) and use raw memory management.
I do not know what DTA is but if you can use operator new you can also
use std::vector. And if you can't use std::vector, I can't see how you
can use operator new[].
And returning to suspended idea about "idiomatic C++ where you never
use operator delete []".
I agree, this is not a best way to prove anything by linking to any
authority only, but some of the following ideas are quite
undestandable.
Somewhere about 90-99 years Stroustrup wrote that:
1. C++ was designed to do not insist on any concrete way of
programming. If you say, that the way is poor, you must say what
conrete thing is a problem with the way. The fact of existance of
other ways is not enough.
You did show that yourself, I believe having three errors in a 20
lines of code because you refused to use the standard library and
insisted on using lower level tools that you did not understand.
2. C++ was designed to be set of orthogonal, self-independed parts of
solid language, that means, that you can select and use any set of
parts you wish. If you say, that the part of language must be used
here, you must say what conrete thing is a problem without. The fact
of existance of other parts is not enough.
You can express multiplication by using addition and a for loop, but
doing so would be silly.
3. Library ( he was speaking about io implementation ) is _not_ a part
of C++ language. And it is right, because there are many libraries in
the world.
I am not sure I understand you here, but the C++ standard library is
very much a part of the C++ language.
I've snipped the rest of your post as I am afraid I do not quite
understand what you are trying to tell (apart that the std::library is
not part of C++ which is wrong).
/Peter