This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/39798] would like flag to disable constructors for built-in types



------- Comment #2 from kraftche at cae dot wisc dot edu  2009-04-20 15:52 -------
Subject: Re:  would like flag to disable constructors for built-in
 types

falk at debian dot org wrote:
> ------- Comment #1 from falk at debian dot org  2009-04-20 15:28 -------
> Removing the default constructor is a bad idea, since it would break about any
> available library including the standard lib in subtle ways, and would make g++
> pretty much unusable.
> 
> But apparently this isn't actually what you really want anyway, but actually
> you want to be able to create STL containers with uninitialized memory. This
> seems to me a pretty unusual requirement, and it could be achieved by creating
> a wrapper class for int with empty constructor, so I don't think this justifies
> language or library changes.

I was asking for a flag to change the behavior of the default/builtin
constructors for intrinsic types.  That isn't quite as extreme as removing
default constructors entirely.

Yes, I had requested that behavior with the intention of creating STL
containers with uninitialized memory.  I have used other work-arounds
(wrapper classes and such) in a few instances where that was necessary for
performance reasons.  But there are other cases where a flag to change the
constructor behavior for intrinsic types would be more appropriate.  For
example, it is often the case that the zero value assigned to all container
entries is logically just as unitialized as any other arbitrary value.  When
debugging such code it would be nice if the zero-ing behavior could be
removed because it masks such errors from tools like valgrind.  Using a
work-around would unnecessarily complicate the code because it is not
necessary for correctness or performance.

Anyway, this was purely a request for a wish-list type convenience feature.
 If it is infeasible or likely to introduce other subtle errors in the
functioning of the standard library, then please close this bug with my
thanks for taking the time to read it any my apologies for any nuisance.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39798


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]