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
That was implied by your two calls to operator new followed by plain
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
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
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
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.
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-
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.