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 i
> 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 outsi
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 an
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
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 q
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
> >> value
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 stru
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 a
michael.a wrote:
>
>
> I guess I will have to sort out why the compiler isn't finding it (any
> advice is welcome -- just for the record, I did a straight install from
> packaged sources with previous gcc installs removed before hand)
>
>
Actually, funny story... I was actually looking for
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
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)
>
>
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) ...
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 mul
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---
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 rela
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 t
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 extensi
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 e
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 "prem
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-
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
> p
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
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
"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 --disabl
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-l
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
>> be
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 th
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
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/
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:
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 su
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 a
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).
> Mist
On 6/16/07, michael.a <[EMAIL PROTECTED]> wrote:
You are of course free to demonstrate how placement new could circumnavigate
the need of unions.
Boost.Variant implements discriminated unions using placement new:
http://www.boost.org/doc/html/variant.html
Of course, you would have to mimic t
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,
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
Tim Prince-4 wrote:
>
> Then use s release or snapshot tarball from mirrors of
> ftp://gcc.gnu.org/pub/gcc/, and/or get better software, and use gcc-help
> as intended.
>
Yes, I apologize, that link and virtually all of the mirrors were timing out
all last night (well for a couple hours at
[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 googl
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.
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%
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 fro
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
Just for the record, this construction was proposed to me from behind the
scenes:
> class Rect
> {
>Rect()
>{
> new (&xlat) Vec2(); // Explicit calls to the ctor
> new (&size) Vec2();
>}
>~Rect()
>{
> xlat.~Vec2();
>
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)
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
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 mis
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
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.
First of all, I think you mean unintereste
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 me
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
rebuild
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
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 a
David Fang wrote:
>
>
> ... And when the said constructor is trivial (e.g. for POD), then you pay
> nothing, zilch, nada. (same with placement delete) In C++, some things
> you write (od don't write) are merely abstractions for what should happen,
> which can represent 'nothing'. Only if yo
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.
>
> 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
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 uni
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
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, althoug
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 i
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
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 associ
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
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
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 p
> 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 interestin
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 equivalen
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 lega
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
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 suppor
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 rel
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,
72 matches
Mail list logo
