is this portable

Discussion in 'C++' started by Martin Vorbrodt, Oct 9, 2004.

  1. Hi there. Is this code portable between platforms? Is it also 100% standard
    compliant?

    #include <iostream>
    using namespace std;

    class Point {
    public:
    enum COORDS { X = 0, Y, Z };
    Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}

    const int& operator[](COORDS c) const
    { return (&_x)[c]; }

    private:
    int _x, _y, _z;
    };

    int main() {
    Point p(1, 2, 3);

    cout << p[Point::X] << endl;
    cout << p[Point::Y] << endl;
    cout << p[Point::Z] << endl;
    }

    Is it save to get the address of the first member, and do pointer arithmetic
    on it to get to all 3 elements?

    Thanx
    Martin



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Martin Vorbrodt, Oct 9, 2004
    #1
    1. Advertising

  2. "Martin Vorbrodt" <> wrote in message
    news:ck6adr$her$...
    > Hi there. Is this code portable between platforms? Is it also 100%
    > standard
    > compliant?


    No, and no.

    But why would you want to write code like this?

    john
     
    John Harrison, Oct 9, 2004
    #2
    1. Advertising

  3. Martin Vorbrodt

    Phlip Guest

    John Harrison wrote:

    > Martin Vorbrodt wrote:


    > > Hi there. Is this code portable between platforms? Is it also 100%
    > > standard
    > > compliant?

    >
    > No, and no.


    The data members were within one private: tag, so their order is
    well-defined, and their paddings are implementation-defined.

    The second rule makes them non-portable.

    So, John, why are they not 100% standard compliant?

    > But why would you want to write code like this?


    Because OpenGL rewards you to. It permits many variations of its methods to
    take an array of indices as a primitive "point object".

    The OP is advised to assert() that the size of Point equals the size of
    three ints, and keep going. Unless if John can talk him out of it.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Oct 9, 2004
    #3
  4. * Phlip:
    > John Harrison wrote:
    >
    > > Martin Vorbrodt wrote:

    >
    > > > Hi there. Is this code portable between platforms? Is it also 100%
    > > > standard
    > > > compliant?

    > >
    > > No, and no.

    >
    > So, John, why are they not 100% standard compliant?


    The program has undefined effect due to invalid pointer arithmetic
    (via indexing). My experience is that you'll probably respond to
    that by demanding some further justification. And to respond to
    that response in advance, look up the rules for valid pointer values.


    > > But why would you want to write code like this?

    >
    > Because OpenGL rewards you to. It permits many variations of its methods to
    > take an array of indices as a primitive "point object".
    >
    > The OP is advised to assert() that the size of Point equals the size of
    > three ints, and keep going. Unless if John can talk him out of it.


    That's very bad advice because undefined effect is unnecessary.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Oct 9, 2004
    #4
  5. "Phlip" <> wrote in message
    news:uLS9d.6832$...
    > John Harrison wrote:
    >
    >> Martin Vorbrodt wrote:

    >
    >> > Hi there. Is this code portable between platforms? Is it also 100%
    >> > standard
    >> > compliant?

    >>
    >> No, and no.

    >
    > The data members were within one private: tag, so their order is
    > well-defined, and their paddings are implementation-defined.
    >
    > The second rule makes them non-portable.
    >
    > So, John, why are they not 100% standard compliant?


    I guess it depends what you mean by standard compliant. I said no because
    dubious pointer arithmetic in the Point class potentially allows access to
    padding bytes resulting in undefined behaviour.


    >
    >> But why would you want to write code like this?

    >
    > Because OpenGL rewards you to. It permits many variations of its methods
    > to
    > take an array of indices as a primitive "point object".
    >


    I can't see the advantage of the OP's code over this, which is portable and
    standards compliant

    class Point {
    public:
    enum COORDS { X = 0, Y, Z };
    Point(int x, int y, int z)
    {
    _val[X] = x;
    _val[Y] = y;
    _val[Z] = z;
    }

    const int& operator[](COORDS c) const
    { return _val[c]; }

    private:
    int _val[3];
    };

    > The OP is advised to assert() that the size of Point equals the size of
    > three ints, and keep going. Unless if John can talk him out of it.
    >


    The OP's code is very likely to work in practice, but it seems to me that
    100% complaint code could do as well, and should be preferred.

    john
     
    John Harrison, Oct 9, 2004
    #5
  6. John Harrison wrote:
    > "Phlip" <> wrote in message
    > news:uLS9d.6832$...
    >
    >>John Harrison wrote:
    >>
    >>
    >>>Martin Vorbrodt wrote:

    >>
    >>>>Hi there. Is this code portable between platforms? Is it also 100%
    >>>>standard
    >>>>compliant?
    >>>
    >>>No, and no.

    >>
    >>The data members were within one private: tag, so their order is
    >>well-defined, and their paddings are implementation-defined.
    >>
    >>The second rule makes them non-portable.
    >>
    >>So, John, why are they not 100% standard compliant?

    >
    >
    > I guess it depends what you mean by standard compliant. I said no because
    > dubious pointer arithmetic in the Point class potentially allows access to
    > padding bytes resulting in undefined behaviour.
    >
    >
    >
    >>>But why would you want to write code like this?

    >>
    >>Because OpenGL rewards you to. It permits many variations of its methods
    >>to
    >>take an array of indices as a primitive "point object".
    >>

    >
    >
    > I can't see the advantage of the OP's code over this, which is portable and
    > standards compliant
    >
    > class Point {
    > public:
    > enum COORDS { X = 0, Y, Z };
    > Point(int x, int y, int z)
    > {
    > _val[X] = x;
    > _val[Y] = y;
    > _val[Z] = z;
    > }
    >
    > const int& operator[](COORDS c) const
    > { return _val[c]; }
    >
    > private:
    > int _val[3];
    > };
    >
    >
    >>The OP is advised to assert() that the size of Point equals the size of
    >>three ints, and keep going. Unless if John can talk him out of it.
    >>

    >
    >
    > The OP's code is very likely to work in practice, but it seems to me that
    > 100% complaint code could do as well, and should be preferred.
    >
    > john
    >
    >


    I thought identifiers with leading underscores were reserved
    for the compiler / implementation's usage. If this is so,
    then it is not portable (because some compilers may have
    identifiers with those names).

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.comeaucomputing.com/learn/faq/
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    http://www.sgi.com/tech/stl -- Standard Template Library
     
    Thomas Matthews, Oct 9, 2004
    #6
  7. >
    > I thought identifiers with leading underscores were reserved
    > for the compiler / implementation's usage. If this is so,
    > then it is not portable (because some compilers may have
    > identifiers with those names).
    >


    Only when those identifiers are at namespace scope. Within a class or a
    function they are OK.

    john
     
    John Harrison, Oct 9, 2004
    #7
  8. Martin Vorbrodt

    Mike Wahler Guest

    "Thomas Matthews" <> wrote in
    message news:...
    > John Harrison wrote:
    > > "Phlip" <> wrote in message
    > > news:uLS9d.6832$...
    > >
    > >>John Harrison wrote:
    > >>
    > >>
    > >>>Martin Vorbrodt wrote:
    > >>
    > >>>>Hi there. Is this code portable between platforms? Is it also 100%
    > >>>>standard
    > >>>>compliant?
    > >>>
    > >>>No, and no.
    > >>
    > >>The data members were within one private: tag, so their order is
    > >>well-defined, and their paddings are implementation-defined.
    > >>
    > >>The second rule makes them non-portable.
    > >>
    > >>So, John, why are they not 100% standard compliant?

    > >
    > >
    > > I guess it depends what you mean by standard compliant. I said no

    because
    > > dubious pointer arithmetic in the Point class potentially allows access

    to
    > > padding bytes resulting in undefined behaviour.
    > >
    > >
    > >
    > >>>But why would you want to write code like this?
    > >>
    > >>Because OpenGL rewards you to. It permits many variations of its methods
    > >>to
    > >>take an array of indices as a primitive "point object".
    > >>

    > >
    > >
    > > I can't see the advantage of the OP's code over this, which is portable

    and
    > > standards compliant
    > >
    > > class Point {
    > > public:
    > > enum COORDS { X = 0, Y, Z };
    > > Point(int x, int y, int z)
    > > {
    > > _val[X] = x;
    > > _val[Y] = y;
    > > _val[Z] = z;
    > > }
    > >
    > > const int& operator[](COORDS c) const
    > > { return _val[c]; }
    > >
    > > private:
    > > int _val[3];
    > > };
    > >
    > >
    > >>The OP is advised to assert() that the size of Point equals the size of
    > >>three ints, and keep going. Unless if John can talk him out of it.
    > >>

    > >
    > >
    > > The OP's code is very likely to work in practice, but it seems to me

    that
    > > 100% complaint code could do as well, and should be preferred.
    > >
    > > john
    > >
    > >

    >
    > I thought identifiers with leading underscores were reserved
    > for the compiler / implementation's usage.


    Only those at namespace or 'global' scope.

    However, I've adopted the practice of not using them at
    all, obviating the need to even consider the details of
    rules like this.

    -Mike
     
    Mike Wahler, Oct 10, 2004
    #8
  9. Martin Vorbrodt

    Phlip Guest

    John Harrison wrote:

    > I guess it depends what you mean by standard compliant. I said no because
    > dubious pointer arithmetic in the Point class potentially allows access

    to
    > padding bytes resulting in undefined behaviour.


    That's implementation-defined. But I have not read the other posts yet...

    > I can't see the advantage of the OP's code over this, which is portable

    and
    > standards compliant


    I added the syntactic sugar the OP wanted:

    > class Point {
    > public:
    > enum COORDS { X = 0, Y, Z };


    int &x_;
    int &y_;
    int &z_;

    > Point(int x, int y, int z)

    : x_(_val[X]),
    y_(_val[Y]),
    z_(_val[Z])
    > {
    > _val[X] = x;
    > _val[Y] = y;
    > _val[Z] = z;
    > }
    >
    > const int& operator[](COORDS c) const
    > { return _val[c]; }
    >
    > private:
    > int _val[3];
    > };


    New question: Is taking a reference to the storage where a variable will be
    before it initializes defined?

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Oct 10, 2004
    #9
  10. Martin Vorbrodt

    Phlip Guest

    Alf P. Steinbach wrote:

    > The program has undefined effect due to invalid pointer arithmetic
    > (via indexing). My experience is that you'll probably respond to
    > that by demanding some further justification. And to respond to
    > that response in advance, look up the rules for valid pointer values.


    Point to a valid object, NULL, or one off the end of an array..? Nope - not
    gonna ask.

    (I'm still waiting to hear if you found a real reason to disliked my TEST_
    macro, besides I wrote it.)

    > > The OP is advised to assert() that the size of Point equals the size of
    > > three ints, and keep going. Unless if John can talk him out of it.

    >
    > That's very bad advice because undefined effect is unnecessary.


    Code dealing with Points, such as OpenGL code, typically undergoes sick
    optimizations. Naturally I have seen worse than my bad advice.

    Even applying my other post might degrade performance, when the compiler
    can't optimize the references away fully.

    Oh, and would those references make the Point a non-PODs? So the pointer
    trick might have another reason to be less defined?

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Oct 10, 2004
    #10
  11. Martin Vorbrodt

    Mike Wahler Guest

    "Phlip" <> wrote in message
    news:Us0ad.6899$...
    > John Harrison wrote:
    >
    > > I guess it depends what you mean by standard compliant. I said no

    because
    > > dubious pointer arithmetic in the Point class potentially allows access

    > to
    > > padding bytes resulting in undefined behaviour.

    >
    > That's implementation-defined.


    Which renders it unportable.

    > But I have not read the other posts yet...
    >
    > > I can't see the advantage of the OP's code over this, which is portable

    > and
    > > standards compliant

    >
    > I added the syntactic sugar the OP wanted:
    >
    > > class Point {
    > > public:
    > > enum COORDS { X = 0, Y, Z };

    >
    > int &x_;
    > int &y_;
    > int &z_;
    >
    > > Point(int x, int y, int z)

    > : x_(_val[X]),
    > y_(_val[Y]),
    > z_(_val[Z])
    > > {
    > > _val[X] = x;
    > > _val[Y] = y;
    > > _val[Z] = z;
    > > }
    > >
    > > const int& operator[](COORDS c) const
    > > { return _val[c]; }
    > >
    > > private:
    > > int _val[3];
    > > };

    >
    > New question: Is taking a reference to the storage where a variable will

    be
    > before it initializes defined?


    AFAIK, it's perfectly legal, just don't try to evaluate the
    object to which it refers until that object has been assigned
    a value. IMO this is the same thing as declaring a reference
    parameter to a function, which of course is fine.

    -Mike
     
    Mike Wahler, Oct 10, 2004
    #11
  12. Martin Vorbrodt

    Phlip Guest

    Mike Wahler wrote:

    > > That's implementation-defined.

    >
    > Which renders it unportable.


    Sorry - I didn't hear "portable to any conceivable C++ platform". Hence the
    assert(sizeof) thing to simply raise an alarm when the portability envelop
    is crossed. But there I go again, helping solve the outer problem instead of
    the exact question...

    The OP is advised to write code whose legality can be trivially determined,
    and to profile various kinds of statements to learn which ones are optimal.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Oct 10, 2004
    #12
  13. * Phlip:
    >
    > (I'm still waiting to hear if you found a real reason to disliked my TEST_
    > macro, besides I wrote it.)


    Well, I dislike macros, so in the context of what would be _ideal_ I dislike
    macro-based code -- but in the context of getting the job done, if it works,
    don't fix it... ;-) There's also the question of learning curve both for the
    one who implements the thing (that doesn't apply to you here, but in general)
    and for those using it. So in that non-C++ perspective I think it's fine, a
    Good Idea (TM), because it's much better to have automated testing than not.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Oct 10, 2004
    #13
  14. "Phlip" <> wrote in message
    news:Us0ad.6899$...
    > John Harrison wrote:
    >
    >> I guess it depends what you mean by standard compliant. I said no because
    >> dubious pointer arithmetic in the Point class potentially allows access

    > to
    >> padding bytes resulting in undefined behaviour.

    >
    > That's implementation-defined. But I have not read the other posts yet...


    OK my bad, I didn't look it up.

    >
    >> I can't see the advantage of the OP's code over this, which is portable

    > and
    >> standards compliant

    >
    > I added the syntactic sugar the OP wanted:
    >
    >> class Point {
    >> public:
    >> enum COORDS { X = 0, Y, Z };

    >
    > int &x_;
    > int &y_;
    > int &z_;
    >
    >> Point(int x, int y, int z)

    > : x_(_val[X]),
    > y_(_val[Y]),
    > z_(_val[Z])
    >> {
    >> _val[X] = x;
    >> _val[Y] = y;
    >> _val[Z] = z;
    >> }
    >>
    >> const int& operator[](COORDS c) const
    >> { return _val[c]; }
    >>
    >> private:
    >> int _val[3];
    >> };


    Are you sure? In his original post he as _x, _y and _z as private.

    In any case I don't consider the price worth paying.

    john
     
    John Harrison, Oct 10, 2004
    #14
  15. Martin Vorbrodt

    Mike Wahler Guest

    "Phlip" <> wrote in message
    news:5S0ad.6901$...
    > Mike Wahler wrote:
    >
    > > > That's implementation-defined.

    > >
    > > Which renders it unportable.

    >
    > Sorry - I didn't hear "portable to any conceivable C++ platform".


    I heard "is this portable?" and "is this 100% standard compliant?"

    > Hence the
    > assert(sizeof) thing to simply raise an alarm when the portability envelop
    > is crossed. But there I go again, helping solve the outer problem instead

    of
    > the exact question...


    If what you wrote helps anyone, that's great.

    > The OP is advised to write code whose legality can be trivially

    determined,
    > and to profile various kinds of statements to learn which ones are

    optimal.

    Agreed.

    -Mike
     
    Mike Wahler, Oct 10, 2004
    #15
  16. * Martin Vorbrodt:
    > Hi there. Is this code portable between platforms? Is it also 100% standard
    > compliant?
    >
    > #include <iostream>
    > using namespace std;
    >
    > class Point {
    > public:
    > enum COORDS { X = 0, Y, Z };
    > Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}
    >
    > const int& operator[](COORDS c) const
    > { return (&_x)[c]; }


    No (because of padding & alignment issues), and no (it's Undefined Behavior).


    > private:
    > int _x, _y, _z;
    > };


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Alf P. Steinbach, Oct 10, 2004
    #16
  17. "Martin Vorbrodt" <> wrote in message news:<ck6adr$her$>...
    > Hi there. Is this code portable between platforms? Is it also 100% standard
    > compliant?

    ....

    > class Point {
    > public:
    > enum COORDS { X = 0, Y, Z };
    > Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}
    >
    > const int& operator[](COORDS c) const
    > { return (&_x)[c]; }
    >
    > private:
    > int _x, _y, _z;
    > };


    No. Absolutely not. The address of _x tells you where _x is located.
    It does not imply anything about the other members, and it's
    undefined to use &x as the base pointer of an array, since it doesn't
    point into one. You really don't want to use it as if it were one,
    because that takes you into undefined territory.

    If you do this, you're depending on compiler implementation detail
    such as the order that the members are layed out in memory, and that
    there's no padding bytes between the members. It goes without saying
    that depending on compiler implementation details is not portable.

    > Is it save to get the address of the first member, and do pointer arithmetic
    > on it to get to all 3 elements?


    Tricks like this may sometimes (unfortunately) work as expected, and
    sometimes even so-called experts do them. But undefined behavior is
    undefined behavior, and the appearance of "working" is one way
    undefined behvaior manifests itself. This kind of coding is
    needlessly dangerous and certain to eventually cause you harm. (That
    is, it WILL break someday, on some platform, and you'll spend hours
    debugging a problem that should not exist.) I suggest you write code
    that is so obviously correct that you don't have to ask. For example:

    class Point {
    public:
    enum COORDS { X = 0, Y, Z };
    Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}

    const int& operator[](COORDS c) const
    { switch(c) {
    case X: return _x;
    case Y: return _y;
    case Z: return _z;
    default: throw std::runtime_error("Invalid argument");
    }

    private:
    int _x, _y, _z;
    };

    Or alternately,

    class Point {
    public:
    enum COORDS { X = 0, Y, Z };
    Point(int x, int y, int z) { xyz[X] = x; xyz[Y] = y; xyz[Z]
    = z;}

    const int& operator[](COORDS c) const
    { return xyz[c]; }

    private:
    int xyz[3];
    };

    In this second case, member xyz is an array and it's thereforce safe
    to index into. (Assuming the argument to operator[] is in range, of
    course.)

    --
    Chris

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Chris Uzdavinis, Oct 10, 2004
    #17
  18. Hi,

    Martin Vorbrodt wrote:
    > Hi there. Is this code portable between platforms? Is it also 100% standard
    > compliant?
    >
    > #include <iostream>
    > using namespace std;
    >
    > class Point {
    > public:
    > enum COORDS { X = 0, Y, Z };
    > Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}
    >
    > const int& operator[](COORDS c) const
    > { return (&_x)[c]; }
    >
    > private:
    > int _x, _y, _z;
    > };
    >
    > int main() {
    > Point p(1, 2, 3);
    >
    > cout << p[Point::X] << endl;
    > cout << p[Point::Y] << endl;
    > cout << p[Point::Z] << endl;
    > }
    >
    > Is it save to get the address of the first member, and do pointer arithmetic
    > on it to get to all 3 elements?


    No, it is no safe. There may be padding between the members and your
    indexing operator assumes that the members are placed one after another
    in memory. This is not guaranteed (but may happen to work on many
    platforms).

    What about this:

    class Point
    {
    public:
    enum COORDS { X = 0, Y, Z };
    Point(int x, int y, int z)
    { coords_[0] = x; coords_[1] = y; coords_[2] = z;}

    const int & operator[](COORDS c) const { return coords_[c]; }

    private:
    int coords_[3];
    };

    --
    Maciej Sobczak : http://www.msobczak.com/
    Programming : http://www.msobczak.com/prog/


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Maciej Sobczak, Oct 10, 2004
    #18
  19. Martin Vorbrodt

    Tokyo Tomy Guest

    "Martin Vorbrodt" <> wrote in message news:<ck6adr$her$>...
    > Hi there. Is this code portable between platforms? Is it also 100% standard
    > compliant?
    >
    > ...
    > Is it save to get the address of the first member, and do pointer arithmetic
    > on it to get to all 3 elements?
    >


    Pointer arithmetic is effective for continuous memory arrangement. I
    don't think that the standard say something how to arrange class
    members, _x, _y, and _z, on memory. Therefore your code is not
    guaranteed to work, although I think it works in many cases.

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Tokyo Tomy, Oct 10, 2004
    #19
  20. Martin Vorbrodt

    Carl Barron Guest

    In article <ck6adr$her$>, Martin Vorbrodt
    <> wrote:

    > Hi there. Is this code portable between platforms? Is it also 100% standard
    > compliant?
    >
    > #include <iostream>
    > using namespace std;
    >
    > class Point {
    > public:
    > enum COORDS { X = 0, Y, Z };
    > Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}
    >
    > const int& operator[](COORDS c) const
    > { return (&_x)[c]; }
    >
    > private:
    > int _x, _y, _z;
    > };
    >
    > int main() {
    > Point p(1, 2, 3);
    >
    > cout << p[Point::X] << endl;
    > cout << p[Point::Y] << endl;
    > cout << p[Point::Z] << endl;
    > }
    >
    > Is it save to get the address of the first member, and do pointer arithmetic
    > on it to get to all 3 elements?
    >

    I can't name a compiler on which it will fail, but the compiler is
    permitted to insert padding of its choice between _x,_y,_z and is
    not permitted to do so with an int array. That said why not just provide
    three access inlined access function members??

    class Point
    {
    // ...
    public
    int X() const {return _x;}
    int Y() const {return _y;}
    int Z() const {return _z;}
    };

    This is portable and unless you prohibit inliniing it willl be at least
    as efficient.
    Point p(1,2,3);
    std::cout << p.X() << ',' << p.Y() << ',' << p.Z() << '\n';

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Carl Barron, Oct 10, 2004
    #20
    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. Roger

    Portable Coding Guidelines?

    Roger, Dec 17, 2004, in forum: VHDL
    Replies:
    0
    Views:
    566
    Roger
    Dec 17, 2004
  2. Eli Bendersky
    Replies:
    1
    Views:
    1,197
    Mike Treseler
    Mar 1, 2006
  3. =?Utf-8?B?c3VyZXNoX0Mj?=
    Replies:
    8
    Views:
    7,533
    =?Utf-8?B?TWFoZXNoIE5pbWJhbGthcg==?=
    May 3, 2005
  4. Albretch
    Replies:
    4
    Views:
    548
    Roedy Green
    Jun 18, 2004
  5. Replies:
    7
    Views:
    937
Loading...

Share This Page