Re: I'm sorry, but this is unacceptable (union members and ctors)

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ross Ridge]

Robert Dewar writes:
>The only time that it is reasonable to extend is when there are clear
>signals from the standards committee that it is likely that a feature
>will be added, in which case there may be an argument for adding the
>feature "prematurely".

I completely disagree.  Standards should primarily standardize existing
practice, not inventing new features.  New features should be created
by people who actually want and will use the features, not by some
disinterested committee.

GCC has always been a place for experimenting with new features.  Many of
the new features in C99 had already been implemented GCC.  Even in the
cases where C99 standardized features differently, I think both GCC and
Standard C benefited from the work done in GCC.

						Ross Ridge

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

Ross Ridge wrote:

> I completely disagree.  Standards should primarily standardize existing
> practice, not inventing new features.  New features should be created
> by people who actually want and will use the features, not by some
> disinterested committee.

First of all, I think you mean uninterested and not disinterested, 
indeed the ideal is that all committee members *should* be
disinterested, though this is not always the case.

But in fact I disagree fundamentally,
> 
> GCC has always been a place for experimenting with new features.  Many of
> the new features in C99 had already been implemented GCC.  Even in the
> cases where C99 standardized features differently, I think both GCC and
> Standard C benefited from the work done in GCC.

The history for C here does not apply to C++ in my opinion. Adding new
features to a language like C++ is at this stage highly non-trivial in
terms of getting a correct formal definition.
> 
> 						Ross Ridge

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Lawrence Crowl]

On 6/16/07, Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
> Robert Dewar writes:
> >The only time that it is reasonable to extend is when there are clear
> >signals from the standards committee that it is likely that a feature
> >will be added, in which case there may be an argument for adding the
> >feature "prematurely".
>
> I completely disagree.  Standards should primarily standardize existing
> practice, not inventing new features.

That is one view.  The other view is that standards can push the state
of the art in programming.  The Ada standard is a pure example of
the latter approach.  In practice, both C and C++ have been a mix of
existing practice and invention.  I think purity in approach is actually
suboptimal.

> New features should be created by people who actually want and
> will use the features, not by some disinterested committee.

The C++ standards committee consists of volunteers that actually
want and will use the features.  There is too much sheer work and
negotiation involved in the standards process to not be interested.

> GCC has always been a place for experimenting with new features.
> Many of the new features in C99 had already been implemented in
> GCC. Even in the cases where C99 standardized features differently,
> I think both GCC and Standard C benefited from the work done in
> GCC.

All true.  What the standards process buys you is more review by a
wider variety of stakeholders.  The result is generally something that
more folks can use.

On the specific topic of unions, there is a proposal before the
committee to extend unions in this direction.  Let me caution you
that this proposal has not been reviewed by a significant fraction
of the committee, and hence has a small chance of being accepted
and an even smaller chance of surviving unchanged.  See
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2248.html

-- 
Lawrence Crowl

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

mark-28 wrote:
> 
>> Mark Mielke wrote "Why not This?":
>> >     class Rectangle {
>> >         Vector2d position;
>> >         Vector2d size;
>> >     };
>> > ... rectangle.position.x = ... ...
> 
> On Thu, Jun 28, 2007 at 03:00:07AM -0700, michael.a wrote:
>> My foremost personal requirement is that no code need change outside the
>> object definition files. And besides it is ridiculous to jump through two
>> hoops, when one would suffice.
>> ...
>> Have you read the thread? (not that you should -- but before making such
>> an
>> assessment)
> 
> You find it unacceptable that GCC implements the C++ spec, and fails to
> compile
> your software that was not implemented according to the C++ spec.
> 
> You find it unacceptable that you would need to change your code to
> match the spec, but would instead rather modify GCC and have your patch
> to GCC rushed out so that you can release your product on Linux.
> 
> You find it unacceptable that union members not be allowed to contain
> struct with constructors, because you believe that the practice is safe,
> and valid, because the designer knows best. You believe the spec should
> be changed and that Microsoft has lead the way in this regard.
> 
> Do I have this right?
> 
> Is there a reason that this discovery did not occur until late in your
> development cycle? It seems to me that the first mistake on your part
> was not testing on Linux/GCC when writing the original code, if you
> knew that this was an intended port.
> 
> Cheers,
> mark
> 
> P.S. I apologize for getting confused on my last post. I was tired + ill
>      and stupidly posting after midnight. Perhaps this one will be more
> relevant
>      and effective?
> 
> 

This is a correct sumization in effect. Though I would differ that it was
not so much my mistake to not conform to gcc from the offset. I'm planning
on releasing binaries, so its not a major hickup to hack gcc. It would be
nice to see an official solution evolve in due course however. I see no
reason why c++ should be neutered to this effect. I would sight laziness on
behalf of the gcc development effort (with the effort present excuse of
adhering to spec)

C++ should've removed unions from the spec altogether if they won't support
the fundamental basis of the need for an object oriented C language (and
there is no reason why they can not be supported -- albeit, with some
caveats which really any even remotely competent person could predict)

There really is no call for such platitudes, you've simply chosen the losing
side of the argument if you choose to believe C++ will never accomodate
functional objects to be unioned. 

This is all I have to say. I will let everyone know how construction/etc is
handled by the compiler as soon as the porting process permits (a testbed
application would not likely reflect real world scenarios so easily I
suspect)

sincerely,

michael

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11353323
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[mark]

> Mark Mielke wrote "Why not This?":
> >     class Rectangle {
> >         Vector2d position;
> >         Vector2d size;
> >     };
> > ... rectangle.position.x = ... ...

On Thu, Jun 28, 2007 at 03:00:07AM -0700, michael.a wrote:
> My foremost personal requirement is that no code need change outside the
> object definition files. And besides it is ridiculous to jump through two
> hoops, when one would suffice.
> ...
> Have you read the thread? (not that you should -- but before making such an
> assessment)

You find it unacceptable that GCC implements the C++ spec, and fails to compile
your software that was not implemented according to the C++ spec.

You find it unacceptable that you would need to change your code to
match the spec, but would instead rather modify GCC and have your patch
to GCC rushed out so that you can release your product on Linux.

You find it unacceptable that union members not be allowed to contain
struct with constructors, because you believe that the practice is safe,
and valid, because the designer knows best. You believe the spec should
be changed and that Microsoft has lead the way in this regard.

Do I have this right?

Is there a reason that this discovery did not occur until late in your
development cycle? It seems to me that the first mistake on your part
was not testing on Linux/GCC when writing the original code, if you
knew that this was an intended port.

Cheers,
mark

P.S. I apologize for getting confused on my last post. I was tired + ill
     and stupidly posting after midnight. Perhaps this one will be more relevant
     and effective?

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

On Wed, Jun 27, 2007 at 11:36:23PM -0700, michael.a wrote:
> mark-28 wrote:

I agree with the sentiment, but not with the relevance. I don't see
how having a four field structure automatically appear as a completley
different two field structure, based only upon a match up between
field types and names seems more complicated and magical to me.

........

This would disagree with much of the modern programming world. Black box
programming implies that you do not need to know whether a field is a real
field, or whether it is derived from other fields. Syntactically, it sounds
you are asking for operator overloading on fields, which maps to properties
in some other language. This is not more "simpler", as it only conceals
that a function may be performed underneath. It may look prettier, or use
fewer symbol characters.
[/quote]

I really don't think it serves the thread to mince words over these matters.
I don't think having functional aliases for essentially the same data member
is magical thinking. And I made the case for the black box scenario, but I
think its also useful (especially for very low level objects) ...to know
when you are dealing with a black box (interfaced) or a very simple direct
object of the inlineable variety.

[quote]
Even so - I don't see why the following simplification of the example
provided would not suffice for your listed requirement:

    class Rectangle {
        Vector2d position;
        Vector2d size;
    };

    ... rectangle.position.x = ... ...
[/quote]

My foremost personal requirement is that no code need change outside the
object definition files. And besides it is ridiculous to jump through two
hoops, when one would suffice.

[quote]
To have these automatically be treated as compatible types seems very
wrong:

    class Rectangle { int x, y, w, h; };
    class Vector2d  { int dx, dy; };

Imagine the fields were re-arranged:

    class Rectangle { int y, x, h, w; };
    class Vector2d  { int dx, dy; };

Now, what should it do?

[/quote]

All non-toy compilers have means of insuring members are ordered in memory
as they are declared. I have a problem with people retreating to really pety
divisive arguments inorder to make regressive points.

[quote]
My best interpretation of this thread is that you are substituting
itnelligibility with DWIM, where DWIM for you is not the same as DWIM
for me, and I don't believe you could write out what your DWIM
expectation is in a way that would not break.
[/quote]

Have you read the thread? (not that you should -- but before making such an
assessment)

sincerely, (and cordially)

michael


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11340286
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[mark]

On Wed, Jun 27, 2007 at 11:36:23PM -0700, michael.a wrote:
> mark-28 wrote:
> > I don't understand what is being requested. Have one structure with
> > four fields, and another with two, and allow them to be used
> > automatically interchangeably? How is this a good thing? How will
> > this prevent the implementor from making a stupid mistake?
> Its less a question of making a stupid mistake, as code being intelligible
> for whoever must work with it / pick it up quickly out of the blue. The more
> intelligible (less convoluted) it is, the easier it is to quickly grasp what
> is going on at the macroscopic as well as the microscopic levels. The way I
> personally program, typically a comment generally only adds obscusification
> to code which already more effeciently betrays its own function.

I agree with the sentiment, but not with the relevance. I don't see
how having a four field structure automatically appear as a completley
different two field structure, based only upon a match up between
field types and names seems more complicated and magical to me.

> Also syntacticly, I think its bad form for a function to simply access a
> data member directly / fudge its type. A function should imply that
> something functional is happening (or could be happening -- in the case of
> protected data / functionality)

This would disagree with much of the modern programming world. Black box
programming implies that you do not need to know whether a field is a real
field, or whether it is derived from other fields. Syntactically, it sounds
you are asking for operator overloading on fields, which maps to properties
in some other language. This is not more "simpler", as it only conceals
that a function may be performed underneath. It may look prettier, or use
fewer symbol characters.

Even so - I don't see why the following simplification of the example
provided would not suffice for your listed requirement:

    class Rectangle {
        Vector2d position;
        Vector2d size;
    };

    ... rectangle.position.x = ... ...

To have these automatically be treated as compatible types seems very
wrong:

    class Rectangle { int x, y, w, h; };
    class Vector2d  { int dx, dy; };

Imagine the fields were re-arranged:

    class Rectangle { int y, x, h, w; };
    class Vector2d  { int dx, dy; };

Now, what should it do?

> Granted, often intelligibility can demand too much semantic overhead from
> strict languages like c, but just as often perhaps, in just such a case, a
> simple accommodation is plainly obvious.

My best interpretation of this thread is that you are substituting
itnelligibility with DWIM, where DWIM for you is not the same as DWIM
for me, and I don't believe you could write out what your DWIM
expectation is in a way that would not break.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

mark-28 wrote:
> 
> I don't understand what is being requested. Have one structure with
> four fields, and another with two, and allow them to be used
> automatically interchangeably? How is this a good thing? How will
> this prevent the implementor from making a stupid mistake?
> 

Its less a question of making a stupid mistake, as code being intelligible
for whoever must work with it / pick it up quickly out of the blue. The more
intelligible (less convoluted) it is, the easier it is to quickly grasp what
is going on at the macroscopic as well as the microscopic levels. The way I
personally program, typically a comment generally only adds obscusification
to code which already more effeciently betrays its own function.

Also syntacticly, I think its bad form for a function to simply access a
data member directly / fudge its type. A function should imply that
something functional is happening (or could be happening -- in the case of
protected data / functionality)

Granted, often intelligibility can demand too much semantic overhead from
strict languages like c, but just as often perhaps, in just such a case, a
simple accommodation is plainly obvious.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11337824
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[mark]

On Wed, Jun 27, 2007 at 10:14:18PM -0700, michael.a wrote:
> >> For instance, say you need to impliment a GUI, so you have yourself a
> >> rectangle struct which consists of four floating point values (the origin
> >> and difference between the opposite corner) ...Now you want those four
> >> values, but you also have a 2D vector struct.
> ...
> I pointed this out as the obvious portable solution somewhere in the thread.
> I just firmly believe this is an unnecessarily back breaking way of going
> about it (and physically backbreaking for whoever would have to change all
> of the code) 
> It would be a blessing were intelligible code somewhat higher up on the
> rungs of c++ priorities (being the ever ubiquitous mainstay systems
> programming language it has become and will likely remain)

Minding reading has always been considered a blessing when it comes
to programming languages. Also, an impossibility.

I don't understand what is being requested. Have one structure with
four fields, and another with two, and allow them to be used
automatically interchangeably? How is this a good thing? How will
this prevent the implementor from making a stupid mistake?

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Antoine Chavasse wrote:
> 
>> For instance, say you need to impliment a GUI, so you have yourself a
>> rectangle struct which consists of four floating point values (the origin
>> and difference between the opposite corner) ...Now you want those four
>> values, but you also have a 2D vector struct.
> 
> Here is a portable alternative to achieve this:
> 
> struct Rectangle
> {
>   private:
>     Vector2D m_Position;
>     Vector2D m_Size;
> 
>   public:
>     Vector2D& position() { return m_Position; }
>     const Vector2D& position() const { return m_Position; }
> 
>     Vector2D& size() { return m_Size; }
>     const Vector2D& size() const { return m_Size; }
> 
>     float& left() { return m_Position.x; }
>     float left() const { return m_Position.x; }
> 
>     float& top() { return m_Position.y; }
>     float top() const { return m_Position.y; }
> 
>     float& width() { return m_Size.x; }
>     float width() const { return m_Size.x; }
> 
>     float& height() { return m_Size.y; }
>     float height() const { return m_Size.y; }
> };
> 
> Then you can access the members like this:
> 
> Rect somerectangle;
> 
> Rect.position().x = 45;
> Rect.left() = 45;
> 
> 

I pointed this out as the obvious portable solution somewhere in the thread.
I just firmly believe this is an unnecessarily back breaking way of going
about it (and physically backbreaking for whoever would have to change all
of the code) 

It would be a blessing were intelligible code somewhat higher up on the
rungs of c++ priorities (being the ever ubiquitous mainstay systems
programming language it has become and will likely remain)

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11337133
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Antoine Chavasse]

> For instance, say you need to impliment a GUI, so you have yourself a
> rectangle struct which consists of four floating point values (the origin
> and difference between the opposite corner) ...Now you want those four
> values, but you also have a 2D vector struct.

Here is a portable alternative to achieve this:

struct Rectangle
{
  private:
    Vector2D m_Position;
    Vector2D m_Size;

  public:
    Vector2D& position() { return m_Position; }
    const Vector2D& position() const { return m_Position; }

    Vector2D& size() { return m_Size; }
    const Vector2D& size() const { return m_Size; }

    float& left() { return m_Position.x; }
    float left() const { return m_Position.x; }

    float& top() { return m_Position.y; }
    float top() const { return m_Position.y; }

    float& width() { return m_Size.x; }
    float width() const { return m_Size.x; }

    float& height() { return m_Size.y; }
    float height() const { return m_Size.y; }
};

Then you can access the members like this:

Rect somerectangle;

Rect.position().x = 45;
Rect.left() = 45;

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

michael.a wrote:
> 
> 
> I guess I will have to sort out why the compiler isn't finding it (any
> advice is welcome -- just for the record, I did a straight install from
> packaged sources with previous gcc installs removed before hand)
> 
> 

Actually, funny story... I was actually looking for vsnprintf, and just
assumed stdarg.h was the culprit because it twasn't there (should've looked
for a stdarg.h including error - summer is a bit warm) ...actually turned
out the Microsoft cruntime libraries declare vsnprintf as _vsnprintf, so I
just assumed it would be so. Looks like I out thunked myself this time
(learned some things though)
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11243667
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Meissner, Michael wrote:
> 
> 
> You probably should root around to find out why it isn't installed.  I
> would
> suspect you did not install the appropriate development packages or
> somehow
> your compilation system is messed up. 
> 

I rooted thoroughly, not wanting to make this post for fear of reprisal for
being offtopic. For one reason or another, it is nearly impossible to find
relevant answers to these sorts of matter via google.



>  Stdarg.h should be installed in the
> private diretory the compiler keeps its own include files (different revs
> of
> GCC have needed different stdarg.h's in the past, so it is compiler
> specific).
> For example on my Fedora 6 system it is in:
> /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stdarg.h
> 

That explains a lot. The best sources I could find seemed to think it should
be installed by libc6-dev type packages. I doo see some instances in such
locations (I should've filtered out the error lines from the find output)

I guess I will have to sort out why the compiler isn't finding it (any
advice is welcome -- just for the record, I did a straight install from
packaged sources with previous gcc installs removed before hand)



-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11243439
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Michael Meissner]

On Thu, Jun 21, 2007 at 03:08:00PM -0700, michael.a wrote:
> 
> 
> 
> michael.a wrote:
> > 
> > Will likely be a good while before I can report whether simply knocking
> > out the errors cause any run-time issues.
> 
> Is there some reason why stdarg.h would not be on my system (amd64 ubuntu)
> 
> I can find it in the various gcc source trees (apparently gcc brings its
> own) ...is it safe to just copy that one? I'm assuming it belongs in
> /usr/include.
> 
> -- 
> View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11242651
> Sent from the gcc - Dev mailing list archive at Nabble.com.
> 

You probably should root around to find out why it isn't installed.  I would
suspect you did not install the appropriate development packages or somehow
your compilation system is messed up.  Stdarg.h should be installed in the
private diretory the compiler keeps its own include files (different revs of
GCC have needed different stdarg.h's in the past, so it is compiler specific).
For example on my Fedora 6 system it is in:
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stdarg.h

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

michael.a wrote:
> 
> Will likely be a good while before I can report whether simply knocking
> out the errors cause any run-time issues.

Is there some reason why stdarg.h would not be on my system (amd64 ubuntu)

I can find it in the various gcc source trees (apparently gcc brings its
own) ...is it safe to just copy that one? I'm assuming it belongs in
/usr/include.

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11242651
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

michael.a wrote:
> 
> I guess in the meantime I'll go ahead and install it and see if I can use
> it or not.
> 

Success! 

Will likely be a good while before I can report whether simply knocking out
the errors cause any run-time issues.

In the meantime, if anyone can clue me in on squaring multilib support with
amd64 debian, I'd appreciate it very much :)

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11226865
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Cat-4 wrote:
> 
> $ ls -lad gcc*
>     4 drwxr-xr-x 3 root root     4096 2007-06-21 12:35 gcc-4.1-4.1.1ds2
>  6956 -rw------- 1 root root  7109677 2006-12-11 06:02
> gcc-4.1_4.1.1ds2-21.diff.gz
>     4 -rw------- 1 root root     2407 2006-12-11 06:02
> gcc-4.1_4.1.1ds2-21.dsc
> 36156 -rw------- 1 root root 36982690 2006-10-21 23:17
> gcc-4.1_4.1.1ds2.orig.tar.gz
> 
> Which gives us:
> 
> gcc-4.1_4.1.1ds2.orig.tar.gz	- the original source
> gcc-4.1_4.1.1ds2-21.dsc		- a description of the package
> gcc-4.1_4.1.1ds2-21.diff.gz	- debians modifications to the original
> 

I get something like this. I assumed that the patches were preapplied, or do
you have to patch the diff file to the orig extracted archive?

I ask, because I'm getting this error again:

/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching
for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching for
-lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching
for -lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for
-lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status

Which I believe disappeared before when using the --disable-multilib option,
but the main reason I'm building this way is so I don't have to use that
flag (my impression is using that flag disables the ability to compile
different architectures/platforms on the local machine -- I assumed one of
the patches would rectify this matter, or is the previously mentioned patch
not used by [some] debian distros?) 

If nothing else, if someone can answer, I would like a confirmation that the
provided packages should be preapplied to the source package.

I guess in the meantime I'll go ahead and install it and see if I can use it
or not. I'd appreciate it if someone can point me to the Debian amd64
multilib patch that was said to exist if it shouldn't be included in the
repository patches.
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11226604
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[CaT]

On Wed, Jun 20, 2007 at 07:31:44PM -0700, michael.a wrote:
> michael.a wrote:
> > I should probably just find that Debian patch and install into the system
> > directories, but I still don't understand if there are any factors outside
> > of gcc necessary for a successful build (could glibc be related to the
> > crt.o files -- and are the crt.o files tied to the system, or do they just
> > link to shared libraries)
> > 
> 
> I think I have maybe the proper debian patches for gcc from here:
> 
> http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-defaults/gcc-defaults_1.32.tar.gz

That's Ubuntu, not debian. Similar, yet different.

> But even if so, I have no idea what to do with it. Lots of files that look
> like preinst postinst prerm postrm... of course the README file provided is
> absolutely zero help, nor is it particularly possible to not get a swamp of

*looks* Looks helpful to me:

                The Debian GNU Compiler Collection Setup
                ========================================

Abstract
--------

Debian uses a default version of GCC for most packages; however, some
packages require another version.  So, Debian allows several versions
of GCC to coexist on the same system, and selects the default version
by means of the gcc-defaults package, which creates symbolic links as
appropriate.

Versions of GCC present in Debian Etch
--------------------------------------
...

The default compiler versions for Debian GNU/Linux on i386 are
(minor version numbers omitted):

        cpp             : cpp-4.1
        gcc             : gcc-4.1
        g++             : g++-4.1
...

> junk responses from google. Debian doesn't appear to me to actually provide
> GCC sources from the repository, but does provide Debian patches.

Sure it does. Helps to get the right package:

$ apt-get source gcc-4.1                                 
...
$ ls -lad gcc*
    4 drwxr-xr-x 3 root root     4096 2007-06-21 12:35 gcc-4.1-4.1.1ds2
 6956 -rw------- 1 root root  7109677 2006-12-11 06:02 gcc-4.1_4.1.1ds2-21.diff.gz
    4 -rw------- 1 root root     2407 2006-12-11 06:02 gcc-4.1_4.1.1ds2-21.dsc
36156 -rw------- 1 root root 36982690 2006-10-21 23:17 gcc-4.1_4.1.1ds2.orig.tar.gz

Which gives us:

gcc-4.1_4.1.1ds2.orig.tar.gz	- the original source
gcc-4.1_4.1.1ds2-21.dsc		- a description of the package
gcc-4.1_4.1.1ds2-21.diff.gz	- debians modifications to the original

> I've never understood why linux has to be so damn opaque about
> documentation... makes for a lot of unnecessary help requests.

Helps to read the right documentation. Start with the stuff on its
package management tools and move on from there.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

michael.a wrote:
> 
> I should probably just find that Debian patch and install into the system
> directories, but I still don't understand if there are any factors outside
> of gcc necessary for a successful build (could glibc be related to the
> crt.o files -- and are the crt.o files tied to the system, or do they just
> link to shared libraries)
> 

I think I have maybe the proper debian patches for gcc from here:

http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-defaults/gcc-defaults_1.32.tar.gz

But even if so, I have no idea what to do with it. Lots of files that look
like preinst postinst prerm postrm... of course the README file provided is
absolutely zero help, nor is it particularly possible to not get a swamp of
junk responses from google. Debian doesn't appear to me to actually provide
GCC sources from the repository, but does provide Debian patches.

I've never understood why linux has to be so damn opaque about
documentation... makes for a lot of unnecessary help requests.

Any advice please? I'd basicly like to be able to rebuild a proper Debian
compliant GCC, preferably without knocking on more than a handful of mailing
lists in the process.

If I'm nagging at this point please let me know... I'd just like be able to
add to the Linux community. If only it wasn't always so trying to figure out
what the hell is going on.

sincerely,

michael
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11225709
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

michael.a wrote:
> 
> 
> So, I really appreciate all of your patience in helping to get me through
> the build process. I guess I'll post something about how the hacking
> effort / reprogramming expiriments work out. In the meantime I hope this
> discussion (and the relevance of a proper extension) still has some legs.
> 
> 

I had to knockout this error too:

"member with constructor not allowed in anonymous aggregate"

GCC is wayyyy too restrictive in these regards.

I've started with building the simplest shared library I have on hand...
there were a few gcc weird behaviors and quirks (you can't 'friend'
typedefs???) ...but everything was eventually ironed out.

Now I'm stuck in the linking phase though...

I setup another thread in gcc-help where I'm having trouble understanding
the logic of the crt.o files, where they come and how they should be used
etc, but no one has payed any mind to it so far:

http://www.nabble.com/building-installing-GCC-and-crtx.o%27s-confusion-tf3949291.html#a11205247

I would appreciate any assistance possible. I'm really banging my head
against the wall at this point.

I should probably just find that Debian patch and install into the system
directories, but I still don't understand if there are any factors outside
of gcc necessary for a successful build (could glibc be related to the crt.o
files -- and are the crt.o files tied to the system, or do they just link to
shared libraries)

sincerely,

michael

PS: please don't just leave me hanging at this point -michael
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11216839
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ross Ridge]

Lawrence Crowl writes:
> On the specific topic of unions, there is a proposal before the
>committee to extend unions in this direction.  Let me caution you
>that this proposal has not been reviewed by a significant fraction
>of the committee, and hence has a small chance of being accepted
>and an even smaller chance of surviving unchanged.

This only supports my position.  If an active comittee member can't
get their proposal reviewed by a significant fraction of the committee,
then why should an outsider even bother?   You're better off posting a
patch to gcc-patches, at least that will have a chance of being seriously
considered.

					Ross Ridge

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

michael.a wrote:
> 
> 
> Since I'm already posting, now I'm seeing:
> 
> /home/users/michael/gcc.obj/gcc/f951: symbol lookup error:
> /home/users/michael/gcc.obj/gcc/f951: undefined symbol:
> __gmp_get_memory_functions
> 
> 

I was able to find this: 

http://www.nabble.com/Bootstrap-failure-in-libjava...-t3132896.html

Which lead me to discover that there was already old GMP libraries in
/usr/lib (I guess I wish the gcc configure script could've been more
explicit, as opposed to saying it couldn't find gmp libraries when instead
it could find mpfr libraries, but lumped the two into the same message)

Then the build apparently ran into some bad code when building the fortran
front end (i think it was in a .f90 file, might've been intrinsics/asm code,
but the output looked like C) ...in any case, after I configured with
--enable-languages=c,c++ only, everything made it through ok.

So, I really appreciate all of your patience in helping to get me through
the build process. I guess I'll post something about how the hacking effort
/ reprogramming expiriments work out. In the meantime I hope this discussion
(and the relevance of a proper extension) still has some legs.

sincerely,

michael

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11199192
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Daniel Jacobowitz-2 wrote:
> 
> On Mon, Jun 18, 2007 at 04:57:46PM -0700, michael.a wrote:
>> Yeah, I know (mailing lists are so particular -- I guess I fail to see
>> the
>> value beyond a noncentralized discussion)
> 
> But since I believe three different people have asked you to move this
> problem to a different mailing list now, could you please do so?  Thanks.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 
> 

I'm sorry, it just occurred to me that gcc-help was another forum in this
Nabble interface (I'm not really sure how everything is related -- but
mailing list subscriptions drive me crazy, so I was reticent to deal with
another)

Just for the record...


michael.a wrote:
> 
> 
> In any case, without multilib it makes it to here:
> 
> make[2]: Leaving directory `/home/users/michael/gcc.obj/gcc'
> echo timestamp > stmp-multilib
> cp doc/gcc.1 doc/g++.1
> cp: cannot stat `doc/gcc.1': No such file or directory
> make[1]: *** [doc/g++.1] Error 1
> make[1]: Leaving directory `/home/users/michael/gcc.obj/gcc'
> make: *** [all-gcc] Error 2
> 
> Not sure exactly what is going on here. The gcc/doc directory is empty.
> I'm assuming everything made it through. There are about a billion targets
> in the Makefile and no explanatory header. Any suggestions for just
> building the essentials? 
> 
> 

This hack http://gcc.gnu.org/ml/gcc-bugs/2005-04/msg03614.html seemed to get
through that bug (so many pitfalls)

Since I'm already posting, now I'm seeing:

/home/users/michael/gcc.obj/gcc/f951: symbol lookup error:
/home/users/michael/gcc.obj/gcc/f951: undefined symbol:
__gmp_get_memory_functions

I installed the latest GMP libraries earlier, so I'm not really sure what to
think, unless the libraries aren't backwards compatible. I will mention it
in gcc-help tomorrow, unless I hear something.

I hope this conversation isn't otherwise dead at this point.

sincerely,

michael
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11187556
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Daniel Jacobowitz]

On Mon, Jun 18, 2007 at 04:57:46PM -0700, michael.a wrote:
> Yeah, I know (mailing lists are so particular -- I guess I fail to see the
> value beyond a noncentralized discussion)

But since I believe three different people have asked you to move this
problem to a different mailing list now, could you please do so?  Thanks.

-- 
Daniel Jacobowitz
CodeSourcery

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Brian Dessent wrote:
> 
> "michael.a" wrote:
> 
>> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
> 
> This belongs on gcc-help not here.
> 
> Debian-based distros use a 32/64 bit /usr/lib configuration that is
> backwards from what the rest of the world uses and requires a patched
> gcc to multilib correctly.  You'll probably need to --disable-multilib
> if you're building FSF gcc.
> 
> Brian
> 
> 

Yeah, I know (mailing lists are so particular -- I guess I fail to see the
value beyond a noncentralized discussion)

In any case, without multilib it makes it to here:

make[2]: Leaving directory `/home/users/michael/gcc.obj/gcc'
echo timestamp > stmp-multilib
cp doc/gcc.1 doc/g++.1
cp: cannot stat `doc/gcc.1': No such file or directory
make[1]: *** [doc/g++.1] Error 1
make[1]: Leaving directory `/home/users/michael/gcc.obj/gcc'
make: *** [all-gcc] Error 2

Not sure exactly what is going on here. The gcc/doc directory is empty. I'm
assuming everything made it through. There are about a billion targets in
the Makefile and no explanatory header. Any suggestions for just building
the essentials? 

I've only really recently taken on serious linux development and haven't
much actual build experience outside the usual routine. I have autotools
under my belt, but I glossed over most of the auxiliary stuff.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11186332
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Brian Dessent]

"michael.a" wrote:

> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

This belongs on gcc-help not here.

Debian-based distros use a 32/64 bit /usr/lib configuration that is
backwards from what the rest of the world uses and requires a patched
gcc to multilib correctly.  You'll probably need to --disable-multilib
if you're building FSF gcc.

Brian

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Eric Christopher-2 wrote:
> 
> 
> 'gcc -v' will give you the information on how the system gcc was  
> configured.
> 
> -eric
> 
> 

Here is the gcc -v output for the binaries installed by the distro:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

I'm attempting to build from the 4.0.0 releases.
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11185796
Sent from the gcc - Dev mailing list archive at Nabble.com.

RE: I'm sorry, but this is unacceptable (union members and ctors)

[Dave Korn]

On 18 June 2007 23:46, michael.a wrote:

> Eric Christopher-2 wrote:
>> 
>> 
>> You might want to make sure you're passing the same configure options
>> that the distro did when building. It might cause some incompatibility
>> somewhere that ld is detecting. From a quick look it seems that ld
>> believes that the libc that you have doesn't match the gcc that you're
>> building. (i.e. the bfd arch is incompatible).
>> 
>> -eric
>> 
>> 
> 
> I'm sure plenty will look down their nose at me for asking in this
> forum(mailing list) ...but I recall a tool for checking libraries and build
> options (libtool libraries only maybe) ...I can't recall how or where, or
> think what to feed google (The architecture I'm building on is amd64 if that
> stirs up any ideas)

  I always need to 

export LD_LIBRARY_PATH=/usr/lib64:/usr/lib

on linux-x86_64 before I can do a build.  (Yes, I should probably set it in my
.bashrc or whatever...)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Eric Christopher-2 wrote:
> 
> 
> You might want to make sure you're passing the same configure options  
> that the distro did when building. It might cause some incompatibility  
> somewhere that ld is detecting. From a quick look it seems that ld  
> believes that the libc that you have doesn't match the gcc that you're  
> building. (i.e. the bfd arch is incompatible).
> 
> -eric
> 
> 

I'm sure plenty will look down their nose at me for asking in this
forum(mailing list) ...but I recall a tool for checking libraries and build
options (libtool libraries only maybe) ...I can't recall how or where, or
think what to feed google (The architecture I'm building on is amd64 if that
stirs up any ideas)

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11185544
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Eric Christopher]

>
> I'm sure plenty will look down their nose at me for asking in this
> forum(mailing list) ...but I recall a tool for checking libraries  
> and build
> options (libtool libraries only maybe) ...I can't recall how or  
> where, or
> think what to feed google (The architecture I'm building on is amd64  
> if that
> stirs up any ideas)


'gcc -v' will give you the information on how the system gcc was  
configured.

-eric

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Eric Christopher]

>
> Thank you, I guess I missed that page somehow.
>
> Only I ran into the same Libc wall again, so I'm temporarily stumped:
>
> /usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when  
> searching
> for -lc
> /usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when  
> searching for
> -lc
> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when  
> searching
> for -lc
> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when  
> searching for
> -lc
> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching  
> for -lc
> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching  
> for -lc
> /usr/bin/ld: cannot find -lc
> collect2: ld returned 1 exit status

You might want to make sure you're passing the same configure options  
that the distro did when building. It might cause some incompatibility  
somewhere that ld is detecting. From a quick look it seems that ld  
believes that the libc that you have doesn't match the gcc that you're  
building. (i.e. the bfd arch is incompatible).

-eric

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Eric Christopher-2 wrote:
> 
> 
> Sounds like you're using ./configure. Are you following the directions  
> at:
> 
> http://gcc.gnu.org/install/configure.html
> 
> -eric
> 
> 

Thank you, I guess I missed that page somehow.

Only I ran into the same Libc wall again, so I'm temporarily stumped:

/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching
for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching for
-lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching
for -lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for
-lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11185246
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Eric Christopher]

On Jun 18, 2007, at 2:36 PM, michael.a wrote:

> This suggestion made some ground. But I just can't get a build to  
> complete.
> The newest checkout / release aren't compatible with my C libraries it
> seems, and I'm not sure its safe dependency wise to just replace the C
> libraries. So I rewound my subversion checkout to the same branch as  
> is in
> my debian distribution repository. That build gave up when it  
> couldn't find
> a directory called config/i386 I think it was. So I downloaded the  
> same
> major release as my distro just now (4.0.0) and this one is trying  
> to access
> the gcc/include directory with "../include" from "build*/liberty"  
> which
> obviously should be "../../include", so it gives up. I just can't win.

Sounds like you're using ./configure. Are you following the directions  
at:

http://gcc.gnu.org/install/configure.html

-eric

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

If all you need is one memeber that has constructors / destructors, and
all other members are PODs that provide an alternate view of the contents,
then I think that would make a logical extension of the transparent union
extension.  A transparent union as passed to functions in the same manner as
its first member.  You could define that a tranparent union is allowed
to have as its first member a class with constructors and/or destructors,
and that these constructors / destructors are then the constructors /
destructors of the union.

Caveat: If the union is larger or more alingned than its first member,
the argument passing semantics don't make sense.  This is documented in
extend.texi:
  Second, the argument is passed to the function using the calling
  conventions of the first member of the transparent union, not the calling
  conventions of the union itself.  All members of the union must have the
  same machine representation; this is necessary for this argument passing
  to work properly.

There is also a syntax example for __attribute__ ((__transparent_union__))
in
extend.texi.  
Inside the compiler, you can check if union is a transparent union using the
TYPE_TRANSPARENT_UNION macro.

If the initial union member can be an anonymous struct, and rather than
expecting further members to be "POD" instead their ctors/dtors are simply
ignored, then that would work for anything I can come up with.



> 
> Try contrib/gcc_update --touch after the checkout.
> 
> 

This suggestion made some ground. But I just can't get a build to complete.
The newest checkout / release aren't compatible with my C libraries it
seems, and I'm not sure its safe dependency wise to just replace the C
libraries. So I rewound my subversion checkout to the same branch as is in
my debian distribution repository. That build gave up when it couldn't find
a directory called config/i386 I think it was. So I downloaded the same
major release as my distro just now (4.0.0) and this one is trying to access
the gcc/include directory with "../include" from "build*/liberty" which
obviously should be "../../include", so it gives up. I just can't win.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11184663
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Andrew Haley]

Robert Dewar writes:
 > Ross Ridge wrote:
 > t formal definition.
 > 
 > > Most of GCC's long list of extensions to C are also implemented as
 > > extensions to C++, so you've already lost this battle in GNU C++.
 > 
 > And many of them are ill-defined (and some would agree ill-considered).
 > Mistakes in the past are not a good reason for mistakes in the future.
 > 
 > > Trying to add new a new feature without an existing implementation only
 > > makes it harder to get both a correct formal definition and something
 > > that people will actually want to use.
 > 
 > I think the best procedure is to discuss new features from a language
 > design point of view, and the committee is the best forum for that,
 > then implement them as *part* of the (typically fairly drawn out)
 > process of adding a new feature.

There's always a "chicken and egg" problem here: language features
that might be good for a standardization proposal need to be tested in
real-world applications before anyone knows that they will be useful.

Of course, some of gcc's C extensions are ill-considered and caused
problems, but one of the reasons we know how ill-considered they are
is that they were implemented and people tried to use them.  gcc has a
role to play as a deployment vehicle for language extensions.

The trouble is that it's very hard to kill an extension once people
are using it...

Andrew.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Doug Gregor]

On 6/16/07, michael.a <wild.eyed.boy.from.freecloud@gmail.com> wrote:
> You are of course free to demonstrate how placement new could circumnavigate
> the need of unions.

Boost.Variant implements discriminated unions using placement new:

  http://www.boost.org/doc/html/variant.html

Of course, you would have to mimic the techniques it is using and/or
change your code to use Boost.Variant. But, since you've relied on an
extension to C++, you'll have to change your code to make it portable
anyway.

  - Doug

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Joern Rennecke]

michael.a:
> A proper C++ style fix would require the introduction of new syntax rather
> than tagging unions or such. The dominant ctors would have to be specified,
> or unions themselves could simply be allowed ctors that override the member
> ctors. Call them constructor overloads or something, no new syntax or
> revolutionary semantics, just a quick and easy fix.

If all you need is one memeber that has constructors / destructors, and
all other members are PODs that provide an alternate view of the contents,
then I think that would make a logical extension of the transparent union
extension.  A transparent union as passed to functions in the same manner as
its first member.  You could define that a tranparent union is allowed
to have as its first member a class with constructors and/or destructors,
and that these constructors / destructors are then the constructors /
destructors of the union.

Caveat: If the union is larger or more alingned than its first member,
the argument passing semantics don't make sense.  This is documented in
extend.texi:
  Second, the argument is passed to the function using the calling
  conventions of the first member of the transparent union, not the calling
  conventions of the union itself.  All members of the union must have the
  same machine representation; this is necessary for this argument passing
  to work properly.

There is also a syntax example for __attribute__ ((__transparent_union__)) in
extend.texi.  
Inside the compiler, you can check if union is a transparent union using the
TYPE_TRANSPARENT_UNION macro.

Joe Buck:
> I wouldn't object if someone implemented a clean extension.  The problem
> with extensions, though, is documenting how all the corner cases work,
> and making sure that they all get tested.  This is somewhat easier when
> you're cloning someone else's extension, because the other implementation
> can be used for comparison.

To avoid having too many corner cases, you can keep the defined functionality
small and well delineated, declare anything beyond this scope as invoking
undefined behaviour (simplest for implementation - just make sure you
don't ICE) or as a constraint violation (i.e. you should make sure that
the compiler produces an error - the benefit is that it prevents people
from accidentially starting to use accidential functionality that is not
covered by the documented extension).

michael.a:
> Sometimes extensions just have to be quick and dirty. Microsoft is a major
> influence. The facilities should be there to match MS whenever within
> reason... as well as should be ever present warnings not to abuse such
> facilities.

If you make a quick and dirty hack, you have so be prepared for it not to
be maintainable for any length of time.

michael.a:
> I went to compile a "tainted" build last night, but I ran into a build error
> apparently related only to subversion checkouts, which might also be
> particular to the target debian distribution / hardware support for some
> esoteric reason according to what can be gleamed from google. So I went to
> just download the release sources, but all of the mirrors were down for some
> reason. 
> 
> The error is related to a bison/flex build event, which for some reason
> can't be completed by autotools or something... I figure it easier to just
> go with the release sources as suggested (the relevant .c files are
> pregenerated in the release trees)

Try contrib/gcc_update --touch after the checkout.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[KJKHyperion]

On 6/17/07, michael.a <wild.eyed.boy.from.freecloud@gmail.com> wrote:
> I appreciate the thought, but there is sort of an imperitive with this
> effort to shy away from Boost/STL/virtual inheritance completely.

You'd be hard-pressed to find any instance of dynamic polymorphism
anywhere in Boost. Most of Boost is based on compile-time template
tricks. For example, you have been pointed to boost::optional<T>;
here's <boost/optional/optional.hpp>, where it's implemented, see if
you can find "virtual" anywhere:

<http://www.boost.org/boost/optional/optional.hpp>

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Tim Prince-4 wrote:
> 
> Then use s release or snapshot tarball from mirrors of 
> ftp://gcc.gnu.org/pub/gcc/, and/or get better software, and use gcc-help 
> as intended.
> 

Yes, I apologize, that link and virtually all of the mirrors were timing out
all last night (well for a couple hours at least) 

And starting from the bottom of the mirrors (US mirrors) ...I tried about 6
before I assumed the situation had not changed.

I was simply interested in traffic patterns... Mailing list etiquette I'm
afraid is not my strongest suit.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11169013
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Tim Prince]

wild.eyed.boy.from.freecloud@gmail.com wrote:

> http://gcc.gnu.org/mirrors.html
> 
> Can someone recommend an alternative means of obtaining GCC source releases?
> 
> I can't find a GCC source package in debian repositories.
> 
> EDIT: I should've said the subversion repository is likely unworkible for my
> setup according to google (I posted this previously)
Then use s release or snapshot tarball from mirrors of 
ftp://gcc.gnu.org/pub/gcc/, and/or get better software, and use gcc-help 
as intended.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

I'm sorry, but can anyone get through to any of these mirrors ever:

http://gcc.gnu.org/mirrors.html

Can someone recommend an alternative means of obtaining GCC source releases?

I can't find a GCC source package in debian repositories.

EDIT: I should've said the subversion repository is likely unworkible for my
setup according to google (I posted this previously)
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11168832
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ismail Dönmez]

On Monday 18 June 2007 04:23:35 michael.a wrote:
> I'm sorry, but can anyone get through to any of these mirrors ever:
>
> http://gcc.gnu.org/mirrors.html

The first mirror there, ftp://gd.tuwien.ac.at/gnu/gcc/ works fine. But next 
time please use gcc-help mailing list for such questions. Thanks.

/ismail

-- 
Perfect is the enemy of good

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

I'm sorry, but can anyone get through to any of these mirrors ever:

http://gcc.gnu.org/mirrors.html

Can someone recommend an alternative means of obtaining GCC source releases?

I can't find a GCC source package in debian repositories.
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11168832
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Aaron W. LaFramboise-3 wrote:
> 
> michael.a wrote:
> 
>> So in closing, I'm interested in any ideas / advice, but compromising the
>> existing codebase is completely out of the question. You have my
>> appreciation in advance naturally...
> 
> I suspect the proper solution here is something from www.boost.org.  You 
> didn't say exactly what you needed, but if its anything related to a 
> common programming pattern, Boost has probably already implemented it in 
> a portable or standard manner.  See 
> <http://www.boost.org/libs/libraries.htm>.
> 
> In particular, see Boost optional, and aligned_storage in Boost
> typetraits.
> 
> Other people have already pointed it out, but I'll say it again: 
> language extensions are almost always the wrong solution for these sorts 
> of problems.
> 
> 

I appreciate the thought, but there is sort of an imperitive with this
effort to shy away from Boost/STL/virtual inheritance completely.
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11165310
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Aaron W. LaFramboise]

michael.a wrote:

> So in closing, I'm interested in any ideas / advice, but compromising the
> existing codebase is completely out of the question. You have my
> appreciation in advance naturally...

I suspect the proper solution here is something from www.boost.org.  You 
didn't say exactly what you needed, but if its anything related to a 
common programming pattern, Boost has probably already implemented it in 
a portable or standard manner.  See 
<http://www.boost.org/libs/libraries.htm>.

In particular, see Boost optional, and aligned_storage in Boost typetraits.

Other people have already pointed it out, but I'll say it again: 
language extensions are almost always the wrong solution for these sorts 
of problems.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Just for the record, this construction was proposed to me from behind the
scenes:

> class Rect
> {
>        Rect()
>        {
>           new (&xlat) Vec2<T>(); // Explicit calls to the ctor
>           new (&size) Vec2<T>();
>        }
>        ~Rect()
>        {
>           xlat.~Vec2<T>();
>           size.~Vec2<T>();
>        }
> public:
>        union
>        {
>                struct{ Vec2_<T> xlat, size; };
>                struct{ T_ x,y,w,h; };
>        };
> };
>

I think this would likely do the job in many cases with only a little extra
trickery, though I wouldn't be at all surprised if somewhere along the way
the compiler/specs might throw a wrench into the works. 

Nevertheless, it is an interesting expiriment I think, which might contain
further advantages. However, I feel strongly that either avenue of approach
should be open, so that a course of action may be freely chosen. 

I also can't help but consider this a fair ways to go simply to work around
what is I feel a temporary specifications anomale sure to be eventually
sorted out of the future of c++ .  

sincerely,

michael

PS: I really don't think is precisely what the proponents of "placement new"
have in mind, but feel free to rally around this proposal if you must
-michael
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11165235
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Martin Jambor wrote:
> 
> On Sat, Jun 16, 2007 at 06:16:03PM -0700, michael.a wrote:
>> 
>> Any advice on compiling gcc? That is the chicken and egg problem. If I
>> install a binary version of GCC, then use it to build and install a
>> custom
>> GCC (which I want to become the system wide GCC) ...then how is this
>> commonly done? --of course I would like the non custom GCC to do any
>> future
>> rebuilds, so that is to say, I don't want the custom GCC installing over
>> the
>> initial "bootstrap" GCC (if this makes any sense at this point:)
> 
> I  believe that  what you  want to  do at  this stage  is use  the GCC
> version that comes with your  distribution to compile and install your
> custom  patched GCC  that you  configure with  some  unique "--prefix"
> directory  (in your  home,  for  example) and  hack  the configure  or
> Makefile files of  the project you want to compile with  it to use the
> compiler in that directory.
> 
> The --disable-bootstrap  configure option may also be  handy until you
> get the compiler right.
> 
> I   think  that   reading   through  http://gcc.gnu.org/install/   and
> especially  http://gcc.gnu.org/install/configure.html may  save  you a
> lot of questions and experiments, it certainly helped to set me up not
> so long time ago.
> 
> HTH
> 
> Martin
> 
> 

I appreciate the advice. I think what I decided should be done, is I should
hack in a command line option that can be used as a conditional, so that way
GCC can be compiled with all of its functionality, so that it can faithfully
recompile itself, and I can just add that option in the make routines.

I went to compile a "tainted" build last night, but I ran into a build error
apparently related only to subversion checkouts, which might also be
particular to the target debian distribution / hardware support for some
esoteric reason according to what can be gleamed from google. So I went to
just download the release sources, but all of the mirrors were down for some
reason. 

The error is related to a bison/flex build event, which for some reason
can't be completed by autotools or something... I figure it easier to just
go with the release sources as suggested (the relevant .c files are
pregenerated in the release trees)
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11165121
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

Ross Ridge wrote:

> Since it's essentially impossible to be impartial about a feature you
> created, both senses of the word apply here.

It's not only possible, but usual in many technical settings. There
is no reason (or excuse) for getting emotionally attached to language
design proposals. In my decades of work on language design committees,
I have often made language proposals, and then the ensuing technical
discussion shows they are a bad idea, and they get dropped, no problem,
and I have seen this happen with many other people.

If you can't operate objectively, you really don't belong being involved
in a language design discussion.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

Ross Ridge wrote:
t formal definition.

> Most of GCC's long list of extensions to C are also implemented as
> extensions to C++, so you've already lost this battle in GNU C++.

And many of them are ill-defined (and some would agree ill-considered).
Mistakes in the past are not a good reason for mistakes in the future.

> Trying to add new a new feature without an existing implementation only
> makes it harder to get both a correct formal definition and something
> that people will actually want to use.

I think the best procedure is to discuss new features from a language
design point of view, and the committee is the best forum for that,
then implement them as *part* of the (typically fairly drawn out)
process of adding a new feature.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ross Ridge]

Ross Ridge wrote:
>I completely disagree.  Standards should primarily standardize existing
>practice, not inventing new features.  New features should be created
>by people who actually want and will use the features, not by some
>disinterested committee.

Robert Dewar write:
>First of all, I think you mean uninterested and not disinterested,
>indeed the ideal is that all committee members *should* be disinterested,
>though this is not always the case.

Since it's essentially impossible to be impartial about a feature you
created, both senses of the word apply here.

>The history for C here does not apply to C++ in my opinion. Adding new
>features to a language like C++ is at this stage highly non-trivial in
>terms of getting a correct formal definition.

Most of GCC's long list of extensions to C are also implemented as
extensions to C++, so you've already lost this battle in GNU C++.
Trying to add new a new feature without an existing implementation only
makes it harder to get both a correct formal definition and something
that people will actually want to use.

					Ross Ridge

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Martin Jambor]

On Sat, Jun 16, 2007 at 06:16:03PM -0700, michael.a wrote:
> 
> Any advice on compiling gcc? That is the chicken and egg problem. If I
> install a binary version of GCC, then use it to build and install a custom
> GCC (which I want to become the system wide GCC) ...then how is this
> commonly done? --of course I would like the non custom GCC to do any future
> rebuilds, so that is to say, I don't want the custom GCC installing over the
> initial "bootstrap" GCC (if this makes any sense at this point:)

I  believe that  what you  want to  do at  this stage  is use  the GCC
version that comes with your  distribution to compile and install your
custom  patched GCC  that you  configure with  some  unique "--prefix"
directory  (in your  home,  for  example) and  hack  the configure  or
Makefile files of  the project you want to compile with  it to use the
compiler in that directory.

The --disable-bootstrap  configure option may also be  handy until you
get the compiler right.

I   think  that   reading   through  http://gcc.gnu.org/install/   and
especially  http://gcc.gnu.org/install/configure.html may  save  you a
lot of questions and experiments, it certainly helped to set me up not
so long time ago.

HTH

Martin

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Joe Buck wrote:
> 
> On Sat, Jun 16, 2007 at 12:08:40PM -0700, michael.a wrote:
>> As for "placement new", from what I can find, it is unsafe to use with
>> any
>> memory that isn't part of the heap.
> 
> You do have to concern yourself with alignment.  But often an allocator
> that hands out memory that is filled in by placement new doesn't use the
> heap at all.  Using a union for the storage that's filled by the placement
> new call is one way to assure correct alignment.
> 
>> As for the discussion of unions, placement new is way too much overhead.
> 
> Placement new has *no* overhead, it pretty much invokes the constructor
> directly, and if the constructor is inline, there isn't even a function
> call.  I'm sorry that you are not open to learning about it, and that you
> seem to believe many things about it that are not true.  It does require
> you to worry about lower-level details, like assuring correct alignment.
> 
>> Sometimes extensions just have to be quick and dirty. Microsoft is a
>> major
>> influence. The facilities should be there to match MS whenever within
>> reason... as well as should be ever present warnings not to abuse such
>> facilities.
> 
> Not if you want the gcc developers to accept it.  Accepting the extension
> is a commitment to maintain it pretty much indefinitely.  Also, if the gcc
> extension doesn't do everything the Microsoft extension does, your code
> might not work even if it compiles: it might leak memory or crash if
> the constructor/destructor behavior differs.
> 
> But I'm puzzled that you'd rather try to hack the compiler than
> investigate a way to make your program portable C++.  Or do you think you
> can talk others into hacking the compiler for you?  I doubt that it will
> work.
> 

I've thought about every conceivable way of a more portable solution
obviously. I will do whatever is required to get my code to compile for the
time being. If I am able to inspire someone who is qualified to draw out and
implement some proper extension specs, then all the merrier (and the world
would be a better place)

I wouldn't expect such an extension to necessarily be fully compatible
across compilers, but simple preprocessor management should suffice to make
up the differences. The rest would be up to programmers, which should be
aware of the any cons the extension would have to offer.

You are of course free to demonstrate how placement new could circumnavigate
the need of unions. The most obvious solution to such a problem is to simply
make all of the union members accessible by simple functional access. That
is like rect.origin().x, rather than rect.origin.x for example. Of course
this means going through the entire code base and changing every such
instance of origin, and call me nitpicky but its not as clear and is
generally uglier with the parentheses. 

I can think of ways to use placement new which would be about as convenient
as not in lexical terms, but it would still require minor altercations
throughout the codebase at this point.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11159694
Sent from the gcc - Dev mailing list archive at Nabble.com.

RE: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Any advice on compiling gcc? That is the chicken and egg problem. If I
install a binary version of GCC, then use it to build and install a custom
GCC (which I want to become the system wide GCC) ...then how is this
commonly done? --of course I would like the non custom GCC to do any future
rebuilds, so that is to say, I don't want the custom GCC installing over the
initial "bootstrap" GCC (if this makes any sense at this point:)
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11159654
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Joe Buck]

On Sat, Jun 16, 2007 at 12:08:40PM -0700, michael.a wrote:
> As for "placement new", from what I can find, it is unsafe to use with any
> memory that isn't part of the heap.

You do have to concern yourself with alignment.  But often an allocator
that hands out memory that is filled in by placement new doesn't use the
heap at all.  Using a union for the storage that's filled by the placement
new call is one way to assure correct alignment.

> As for the discussion of unions, placement new is way too much overhead.

Placement new has *no* overhead, it pretty much invokes the constructor
directly, and if the constructor is inline, there isn't even a function
call.  I'm sorry that you are not open to learning about it, and that you
seem to believe many things about it that are not true.  It does require
you to worry about lower-level details, like assuring correct alignment.

> Sometimes extensions just have to be quick and dirty. Microsoft is a major
> influence. The facilities should be there to match MS whenever within
> reason... as well as should be ever present warnings not to abuse such
> facilities.

Not if you want the gcc developers to accept it.  Accepting the extension
is a commitment to maintain it pretty much indefinitely.  Also, if the gcc
extension doesn't do everything the Microsoft extension does, your code
might not work even if it compiles: it might leak memory or crash if
the constructor/destructor behavior differs.

But I'm puzzled that you'd rather try to hack the compiler than
investigate a way to make your program portable C++.  Or do you think you
can talk others into hacking the compiler for you?  I doubt that it will
work.

RE: I'm sorry, but this is unacceptable (union members and ctors)

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On 16 June 2007 19:54, michael.a wrote:

> used to aide the compiler for further robustness. In the meantime, I would
> very much appreciate it if you could share any specific directions towards
> minimally hacking the g++ frontend to let the code through. The way I tend
> to use these unions, is always an anonymous union inside a structure. Its
> harmless, and dummy constructors can be used and optimized out later. Its
> just the error that brings everything to a halt.

  Well, you could try just removing the errors like so (attached, untested).
No guarantees that this will work properly and won't just cause errors,
miscompilations or crashes further down the line.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

[-- Attachment #2: suppress-errors-patch.diff --]
[-- Type: application/octet-stream, Size: 1572 bytes --]

Index: gcc/cp/class.c
===================================================================
--- gcc/cp/class.c	(revision 125757)
+++ gcc/cp/class.c	(working copy)
@@ -2748,26 +2748,12 @@
 	 make it through without complaint.  */
       abstract_virtuals_error (field, type);
 
-      if (TREE_CODE (t) == UNION_TYPE)
-	{
-	  if (TYPE_NEEDS_CONSTRUCTING (type))
-	    error ("member %q+#D with constructor not allowed in union",
-		   field);
-	  if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type))
-	    error ("member %q+#D with destructor not allowed in union", field);
-	  if (TYPE_HAS_COMPLEX_ASSIGN_REF (type))
-	    error ("member %q+#D with copy assignment operator not allowed in union",
-		   field);
-	}
-      else
-	{
-	  TYPE_NEEDS_CONSTRUCTING (t) |= TYPE_NEEDS_CONSTRUCTING (type);
-	  TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t)
-	    |= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type);
-	  TYPE_HAS_COMPLEX_ASSIGN_REF (t) |= TYPE_HAS_COMPLEX_ASSIGN_REF (type);
-	  TYPE_HAS_COMPLEX_INIT_REF (t) |= TYPE_HAS_COMPLEX_INIT_REF (type);
-	  TYPE_HAS_COMPLEX_DFLT (t) |= TYPE_HAS_COMPLEX_DFLT (type);
-	}
+      TYPE_NEEDS_CONSTRUCTING (t) |= TYPE_NEEDS_CONSTRUCTING (type);
+      TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t)
+	|= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type);
+      TYPE_HAS_COMPLEX_ASSIGN_REF (t) |= TYPE_HAS_COMPLEX_ASSIGN_REF (type);
+      TYPE_HAS_COMPLEX_INIT_REF (t) |= TYPE_HAS_COMPLEX_INIT_REF (type);
+      TYPE_HAS_COMPLEX_DFLT (t) |= TYPE_HAS_COMPLEX_DFLT (type);
 
       if (!TYPE_HAS_CONST_INIT_REF (type))
 	*cant_have_const_ctor = 1;

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

David Fang wrote:
> 
> 
> ... And when the said constructor is trivial (e.g. for POD), then you pay
> nothing, zilch, nada.  (same with placement delete)  In C++, some things
> you write (od don't write) are merely abstractions for what should happen,
> which can represent 'nothing'.  Only if you ask for pessimized code can
> you possibly pay function call overheads on de-inlined empty functions.
> 
> Fang
> 

Again, my apologies. Being a largely dynamic system, this project itself
isn't particularly effected by peak performance overheads... I was referring
instead to code maintainability, which is a much more significant priority
given the scope of my particular situation. Of course, I would like to
remind everyone, that I'm arguing for many more people than the needs of
myself or my compatriots. There are no shortage of requests for such a
feature on google met with cold attitudes and dismissive responses. When in
reality, this is a very valid feature for consideration. Perhaps the only
difference is, I don't have the option of retreating and regrouping at this
point. So one way or another GCC will have to bend for me, whether it can be
done legitimately, and everyone can benefit, or I have to hack it
sufficiently myself.



-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11157362
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Andrew Pinski-2 wrote:
> 
> Huh?????  It can be used with stack variables, we have tests in the
> testsuite where we use it with such.

Thats not what google told me, I believe from every source I took a look at.



> 
>> As for the discussion of unions, placement new is way too much overhead.
> 
> placement new has no overhead, that is by design.  I literally mean
> placement new does nothing except for changing the dynamic type and
> calling the constructor.  Where is the overhead there?  I see unions
> having more overhead than placement new as unions are not as well
> optimized.
> 
> -- Pinski
> 

I'm sorry, but "placement new" does really one thing nice. Its not terribly
suited to this situation. Hence why it would come with a high overhead as
far as code intelligibility(scalability) is concerned, and would likely
prevent inline optimizations if used in the only way I can think of as far
as the situation at hand is concerned, as I described in another post.

Bottom line, placement new is cool, and I'm glad I am more aware of it now.
But its not going to remedy this matter, or even a subset of its
ramifications. Bottom line is whatever the solution, it would have to not
mean rewriting any code outside the class definitions themselves... and
placement new isn't going to get you there, even if it is safe to use
outside the heap on all platforms/implimentations.

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11157334
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[David Fang]

> On 6/16/07, michael.a <wild.eyed.boy.from.freecloud@gmail.com> wrote:
> >
> > As for "placement new", from what I can find, it is unsafe to use with any
> > memory that isn't part of the heap.
> Huh?????  It can be used with stack variables, we have tests in the
> testsuite where we use it with such.
>
> > As for the discussion of unions, placement new is way too much overhead.
>
> placement new has no overhead, that is by design.  I literally mean
> placement new does nothing except for changing the dynamic type and
> calling the constructor.  Where is the overhead there?  I see unions
> having more overhead than placement new as unions are not as well
> optimized.

... And when the said constructor is trivial (e.g. for POD), then you pay
nothing, zilch, nada.  (same with placement delete)  In C++, some things
you write (od don't write) are merely abstractions for what should happen,
which can represent 'nothing'.  Only if you ask for pessimized code can
you possibly pay function call overheads on de-inlined empty functions.

Fang

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Andrew Pinski]

On 6/16/07, michael.a <wild.eyed.boy.from.freecloud@gmail.com> wrote:
>
> As for "placement new", from what I can find, it is unsafe to use with any
> memory that isn't part of the heap.
Huh?????  It can be used with stack variables, we have tests in the
testsuite where we use it with such.

> As for the discussion of unions, placement new is way too much overhead.

placement new has no overhead, that is by design.  I literally mean
placement new does nothing except for changing the dynamic type and
calling the constructor.  Where is the overhead there?  I see unions
having more overhead than placement new as unions are not as well
optimized.

-- Pinski

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Joe Buck wrote:
> 
> On Fri, Jun 15, 2007 at 08:00:24PM -0700, michael.a wrote:
>> I've actually never seen "placement new" before I think. Its a useful way
>> to
>> "reconstruct" heaped memory, but not useful in anyway in the situation I
>> described (which is really broader than any single fix)
> 
> I disagree; placement new is much more flexible than that, and can be used
> to construct an object inside a static, automatic, or global object.  It
> can be used to implement generalized unions, or as a way to control
> placement of memory-mapped objects.  Furthermore, you've almost certainly
> used it without knowing it, since the STL uses it a lot.  But if you
> really
> want your existing code to work, you'd need to extend the compiler.  If
> your code is modular, and doesn't expose all over the place the particular
> use of unions you described, it wouldn't be hard to switch to a
> placement-new implementation.  Otherwise it could be a hopeless task.
> 
> 

No, the infringing code is left out of the modular interfaces, but necessary
for everything to work. If any portability issues were in the interfaces,
they can be removed harmlessly.

As for "placement new", from what I can find, it is unsafe to use with any
memory that isn't part of the heap. I believe I've seen it before, in
documentation pertaining to overloading the "new" operator. But if I'd
realized it can be used to reinitialize heap objects, I would've seen the
utility of it immediately. Incidentally, I don't believe it is useful (or at
least required) for much else. I can definitely use it in my custom heap
code, whereas before special initialization functions were required to be
defined.

As for the discussion of unions, placement new is way too much overhead. I'm
mostly interested in automatic objects, like vectors for math routines etc.
I could hack it maybe I think, with a placement new style factory in place
of ctors, but it would make inline optimizations virtually impossible and
the only way I could do it would be with a round robin style heap array
which you would always risk overwriting should the demand for autos exceed
the buffer capacity.



> 
> I wouldn't object if someone implemented a clean extension.  The problem
> with extensions, though, is documenting how all the corner cases work,
> and making sure that they all get tested.  This is somewhat easier when
> you're cloning someone else's extension, because the other implementation
> can be used for comparison.
> 
> 

Sometimes extensions just have to be quick and dirty. Microsoft is a major
influence. The facilities should be there to match MS whenever within
reason... as well as should be ever present warnings not to abuse such
facilities.
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11157188
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Brooks Moses-3 wrote:
> 
> michael.a wrote:
>> It would be interesting for someone to try to make a practical argument
>> that
>> is anything but a nest of technicalities, as to why ctors and unions
>> shouldn't be mixable.
> 
> The Fortran language specification allows essentially this, although the 
> terms are initializers and equivalences rather than ctors and unions. 
> Just this week, I reviewed the patch to add this functionality to the 
> GCC Fortran front end, and I wrote a bit of the infrastructure it uses, 
> so I can speak somewhat to the problems of implementing it.
> 
> 

My apologies for saving a response to this post until last... obviously it
is the most substantial contribution to this thread so far.


Brooks Moses-3 wrote:
> 
> Now, as for "shouldn't"?  I can't speak to that, given that the Fortran 
> committee thought it a valuable feature to include, and that we did 
> implement it and it works.  Well, mostly works, at least -- I wouldn't 
> at all swear that we've got all the bugs out of it yet.  But it was a 
> pain, and it (along with one other feature that required simulating the 
> writing of things to target memory) required an amount of effort to 
> implement that was dramatically out of proportion to the importance of 
> the feature.
> - Brooks
> 

I wish I had more to say, but you pretty much covered all of the unturned
bases. It would be very progressive I think if you could make a case for a
similar limited extension of g++. Perhaps __attribute__ type syntax could be
used to aide the compiler for further robustness. In the meantime, I would
very much appreciate it if you could share any specific directions towards
minimally hacking the g++ frontend to let the code through. The way I tend
to use these unions, is always an anonymous union inside a structure. Its
harmless, and dummy constructors can be used and optimized out later. Its
just the error that brings everything to a halt.

I will send you an email or private message if possible before the day is
over.

The system(s) I'm working with are actually extremely interesting. They are
in essence an entirely new "operating system style" environment. Only it
functions like java, in the respect that virtual kernels are implimented for
all platforms, so far that the operating environment itself runs atop your
windows/linuxes/etc, but completely supercedes the presentation while
attempting to build an abstract bridge providing a common shared application
environment utilizing the features of the respective underlying OSes (your
vendor drivers etc) whenever possible, and hopefully emulating when not. The
philosophy of the system is extremely progressive, at the lowest level for
the most part like the best of both the linux and windows experiences...
with completely revolutionary concepts in the command shell, designed to
favor AI, and a completely revolutionary GUI and a universal dynamic program
interpreter able to reconfigure  its own syntax and semantics on the fly,
essentially mimicing and intermingling all of your strict programming
languages etc. The initial drive is aimed at independent video game
development, their communites, and their enthusiasts / player bases... and
from there migrating towards a full featured integrated development
environment... and eventually on to more domestic and business oriented
applications. Off course we would prefer Linux as a primary platform, and I
would personally very much like to deliver video games to Linux. If only
because, it is so difficult to imagine Linux ever being the mainstream os of
choice without its share of compatible video games. 

In any case its a major development, and I would really appreciate some
special attention towards getting GCC to get the job done for linux wherever
I can find it. Anyone who is interested in helping out towards these ends, I
would be happy to contact, and let them in on what we are doing. A public
release isn't possible without a Linux build. So we gotta get this done, and
there is no room for the core codebase to budge.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11157032
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Joe Buck]

On Fri, Jun 15, 2007 at 08:00:24PM -0700, michael.a wrote:
> I've actually never seen "placement new" before I think. Its a useful way to
> "reconstruct" heaped memory, but not useful in anyway in the situation I
> described (which is really broader than any single fix)

I disagree; placement new is much more flexible than that, and can be used
to construct an object inside a static, automatic, or global object.  It
can be used to implement generalized unions, or as a way to control
placement of memory-mapped objects.  Furthermore, you've almost certainly
used it without knowing it, since the STL uses it a lot.  But if you really
want your existing code to work, you'd need to extend the compiler.  If
your code is modular, and doesn't expose all over the place the particular
use of unions you described, it wouldn't be hard to switch to a
placement-new implementation.  Otherwise it could be a hopeless task.

> PS: I did receive another response by mail, but I'm not seeing it in the
> thread. Perhaps it was a private response only somehow. In any case it
> suggested that nonstandard extensions to GCC cut against its philosophy. I
> do believe GCC supports the standard "for loop scope" extension (which seems
> so practical, that many compilers default to it) ...likewise, permitting
> ctored structs in a union seems equally, if not more so practical, and the
> omission just as absurd. It would seem like a natural nonstandard inclusion,
> at least until the c++ specs are amended to include it. 

I wouldn't object if someone implemented a clean extension.  The problem
with extensions, though, is documenting how all the corner cases work,
and making sure that they all get tested.  This is somewhat easier when
you're cloning someone else's extension, because the other implementation
can be used for comparison.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

David Fang wrote:
> 
> <$.02>
> 	It's not highly techinical to see the fundamental difficulty with
> mixing ctor/dtors and unions.  At the core of C++ is the association with
> constructors as initialization actions at the beginning of an object's
> lifetime, and likewise destructors associate with actions take at the end
> of lifetime.  C++ defines the actions precisely: PODs (including pointers)
> need no action, objects of classes invoke their (in-charge) destructors.
> From this, it is evident that a union of PODs poses no problems.  As soon
> as you have destructors, the language gives no automatic means of deciding
> which destructor (if applicable) to call.  How would you make the compiler
> Do The Right Thing (TM)?  Until unions are automatically tagged/embedded
> with type information, the language simply doesn't support proper
> destruction of non-trivial unions.  You can find other dialects of C or
> C++ that do support this.  Any dialect that adds these semantics cannot
> really be a trivial extension of C++.
> 	However, as others have hinted, it is not impossible to emulate
> tagged unions in C++, if you are willing to pay the bookkeeping overhead.
> (Surely you must know *somewhere* in your program what's what...)
> If you wrap your union in a class with a type enum, you can create a
> lookup-table/switch-case of member type destructors to invoke in the
> destructor of the wrapped class.  Placement delete (counterpart of
> placement new) is used for in-place destruction.  Some reinterpret_cast
> may come in handy if you're really into abusing the type system.
> </$.02>

A proper C++ style fix would require the introduction of new syntax rather
than tagging unions or such. The dominant ctors would have to be specified,
or unions themselves could simply be allowed ctors that override the member
ctors. Call them constructor overloads or something, no new syntax or
revolutionary semantics, just a quick and easy fix.

In the meantime, I don't see why a quick and easy workaround shouldn't be in
order, especially in light of all the microsoft originated code which should
be able to compile on linux where the issue is more than what the
preprocessor can handle, and its not some farout platform specific
extension.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11155996
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

michael.a wrote:

> Extensions are harmless as long as authors clearly understand the pitfalls
> they offer and mandatory compile options are required to enact them. The
> line should be drawn somewhere naturally, granted the philosophy of a
> particular implementation. GCC being the premier compiler for Linux however
> definitely should not have such a staunch attitude regarding extensions. The
> EGCS episode should be testament enough in that light.

I disagree, properly defining the semantics in formal standards terms
for extensions is a very difficult task, and all too often, extensions
are added in a haphazard manner without a proper complete semantic
definition. I would say that a minimum requirement is actual language
modifying the standard with proper review.

The burden of adding non-conforming extensions to a language should
be extremely high. The fact that it is done too casually is what causes
this sort of portability problem in the first place. Extensions are
always harmful (they increase complexity), so you have to be VERY
sure that the gain outweighs this inherent harm. I don't see that
the burden is met in this particular case.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Robert Dewar wrote:
> 
> 
> I think there is a lot of merit in
> 
> a) C++ programmers writing in C++ and not idiosyncratic dialects
> b) C++ compilers implementing C++ and not idiosyncratic dialects
> 
> Certainly if you are interested in porting code, as seems to be the
> case here, following a) is a good idea.
> 
> []
> 
> There are hundreds of possible extensions to any language that make
> technical sense, but that still is not a reason for violating b) above.
> The only time that it is reasonable to extend is when there are clear
> signals from the standards committee that it is likely that a feature
> will be added, in which case there may be an argument for adding the
> feature "prematurely".
> 
> 

Extensions are harmless as long as authors clearly understand the pitfalls
they offer and mandatory compile options are required to enact them. The
line should be drawn somewhere naturally, granted the philosophy of a
particular implementation. GCC being the premier compiler for Linux however
definitely should not have such a staunch attitude regarding extensions. The
EGCS episode should be testament enough in that light.

The extension I have proposed here would fall along the lines of the "for
loop scope" extension, which I would regard as a class A extension, which
GCC should definitely accommodate in some simple and definable fashion.
There are many cases where every member in a union with a ctor could be
initialized, and deinitialized, there is therefore no reason why a
programmer should not be permitted to define such a union. Of course there
are many cases where this would cause undesirable behavior, but such
behavior does not have to be unexpected as well. If it is just defined what
will happen, then it is up to the programmer to know the definition after
enabling the extension flag at compile time. Many malformed unions would be
possible, but that would be up to the programmer to avoid.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11155951
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

michael.a wrote:

> My general opinion is it serves no one to be regressive about extensions.

I think there is a lot of merit in

a) C++ programmers writing in C++ and not idiosyncratic dialects
b) C++ compilers implementing C++ and not idiosyncratic dialects

Certainly if you are interested in porting code, as seems to be the
case here, following a) is a good idea.

> It would be interesting for someone to try to make a practical argument that
> is anything but a nest of technicalities, as to why ctors and unions
> shouldn't be mixable.

There are hundreds of possible extensions to any language that make
technical sense, but that still is not a reason for violating b) above.
The only time that it is reasonable to extend is when there are clear
signals from the standards committee that it is likely that a feature
will be added, in which case there may be an argument for adding the
feature "prematurely".

Re: I'm sorry, but this is unacceptable (union members and ctors)

[David Fang]

> My general opinion is it serves no one to be regressive about extensions.
> You can always advise against using them, and somewhere down the road, the
> specs can always decide an extension is worth supporting more conservatively
> or adding to a future spec altogether.
>
> It would be interesting for someone to try to make a practical argument that
> is anything but a nest of technicalities, as to why ctors and unions
> shouldn't be mixable.

Hi,

<$.02>
	It's not highly techinical to see the fundamental difficulty with
mixing ctor/dtors and unions.  At the core of C++ is the association with
constructors as initialization actions at the beginning of an object's
lifetime, and likewise destructors associate with actions take at the end
of lifetime.  C++ defines the actions precisely: PODs (including pointers)
need no action, objects of classes invoke their (in-charge) destructors.
From this, it is evident that a union of PODs poses no problems.  As soon
as you have destructors, the language gives no automatic means of deciding
which destructor (if applicable) to call.  How would you make the compiler
Do The Right Thing (TM)?  Until unions are automatically tagged/embedded
with type information, the language simply doesn't support proper
destruction of non-trivial unions.  You can find other dialects of C or
C++ that do support this.  Any dialect that adds these semantics cannot
really be a trivial extension of C++.
	However, as others have hinted, it is not impossible to emulate
tagged unions in C++, if you are willing to pay the bookkeeping overhead.
(Surely you must know *somewhere* in your program what's what...)
If you wrap your union in a class with a type enum, you can create a
lookup-table/switch-case of member type destructors to invoke in the
destructor of the wrapped class.  Placement delete (counterpart of
placement new) is used for in-place destruction.  Some reinterpret_cast
may come in handy if you're really into abusing the type system.
</$.02>

> In the meantime, I've always intended to hack the bugger (in the always
> bandied about GNU tradition) if I must. It bothers me though to think that
> no one has charted this territory before.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
	-- (2400 baud? Netscape 3.0?? lynx??? No problem!)

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Brooks Moses]

michael.a wrote:
> It would be interesting for someone to try to make a practical argument that
> is anything but a nest of technicalities, as to why ctors and unions
> shouldn't be mixable.

The Fortran language specification allows essentially this, although the 
terms are initializers and equivalences rather than ctors and unions. 
Just this week, I reviewed the patch to add this functionality to the 
GCC Fortran front end, and I wrote a bit of the infrastructure it uses, 
so I can speak somewhat to the problems of implementing it.

(This was PR29786; you can see how long it took before it was fixed, 
even though it was a regression against the old Fortran front end, and 
was also for quite a while only one of two elements of the Fortran 
standard that we hadn't implemented yet.)

In Fortran, the rule is that any element in an equivalence (i.e., union) 
can be initialized, so long as no two initializers attempt to initialize 
the same piece of memory to different values.

The implementation for this creates an unsigned-char buffer array 
representing target memory, and goes through every initializer (i.e., 
ctor) in the equivalence, converting their values into their 
target-memory representations, checking to see what bits of memory they 
touch and whether those have already been initialized to something 
different, and then writing them into the buffer array.  Then, an 
entirely new initializer is created from that buffer array.

That all had to be built on a fair pile of front-end code to convert 
values into their target-memory representations, and then rather more 
code that was essentially a special-purpose initializer constructor to 
deal with the buffer array.

A lot of the trickiness is in exactly how you specify what's allowed. 
The Fortran rule requires explicitly simulating the target memory 
storage and checking byte-value versions of the initializers against 
each other, which is a rather messy thing to be doing in the front end, 
but it's at least simple to specify.

An alternate version would be to specify that overlapping ctors are not 
allowed even if they do result in the same byte-values.  Aside from 
being a somewhat arbitrary restriction, this doesn't simplify things 
very much, since the front end still needs to look pretty deeply into 
the target memory representation to see if things overlap.

The version we used to have in the Fortran front end was simply to only 
allow one item in each equivalence to have an initializer.  That seemed 
to work without doing anything particular to the initializers, but I'm 
not sure whether things are tracked in the other front ends in ways that 
would make enforcing such a rule easy -- and, very likely, it wouldn't 
work for the example you describe (with a four-number rectangle being 
unioned with two two-point vectors) because you have two vectors in the 
union and they both have initializers.  It's also a rather arbitrary 
rule that's not the sort of thing one would really want in a language 
standard.

Now, as for "shouldn't"?  I can't speak to that, given that the Fortran 
committee thought it a valuable feature to include, and that we did 
implement it and it works.  Well, mostly works, at least -- I wouldn't 
at all swear that we've got all the bugs out of it yet.  But it was a 
pain, and it (along with one other feature that required simulating the 
writing of things to target memory) required an amount of effort to 
implement that was dramatically out of proportion to the importance of 
the feature.

- Brooks

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Andrew Pinski-2 wrote:
> 
> Actually that was not really really an extension before the standard
> come out.  The rules changed with the standardization.  Really most of
> GCC extensions to the C++ langauge that exist now (except for a few
> new ones dealing with the C++0x standard) are all legacy extensions
> before there was a standard.
> 
> Really it sounds like MS added this extension to their C++ compiler
> before there was a standard.  I really think you should learn more
> about this extension and give a fully documented specifications on how
> it works.  Right now that is really the current problem with the
> extensions in GCC, is that they are not fully documented on how they
> work so people get confused when the behavior changes slightly.
> 

Are you referring now to the "for loop scope" extension, just to be clear?

My general opinion is it serves no one to be regressive about extensions.
You can always advise against using them, and somewhere down the road, the
specs can always decide an extension is worth supporting more conservatively
or adding to a future spec altogether.

It would be interesting for someone to try to make a practical argument that
is anything but a nest of technicalities, as to why ctors and unions
shouldn't be mixable.

In the meantime, I've always intended to hack the bugger (in the always
bandied about GNU tradition) if I must. It bothers me though to think that
no one has charted this territory before.

-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11150916
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Andrew Pinski]

On 6/15/07, michael.a <wild.eyed.boy.from.freecloud@gmail.com> wrote:
> I  do believe GCC supports the standard "for loop scope" extension

Actually that was not really really an extension before the standard
come out.  The rules changed with the standardization.  Really most of
GCC extensions to the C++ langauge that exist now (except for a few
new ones dealing with the C++0x standard) are all legacy extensions
before there was a standard.

Really it sounds like MS added this extension to their C++ compiler
before there was a standard.  I really think you should learn more
about this extension and give a fully documented specifications on how
it works.  Right now that is really the current problem with the
extensions in GCC, is that they are not fully documented on how they
work so people get confused when the behavior changes slightly.

-- Pinski

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Portability is not a huge issue for these builds actually as the plan is to
distribute binaries for the time being, with open source modules, or module
plugins rather, as the system itself is a suite of modules. Also only
operating system with nestable and mutually dependent shared library support
can be accommodated. 

I've actually never seen "placement new" before I think. Its a useful way to
"reconstruct" heaped memory, but not useful in anyway in the situation I
described (which is really broader than any single fix)

PS: I did receive another response by mail, but I'm not seeing it in the
thread. Perhaps it was a private response only somehow. In any case it
suggested that nonstandard extensions to GCC cut against its philosophy. I
do believe GCC supports the standard "for loop scope" extension (which seems
so practical, that many compilers default to it) ...likewise, permitting
ctored structs in a union seems equally, if not more so practical, and the
omission just as absurd. It would seem like a natural nonstandard inclusion,
at least until the c++ specs are amended to include it. 

In the meantime I'm perfectly prepared to hack away at GCC. If anyone has
suggestions, I would appreciate it. GCC should strive to support extensions
within reasonable limits such as this. Not doing so makes porting code more
difficult, if not impossible, and that is just bad for the community at
large. This seems like a simple enough artifact to remedy, at least to
sufficient extent in some fashion. I'm just hoping someone with GCC dev
experience would weigh in on the matter.
-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11150629
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Joe Buck]

On Fri, Jun 15, 2007 at 04:25:52PM -0700, michael.a wrote:
> I'm afraid I have a fairly major project which requires a Linux port. The
> problem is, development has been put off for a while because GCC lacks any
> means or work around which permits nesting ctors inside a union. 

Rather, you're relying on a nonportable compiler extension.  No matter,
you have a problem to fix.  I guess there's some reason why you can't
use base classes and derived classes to store your data variants; perhaps
it's because you want to put them into an array?

One possible workaround is to use placement new.  As I understand your
motivation, you want to be able to construct one of several types of
objects in the same fixed-size space that is large enough to hold any of
them.  The union is replaced by a class whose data member is a char array
of sufficient size, and you can then construct sub-objects of whatever
type you want in the char array with placement new.

I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Salutations everyone,

I'm afraid I have a fairly major project which requires a Linux port. The
problem is, development has been put off for a while because GCC lacks any
means or work around which permits nesting ctors inside a union. 

The effort is mature enough that it needs a public release, but it can't be
released without a Linux distribution... because it doesn't need to look
like a total Microsoft tool. Linux has always been the ideal platform, but
the nature of the project is rather untailored for Linux development. 

Bottom line is, Windows(msvc) has a work around which alleviates this issue,
though I'm not entirely impressed with it. Linux(gcc) however does not. 

If it isn't clear from the subject, the issue is the C++ specs, specifically
where it says union members can't have ctors. Windows lets you wrap a ctored
member inside an anonymous struct, without a ctor (though the ctor still
appears to be called -- apparently Windows allows this as a sort of half ass
concession... precisely because this spec is sooo regressive) 

It makes no sense to arbitrarily exclude structs with ctors from unions. And
it makes perfect sense in a million powerful ways to permit them. The reason
ctors are not possible in the specs is a pure technicality... because it
would sort of gum up other specs around construction. 

Still one can see from a simple example the power of such a feature...

For instance, say you need to impliment a GUI, so you have yourself a
rectangle struct which consists of four floating point values (the origin
and difference between the opposite corner) ...Now you want those four
values, but you also have a 2D vector struct. So it seems obvious to union
the scalars over the two vectors. Why? Because it makes the code much more
intelligible then it would be to always access the corners from the vectors
(which would be the only alternative outside of sacrificing the
functionality of the vector class) 

Same can be said for embedding 4D vectors in a 4x4 matrix, form a transform
matrix / orthogonal axes coordinate system and translation vector. Of course
the benefits transcend graphics, but that is the simplest example, and the
intensive reuse of graphics primitives and the hairy code they tend to
generate, only further serves to drive the point home.

I use graphics primitives throughout all of my code, even when completely
unrelated to graphics. And I've found myself in a position where I refuse to
sacrifice my handy dandy vector libraries. I can't modify them to suit GCC,
and I can't remove their constructors for obvious reasons (automatic
instantiation, conversion operators, etc)

So I find myself here... I pretty much have to make a case, and beg for a
GCC workaround of some type. GCC doesn't have to conform to for loop scope
spec, so I see no reason why a similar compiler option can't be permitted to
get at this issue. Windows permits it, and it is not an uncommon dilemma.

There is no error code, but the basic errors look like this:

...struct>::xyâ?T with constructor not allowed in union
...struct>::xyâ?T with copy assignment operator not allowed in union

I'm prepared to try to hack GCC myself if I must. I have to wonder what
would happen if the error was simply ignored. My intuition tells me there
would likely be no technical ramifications. A more thorough solution would
of course be preferred. I won't dull out possible scenarios, but it should
appear obvious, that it seems especially cruel, to arbitrarily deny structs
with ctors inclusion in unions.

So in closing, I'm interested in any ideas / advice, but compromising the
existing codebase is completely out of the question. You have my
appreciation in advance naturally...

sincerely,

michael





-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11149318
Sent from the gcc - Dev mailing list archive at Nabble.com.