Two style questions

Hi,

First, clang didn't seems to use any smart_ptr. Is it by design?
I would like to use a scoped_ptr (for class member or local variable), what
should I do:
- do the freeing manually in the destructor or at the end of the function
(error prone and not maintenable)
- use std::auto_ptr
- use an home made scoped_ptr
- use boost::scoped_ptr (I know you don't want to create dependency on
boost, for simplicity of compilation, but we could extract the few class
needed)

Second, in a few place, typedef of void are used as opaque type (for
reducing dependency or allowing various concrete type depending on the
implementation) and I was wondering why not use empty struct instead:

typedef void ExprTy; => struct ExprTy {};

I can see than a void* is easier to cast (static_cast instead of
reinterpret_cast) but the concrete type could derive from the empty struct
achieving the same without cost (thanks to empty base class optimization).
This would allow stronger type checking and less bug, or is there any reason
I didn't see?

In particular, I don't see why BuilderTy in ModuleBuilder.h is declared as
an opaque type since it represente a CodeGenModule and could simply use a
forward declared class no?

typedef void BuilderTy;

=>

Class CodeGenModule;
typedef CodeGenModule BuilderTy;

Regards,

Cédric

Is there really an aversion to all things Boost here?

Some things are often obviously better done with it. For example, see the boost operator header:

http://www.boost.org/libs/utility/operators.htm

It's pretty tame as boost headers go: It's short and it doesn't depend on the MPL (or anything as mind-bending). And if you're going to write an operator function, it seems like you should at least explain to yourself why you think your approach is better.

James Widman

I know you don't want to create dependency on boost [...]

Is there really an aversion to all things Boost here?

No.

There is only an aversion to:

1) importing all of boost into the repo
2) requiring users to get boost before building the project.

I have no problem with sucking in code from boost where useful. To me, the biggest problem with boost is that it has a lot of hacks and build machinery to make it work on multiple compilers. This machinery has caused problems for llvm in the past (when we tried to import a subset of boost into the llvm project).

However, I have no problem sucking in pieces of boost that are not hugely compiler-specific and just incorporating it directly into the llvm namespace or leaving it in the boost namespace. The license of boost is designed exactly for this, and we have done it with several small helper classes in the past.

Some things are often obviously better done with it. For example,
see the boost operator header:

Chapter 1. Boost.Utility - 1.80.0

It's pretty tame as boost headers go: It's short and it doesn't
depend on the MPL (or anything as mind-bending). And if you're going
to write an operator function, it seems like you should at least
explain to yourself why you think your approach is better.

Sure, if it's just a header, and it was useful, I would have no problem with just importing the header.

-Chris