<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/11/2012 4:28 PM, David Held
wrote:<br>
</div>
<blockquote cite="mid:50A042A8.8030101@wyntrmute.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 11/11/2012 2:33 PM, Walter Bright
wrote:<br>
</div>
<blockquote cite="mid:50A0279C.9060206@digitalmars.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
[...]<br>
I've thought about using smart pointers for the CTFE stuff. I
think that would resolve it.<br>
<br>
I'm a little concerned that using smart pointers in general
would cause slowdowns.<br>
</blockquote>
<br>
Well, if you have the choice between compiling small programs
quickly, or compiling large programs at all, which do you think is
the better choice for dmd?</blockquote>
<br>
Good question. But also consider that we're transitioning to 64 bit
compilers, where consuming a lot of memory may not be relevant,
since most of that memory will be "dead".<br>
<br>
<blockquote cite="mid:50A042A8.8030101@wyntrmute.com" type="cite">
And really, I think the performance hit is much smaller than you
fear. With decent inlining, dereference can be as cheap as native
pointers,</blockquote>
<br>
Not quite true, remember the destructor code has to be inserted and
accounted for in all cases. This can add more than just a pointer
decrement & test.<br>
<br>
<blockquote cite="mid:50A042A8.8030101@wyntrmute.com" type="cite">
and reference counting only starts to get expensive if you need to
support multi-threading. Even then, by using raw pointers to
indicate non-owning usage, you can avoid the vast majority of
reference count changes.</blockquote>
<br>
I know about the potential for raw pointers to have all sorts of
bugs from incorrect usage. C++ has no way to protect against that.<br>
<br>
<blockquote cite="mid:50A042A8.8030101@wyntrmute.com" type="cite">
And then, to make a fair comparison, you have to judge the result
against 100% manual memory management (free() tends to be more
expensive than malloc()). I think you will find that smart
pointers stack up pretty well (although I would not advocate a
general-purpose one like shared_ptr<>...that's a bit
heavyweight for dmd).<br>
</blockquote>
<br>
One of the versions with embedded counters would be far more
suitable.<br>
<br>
<blockquote cite="mid:50A042A8.8030101@wyntrmute.com" type="cite"> <br>
<blockquote cite="mid:50A0279C.9060206@digitalmars.com"
type="cite"> Another refactoring I'd like to see happen in dmd
is that some of its data structures become copy-on-write, as
many, many problems have been caused by changing things that
someone else assumed wouldn't be changed.<br>
</blockquote>
<br>
And that job would be made a lot easier if all data were private
to begin with. ;) Again, a lot of these changes could be detected
with some asserts at strategic locations (although, asserts cannot
catch all mutations, obviously, which is why private data goes
further).<br>
<br>
When you say "some data structures", do you mean the Dsymbol
hierarchy?</blockquote>
<br>
No, I mean the Expression one. The Type hierarchy is already copy on
write, and works well.<br>
<br>
<blockquote cite="mid:50A042A8.8030101@wyntrmute.com" type="cite">
That seems to be a pretty major core of the front-end. It would
be great if that were immutable...I see a lot of methods which
could probably be made const (in fact, 90% of the interface could
be made const with no other change, I think).<br>
</blockquote>
<br>
Yes, adding const in would probably be an easy and effective change.
Too bad C++ has no purity :-(<br>
</body>
</html>