Re: I'm sorry, but this is unacceptable (union members and ctors)
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)
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
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | 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)
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-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)
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)
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)
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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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 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)
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 [EMAIL PROTECTED]
Re: I'm sorry, but this is unacceptable (union members and ctors)
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.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 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 wa 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)
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)
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)
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)
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 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)
On 6/16/07, Ross Ridge [EMAIL PROTECTED] 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)
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)
On 6/17/07, michael.a [EMAIL PROTECTED] 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::optionalT; 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: 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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 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)
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)
Just for the record, this construction was proposed to me from behind the
scenes:
class Rect
{
Rect()
{
new (xlat) Vec2T(); // Explicit calls to the ctor
new (size) Vec2T();
}
~Rect()
{
xlat.~Vec2T();
size.~Vec2T();
}
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 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)
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)
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)
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)
[EMAIL PROTECTED] 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 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)
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)
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)
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 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)
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)
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 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)
On 6/16/07, michael.a [EMAIL PROTECTED] 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)
On 6/16/07, michael.a [EMAIL PROTECTED] 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-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 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)
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 suppress-errors-patch.diff Description: Binary data
Re: I'm sorry, but this is unacceptable (union members and ctors)
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)
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 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)
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
I'm sorry, but this is unacceptable (union members and ctors)
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.
Re: I'm sorry, but this is unacceptable (union members and ctors)
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.
Re: I'm sorry, but this is unacceptable (union members and ctors)
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)
On 6/15/07, michael.a [EMAIL PROTECTED] 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)
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)
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)
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!)
