261340 - consider support for advanced C++ features (std::vector, exceptions) in XPCOM

Status: NEW

(Core :: XPCOM, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Filing a bug for shaver to ponder on adding support for a vector attribute in
xpidl to translate into a std::vector, instead of the current array/size_is stuff.

Comment 1

[Benjamin Smedberg]

No! C++ templates are not binary freezable. C is good. Please WONTFIX

Comment 2

[David Bradley]

Ideally what you need is a C array API and then create a C++ class to wrap that 
API. The current state of strings in XPIDL is example of how not to do things. 
I'd rather we not add to the problem.

Ultimately I'd like to see the type system for XPCOM revamped and made a bit 
more cleaner. But it would be quite messy during the period that the old types 
were deprecated.

So I say this is a WONTFIX.

Comment 3

[Darin Fisher]

std::vector can have many different ABIs per implementation.  moreover, it is
today possible to build minimo without libstdc++... familiar linux doesn't ship
libstdc++.  let's please not make that a core requirement!

Comment 4

[Darin Fisher]

I meant: "std::vector can have varying ABIs *across* implementations."

Comment 5

[Darin Fisher]

one more concern with std::vector and stl in general: does it work with
-fno-exceptions?  we don't want to take the hit of enabling exceptions in C++
because that would bloat us badly.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The original thinking behind this bug comes down this.. right now working with
XPCOM, and by extension with the Mozilla platform, sucks quite badly from C++. 
It's incredibly verbose and tedious, to a point where it's a major negative
factor of the platform.  If we think that the future is Mono, then maybe this
isn't such a big issue; but I don't think that's a reasonable plan.

C++ is still going to be with us for some while, and I think we're hamstringing
both our own efficiency as well as the platform itself by sticking with
circa-1998 C++.  In a comparison between the Mozilla platform and more modern
(and future) platforms, I'd guess that the Mozilla platform looks pretty poor in
comparison from a developer's perspective.  Identifying potential areas where we
might be willing to take some pain for substantial benefit would be a good
thing, IMO.  This might be one of those areas; though there are certainly others.

Comment 7

[Darin Fisher]

I hear you and agree with you in principal.  I just have serious doubts about
STL as a viable option due to codesize considerations and binary compatibility.
 I think we can do this with something other than std::vector.  A set of
low-level extern "C" routines and a thin templated class wrapper would be ideal.
 No C++ symbol exports from libxpcom.so! ;-)

Comment 8

[Doug Turner (:dougt)]

what darin said.  xpcom will not export frozen C++ methods, ever.  Based on all
of the feedback, this bug is WONTFIX.

Comment 9

[Mike Shaver (:shaver emeritus)]

All of C++ can have different ABIs across implementations; that's why we have
per-ABI code in xptcall to navigate the vtables and marshal arguments.  The
layout and form of std::vector<T> would become one more thing that people would
have to handle in their xptcall implementation.

The STL dependency on exceptions is, indeed, a killer tile.  I'd like to look at
exception use in XPCOM for Mozilla 2.0, but we're not there yet.

Darin: how much does losing -fno-exceptions bloat our current
(non-exception-using) code?  Can we make that back by removing the number of
explicit NS_FAILED checks in our code?  If so, what's the break-even point for a
given method, etc.?  (I suspect that we can _more_ than make it back for our
current codebase, in which NS_ENSURE_SUCCESS introduces a check branch and call
and return every ~5th line in some places.)

I don't know why C++ templates when used as arguments to virtual methods aren't
binary-freezable, though, or why this would require C++ symbol exports.  Can
someone explain that to me in small words?  It's Monday here, still.

Reopening (you're all very quick to hold the status quo!) and re-summarizing,
because I do want a bug open on this topic.  Maybe I'll have to file another
one, though.

Comment 10

[Benjamin Smedberg]

Are you proposing that we ditch the goal/fantasy that XPCOM is C++-ABI-agnostic?
Admittedly, MSCOM is only ABI-agnostic on windows because microsoft could make a
unilateral decision to use the MSVC vtable layout as "the COM standard". But
once it did that, you don't *need* MSVC to make COM components on windows, as
long as you are using the (poorly-documented) ABI.  It's one thing to say "the
gcc3.x vtable layout is our standard, from now on, gcc4 can go to hell", it's
quite a bit more dramatic to say "you have to link against such-and-such
libstdc++ to work with us".

(New primitive types and exceptions are vastly different issues, IMO, and we
should discuss them separately. Exceptions break backwards-compatibility,
AFAICT, and are much worse than new primitive types.)

Comment 11

[Darin Fisher]

> The STL dependency on exceptions is, indeed, a killer tile.  I'd like to look 
> at exception use in XPCOM for Mozilla 2.0, but we're not there yet.

This sounds like you're talking about completely changing our ABI.  I think we
should look for ways to improve the usability of our API without breaking
compatibility with our ABI if at all possible.


> Darin: how much does losing -fno-exceptions bloat our current
> (non-exception-using) code?

Hard to say without actually translating a large portion of our code, but simple
tests show that indeed there is a fixed overhead for exception handling in any
function that calls another function, and there is additional overhead where
exceptions are thrown.  I agree that if enough functions are called, the
overhead of exceptions could be minimized.  Given our codebase, I wouldn't be
surprised though if the overhead would kill us due to the large number of small
functions in our codebase that just call another function.  Imagine what would
happen to all those functions that just call AddRef to return an interface pointer?

Simply building mozilla today with exceptions enabled is obviously a really bad
idea, but perhaps if we were to _rewrite_ all of our code to not do explicit
error handling, then exceptions could _perhaps_ be an efficient choice for
mozilla.  That doesn't sound like a good proposition to me.

I'll attach a little GCC 3.3.3 testcase.

Comment 12

[Darin Fisher]

Attachment: exception fun

Comment 13

[Doug Turner (:dougt)]

requiring the C++ runtime (for stl) to run would be a mistake.  there are many
embedding customers that don't ship this library and would have to bundle it
made this change.

I would rather more cleanly expose arrays, vectors, maps, etc.  we already have
that kinda stuff in xpcom/ds.  :-)

Comment 14

[Mike Shaver (:shaver emeritus)]

Mass abdication.