memory leak in the code?

[Grizlyk]

You use the standard elements available, e.g. std::string. This is
very good advice.

The good advice has no provements. Any simple thing is always better
than complex one. What is the problems with strXXX in the concrete
context? Nothing. The code in not intended to be reused, never.

No. The program is "stupid" because it does not use
what is available

I think i answered on the question below:
So, we will see your opinion on the idea below.

but insists on using elements of a coding style
that were meant for more low-level programming.

It is freedom, to be without strange limitations .

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

Who is the grave "glimpse", that can not see templates, namespaces and
tons of C++ code ? He is wrong.

The template is an attempt to have a "smart" pointer to some
storage perhaps?

The concrete listed template is intended to be storage for all dynamic
C-style arrays, that required inside of any block scope. The template
is owner of memory of the arrays and makes all that neccesery to
correctly return unused memory into system back.

The template has only free-stating methods, so implementation of the
template has not more overhead than ordinary POD pointer.

I am afraid I fail to see the purpose of that class.

This is very useful thing, if you need C-style array with unknown for
compile time size of the array, for non-intrusive, dynamic arrays
allocated by new[].

Did you measure your perceived loss?

Sorry, It was question for which I was going to answer myself: "what
kind of replacement _could_ be done...". No, i did not measure
anything, but saw assempler output.

A SIG is not a C++ exception.

I agree.

Do not transform hardware exceptions into C++ exceptions.

I guess, you advise to do not throw from signal handler, probably? I
agree. To deliver SIGxxx to signal handler environment of executable
do some thing, that outside of C++ scope, but not prohibited by C++ to
catch excepion inside of strcpy.

At any rate, is does not matter, who can throw inside of strcpy, but
the code is ready to catch the possible exception and return the
unused memory into system back.

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.

All depends from target, but if "new[]" is not prohibited, it must
work correctly. I hope, that for C++ "correct work" will be selected
instead of attacks again "new[]".

I do not know what DTA is

DTA is a raw memory area for transfer data over any boundaries or used
for temporary storage.

but if you can use operator new you can also
use std::vector.

But i am not goint do use no one member of class vector<>, and the

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.

And what _exactly_ i do not understand in the concrete low level
tools? I see, you want to say, that all errors in C++ produced only by
human, in spite of compiler bring all forces to help him?

And your advice looks like you believe, that if i want to use any part
of C++, but i am not sure do i understand or do not what i am going to
do, i must select the standard library, doesn't it? Or what?

The question was: are you allowing use of other parts of language, and
if yes, why they can not be done also safe, as your lovely standard
library - is only true way to the future?

You can express multiplication by using addition
and a for loop, but doing so would be silly.

I do not understand, i did not use "addition and for loop". What is
concrete problem in my example without unused parts (excluding errors
already detected by me).

I am not sure I understand you here, but the C++ standard
library is very much a part of the C++ language.

All is quite clear. Type "int" is a part of language, but function
"printf" is not. The "printf" is member of a ordinary library, but the
library is standard, so you can think, that the library will exist and
your code will be portable and understandable for other readers.

Maksim A. Polyanin
old page about some C++ improvements:
http://grizlyk1.narod.ru/cpp_new

 

[peter koch]

I like it, let's go .

[snip]
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. This is especially true when
you find code with three errors in 20 lines and programmers that do
not know when to use delete and when to use delete []. Use the
standard libraries, measure and rewrite where you have to - if need be
by replacing e.g. standard containers by your own product (though I do
not remember when that gave any speed-up worth mentioning).

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. You
certainly must have spent some time profiling std::vector and your own
alt_vector so that you can tell us ignorant fools what the secret
behind your alt-vector is.

/Peter

 

[peter koch]

The good advice has no provements. Any simple thing is always better
than complex one. What is the problems with strXXX in the concrete
context? Nothing. The code in not intended to be reused, never.

What is wrong with the code is that you are using three lines of code
where one should suffice and that your code risks a buffer-overflow.
And this in a section of code, where performance of code matters
zilch.
Apart from that, my guess is that the std::string approach would be
faster than your homegrown code.

[snip]

So, we will see your opinion on the idea below.


It is freedom, to be without strange limitations .

It is freedom being without limitations which obviously you don't seem
to have. You are just not using your freedom wisely, but what can one
expect from a russian? ;-)

Who is the grave "glimpse", that can not see templates, namespaces and
tons of C++ code ? He is wrong.

A template and a namespace does not do it. Sorry.

The concrete listed template is intended to be storage for all dynamic
C-style arrays, that required inside of any block scope. The template
is owner of memory of the arrays and makes all that neccesery to
correctly return unused memory into system back.

Something that std::vector does perfectly.

The template has only free-stating methods, so implementation of the
template has not more overhead than ordinary POD pointer.

Should I interpret the above to mean that you believe that member
functions cause any overhead? Sorry - you are wrong again.

I am afraid I fail to see the purpose of that class.

This is very useful thing, if you need C-style array with unknown for
compile time size of the array, for non-intrusive, dynamic arrays
allocated by new[].

Again, std::vector does this just as well and just as efficiently.

Sorry, It was question for which I was going to answer myself: "what
kind of replacement _could_ be done...". No, i did not measure
anything, but saw assempler output.

So you measured nothing. Actually, I am not surprised.

A SIG is not a C++ exception.

I agree.

Do not transform hardware exceptions into C++ exceptions.

I guess, you advise to do not throw from signal handler, probably? I
agree. To deliver SIGxxx to signal handler environment of executable
do some thing, that outside of C++ scope, but not prohibited by C++ to
catch excepion inside of strcpy.

At any rate, is does not matter, who can throw inside of strcpy, but
the code is ready to catch the possible exception and return the
unused memory into system back.

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.

All depends from target, but if "new[]" is not prohibited, it must
work correctly. I hope, that for C++ "correct work" will be selected
instead of attacks again "new[]".

New works perfectly and is not prohibited, there's just no use for it.

DTA is a raw memory area for transfer data over any boundaries or used
for temporary storage.

std::vector is perfect for "DTA".

But i am not goint do use no one member of class vector<>, and the
vector<> will only protect the memory from me, but i need the memory
raw accessed.

Which you can get.

And what _exactly_ i do not understand in the concrete low level
tools? I see, you want to say, that all errors in C++ produced only by
human, in spite of compiler bring all forces to help him?

And your advice looks like you believe, that if i want to use any part
of C++, but i am not sure do i understand or do not what i am going to
do, i must select the standard library, doesn't it? Or what?

My advice is to use the standard library. If the standard library does
not do what you want fast enough (and if you are sure you understand
the standard library and use it correctly), you can try to roll wour
own specialisation and see it it helps.

The question was: are you allowing use of other parts of language, and
if yes, why they can not be done also safe, as your lovely standard
library - is only true way to the future?

Use safe features first. A program is worth nothing it does not work
correctly and using unsafe constructs is one way to spend time testing
rather than developing.

I do not understand, i did not use "addition and for loop". What is
concrete problem in my example without unused parts (excluding errors
already detected by me).

With C++ you have a nice toolbox, but to me it seems you're only using
the hammer. This is not an efficient way to program.

All is quite clear. Type "int" is a part of language, but function
"printf" is not. The "printf" is member of a ordinary library, but the
library is standard, so you can think, that the library will exist and
your code will be portable and understandable for other readers.

That is wrong. printf (to use a bad example) is part of the C++
standard library.

/Peter

 

[kwikius]

It's a dedicated system.  There aren't (or shouldn't be) any
other "applications".

Disallowing other applications greatly simplifies the design for
sure ;-).

We have logs, we can change the log configuration without
stopping the process, and we can even ftp into the users machine
to recover the log.

If your system is handling some critical job, it had better be
"perfect".

<...>

In a perfect system, logs should surely be unnecessary?

Perfect systems only exist as simplifications for theoretical proofs.
Every real system is imperfect.

 

[kwikius]

Disallowing other applications greatly simplifies the design for
sure ;-).

............

Apologies. I should have added a break here

.............

<...>

regards
Andy Little

 

[James Kanze]

Disallowing other applications greatly simplifies the design for
sure ;-).

You want your application to work, no? It's not a question of
the design of my application; regardless of the design, a rogue
application could eat up all of the resources, leaving my
application out in the cold. And if my application stops, all
long distance phone service in Germany stops, or IP address
allocation for the WAN stops, or traders cannot pass orders on
the market (and even a minute's delay in passing an order can be
expensive).

As I said, my "users" aren't very tolerant. But they're willing
to do what has to be done to achieve the reliability they need.
Most serious servers run on dedicated machines, since they don't
want some other application depriving clients of the service
(and of course, given the cost of a machine today...).

 

[Grizlyk]

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++.
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.

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 .

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).

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.

Maksim A. Polyanin
old page about some C++ improvements:
http://grizlyk1.narod.ru/cpp_new

 

[Jerry Coffin]

[ ... ]

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 more or less the case: vector can do things an array cannot do
on its own. The most obvious is that a vector can expand to hold more
items as you insert them, which an array cannot. If you're really never
using that capability, your program can include code that's never used.

The cost of this dead code is relatively low though -- it's stored on
disk, but if it's never used, it may never even be paged into physical
memory.

To support that, std::vector also uses dynamically allocated memory,
which means all access to the memory is via a pointer. Depending on the
processor and such, this _may_ be marginally slower than direct access
to the memory (though, in all honesty, it's been quite a while since I
saw a processor for which this was likely to be an issue).

For situations where these constitute real problems, TR1 and C++ 0x both
include an array class that acts more like a built-in array -- it's size
is set at creation time, and remains constant until it's destroyed.

[ ... ]

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.

I disagree. In fact, the containers (and iterators and algorithms) in
the standard library have very little object orientation at all. They
are designed to be generic, but not to be object oriented. Just for one
obvious example of this, they are NOT designed to be used with
inheritance at all.

This ties back nicely to your concern for efficiency. Being template
based, all the type inferencing (and such) involved with using these
parts of the standard library takes place at compile time. An object
oriented interface, by contrast, typically means using virtual function
calls (for one example) which carry some runtime overhead. Admittedly,
the overhead is quite small, but it can be significant anyway.

Being template based also means that the algorithms in the standard
library are often faster than (for example) their counterparts from the
C part of the library. One obvious example is the c-library qsort
function. This uses a rather object oriented interface, though the
"virtual function" used for comparison is exposed as a pointer to a
function (since C doesn't support virtual functions directly).
std::sort, by contrast uses a template so the comparison function is
resolved at compile time. The result is that it's generally much
_faster_ to use std::sort on a vector than it is to use qsort on an
array. Here's a quick comparison test:

#include <vector>
#include <algorithm>
#include <stdlib.h>
#include <time.h>

int compare(void const *a, void const *b) {
if (*(int *)a > *(int *)b)
return -1;
if (*(int *)a == *(int *)b)
return 0;
return 1;
}

const int size = 200000;

typedef unsigned long ul;

void report(char const *title, clock_t ticks) {
printf("%s took %f seconds\n", title, ticks/(double)CLOCKS_PER_SEC);
}

void wait() {
while (clock() == clock())
;
}

int main(void) {
static int array1[size];
static int array2[size];

srand(time(NULL));

for (int i=0; i<size; i++)
array1 = rand();

const int iterations = 100;

clock_t total = 0;

for (int i=0; i<iterations; i++) {
memcpy(array2, array1, sizeof(array1));
wait();
clock_t start = clock();
qsort(array2, size, sizeof(array2[0]), compare);
total += clock()-start;
}
report("qsort", total);

total = 0;
for (int i=0; i<iterations; i++) {
memcpy(array2, array1, sizeof(array1));
wait();
clock_t start = clock();
std::sort(array2, array2+size);
total += clock()- start;
}
report("std::sort (array)", total);

total = 0;
for (int i=0; i<iterations; i++) {
std::vector<int> array3(array1, array1+size);
wait();
clock_t start = clock();
std::sort(array3.begin(), array3.end());
total += clock()-start;
}
report("std::sort (vector)", total);

return 0;
}

At least with the compilers I've tested so far, std::sort is
consistently at least twice as fast as qsort. std::sort on an array is
sometimes faster than std::sort on a vector -- but sometimes it's
slower. I'm pretty sure you'd have to do the test extremely carefully
(and often) to be sure whether there's a statistically significant
difference between the two. Even if there is a difference, I'm quite
certain it's too small to care about most of the time.

 

[James Kanze]

[ ... ]

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 more or less the case: vector can do things an array
cannot do on its own. The most obvious is that a vector can
expand to hold more items as you insert them, which an array
cannot. If you're really never using that capability, your
program can include code that's never used.

The cost of this dead code is relatively low though -- it's
stored on disk, but if it's never used, it may never even be
paged into physical memory.

It's less than that: the functions which implement it are
templates, which aren't instantiated unless they are used.

To support that, std::vector also uses dynamically allocated
memory, which means all access to the memory is via a pointer.
Depending on the processor and such, this _may_ be marginally
slower than direct access to the memory (though, in all
honesty, it's been quite a while since I saw a processor for
which this was likely to be an issue).

On a Sparc (and I suspect most RISC machines), accessing through
the pointer is actually faster. (Of course, all of the
compilers I know convert the array code to use pointers
internally, so typically, there's no difference.)

For situations where these constitute real problems, TR1 and
C++ 0x both include an array class that acts more like a
built-in array -- it's size is set at creation time, and
remains constant until it's destroyed.

More importantly, it actually acts like a real data type; it
doesn't convert to a ponter (loosing the size) unless you want
it too.

One of the reasons people don't like C style arrays is that they
don't implement the concept of array very well. Conceptually,
an array is a data type, and in C/C++, data has value semantics.
Conceptually, an array has a length, and in C/C++, as soon as
the implicit conversion to a pointer has occured, the
abstraction is broken. Conceptually, std::vector<T> is a closer
approximation of an array than is T[].

[...]

At least with the compilers I've tested so far, std::sort is
consistently at least twice as fast as qsort. std::sort on an array is
sometimes faster than std::sort on a vector -- but sometimes it's
slower. I'm pretty sure you'd have to do the test extremely carefully
(and often) to be sure whether there's a statistically significant
difference between the two. Even if there is a difference, I'm quite
certain it's too small to care about most of the time.

If there is a difference, then it will depend on the compiler
and the architecture. One may be faster with one compiler or
architecture, and slower with another.

 

[peter koch]

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.

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

 

[Jerry Coffin]

[ ... ]

It's less than that: the functions which implement it are
templates, which aren't instantiated unless they are used.

Potentially used -- I was thinking of a case where you used push_back on
your vector, but in every case had used reserve up-front to ensure that
the push_back would never reallocate the vector. Even though the
reallocation will never be called, the linker won't (normally) be able
to determine that, so it'll get compiled in even though it's never used.

[...]

At least with the compilers I've tested so far, std::sort is
consistently at least twice as fast as qsort. std::sort on an array is
sometimes faster than std::sort on a vector -- but sometimes it's
slower. I'm pretty sure you'd have to do the test extremely carefully
(and often) to be sure whether there's a statistically significant
difference between the two. Even if there is a difference, I'm quite
certain it's too small to care about most of the time.

If there is a difference, then it will depend on the compiler
and the architecture. One may be faster with one compiler or
architecture, and slower with another.

True -- my point wasn't that array can't ever be faster (in fact, I know
of one compiler on Windows were it is) but that you can't depend on it
being faster -- I also know of one compiler on Windows where sorting the
vector (with the code I posted previously) is roughly twice the speed of
sorting the array.

 

[Grizlyk]

This is more or less the case: vector can do things an array
cannot do on its own. The most obvious is that a vector can
expand to hold more items as you insert them, which an array
cannot.

I assume you say about C-style array. But i have said about an
abstract array. The concrete concept of abstract array can be not
equal to C-style array.

The cost of this dead code is relatively low

I have said about object-oriented paradigm only. For the paradigm
(supported by C++) the digging of any implementation is not allowed.

That is why, it is impossible to guess anything about implementation
details over interface (by declarations of public class members). In
fact, the difference of interfaces is a reason to speak about concept
is less or more.

By the way, C++ declaration of method of conrete class does not allow
to strictly declare free-standing method as method without unused
data, or free-standing method as method without unused code.

From desing side, it is often impossible to declare any limited
implementation of an interface, for example, is impossible to strictly
declare method as free-standing, because during implementation of the
declared thing, we can find out, that free-standing implementation for
the target can not exist. And what to do?

For situations where these constitute real problems,
TR1 and C++ 0x both include an array class that acts
more like a built-in array -- it's size is set at
creation time, and remains constant until it's destroyed.

The idea of my large post is that it is impossible to enumerate and
then make as part of any library all possible concepts due to complex
nature of high-level classes.

Fortunatelly, for object-oriented paradigm a presence of any
particular library with all possible concepts is not necessary,
because code is independed from any concrete interface, so any
suitable library can be used.

I disagree. In fact, the containers (and iterators and
algorithms) in the standard library have very little
object orientation at all.

I have said about object-oriented paradigm only. The fact, that "they
are designed to be generic" can not improve C++ support of object-
oriented paradigm and can not refute the idea, that "object oriented
paradigm is required perfect access...".

In other words, the difficulties of working with interfaces of
ordinary libraries with C++ programming are real reason of the
difficulties of C++ programming with unfamiliar libraries and losses
of already development code with the unfamiliar libraries.

The fact, that universal super library is not complete or that the
existed library is unfamiliar, is not a real reason of the
difficulties.

They are designed to be generic, but not to be object
oriented. Just for one obvious example of this, they
are NOT designed to be used with inheritance at all.

By the way, object-oriented paradigm is not the same as "classes
developed with the help of inheritance". Encapsulation and
polimorphism is also required.

For C++ inheritance (in comparison with composition) is only desing
way to create a run-time templates (in comparison with compile-time

An object oriented interface, by contrast, typically means
using virtual function calls (for one example) which carry
some runtime overhead.

No, i disagree. See above.

Being template based also means that the algorithms in the
standard library are often faster than (for example) their
counterparts from the C part of the library.

I am very happy that the library is so good, but in accordance with
object-oriented paradigm, the great properties must be explicitly
declared with the help of interfaces of the library.

One obvious example is the c-library qsort function.

It is possible, but for the concrete example of array, the qsort
function is not required.

Maksim A. Polyanin
old page about some C++ improvements:
http://grizlyk1.narod.ru/cpp_new

 

[Jerry Coffin]

[ ... ]

I assume you say about C-style array. But i have said about an
abstract array. The concrete concept of abstract array can be not
equal to C-style array.

Are you saying you want to compare vector to something that exists only
in your imagination?

I have said about object-oriented paradigm only. For the paradigm
(supported by C++) the digging of any implementation is not allowed.

digging? I'm not sure what you're trying to say here.

That is why, it is impossible to guess anything about implementation
details over interface (by declarations of public class members). In
fact, the difference of interfaces is a reason to speak about concept
is less or more.

I'm guessing that English is not your primary language, and I'm trying
to allow for that, but I _really_ can't figure out what you're trying to
say here or throughout the rest of your post. Is there any chance you
can find somebody who knows English a bit better to help you express
your thoughts in a way that the rest of us might stand a bit better
chance of understanding what you're getting at?

The closest I can tell, you seem to be comparing vector to something
purely abstract, and saying that under some possible circumstances, you
can imagine something else being better than vector. If that's the case,
I have to agree: vector is not perfect for all possible situations.
OTOH, unless you're talking about something else that actually exists,
the comparison strikes me as nearly pointless.

 

[Linonut]

* Jerry Coffin peremptorily fired off this memo:

True -- my point wasn't that array can't ever be faster (in fact, I know
of one compiler on Windows were it is) but that you can't depend on it
being faster -- I also know of one compiler on Windows where sorting the
vector (with the code I posted previously) is roughly twice the speed of
sorting the array.

How come nobody ever names the compilers? I'd like to know more about
the tools I might use!

 

[Jerry Coffin]

* Jerry Coffin peremptorily fired off this memo:


How come nobody ever names the compilers? I'd like to know more about
the tools I might use!

In this case because the compiler was more or less beside the point.
Since you care, however, most of the MS compilers I have handy produce
code that seems to run the same speed for both an array and a vector.
g++ (3.4.4) produces code that's substantially slower for a vector than
an array. Comeau produces code that's about twice as fast for a vector
as an array (and, incidentally, the code it produces for an array is
still faster than anybody else produces. That's with Comeau using
Microsoft as its back-end -- I haven't really tried this particular test
with a lot of other back-ends.

 

[Grizlyk]

Are you saying you want to compare vector to something
that exists only in your imagination?

Do you really not understand what is "abstract array"? (I do not
insist on answer).

digging? I'm not sure what you're trying to say here.

Do you really can not make a noun with "ing" from verb "dig"? (I do
not insist on answer).

I saw a man in the group, who believe, that templated source can be
compiled with pure C language. And so on.

I think, any man, who are not going to asnwer for his words and allows
to himself to do anywhing what he want, is not a best company to
discuss anything. At least because the kind of man will never limit
himself only by the C++ questions and the habit will be applied by him
for anything, that is why the result of the application will be ugly
and often unexpected for any other poor listener aside, who will
believe to the honest man .

And yet, dear experts and users of stl++ and boost++ programming
languages. Take in account, there are no other group to discuss C++
questions. Note, that comp.lang.c++ is not the same as group to learn C
++ and to discuss only a certain styles of C++ programming.

I can not trace the group comp.lang.c++ day by day so i can ask time
by time some questions, in hope to find a concrete readers, who will
be able to understand the question about, and no more - i am ready to
get answers from anybody, but do not insist to answer for anybody .

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Jerry Coffin]

[ ... ]

I think, any man, who are not going to asnwer for his words and allows
to himself to do anywhing what he want, is not a best company to
discuss anything.

I agree.

Plonk!