This is the mail archive of the 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]

Re: [PATCH 5/5] add libcc1

On Tue, Jun 24, 2014 at 11:12:38AM -0600, Tom Tromey wrote:
> Trevor>  hrm, I know basically nothing about the upcoming changes, but I would
> Trevor>  have expected linking c++03 code against c++11 code would be fine
> Trevor>  especially when the interface doesn't involve any stl.
> This warns against mixing with C++98, which seems to be how GCC is
> built.
> While I agree that in this specific case it is probably safe, since gcc
> in general isn't a heavy user of libstdc++, I think it's reasonable to
> simply follow gcc.  This is safer in case gcc changes; and the benefit

yeah, I'm not disagreeing at this point.

> from C++11 in libcc1 is modest, especially when you consider the extra
> template magic we'd need in order to actually use variadic templates for
> the RPC stuff.

It would get a little more than that, actually deleting the copy ctors
and stuff you don't want people to call is one thing that comes to mind.

> Trevor>  Well, we build everything or at least everything I've seen with
> Trevor>  -fno-exceptions, so if something does throw we'll just crash right?
> Trevor>  istm we certainly write code calling the throwing new with that
> Trevor>  expectation.
> Gcc's coding conventions say that code ought to be exception-safe in
> case exceptions are used in the future.  Search for "Exceptions" here:

I think that's a good idea in general, mostly because it results in
simpler code, I think the idea gcc will be exception safe in a
reasonable amount of time is a bit of a pipe dream.

> I think retaining the std::nothrow is safer in view of this, and doesn't
> cause any problems.

 I think in general trying to handle allocator failure is a waste of
 time, that is all the places we call the throwing new today we'd want
 to keep doing that in a world with exceptions and just let the
 exception kill us.  So assuming you actually want to handle allocator
 failure in this particular case for some reason that seems reasonable.


> Tom

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