typedef

[Jon Skeet]

Thats a matter of opinion though. I think they improved readability bo
eliminating a bunch commonly used blocks of code.

Commonly used blocks of code should be refactored into methods, not
macros.

 

[Jon Skeet]

Consider if you could derive from value types. Suddenly they wouldn't
have a fixed size - an array declared as:

MyStruct[] x = new MyStruct[100];

couldn't just allocate 100*(size of MyStruct) because it could hold
MyDerivedStruct elements which were larger than MyStruct ones.

Now propagate that problem everywhere else - parameter passing, stack
sizing, etc.

there will be no problem. in c/c++/pascal and most of other languages allow
inheritance of value types. where could there be a problem?

1) a cast from MyStruct[] x to MyDerivedStruct[] x is not allowed
2) when you pass MyDerivedStruct as parameter where MyStruct was expected a
downcast is performed

Ah... right. In that case, I don't see that much advantage. I don't
want data being lost all over the place as that would basically give.

i see no reason why inheritance of structs should not be allowed.

Wheras I've never wanted it and don't see much advantage. Ah well...

 

[Chris LaJoie]

Commonly used blocks of code should be refactored into methods, not

macros.

It takes longer to call a method than it does to do things inline. consider
this

#define DegToRadian( degree ) ((degree) * (PI / 180.0f))

in a graphically intensive game this could be called hundreds of times every
second. would it be practical to put it inside its own method?

Chris

 

[Daniel O'Connell]

It takes longer to call a method than it does to do things inline. consider
this

#define DegToRadian( degree ) ((degree) * (PI / 180.0f))

Such things should be placed in static utility methods, I think. that
#define shouldn't pass between files under standard rules and you'd have to
define it in every file, considering the (thankful) lack of includes.

An attribute or keyword that specifies a given method that is short,
non-virtual, and defined within the same assembly should be inlined by the
compiler instead of letting the JIT decide could be of some use in
alleviating that situation.

However, one would hope the JIT would handle that inlining in most cases
itself, its hard to trust it sometimes.

 

[codymanix]

It takes longer to call a method than it does to do things inline.
consider

this

#define DegToRadian( degree ) ((degree) * (PI / 180.0f))

in a graphically intensive game this could be called hundreds of times every
second. would it be practical to put it inside its own method?

the jitter will inline small, non virtual methods anyway.

 

[Daniel O'Connell]

Such things should be placed in static utility methods, I think. that
#define shouldn't pass between files under standard rules and you'd have to
define it in every file, considering the (thankful) lack of includes.

An attribute or keyword that specifies a given method that is short,
non-virtual, and defined within the same assembly should be inlined by the
compiler instead of letting the JIT decide could be of some use in
alleviating that situation.

However, one would hope the JIT would handle that inlining in most cases
itself, its hard to trust it sometimes.

Or, more valuably, perhaps an attribute that issues an error if a given
method probably will not be inlined because of size, virtuality, or any
other issues, to keep the designer from making serious mistakes that breaks
inlining at any given moment in design.

 

[Jon Skeet]

It takes longer to call a method than it does to do things inline. consider
this

#define DegToRadian( degree ) ((degree) * (PI / 180.0f))

in a graphically intensive game this could be called hundreds of times every
second. would it be practical to put it inside its own method?

Yes, because the JIT compiler would inline it.