Re: Future of C++
on Sat Aug 16 2008, gpderetta <gpderetta-AT-gmail.com> wrote:
On Aug 15, 6:54 am, David Abrahams <d...@boostpro.com> wrote:
on Thu Aug 14 2008, gpderetta <gpderetta-AT-gmail.com> wrote:
The fact that it has a mutex may be an implementation detail, but the
fact that the destructor is non trivial is part of the interface: the
user can know this via std::has_trivial_destructor<>.
The fact that something is discoverable doesn't make it part of the
public interface. If I don't document the fact that a class has a
trivial destructor, and will for all time, I rightfully expect to be
able to add a nontrivial dtor without breaking client code.
You are of course right: you can discover the size of an object via
sizeof, but that doesn't make it necessarily part of the interface (In
fact even knowing that the size of the object is fixed is useful for a
library user that need a stable ABI).
As it is often the case, the less an interface is defined, the happier
is the library developer, on the other hand the more the interface is
constrained, the happier is the library user.
Unless the user might want bugfixes and enhancements someday.
If I'm developing a multithreaded application, I won't use a library
that doesn't document its thread safety. In the same way, if I'm
developing a GC'd application, I won't use any library that doesn't
document its non memory resource usage. Currently not many do, but the
convention might change if GC becomes part of the language.
It might.
Maybe a trait like has_almost_trivial_destructor<> which is true if
the only thing the destructor does is calling delete or other
destructors that only call delete (hard to implement I
guess).
Hard enough to be impossible. In general the compiler can't see the
dtor's implementation.
Righ, but this information could be known at run time (see below for
why this might be useful).
Probably the way to go is a destructor attribute like
[[when_gc_disabled]] that would make the destructor '= deleted' when
the garbage collection is active.
So as you can see, it gets kinda messy when you try to shoehorn GC into
C++.
I do not think an attribute is that messy.
No offense, but I doubt you've thought through all of the implications in
the
short time it took you to make the suggestion. Whatever messiness
you'd ascribe to the attribute is the tip of the iceberg.
But maybe compile time
annotation or introspection for non memory resources is not strictly
necessary. It could be left as something that need to be documented
and it would be responsibility of the user to make sure that all
needed destructors are called.
Which makes GC incompatible by default with all existing C++ code, where
by rights it ought to be compatible with nearly all existing C++ code.
Not very satisfying.
Failure to destroy any non memory resource could be detected by the GC
How could *that* possibly work? I think if the GC could detect
non-memory resources it would only be a few short steps to freeing them
as well.
When you introduce GC into the language, clients suddenly get the
freedom to intentionally "leak" most objects... but not mutexes,
queues,
or simulations. [GC wouldn't call destructors
(seehttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1943.pdf) and
even if it did, there's no guarantee that it would ever run. There
are
myriad other reasons that destructors cannot be called from GC
cleanup.]
So the fact that they manage a non-memory resource is no longer an
implementation detail of queue or simulation.
Then maybe it shouldn't be.
Maybe that would work for you, but personally I value encapsulation over
the advantages of GC.
Hum, actually, at least for finite resources, the fact that such a
resource is held or not held by an object is not an implementation
detail, even if it is not always documented.
So that would apply to memory as well. It is finite. Machine cycles
are finite, so you might want to ask people to document the constant
factors associated with the big-O efficiency of an operation.
No. There's information you absolutely need in order to use a class
successfully, and then there's information that might be useful but can
be legitimately hidden behind an abstraction. In a GC'd system, the
management of non-memory resources is information of the first kind. In
a non-GC system, it's information of the second kind.
In most cases it is obvious. For example, most programmers would
expect a stream buffer to own a file descriptor, but I know I would be
extremely disappointed if std::string kept open a file descriptor (it
would mean that you could only have a very small number of strings at
the same time). Note that even mutexes, on some systems, are scarce
resources.
I know.
So, again, it would be a matter of starting to document what non
memory resources an object uses. And IMVHO even the fact that an
object allocates (or not) dynamic memory should be documented (in fact
this is already the case in the hard real time world).
So where does it stop? If you expose all the detail of an
implementation it becomes effectively unusable as an abstraction. If
you would mandate that the use of dynamic memory be documented in all
library code regardless of application domain, then similarly you ought
to madate that that a function documents whether it calls other
functions (uses stack).
Anyways, I do not think that there is really a need for deep language
changes: GC is used in C++ now, with very good results.
No, we do not need deep language changes to use GC in C++; the committee
is making the (very small) changes needed to allow a GC'd C++
implementation to work in all legal programs.
What we need, as I've said, is a programming model that allows us to
safely and effectively combine GC'd C++ that doesn't call destructors
with existing code using dtors to manage non-memory resources.
A blessing from the committee would means that library developers
would be more aware of its existence and would add additional
documentation to their libraries.
Perhaps. What kind of further blessing do you have in mind?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]