sphere* make_sphere( double radius, double x, double y, double z);

void do_something( /* ... */ )

{

// ...

sphere* my_sphere = make_sphere(10,0,0,1);

}

and

class position

{

// ...

public:

position( double x, double y, double z);

//...

};

sphere* make_sphere( position const& p, double radius);

void do_something( /* ... */ )

{

// ...

position center( 0,0,1);

sphere* my_sphere = make_sphere();

}

class nifty_curve_calculator { // ... public: nifty_curve_calculator( double convergence_epsilon, double fitol_desired, ...); //.. };

`nifty_curve_calculator`, exact points on a curve are calculated to

`convergence_epsilon`. The

`nifty_curve_calculator`then concatenates a bunch of exact points on the curve into a bspline fit for the curve. The fitol is the requested distance of the bspline from the exact curve being calculated. The two tolerances mean completely different things, but the compiler will happily accept code which switches the two tolerances. In the case I looked at today, the two parameters were swapped which resulted in code that worked most of the time, but caused a hang with more poorly behaved geometry. We should expect that

`convergence_epsilon`is a lot smaller (10^3 times smaller or more) than the

`fitol_desired`.

`MESH_MANAGERS`) where large objects are stored using arrays of indices into other arrays. If everything has type int (or size_t if that is how you roll), then compiler type checking doesn't help much. Pointers are slightly better for this, but then you get into ownership issues. I really wish you could do typedefs that aren't convertable to each other but have the same operations as integers.

## Comments

## Just an idea how to get type

Just an idea how to get type checking:

enum valueType{NUMERATOR,DENOMINATOR};

template<valueType NAME,class T>

struct strongTypedValue

{

strongTypedValue(T aValue) {mValue = aValue;};

operator T(){return mValue;}

T mValue;

};

typedef strongTypedValue<NUMERATOR,double> numerator;

typedef strongTypedValue<DENOMINATOR,double> denominator;

double Divide(numerator aNumerator,denominator aDenominator)

{

double lResult = aNumerator / aDenominator;

return lResult;

}

numerator lNumerator(12.) ;

denominator lDenominator(34.) ;

double lResult = Divide(lNumerator,lDenominator); // compiles

lResult = Divide(lDenominator,lNumerator); // won't compile

Maybe you like it...

## Thanks. That is a really good

Thanks. That is a really good idea!

As I mentioned in the post, this comes up in meshes a lot, where you have a big array of vertices, and another big array of triangles (where a triangle is a block of three consecutive vertex indices). Code often needs to refer to both triangle and vertex indices in a relatively small space. Something like this trick allows type checking so you can have lots of kinds of "int"s if you need them.

Examining the code, it looks like (1) there is no run time penalty for doing this as long as you have a decent compiler, and (2) you could use "int"s rather than the enums for the value types if you don't know before hand how many different types of integers you will need. Maybe some sort of template/macro scheme could be used for incrementing valueType field.

best regards

Eric Zenk

## A couple of added ramblings:

A couple of added ramblings: I made the constructor explicit so you cannot accidentally convert a raw type into strong type. I also ended up making the data member private and added get/set methods for it. The whole point of the added type safety is to prevent me from accidentally converting things that aren't the same.

I should mention I have already used this in some prototype code this week and it seems to work really well.

thanks again. It's a great idea.

Eric

## I was curious if you ever

I was curious if you ever thought of changing the

structure of your site? Its very well written; I love

what youve got to say. But maybe you could a little more in the way of content so people could

connect with it better. Youve got an awful lot of text for only having one or two pictures.

Maybe you could space it out better?

## Thanks for the input, we will

Thanks for the input, we will definitely take it into consideration.

## See comments