Re: [Cpptool-develop] welcome back

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, April 23, 2003 5:50 PM
Subject: Re: [Cpptool-develop] welcome back


> On Wed, 23 Apr 2003, Baptiste Lepilleur wrote:
> > ...
> >
> > By the way Sven, would you mind changing your editor settings from
'insert
> > tabs' to 'insert spaces' ? This would allow the code to be correctly
> > indented without regards to the editor settings.
>
> Hmmm... usually emacs inserts spaces. The only issue that I can think of
> is that when adding a statement, it uses the indentation space found in
> the previous statement. Where there tabs in all the code I added?

Hum, tabs length was around 8 if I remember. It may be an optimization
applied when saving the file.

> I still need to remember to change the indentation space; right now emacs
> uses 2 spaces, where as in most of the code, 3 spaces are used, if I'm not
> mistaken.

Yes, the tabs were presents only on the new code (checked by enable view
whitespace in VC).

> > Don't ever do that. stdafx.h is an optimization only (I made some
benchmark
> > a while ago with an old project and it saved about 5 seconds out of 35
> > seconds for a complete build). The project should compile correctly fine
if
> > stdafx.h is a blank file. Only widely used STL headers should go there.
If
> > it does not compile on Unix, then it is a bug, and the missing STL
include
> > should be added.
>
> Ok. BTW, your timing is impressive. gcc is way slower. Just tested, it
> uses 7 min for a complete rebuild (with tests, but without eclipse and VC
> plugins) :( But then, I have a slow computer.

Timing was refering to an old project. Rfta in debug configuration
(including cppunit, the dllplugintester and all the unit tests ) takes about
1mn30s on my PC (P4 2.4Ghz). Amazingly the release configuration takes a
similar time (even though unit test are not compiled, but that the time cost
for optimization). For notes, pyrfta (basic python binding using
Boost.Python which use the MPL) takes 1mn20s. That the cost of 'template to
death' ;-(

> [...]
> > If so, we may want to introduce a asssertion facilities (throw exception
in
> > standard mode, break in 'advanced debug mode').
>
> Is it correct that during normal execution of the code, no exceptions are
> thrown? Then I could just switch off support for exceptions. However, I
> think that at least CppUnit relies heavily on them.

No, this is incorrect. A major exception may be thrown during the normal
execution: There is some exception that may be thrown during normal
execution: it's ParserError, thrown when parsing fail. This occurs for
example when a badly formed (or unsupported) source is provided. This is
part of the 'normal' path.

Some others libraries also rely on exception to report error
(Boost.FileSystem, converting a weak_ptr to a shared_ptr if the pointed
object has been destroyed...). Also, I think the default new handler throw
an exception if no memory is available.

> > Check out the boost documentation in boost/libs/smart_ptr. You'll find
the
> > few functions to deal with smart-pointer (cast...), as well as a new
page
> > explaining the many use of shared_ptr.
> >
> > > The other point is that I understand the use of shared pointers if we
have
> > > several pointers to the same object, and it is not clear which one
will
> > > survive longer. IMO this is not the case when dealing with a visitor;
the
> > > host calls a method of the visitor in its accept method, and the host
> > > certainly exists during the execution of the method. Thus an ordinary
> > > pointer is sufficient in this case; since it is simpler to manage (and
> > > more efficient) it should be preferred.
> > > Please let me know if I'm missing a good reason why to use shared
pointers
> > > here.
> >
> > Yes there is. This allow you to collect code element while visiting and
> > reuse them when transforming the code. Main use though would probably be
to
> > move statements and declarations around.
>
> I still need to get used to the idea of a visitor modifying the structure
> (not only the content) of the object it is visiting.

I was more thinking of the visitor collecting the interesting element.
Change being made to the structure after it was visited.

Baptiste.

>
> Later,
> Sven.
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...