This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/39798] would like flag to disable constructors for built-in types
- From: "kraftche at cae dot wisc dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Apr 2009 15:52:34 -0000
- Subject: [Bug c++/39798] would like flag to disable constructors for built-in types
- References: <bug-39798-17521@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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