vector and struct deallocation

[none]

Unless the particular std::string implementation happens to use short
string optimization (which really isn't a given), it will be horribly
inefficient and wastes memory. Even if it *does* implement short string
optimization, it will still be a lot larger than 6 bytes. std::string
doesn't protect you from out-of-bounds accesses either (except in the
debug mode of some compilers).

If you really need an operator== for it, either write it as a member of
that struct or use std::array instead.

There's an advantage to std::string over a static array only if the size
of the string could grow. (Even then you should be aware of the possible
efficiency problems.)

Hmm, not quite as simple as that. Even without going deep into the details:

std::string::size() will be faster than strlen on a static array
std::string:perator==() is faster than strcmp if length differ.

Particularly relevant since OP stated that the id vary in length.

So depending on the data and the usage, the space overhead of
std::string may be compensated by a speed improvements.

Yannick

 

[Rui Maciel]

If the 'id' member can have at most 6 characters, and especially if this
is checked when it's assigned to, why on earth would you want to use
std::string instead of char[6]?

http://www.parashift.com/c++-faq/use-string-not-char-ptr.html


Rui Maciel

That shows why std:string is better than raw char* pointers, not better
than char[] arrays.

The very first sentence in that site reads as follows:

<quote>
If what you really want to do is work with strings, don't use an array of
char in the first place, since arrays are evil. Instead use an object of
some string-like class.
</quote>


Rui Maciel

 

[Juha Nieminen]

std::string::size() will be faster than strlen on a static array
std::string:perator==() is faster than strcmp if length differ.

If you need the length to be as fast as possible, you could just store
it as another member variable (and then write some member functions to
make it easy to do any operations related to it).

In fact, since the length cannot ever be larger than 6, you can make the
integral variable a small one, such as a short or a char, in which case
the entire id string (contents and size) will take a nice round 8 bytes
from the struct object.

 

[Juha Nieminen]

The very first sentence in that site reads as follows:

<quote>
If what you really want to do is work with strings, don't use an array of
char in the first place, since arrays are evil. Instead use an object of
some string-like class.
</quote>

"Array" is an ambiguous term in C/C++ because there are two types of
arrays: Static arrays and dynamically allocated arrays. These are two
completely different beasts (even though a pointer of the same type can
point to either one, and the former can be implicitly casted to such a
pointer).

From the context, and from the rest of the article, it's clear that the
first paragraph is talking about dynamically allocated char arrays.

In general, in the vast majority of cases, there's little reason to not
to prefer std::string over handling "raw" dynamically allocated char arrays
if you are handling strings. The former is just a lot safer, offers more,
and is often more efficient (for example std::string::size() is faster than
the C equivalent strlen().)

However, when we are talking about static arrays, the problem is not as
straightforward. A beginner should prefer using std::string even in this
case because static arrays are pretty low-level and require for you to
know what you are doing. However, for experienced programmers static arrays
offer a great tool for optimization (both in terms of memory consumption and
speed). Of course a big emhpasis on "you have to know what you are doing".
Using static arrays requires more care and attention to detail than using
std::string, but when correctly used, the result can be significantly more
efficient. (Of course such optimization is worth only in cases where it
really matters, eg. if you need to instantiate a struct containing such
a string millions of times. In a one-shot case it's often not worth the
extra effort.)

 

[none]

I would like to thank all of you, but nobody answered my question.
Now I use a totally different approach, but it could be still
interesting to know the correct deallocation procedure.

Divide and conquer.

You have a struct WPT and a struct ROUTE.
Create a function "FreeStructWPT(WPT *) and
a function FreeStructROUTE(ROUTE *)

Make sure that the functions are safe and work independently

Now if you want to free a collection of WPT *, you call
FreeStructWPT() for each of the contained pointers. Etc.

Once you have done it and are confortable with it, rename your
function FreeStructWPT(WPT *) to WPT::~WPT(). you've just
invented destructor

Yannick

 

[none]

If you need the length to be as fast as possible, you could just store
it as another member variable (and then write some member functions to
make it easy to do any operations related to it).

In fact, since the length cannot ever be larger than 6, you can make the
integral variable a small one, such as a short or a char, in which case
the entire id string (contents and size) will take a nice round 8 bytes
from the struct object.

Agree. But my point remains: there are other advantages to
std::string over static arrays. Not just if the size can grow
dynamically.

Yannick

 

[Krice]

    if(wpt->route) {

Try to remove this check and see what happens. If you always allocate
route it's not needed anyway.

 

[Cristiano]

if(wpt->route) {

Try to remove this check and see what happens.

Unfortunately I totally changed the code to use std::string (when I
don't use char ID[6]).

If you always allocate route it's not needed anyway.

Some WPTs don't need route.
You see
WPT *wp= new WPT; wpt.push_back(wp);
ROUTE *rou= new ROUTE; wp->route= rou;
just because I posted the "typical" program flow (without branches).
It is possible that I did some "strange" things inside the branches, but
now that I deleted the original code, we'll never know.

Cristiano

 

[Jorgen Grahn]

On 01/09/2012 20:19, Victor Bazarov wrote: ....

I have two old books,

Old books on C++ are often worse than no books at all.
Like Victor writes, get a good one.

/Jorgen