The problem with the latest spate of compiler optimizations was not the
optimization, but the lack of warnings about exploiting undefined behavior.
--
Lawrence Crowl
r even without dependency ordering, so P0190R0
>> > kicks this particular can down the road. One option that
>> > has been suggested is to provide intrinsics for this purpose.
>> > (Sorry, but I forget who suggested this.)
>> >
>> > Thoughts?
>> >
>> > Thanx, Paul
>> >
>> > ___
>> > Parallel mailing list
>> > paral...@lists.isocpp.org
>> > Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
>> > Link to this post: http://lists.isocpp.org/parallel/2016/02/0040.php
>> > ___
>> > Parallel mailing list
>> > paral...@lists.isocpp.org
>> > Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
>> > Link to this post: http://lists.isocpp.org/parallel/2016/02/0045.php
>>
>> ___
>> Parallel mailing list
>> paral...@lists.isocpp.org
>> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
>> Link to this post: http://lists.isocpp.org/parallel/2016/02/0046.php
>
--
Lawrence Crowl
types.
So, in your new search, you could have two functions with the same
name and same parameter types. You will need to keep a bit on the
template-derived version so that you can break the tie.
--
Lawrence Crowl
On 3/25/13, Tom Tromey wrote:
>>>>>> "Lawrence" == Lawrence Crowl writes:
>
> Lawrence> Hm. I haven't thought about this deeply, but I think SFINAE may
> Lawrence> not be less of an issue because it serves to remove candidates
> Lawre
On 3/25/13, Tom Tromey wrote:
>>>>>> "Lawrence" == Lawrence Crowl writes:
>
> Lawrence> My model is that I should be able to cut and paste an expression
> Lawrence> from the source to the debugger and have it work. I concede that
> Lawrence> C
f names; but are we
> still doing that?
We could have an option to take the compile time (and probably some
parts of the file path) out of the random number generator.
> Clang appears to use anonymous namespaces...
--
Lawrence Crowl
that by default we use the most
> correct mangling. If people really need backward compatible
> mangling for some reason they can specify the flag appropriately.
Are you planning for C++11 ABI stability in 4.9?
--
Lawrence Crowl
a
> long time and you all seem approachable rather than the distant compiler
> gods I expected.
>
> I can also see why 'strong typedefs' were not done, it tries to do too much
> with the type system and becomes very object like
>
> Alec Teal wrote:
>
>>On 2
. Consider its semantics when implementing.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf
--
Lawrence Crowl
des the one outlined by N3347 and the slides
> > Chris pointed a link to?
>
> Lawrence Crowl (in collaboration with Diego I think) has a proposal
> based on PPH. Lawrence knows best the proposal number.
The paper is N3426 Experience with Pre-Parsed Headers.
http://www.open-std.org/jtc1/sc2
On 11/23/12, Andrew MacLeod wrote:
> On 11/22/2012 01:18 PM, Lawrence Crowl wrote:
> > I have found that tree-flow.h implements iteration over htab_t,
> > while there is no current facility to do that with hash_table.
> > Unfortunately, the specific form does not
you prefer?
--
Lawrence Crowl
On 11/20/12, Xinliang David Li wrote:
> one minus -- less gdb friendly.
Do you mean that gdb does not handle the stream expressions
or something else?
>
> David
>
> On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl wrote:
>> On 11/20/12, Diego Novillo wrote:
>&
On 11/20/12, Diego Novillo wrote:
> On Nov 20, 2012 Basile Starynkevitch wrote:
> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
> > > function (FILE *, item_to_dump, formatting)
> > > function (item_to_dump, formatting)
> >
> > Sin
In graphds.h, struct graph has a field "htab_t indices".
As near as I can tell, it is completely unused. It builds
and tests fine with the field #if'd out.
Shall I remove the field?
--
Lawrence Crowl
On 11/20/12, Andrew MacLeod wrote:
> On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> We propose to provide several function overload sets, as below.
>>
>>
>> dump_pretty
>&
n,
> dump_tree, dump_generic, and we may need a few more.
Diego and I talked about this a bit more, and would like to explore
a set of dump names that distinguish between dumping the head of
an item and its body. In essence, the former asks for the function
declaration, the latter its definition.
Comments?
--
Lawrence Crowl
On 11/12/12, Diego Novillo wrote:
> On Mon, Nov 12, 2012 at 2:31 PM, Lawrence Crowl wrote:
>> On 11/12/12, Lawrence Crowl wrote:
>>> It appears that
>>>
>>> static bitmap clear_alias_sets = NULL;
>>>
>>> is never set, and as a conseq
these components #if'd out.
Should I remove them?
--
Lawrence Crowl
ollection, so the vast bulk of the
existing code will work unmodified.
The only disadvantage, as near as I can tell, are small performance
losses during normal compilation, and possibly somewhat larger
losses for PCH.
--
Lawrence Crowl
ecognize GTY, and the second (and subsequent) built compiler would
have these features.
Because the first built compiler would not have GGC, we need some
other memory management, and the Boehm collector is the nearest
handy tool.
--
Lawrence Crowl
#ifdef'd out. Should I remove
them?
--
Lawrence Crowl
On 11/15/12, Michael Matz wrote:
> On Wed, 14 Nov 2012, Lawrence Crowl wrote:
> > Diego and I seek your comments on the following (loose) proposal.
>
> In principle I agree with the goal, I'm not sure I like the
> specific way yet, and even if I do I have some suggestions:
On 11/14/12, Basile Starynkevitch wrote:
> On Wed, Nov 14, 2012 at 05:13:12PM -0800, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> Generating gimple and tree expressions require lots of detail,
>> which is
On 11/14/12, Andrew Pinski wrote:
> On Nov 14, 2012, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> It is sometimes hard to remember which printing function is used
>> for debugging a type, or even which type y
lasses that provide a simplified IL
building interface. Essentially, these builder classes will abstract
most of the bookkeeping code required by the current interfaces.
These classes will not replace the existing interfaces. We do not
expect that all the IL generation done in current transformations
will be able to use the simplified interfaces. The goal is to
simplify most of them, however.
--
Lawrence Crowl
optional, with a default suitable to the kind
of item to dump.
We should remove tree-browser.c. It is not used at all and it is
likely broken.
--
Lawrence Crowl
On 11/12/12, Lawrence Crowl wrote:
> It appears that
>
> static bitmap clear_alias_sets = NULL;
>
> is never set, and as a consequence
>
> clear_alias_set_lookup (alias_set_type alias_set)
>
> is never called. This conclusion is reinforced because it
&g
It appears that
static bitmap clear_alias_sets = NULL;
is never set, and as a consequence
clear_alias_set_lookup (alias_set_type alias_set)
is never called. This conclusion is reinforced because it
unconditionally uses htab_t clear_alias_mode_table, which is never
allocated.
--
Lawrence
overhaul soon. With any luck this week,
> but PCH and gengtype are giving me a lot of grief.
I have three remaining bitmap patches and the recently approved
is_a/symtab/cgraph patch.
However, Alexandre Oliva has a patch for
bootstrap failure that is biting me. I can either incorporate it
into my patches or wait for his patch and then submit. Comments?
--
Lawrence Crowl
It turns out that gcc/ebitmap.[hc] is not used.
Should we kill it?
--
Lawrence Crowl
On 10/15/12, Michael Matz wrote:
> On Sat, 13 Oct 2012, Lawrence Crowl wrote:
> > > > I have no problem in always returning a status change,
> > > > if you are OK with that.
> > >
> > > I am ok with that.
> >
> > There is some rationale f
always returning the status change, but we might get
a significant performance change, and I don't want the blame if it
shows up. :-)
--
Lawrence Crowl
On 10/11/12, Diego Novillo wrote:
> On 2012-10-11 13:26 , Lawrence Crowl wrote:
>> My only other concern was that the mapping between those function
>> names and the tasks to be done sometimes seemed less than obvious.
>> So, I proposed the name change. However, I think the
On 10/11/12, Richard Biener wrote:
> On Oct 11, 2012, Lawrence Crowl wrote:
>> As part of our effort to make programming in GCC easier, we would like
>> to improve the interface to bitmaps.
>>
>> There are three bitmap types, each with disparate operations and
>>
on, vector, debug/dump/print
and functions alone for the time being.
Comments?
--
Lawrence Crowl
ou quoted, but occurs above.
>
> Do a 'make' and you'll see the error more clearly.
You are correct. It appears that gengtype is falling over, which is
at least sensible!
Sorry for the confusion.
--
Lawrence Crowl
character `&'
../../src2/gcc/cgraph.h:467: unexpected character `&'
--
Lawrence Crowl
e == SYMTAB_VARIABLE);
>>return x_variable; }
>>
>>
>>
>> add
>> symtab_node_base *symtab_node_def::try_symbol()
>> { return &symbol; }
>> cgraph_node *symtab_node_def::try_cgraph()
>> { return symbol.type == SYMTAB_F
rver.c:195: error: ignoring return value
of 'getcwd', declared with attribute warn_unused_result
The warning is correct. It is not clear what one should do upon
testing the return value, as server_setup does not signal errors.
Suggestions?
Do we consider contrib/config-list.mk dead?
--
Lawrence Crowl
ol (node)"
TYPE SAFETY ###
If a function asserts that its symtab_node parameter is symtab_function_p,
then convert the function to take a cgraph_node*
and change the callers to convert as above.
--
Lawrence Crowl
at once. In particular, the discussion
on cgraph can go on in parallel with finishing up double_int.
--
Lawrence Crowl
e --> derived from symbol;
>
> typedef node cnode;
A node is not a derived class of node even when
function is derived from symbol. That property is helpful in
ensuring usable type safety.
> 4) coding convention is needed for functions that do 'casting'
> and 'trial casti
afe.
> Probably is_function/is_variable & try_function/try_variable
> sounds more readable to me. What do you think?
Fine with me.
> (I just arrived from China, so will take it more tought once
> unjetlagged)
--
Lawrence Crowl
hanging
typedef union symtab_node_def *symtab_node;
typedef const union symtab_node_def *const_symtab_node;
to
typedef symtab_node_base *symtab_node;
typedef const symtab_node_base *const_symtab_node;
changing used of
symtab_node_def
to
symtab_node_base
--
Lawrence Crowl
On 9/3/12, Richard Guenther wrote:
> On Aug 24, 2012, Lawrence Crowl wrote:
> > To take full advantage of the conversion to C++, we will need to use
>
> I'm not sure what "full advantage" of single-inheritance vs. composition
> is.
You get automatic pointer-to-
;> class FTYPE : GTY ((tag ("F2"))) public CTYPE { ... };
>>>
>>> I wonder if the second discriminator support is easily generalizable
>>> to enabling any derived class being a root class on it own with its
>>> own subtree? If I understand correctly,
ds a bit more testing in uncommon build environments,
> > i.e., anything other than x86_64 GNU/Linux, to make sure that
> > it at least builds and does not crash even when it can't get
> > a backtrace.
>
> Kudos for doing this. I am sure Diego would love it (when he
> is back.)
Diego already loves it!
--
Lawrence Crowl
On 8/30/12, Gabriel Dos Reis wrote:
> On Aug 30, 2012 Richard Henderson wrote:
> > On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
> > > > > I wonder if the second discriminator support is easily
> > > > > generalizable to enabling any derived class being a
On 8/30/12, Richard Henderson wrote:
> On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
>>> I wonder if the second discriminator support is easily generalizable
>>> to enabling any derived class being a root class on it own with its
>>> own subtree? If I understand corr
sily generalizable
> to enabling any derived class being a root class on it own with its
> own subtree? If I understand correctly, the GTY syntax would be the
> same.
If I understand correctly, you are suggesting multiple inheritance
via enums. I think it is possible, but I think the tag syntax
would need to be changed to more directly associate the tag with
the variable.
--
Lawrence Crowl
begin to
suspect that any solution using the standard library will require a
first-class implementation within the compiler itself, as the compiler
has full access to fields and can bypass any privacy.
--
Lawrence Crowl
f physical memory and
doing lots of paging. If so, there are some solutions.
(1) Get more memory for the machine.
(2) Compile at lower levels of optimization.
(3) Partition your application into smaller source files, as measured
by the size of the preprocessed file that they expand into.
--
Lawrence Crowl
Would it be more productive to ensure that existing tools, like
valgrind, are effective with gcc?
--
Lawrence Crowl
urces, or in general? I think the
latter would fail compatibility tests.
> It general, it might be good to avoid too many ways of spelling
> the same thing.
While I'm not excited by the name, __builtin_lazy_FILE has the
virtue of being clear in the lazy binding of the name.
--
Lawrence Crowl
on bigger scale changes
> > that will not be ready for this release (e.g., experimenting
> > with gimple and tree).
> >
> > I will split up the merge patch in 4 or 5 chunks to simplify
> > reviews. For now, we would appreciate if folks test the branch
> > with:
> >
> > $ svn co ssh://gcc.gnu.org/svn/gcc/branches/cxx-conversion
> > $ mkdir bld && cd bld
> > $ ../cxx-conversion/configure --enable-languages=all,ada,go && make
> > bootstrap && make check
> >
> > We welcome any suggestions (and volunteers!)
--
Lawrence Crowl
macro that
produces the declarations. Second, have an external script generate
the headers. The redundancy will appear in the user-facing headers,
but not in the sources programmed.
The second thing you can do is minimize the number of behaviors
that depend on command-line arguments. These bloat
ard says x.h exports d. From there
you descend into what the OS folks fondly call "header hell". :-)
The root problem is in the standards, and given the legacy code
base, it's going to be really hard to fix. I suspect that with
convincing we could get alternate headers (or modules) defined with
better behavior. I doubt we could change the existing headers.
--
Lawrence Crowl
,
> but as a general guideline, I would suggest to forget them.
Implicit, I think, in Gabriel's statement is that if you really need
enable_if, and make a convincing case, you can get an exception to
the general rule.
To my mind, one of the advantages of enable_if is that customers do
not need to know about it. It is an internal implementation issue,
and presumably authors using enable_if are comfortable with it.
--
Lawrence Crowl
>
> But Jakub points out glibc having at_quick_exit.
>
> > > - Allow atomics use in signal handlers
> > > - Sequence points
> >
> > I would guess that these don't require any changes, but haven't
> > verified this.
I believe that no work is required for atomics in signal handlers.
The issue in the standard was to permit what would work anyway.
--
Lawrence Crowl
type_decl *) p;
> do_type_work_2 (p_type_decl);
> }else if(is_field_decl(p)){
> field_decl * p_field_decl = (field_decl *) p;
> do_field_work_3 (p_field_decl);
> }
That approach will certainly work, but makes the correctness of
the assignment contingent on the condition being right. If the
condition changes in appropriately, you can get a bug. Even so,
I think what you suggest is a good intermediate step.
--
Lawrence Crowl
On 4/12/12, Ian Lance Taylor wrote:
> Lawrence Crowl writes:
> > On 4/12/12, Manuel López-Ibáñez wrote:
> > > So given your ideal implementation, if the user-visible
> > > result was exactly like the one in Clang, will you be happy
> > > with any of the th
e I don't know all manners.
--
Lawrence Crowl
On 4/11/12, Richard Guenther wrote:
> On Apr 11, 2012 Lawrence Crowl wrote:
> > On 4/10/12, Jakub Jelinek wrote:
> > > That when stepping through code in the debugger you keep
> > > enterring/exiting these one liner inlines, most of them
> > > really shou
pproach with GCC trees.
() Class hierarchies also mean that programmers can distinguish
in the pointer types that a function needs a decl parameter,
without having to say 'all trees' versus 'a very specific tree'.
The static type checking avoids run-time bugs.
I have written compilers in both C and C++. I much prefer the
latter.
--
Lawrence Crowl
On 4/10/12, Richard Guenther wrote:
> On Apr 9, 2012 Lawrence Crowl wrote:
> > On 4/9/12, Jakub Jelinek wrote:
> > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> > > > A build conversion to C++ is a precondition to any source
> > > &
e the current data structures are densely packed,
they are not necessarily information rich. In the PPH branch,
we found that near half the pointers we were streaming were null,
which says that many of the fields are unused. This information
could be shifted to auxilary tables.
--
Lawrence Crowl
On 4/9/12, Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote:
>> On 4/9/12, Jakub Jelinek wrote:
>> > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> > > A build conversion to C++ is a precondition to an
On 4/9/12, Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> > A build conversion to C++ is a precondition to any source change
> > using C++, though the two could be bundled into one patch. In any
> > event, I agree that the conver
On 4/9/12, Richard Guenther wrote:
> On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl wrote:
>> On 4/5/12, Richard Guenther wrote:
>>> How do you expect tree errors to become static? By using derived
>>> types everywhere? Note that this would only be possible in a
&g
On 4/5/12, Richard Guenther wrote:
> On Apr 4, 2012 Lawrence Crowl wrote:
> > On 4/4/12, Richard Guenther wrote:
> > > Making tree or gimple a C++ class with inheritance and
> > > whatever is indeed a huge waste of time and existing developer
> > > ressources
ing C++ in gdb somewhat more annoying than
> > debugging plain C, and at the moment I always go back to a
> > stage1 compiler.
>
> Indeed - I'd be worried if my debugging efficiency decreases by
> more than 5%.
If the number of debugging sessions was reduced by the same amount,
the result would be a net wash.
--
Lawrence Crowl
sure we have them covered in 4.8.
>
> OK. Does it say anywhere on the website exactly what can and
> can't be done with respect to the memory model?
We cannot really know until after the optimization audit has been
completed.
It might be helpful to say the model is correct at some maximum
optimization level, probably -O0 or -O1.
--
Lawrence Crowl
It appears that "cd gcc; make" now fails to build crtbegin.o.
An additional "make all-install" seems to be needed. Was
this change intentional?
--
Lawrence Crowl
clearly explained.
I am willing to wager that the implicit assumption here is that
relationships are managed with pointers.
I am also willing to wager that the author is willing to accept a 5x
increase in memory use to get cited benefits. While that tradeoff is
good for many applications, it is not good for all applications.
--
Lawrence Crowl
gent.
I think the most likely use of volatile atomics is in communicating
between to processes sharing memory. Note, though, that such
atomics may need to be lock-free and/or address-free.
--
Lawrence Crowl
other atomic variables. Second, some
algorithms need more than one atomic operation, but are only
'effective' on one of them, and only that one needs to synchronize
other memory.
--
Lawrence Crowl
lar, what you
buy or lose by changing compilers and/or optimization/debug levels.
--
Lawrence Crowl
file
without dejagnu trying to interpret it as a test?
It might be sufficient if I just knew the path to the compiler.
Any ideas?
--
Lawrence Crowl
On 6/9/11, Janis Johnson wrote:
> On 06/09/2011 01:30 PM, Lawrence Crowl wrote:
>> On 6/9/11, Janis Johnson wrote:
>>> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
>>>> On 6/6/11, Janis Johnson wrote:
>>>>> On 06/03/2011 11:14 AM, Lawrence Crowl
On 6/9/11, Janis Johnson wrote:
> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
>> On 6/6/11, Janis Johnson wrote:
>>> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>>>> The PPH project has tests that compile two different ways, and
>>>> then compar
On 6/6/11, Janis Johnson wrote:
> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>> The PPH project has tests that compile two different ways, and
>> then compare the assembly. If either of the compiles fails, the
>> comparison will fail. We'd like to simply not ru
s subsequent actions when the test is known
a priori to have errors. How do we detect compilation errors,
so as to skip the remainder of the actions?
--
Lawrence Crowl
el.
I made the changes to save/restore current_namespace, and the front
end works. There is a segfault in the back end. The cause is as yet
unknown.
--
Lawrence Crowl
fter-pph-branch?
>
> I'd like to start documenting this project/branch on the GCC wiki. At
> least the command options in gcc/c-family/c.opt, and have usage
> examples. You'd mentioned that this may use the incremental linker
> page, but as PPH/PTH is but one part of this I'm hoping to convince you
> to use a new page, say PrettyCachedHeader or PPHPTH or FECaching or
> something. Thoughts?
Diego's on vacation (or holiday) right now, so it might be a while
before he answers.
--
Lawrence Crowl
case : the general
> case is provided ; in another, separate file, prohibition of the copy
> constructor is specialized.
>
> What is your opinion about this?
I think the compiler should use the specialization regardless of
the order.
--
Lawrence Crowl
On 8/20/09, Boehm, Hans wrote:
> > -Original Message-
> > From: Lawrence Crowl [mailto:cr...@google.com]
> > The problem is that gcc does support 80386. It also supports
> > other processors that have less-than-complete support for
> > concurrency. Jus
On 8/19/09, Joseph S. Myers wrote:
> On Wed, 19 Aug 2009, Lawrence Crowl wrote:
>
> > I am quoting from several different messages.
> >
> > On 8/17/09, Joseph S. Myers wrote:
> > > (A) Code compiled against headers from libc version X must be run
&g
B
SSE SFENCE
SSE2MFENCE
late AMD64 CMPXCHG16B
So, we do not get to ignore the problem as a relic of 80386.
Hm. We also need that mapping between architecture and type, which
probably needs to indicate a lock-free implementation for each operation.
Alexander Terekhov did a large chunk of that.
--
Lawrence Crowl
On 8/14/09, Joseph S. Myers wrote:
> On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> > So, suppose I compile my program A, using libc version X, on
> > a processor of type D, which permits me to inline the atomic
> > operations. Then suppose that I execute A on a processor of
On 8/14/09, Joseph S. Myers wrote:
> On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> > So, if -march=D should not imply inlining of the atomic
> > operations, we need another option that does. That other
> > option in turn must require the dynamic library use compatible
>
On 8/13/09, Joseph S. Myers wrote:
> On Thu, 13 Aug 2009, Lawrence Crowl wrote:
> > > Now a processor D for this architecture comes out. All code
> > > for A, B and C will work on D, but D also has 8-byte atomic
> > > operations. GCC 4.7, with -march=D, genera
On 8/13/09, Joseph S. Myers wrote:
> On Thu, 13 Aug 2009, Lawrence Crowl wrote:
> > > In that it defines functions, is unlike all the
> > > headers presently required of freestanding implementations,
> >
> > But , , and all define functions.
>
> I'
On 8/12/09, Joseph S. Myers wrote:
> On Wed, 12 Aug 2009, Lawrence Crowl wrote:
> > > The C1x atomics specification
> > > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm>
> > > does not mention any amendment to the list of headers to be
> >
he
> memory model, in particular) unless given an option to say it
> doesn't need to follow the model.
My recommendation is to just do a good enough job on _changing_
the optimizations so that you don't need an option. It would
probably avoid some rather elusive bugs when someone links in a
library compiled the wrong way.
--
Lawrence Crowl
he interface.
Most of that work has yet to be done. Once that work is done,
though, the actual coding will be fairly easy. So, I suggest
that Posix/C++ integration would not be good for a GSoC project.
A project that has a narrower scope and more code would be better.
--
Lawrence Crowl
, it would not be possible to
> > implement a function like ldexp or frexp in C or C++, where we want
> > to consider the same storage either as a double or as a sequence of
> > bytes.
>
>
> It's possible to do that without using unions; pointers to character
> types are explicitly permitted to alias any storage.
>
>
> -- James
>
--
Lawrence Crowl
I doubt that the C++ committee has ever addressed this issue.
The general thinking would be "if you cannot change fields, you
don't need the union". I see why the approach was taken.
The C++ draft standard is in review now. If you have specific
recommendations, now would be a good time to forward them as
comments to your national representative to ISO.
--
Lawrence Crowl
tandard; I'd be
> surprised if such a patch were accepted, but I have no way to know for
> sure.
In summary, the change to unions is to allow non-pod types in unions.
To use this capability, though, you need to remember what the last
active field was so you can destruct it.
I agree that having multiple initialized members of a union is highly
unlikely. The semantics depend too much on the details of compilers
and platforms, so the best the standard could do is "implementation
defined", and the general trend is towards avoiding that were possible.
--
Lawrence Crowl
s make life hard for the
programmers that must code to multiple platforms.
--
Lawrence Crowl
1 - 100 of 106 matches
Mail list logo
