Reassigning references (to std::map in this case)...

[Tobe]

Hi,

Here's an example of something that feels like it should be OK but
does in fact produce a segfault on every compiler I've tried (VC2005, g
++ 4.1.2/Linux, g++ 3.4.4/Cygwin). The line marked // KABOOM is the
one that segfaults. If I change the references to pointers (and make
the appropriate dereferences) everything works just fine so is this
some finer point of references I'm not grasping or an issue with the
STL ?

Answers gratefully received..

--
Tobe

=============== ==========

#include <map>
#include <string>
#include <stdio.h>

class Entry;
typedef std::map<std::s tring, EntryEntryMap;

class Entry
{
public:
std::string iValue;
EntryMap iEntries;
Entry *iParentEntry;

Entry() { iParentEntry = NULL; }
};

int main(int argc, char* argv[])
{
EntryMap entries;

entries["1"].iEntries["2"].iEntries["3"].iValue = "three";

EntryMap &entriesRef1 = entries["1"].iEntries;
EntryMap &entriesRef2 = entries["1"].iEntries["2"].iEntries;

printf("%s\n", entriesRef2["3"].iValue.c_str() );

entriesRef1 = entriesRef2; // KABOOM
printf("%s\n", entriesRef1["3"].iValue.c_str() );

return 0;
}

[Victor Bazarov]

Tobe wrote:

Here's an example of something that feels like it should be OK but
does in fact produce a segfault on every compiler I've tried (VC2005,
g ++ 4.1.2/Linux, g++ 3.4.4/Cygwin). The line marked // KABOOM is the
one that segfaults. If I change the references to pointers (and make
the appropriate dereferences) everything works just fine so is this
some finer point of references I'm not grasping or an issue with the
STL ?

Answers gratefully received..

NEVER put anything beside your signature after the "-- " (the signature
separator). Now I have to manually drag your source code in here...

EntryMap &entriesRef1 = entries["1"].iEntries;
EntryMap &entriesRef2 = entries["1"].iEntries["2"].iEntries;

So, 'entriesRef2' is a reference to an entry in a member of the
'entriesRef1's referred object.

entriesRef1 = entriesRef2; // KABOOM

What happens? You start overriding 'entries["1"].iEntries' value by
means of assigning to a reference to it. And at the same time you
probably want to continue using it (since the right-hand side still
refers to it). It's not going to work. 'entriesRef2' becomes invalid
as soon as the assignment to 'entriesRef1' begins because assignment
cleans out the contents of 'entries["1"].iEntries' thus deleting what
is behind the 'entriesRef2' along with it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Default User]

Victor Bazarov wrote:

Tobe wrote:

Here's an example of something that feels like it should be OK but
does in fact produce a segfault on every compiler I've tried
(VC2005, g ++ 4.1.2/Linux, g++ 3.4.4/Cygwin). The line marked //
KABOOM is the one that segfaults. If I change the references to
pointers (and make the appropriate dereferences) everything works
just fine so is this some finer point of references I'm not
grasping or an issue with the STL ?

Answers gratefully received..

NEVER put anything beside your signature after the "-- " (the
signature separator). Now I have to manually drag your source code
in here...

Actually, he didn't have "-- ", but "--". I assume your newsreader is
not strict on .sig separators.


Brian

[James Kanze]

On Sep 6, 8:46 pm, "Default User" <defaultuse...@ yahoo.comwrote:

Victor Bazarov wrote:

Tobe wrote:

Here's an example of something that feels like it should be OK but
does in fact produce a segfault on every compiler I've tried
(VC2005, g ++ 4.1.2/Linux, g++ 3.4.4/Cygwin). The line marked //
KABOOM is the one that segfaults. If I change the references to
pointers (and make the appropriate dereferences) everything works
just fine so is this some finer point of references I'm not
grasping or an issue with the STL ?

Answers gratefully received..

NEVER put anything beside your signature after the "-- " (the
signature separator). Now I have to manually drag your source code
in here...

Actually, he didn't have "-- ", but "--". I assume your newsreader is
not strict on .sig separators.

Or yours truncates trailing whitespace in some cases. I see
"-- " with Google news (and I'd be surprised if even Google adds
a trailing white space).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Alf P. Steinbach]

* James Kanze:

>
I see
"-- " with Google news (and I'd be surprised if even Google adds
a trailing white space).

The original message had only "--".

From earlier discussion of this, it seems that when posting, Google
Groups strips the space at the end of "-- ", because stripping it will
cause most harm and confusion, and from your comment it seems that when
reading, Google Groups adds a space, because that will cause most harm
and confusion. If Google Groups had done nothing, signature delimiters
would work perfectly. They're /actively/ messing them up.

And of course there is no obvious way to report problems with Google
Groups -- you're led on a wild goose tour leading nowhere.
Cheers,

- Alf

CC: Oh, I would CC to Google Groups technical support or customer
service or whatever, if any address was available (of course it isn't).

[mike.polyakov]

EntryMap &entriesRef1 = entries["1"].iEntries;

EntryMap &entriesRef2 = entries["1"].iEntries["2"].iEntries;

printf("%s\n", entriesRef2["3"].iValue.c_str() );

entriesRef1 = entriesRef2; // KABOOM
printf("%s\n", entriesRef1["3"].iValue.c_str() );

Your map entriesRef1 contains the map referenced by entriesRef2. When
you assign entriesRef2 to entriesRef1, entriesRef1 will be emptied
first, which will delete entriesRef2, because it is inside
entriesRef1. Then you will try to assign this dangling reference
entriesRef2 into entriesRef1, which fails.

[James Kanze]

On Sep 7, 11:55 am, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

I see
"-- " with Google news (and I'd be surprised if even Google adds
a trailing white space).

The original message had only "--".

From earlier discussion of this, it seems that when posting, Google
Groups strips the space at the end of "-- ", because stripping it will
cause most harm and confusion, and from your comment it seems that when
reading, Google Groups adds a space, because that will cause most harm
and confusion. If Google Groups had done nothing, signature delimiters
would work perfectly. They're /actively/ messing them up.

Maybe. There are so many intermediaries involved that I'm no
longer sure who's doing what. But it's true that back in the
old days, before Google and IE, things seemed to work better.

FWIW: making trailing spaces significant is a major error in the
specification, since some more exotic systems don't have any
means of maintaining them. (The existance of such systems is
why C and C++ don't guarantee them in text mode.)

And of course there is no obvious way to report problems with Google
Groups -- you're led on a wild goose tour leading nowhere.

I reported a problem once to them, and got a response. I don't
remember where I sent it, but I do know that it took some effort
to find the address, and if I remember correctly, you need a
Google account to access it.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]