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
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
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
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
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
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.
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
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
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
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
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
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)
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
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
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
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
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:
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
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
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
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
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
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
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
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:
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
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
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
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
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.
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
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
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?
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
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
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
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
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();
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
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
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:
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.
[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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
66 matches
Mail list logo