Re: memory leak in the code?
On 14 Jan., 05:39, Grizlyk <grizl...@yandex.ru> wrote:
peter koch wrote:
I really do not want to talk to much about performance.
Any competent programmer knows that performance problems
are best solved by profiling code and removing bottlenecks.
I did my best in order to show why blind usage of any classes
(including std::vector<>) will produce ugly code and why i can not
exclude using of raw stuffs of C++.
But you are just ignoring my concrete arguments and tried to show 2
main points of my errors:
1. I must not use raw (or some certain) stuffs of C++.
I did not tell you not to use raw pointers. I told you not to use
operator new[]. But of course, you should avoid raw pointers also as
you should any low level concept - whenever you don't have to use it.
2. I do not know the stuffs - even worse :) than the idea that this is
programmer resposibility to check usage rather than compiler will
check.
That was implied by your two calls to operator new[] followed by plain
operator delete.
Both of them looks like only your private opinion, your philosophical
sence of world :), and as you are not refute the concrete arguments, i
can not prove, of course, but can only repeat all silently ignored
one, but sure this is not required :).
I never saw a single concrete argument from you - only some mumbo
jumbo about high-level versus low-level stuff. There was not a single
argument why you could not use std::vector or std::string.
But since you seem so obsessed with performance,
I believe it would serve you better to give us some
examples where std::vector is unable to keep up with
the performance of your home-grown class.
Hmm, this is quite clear from my previous large explanaition, where
vector<> can not be used. In terms of C++ concept (or in terms of obj-
oriented interfaces), one can say, that:
1. If requested concept of array is equal to concept of vector<>, then
std library can (and must) garantee, that the concept will be
implemented as efficienly, as C++ allowes (means vector<> can be
used).
2. If requested concept of array is more than concept of vector<>,
then vector<> can not be used, you need new extra class to implement
the requsted concept of array (implementation of the new class can use
vector<> hiddenly).
3. If requested concept of array is less than concept of vector<>,
then vector<> can produce poor code, because not-used properties of
more complex concept of vector<> can produce not-used data and code.
"will do produce" or "will do not produce" depends only from concrete
implementation of concrete vector<> for concrete target arch.
In order to detect, you need refer to the concrete implementation of
of concrete vector<> for concrete target arch.
(Any reference to implementation violates encapsulation - bad desing
way).
This is not so. std::vector (as do all the containers) have strict
requirements with regards to their implementation and performance. I
told you so in one of my earlier threads, but you don't listen or you
don't understand (or I don't explain well enough).
As I also told you before, the right way to write code is to use the
obvious tools available and turn back to low-level hacks only when
performance dictates you to do so. The std::library will often be just
as fast and your low-level hack, and almost always be fast enough. I
have had to go outside the standard library only quite rarely in order
to satisfy my needs, and the reason to step out has not been non-
optimal performance but to be able to use the underlying architecture
in a better way.
/Peter
And the main idea of my preciuos large post, that object oriented
paradigm is independent from any concrete library interface and
problems of object oriented programming with C++ (unlike usage of POD
types) can not be resolved with the help of invention of any super-
library only.
Object oriented paradigm is required perfect access to interfaces of
any library, otherwise probably perfect and already existed code will
be lost for C++ programmer only due to difficulties of the access.