On Fri, Dec 25, 2009 at 11:33 AM, Brandon Olivares wrote:

On 2009-12-25, OvermindDL1 wrote:

...

 As for dynamically creating types, you can do that all you wish, but you have no type information then (unless you use variant or any or something, but that has needless overhead, well, maybe not variant). That is the point of Boost.Units, to enforce that you are doing things correctly, at compile time, it optimizes completely out at run-time.

OK thanks, perhaps you are right. I'm just really trying to figure out a way to make compilation a bit faster. My concern is that since these are in header files, well any source file that needs units will require them all to be processed again, and that is really inconvenient.

Yep, that is the major hazard of C++. If you learn how to structure things differently and use forward declarations and less class member functions (use external functions instead, ala C), that can speed up compilation tremendously.

On Fri, Dec 25, 2009 at 6:30 PM, Brandon Olivares wrote:

On 2009-12-25, OvermindDL1 wrote:

...

Yep, that is the major hazard of C++.  If you learn how to structure things differently and use forward declarations and less class member functions (use external functions instead, ala C), that can speed up compilation tremendously.

Ah, but you can, depends on how you can abstract your system. Think of how C works with void pointers and such and you can start to see patterns for your classes. Think of this. Say you have a class like this in your header: class myStuff { private: someSuperHeavyTemplate<int> mySpecialInt; /* other member vars */ public: void operateOnMySpecialInt(int i); int getSpecialInt(void); /* other member functions */ } And the implementation is in a cpp file, but now everything that uses this has to include all the nasty and slow instancing for the someSuperHeavyTemplate<int> type. Now think of this in a C way... class myStuff; void operateOnMySpecialInt(myStuff &m, int i); int getSpecialInt(myStuff &m); /* other functions that operate on myStuff */ And the implementation contains the implementation of myStuff and the function definitions. Only that cpp file includes the heavy template instancing, and all other accesses are fast. You can only do this on classes/struct that you normally use as pointers in the first place, but if you can then you can see how you can vastly simplify access to only what is needed in the public interface, rather then *everything* that is in the interface. On Fri, Dec 25, 2009 at 6:30 PM, Brandon Olivares wrote:

Well yeah, that's the problem. The units are all typedefs and constants so, AFAIK, you can't use forward declarations.

True, but how much of your code *needs* all of them, only include those in the cpp by cpp basis, rather then in all headers everywhere. On Fri, Dec 25, 2009 at 6:30 PM, Brandon Olivares wrote:

I'm hoping to perhaps do something similar to the runtime_unit.cpp example. I can declare all of the base units, so to speak, and then hopefully scale them as necessary.

I mostly want to be able to apply any of the SI prefixes to the metric units. Again though if I declare them explicitly, it takes forever to compile.

Still though, upgrade to GCC4.4+ and you will see a dramatic bettering of compile speed, generally 30% at minimum with heavy template code.

On Fri, Dec 25, 2009 at 7:25 PM, Ray Burkholder wrote:

I think this falls under the PIMPL idiom, which is described by Herb Sutter at:

http://www.gotw.ca/publications/mill04.htm http://www.gotw.ca/publications/mill05.htm

with more generically useful articles at:

http://www.gotw.ca/publications/index.htm

Not generally. I am not really a proponent of Pimpl. The C style gives you complete abstraction, not even any overhead of the Pimpl, and anything is visible only through functions. As much as many idiots like to say, the C++ OO style is *not* OO. In C++, lets take this class: class anotherClass; class myStuff { private; int i; float f; std::string s; public: void doOperation(anotherClass *c); } Now, that can let you do things like: anotherClass *a = fromSomewhere(); myStuff *m = fromSomeplace(); m->doOperation(a); Now this is no where near real OO as it was originally described. Of all programming languages, CLOS gets the closest to real OO, and in pseudo-C++ that would be more like: class anotherClass; class myStuff { int i; float f; std::string s; } void doOperation(anotherClass *c); Hence you could do things like this still: anotherClass *a = fromSomewhere(); myStuff *m = fromSomeplace(); m->doOperation(a); Although, doOperation(m,a) might be better if the function were defined as: void doOperation(myStuff *m, anotherClass *c); However, if both myStuff and anotherClass are virtual and can have different base classes, you can still only switch based on the first. Continuing in a pseudo-C++, what if: class base1 {}; class base2 {}; class child1a : virtual base1 {}; class child1b : virtual base1 {}; class child2a : virtual base2 {}; class child2b : virtual base2 {}; void doOperation(virtual base1 *b1, virtual base2 *b2, int i); // base overload void doOperation(virtual child1a *c1a, virtual child2a *c2a, int i); // overload 1 void doOperation(virtual child1b *c1b, virtual child2a *c2a, int i); // overload 2 void doVB1(virtual base1 *b1, base2 *b2); // overload first void doVB1(virtual child1a *c1a, child2a *c2a); // overload second // Now we have some filled pointers base1 *b1 = get_b1(); base2 *b2 = get_b2(); child1a *c1a = get_c1a(); child1b *c1b = get_c1b(); child2a *c2a = get_c2a(); child2b *c2b = get_c2b(); base1 *t1; base2 *t2; // Now to use it t1=b1;t2=b2; doOperation(t1,t2,0); // calls base overload t1=c1a;t2=b2; doOperation(t1,t2,0); // calls base overload t1=c1a;t2=c2a; doOperation(t1,t2,0); // calls overload 1 t1=c1a;t2=c2b; doOperation(t1,t2,0); // calls base overload t1=c1b;t2=c2a; doOperation(t1,t2,0); // calls overload 2 t1=c1b;t2=c2b; doOperation(t1,t2,0); // calls base overload t1=c1a;t2=c2a; doVB1(t1,t2); // calls overload first doVB1(t1,c2a); // calls overload second, because it needs to be explicit due to no 'virtual' And so forth, and of course it can be extended to more then 2 virtuals as well. If you notice, the virtual tables are built per call site based on what doOperation's are visible at that point. If there is a doOperation that defines it for child1b* and child2b*, it would not be in this overload resolution table because it is not visible. For conflicting overloads, like this: // a diamond inheritance: class child1ab : virtual child1a, virtual child1b {}; void doOperation1(virtual base1 *b1a, virtual base1 *b1b, int i); // overload base void doOperation1(virtual child1a *c1a, virtual child1b *c1b, int i); // overload A void doOperation1(virtual child1b *c1b, virtual child1a *c1a, int i); // overload B You can either do something like just throw an exception due to ambiguity if called with this: t1 = t2 = new child1ab; doOperation1(t1,t2,0); Or you can also (and this is what is more commonly done) use the most complete and unambiguous overload, which in this case would be the overload base. Although you would probably want to issue a warning at compile time since you have the nice safety of the C++ type system unlike in CLOS regardless of what you choose. The nice thing about this style, your class definitions can be pretty completely forward declared (change the syntax for a forward declaration can take an inheritance list, you do not need to generate a size for it since we are only using pointers, but the inheritance list would be all we would need for virtual type resolution. C++ was poorly designed with regards to classes in the first place, if it went this way we would have more power, faster compile times, etc...

On Fri, Dec 25, 2009 at 8:43 PM, Emil Dotchevski wrote:

On Fri, Dec 25, 2009 at 6:25 PM, Ray Burkholder wrote:

...

I think this falls under the PIMPL idiom, which is described by Herb Sutter at:

http://www.gotw.ca/publications/mill04.htm http://www.gotw.ca/publications/mill05.htm

Quite frankly, I don't see much point in using the PIMPL idiom. I'd much rather use:

struct widget; shared_ptr<widget> make_widget(); void frobnicate( widget & );

Exactly! Ditto. Just what my last post said. It is a very "C" style rather then C++, but its compiling speed enhancements are very nice.

On Fri, Dec 25, 2009 at 10:49 PM, Brandon Olivares wrote:

On 2009-12-25, OvermindDL1 wrote:

...

On Fri, Dec 25, 2009 at 11:33 AM, Brandon Olivares wrote:

...

...

 As for dynamically creating types, you can do that all you wish, but you have no type information then (unless you use variant or any or something, but that has needless overhead, well, maybe not variant). That is the point of Boost.Units, to enforce that you are doing things correctly, at compile time, it optimizes completely out at run-time.  OK thanks, perhaps you are right. I'm just really trying to figure out a way to make compilation a bit faster. My concern is that since these are in header files, well any source file that needs units will require

On 2009-12-25, OvermindDL1 wrote: them all to be processed again, and that is really inconvenient.

Yep, that is the major hazard of C++.  If you learn how to structure things differently and use forward declarations and less class member functions (use external functions instead, ala C), that can speed up compilation tremendously.

OK, well perhaps there's another method. The primary bulk of the units I was defining were velocities. I just realized though that you can do l/t though, where l is some length and t is some time, and it doesn't have to define an existing unit.

But if I do that, I'm not sure what type to actually define the variable as.

sometype v = l/t;

What is the type in this case?

So for instance if l is light_year and t is hour, just as an example, I don't want to have to define light_year_per_hour as I was before. It's obvious that this is allowed:

quantityastronomical::light_year_unit l(3.0 * astronomical::light_years); quantitymetric::hour_unit t(8.0 * metric::hours); quantity v(l/t);

You could just auto it. :) BOOST_AUTO(v, l/t); Then you do not need to bother figuring out what type it is, although it is your light_year_per_hour, although maybe a little more efficient representation. If you just want the type of an expression like l/t if you want to typedef it or something, then you can use BOOST_TYPEOF. It is all in the documentation. :)

On Sat, Dec 26, 2009 at 12:16 AM, Brandon Olivares wrote:

On 2009-12-26, OvermindDL1 wrote:

...

You could just auto it.  :)   BOOST_AUTO(v, l/t); Then you do not need to bother figuring out what type it is, although it is your light_year_per_hour, although maybe a little more efficient representation.

If you just want the type of an expression like l/t if you want to typedef it or something, then you can use BOOST_TYPEOF.  It is all in the documentation.  :) _______________________________________________

Oh that's perfect; that has solved my problem! Thank you very much, and it only took 5 seconds to compile.

Yeah, I guess I should have thought of that earlier. I use BOOST_AUTO and BOOST_TYPEOF rather often actually since it can cut down on template instancing pretty dramatically in some libraries.