Can anyone explain this, bug in GCC????

Discussion in 'C++' started by Joost Kraaijeveld, Feb 9, 2009.

  1. Hi,

    Can anyone try to explain why on the line marked with "----->" the
    variable "start" changes from it's original value to another value,
    being const?

    Example output (GCC 4.2 and 4.3 on Linux, 4.3 on Windows):

    start 0: H
    start 3: H
    start 4: H
    start 5a: A
    start 5b: H


    If you want the full source code:
    http://trac.askesis.nl/svn/tidbits/AIAStar/Main.cpp

    line 577 and further

    1 file, can be compiled by gcc 4.2 /4.3 Windows/Linux with an installed
    boost library


    void findAStarCheapestPath( const Vertex& start,
    const Vertex& finish,
    Vertices pathVertices,
    Edges pathEdges,
    Vertices& allDiscoveredVertices,
    Vertices& cheapestPathVertices,
    Edges& cheapestPathEdges) const
    {
    Vertex localStart = start;
    std::cout << "start 0: " << start << "\n";

    pathVertices.insert( pathVertices.end(), /*start*/localStart);

    Edges vertexEdges = getEdgesFor( /*start*/localStart);
    Edges::iterator e = vertexEdges.begin();
    while (e != vertexEdges.end())
    {
    const Vertex& nextVertex = (*e).otherSide( /*start*/localStart);
    //std::cout << "start 1: " << /*start*/localStart << "\n";
    if (nextVertex == finish )
    {
    pathEdges.insert( pathEdges.end(), (*e));
    pathVertices.insert( pathVertices.end(), finish);
    std::cout << "start 2: " << start << "\n";
    break;
    }
    std::cout << "start 3: " << start << "\n";
    if (std::find( allDiscoveredVertices.begin(),
    allDiscoveredVertices.end(), nextVertex) == allDiscoveredVertices.end()
    &&
    std::find( pathVertices.begin(), pathVertices.end(), nextVertex) ==
    pathVertices.end())
    {
    std::cout << "start 4: " << start << "\n";
    allDiscoveredVertices.insert(allDiscoveredVertices.begin(), nextVertex);
    ------------------> std::cout << "start 5a: " << start << "\n";
    std::cout << "start 5b: " << /*start*/localStart << "\n";
    }


    TIA

    Joost
    Joost Kraaijeveld, Feb 9, 2009
    #1
    1. Advertising

  2. * Joost Kraaijeveld:
    > Hi,
    >
    > Can anyone try to explain why on the line marked with "----->" the
    > variable "start" changes from it's original value to another value,
    > being const?
    >
    > Example output (GCC 4.2 and 4.3 on Linux, 4.3 on Windows):
    >
    > start 0: H
    > start 3: H
    > start 4: H
    > start 5a: A
    > start 5b: H
    >
    >
    > If you want the full source code:
    > http://trac.askesis.nl/svn/tidbits/AIAStar/Main.cpp
    >
    > line 577 and further
    >
    > 1 file, can be compiled by gcc 4.2 /4.3 Windows/Linux with an installed
    > boost library
    >
    >
    > void findAStarCheapestPath( const Vertex& start,
    > const Vertex& finish,
    > Vertices pathVertices,
    > Edges pathEdges,
    > Vertices& allDiscoveredVertices,
    > Vertices& cheapestPathVertices,
    > Edges& cheapestPathEdges) const
    > {
    > Vertex localStart = start;
    > std::cout << "start 0: " << start << "\n";
    >
    > pathVertices.insert( pathVertices.end(), /*start*/localStart);
    >
    > Edges vertexEdges = getEdgesFor( /*start*/localStart);
    > Edges::iterator e = vertexEdges.begin();
    > while (e != vertexEdges.end())
    > {
    > const Vertex& nextVertex = (*e).otherSide( /*start*/localStart);
    > //std::cout << "start 1: " << /*start*/localStart << "\n";
    > if (nextVertex == finish )
    > {
    > pathEdges.insert( pathEdges.end(), (*e));
    > pathVertices.insert( pathVertices.end(), finish);
    > std::cout << "start 2: " << start << "\n";
    > break;
    > }
    > std::cout << "start 3: " << start << "\n";
    > if (std::find( allDiscoveredVertices.begin(),
    > allDiscoveredVertices.end(), nextVertex) == allDiscoveredVertices.end()
    > &&
    > std::find( pathVertices.begin(), pathVertices.end(), nextVertex) ==
    > pathVertices.end())
    > {
    > std::cout << "start 4: " << start << "\n";
    > allDiscoveredVertices.insert(allDiscoveredVertices.begin(), nextVertex);
    > ------------------> std::cout << "start 5a: " << start << "\n";
    > std::cout << "start 5b: " << /*start*/localStart << "\n";
    > }


    'const' is only a promise that the routine won't change the object.

    Have you considered aliasing.

    Other than that, try to reduce the problem to a minimum, complete program and
    post it.


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Feb 9, 2009
    #2
    1. Advertising

  3. Alf P. Steinbach wrote:
    >
    > 'const' is only a promise that the routine won't change the object.
    >
    > Have you considered aliasing.


    Could you explain what you mean by this?

    > Other than that, try to reduce the problem to a minimum, complete
    > program and post it.

    That is why I send the link to the file along with the message, IMHO: a
    shorter file would not make it any clearer, but I may be wrong...

    TIA

    Joost
    Joost Kraaijeveld, Feb 9, 2009
    #3
  4. Joost Kraaijeveld

    Daniel Pitts Guest

    Joost Kraaijeveld wrote:
    > Alf P. Steinbach wrote:
    >> 'const' is only a promise that the routine won't change the object.
    >>
    >> Have you considered aliasing.

    >
    > Could you explain what you mean by this?
    >
    >> Other than that, try to reduce the problem to a minimum, complete
    >> program and post it.

    > That is why I send the link to the file along with the message, IMHO: a
    > shorter file would not make it any clearer, but I may be wrong...


    Here is a shorter file that shows the same "bug" as your code, but it is
    not a compiler bug.

    #include <iostream>

    struct foo {
    int a;
    };

    struct bar {
    foo f;
    };

    void moreStuff(bar &b) {
    b.f.a -= 3;
    }

    void stuff(const foo &f, bar &b) {
    using std::cout;
    using std::endl;

    cout << "First: " << f.a << endl;
    moreStuff(b);
    cout << "Second: " << f.a << endl;

    }

    int main(int argc, char**argv) {
    bar b = {{7}};
    stuff(b.f, b);
    }

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Feb 9, 2009
    #4
  5. Daniel Pitts wrote:
    > Here is a shorter file that shows the same "bug" as your code, but it is
    > not a compiler bug.


    Could you tell/suggest me what (exactly???) the point is , as I have
    looked at it without any enlightment , sight....

    TIA

    Joost
    Joost Kraaijeveld, Feb 9, 2009
    #5
  6. Joost Kraaijeveld

    Daniel Pitts Guest

    Joost Kraaijeveld wrote:
    > Daniel Pitts wrote:
    >> Here is a shorter file that shows the same "bug" as your code, but it is
    >> not a compiler bug.

    >
    > Could you tell/suggest me what (exactly???) the point is , as I have
    > looked at it without any enlightment , sight....
    >
    > TIA
    >
    > Joost

    The point is that some *other* function is modifying the same instance.

    It might be doing a const_cast to remove constness, or it might be
    modifying a different (non-const) reference to that same instance.

    You know that it changes right after that particular call. The problem
    is in there. Look for anything that might modify any Vertex, and see if
    there is a possibility that it is the same Vertex that you're looking at.



    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Feb 9, 2009
    #6
  7. Daniel Pitts wrote:
    > Joost Kraaijeveld wrote:
    >> Daniel Pitts wrote:
    >>> Here is a shorter file that shows the same "bug" as your code, but it is
    >>> not a compiler bug.

    >>
    >> Could you tell/suggest me what (exactly???) the point is , as I have
    >> looked at it without any enlightment , sight....
    >>
    >> TIA
    >>
    >> Joost

    > The point is that some *other* function is modifying the same instance.
    >
    > It might be doing a const_cast to remove constness, or it might be
    > modifying a different (non-const) reference to that same instance.
    >
    > You know that it changes right after that particular call. The problem
    > is in there. Look for anything that might modify any Vertex, and see if
    > there is a possibility that it is the same Vertex that you're looking at.


    Ah. That is not likely isn't it? The only thing that happens is that
    something else (nextVertex) is put into
    a vector (allDiscoveredVertices) after which the value is changed.....
    Maybe (likely?) I am missing something though

    Joost
    Joost Kraaijeveld, Feb 9, 2009
    #7
  8. Joost Kraaijeveld schrieb:
    > Daniel Pitts wrote:
    >> Joost Kraaijeveld wrote:
    >>> Daniel Pitts wrote:
    >>>> Here is a shorter file that shows the same "bug" as your code, but it is
    >>>> not a compiler bug.
    >>> Could you tell/suggest me what (exactly???) the point is , as I have
    >>> looked at it without any enlightment , sight....
    >>>
    >>> TIA
    >>>
    >>> Joost

    >> The point is that some *other* function is modifying the same instance.
    >>
    >> It might be doing a const_cast to remove constness, or it might be
    >> modifying a different (non-const) reference to that same instance.
    >>
    >> You know that it changes right after that particular call. The problem
    >> is in there. Look for anything that might modify any Vertex, and see if
    >> there is a possibility that it is the same Vertex that you're looking at.

    >
    > Ah. That is not likely isn't it? The only thing that happens is that
    > something else (nextVertex) is put into
    > a vector (allDiscoveredVertices) after which the value is changed.....
    > Maybe (likely?) I am missing something though


    If start (the value which changes) is a reference into this vector, then
    a reallocation by this vector invalidates the reference.

    --
    Thomas
    Thomas J. Gritzan, Feb 9, 2009
    #8
  9. Joost Kraaijeveld

    Jim Langston Guest

    "Joost Kraaijeveld" <> wrote in message
    news:499080ba$0$3361$4all.nl...
    > Hi,
    >
    > Can anyone try to explain why on the line marked with "----->" the
    > variable "start" changes from it's original value to another value,
    > being const?
    >
    > Example output (GCC 4.2 and 4.3 on Linux, 4.3 on Windows):
    >
    > start 0: H
    > start 3: H
    > start 4: H
    > start 5a: A
    > start 5b: H
    >
    >

    <SNIP>
    >
    > void findAStarCheapestPath( const Vertex& start,
    > const Vertex& finish,
    > Vertices pathVertices,
    > Edges pathEdges,
    > Vertices& allDiscoveredVertices,
    > Vertices& cheapestPathVertices,
    > Edges& cheapestPathEdges) const
    > {

    <SNIP>
    > {
    > std::cout << "start 4: " << start << "\n";


    > allDiscoveredVertices.insert(allDiscoveredVertices.begin(), nextVertex);


    Here you are modifying a vector (presuming allDiscoveredVertices is a
    vector) by inserting. This will change existing references as the memory
    changes. Basically the vector is moved around in memory. Where it is moved
    to and how is platform dependant. But the point is, once you do an insert
    you can not count on existing references into the vector to be good anymore.
    And your start is a reference to the start of the vector (still presuming
    it's a vector, not sure how Vertex is defined).

    > ------------------> std::cout << "start 5a: " << start << "\n";
    > std::cout << "start 5b: " << /*start*/localStart << "\n";
    > }
    >
    >
    > TIA
    >
    > Joost
    Jim Langston, Feb 11, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. renata
    Replies:
    1
    Views:
    790
    Kevin Spencer
    Jun 25, 2003
  2. Michael Tsai
    Replies:
    3
    Views:
    460
    Michael Tsai
    Aug 19, 2005
  3. Wookie
    Replies:
    2
    Views:
    320
    Mr Newbie
    Nov 13, 2005
  4. Sir Bill
    Replies:
    5
    Views:
    512
    Scott Allen
    Jan 12, 2006
  5. Harry

    Can anyone explain this...

    Harry, Feb 10, 2004, in forum: Java
    Replies:
    0
    Views:
    372
    Harry
    Feb 10, 2004
Loading...

Share This Page