tags:

views:

121

answers:

4

So in C++, I'm used to being able to do:

typedef int PeerId;

This allows me to make a type more self-documenting, but additionally also allows me to make PeerId represent a different type at any time without changing all of the code. I could even turn PeerId into a class if I wanted. This kind of extensibility is what I want to have in C#, however I am having trouble figuring out how to create an alias for 'int' in C#.

I think I can use the using statement, but it only has scope in the current file I believe, so that won't work (The alias needs to be accessible between multiple files without being redefined). I also can't derive a class from built-in types (but normally this is what I would do to alias ref-types, such as List or Dictionary). I'm not sure what I can do. Any ideas?

+9  A: 

You need to use the full type name like this:

using DWORD = System.Int32;
ChaosPandion
This solution doesn't handle this part of his question: 'I think I can use the using statement, but it only has scope in the current file I believe, so that won't work (The alias needs to be accessible between multiple files without being redefined)'
BioBuckyBall
+3  A: 

You could (ab)use implicit conversions:

struct PeerId
{
    private int peer;

    public static implicit operator PeerId(int i)
    {
        return new PeerId {peer=i};
    }

    public static implicit operator int(PeerId p)
    {
        return p.peer;
    }
}

This takes the same space as an int, and you can do:

PeerId p = 3;
int i = p;

But I agree you probably don't need this.

Matthew Flaschen
I do this sometimes for slightly more complex value types but I wouldn't do this just to have a name.
ChaosPandion
+4  A: 

Summary

Here's the short answer:

  • Typedefs are actually a variable used by compile-time code generators.
  • C# is being designed to avoid adding code generation language constructs.

Therefore, the concept of typedefs doesn't fit in well with the C# language.

Long Answer

In C++, it makes more sense: C++ started off as a precompiler that spit out C code, which was then compiled. This "code generator" beginning still has effects in modern C++ features (i.e., templates are essentially a Turing-complete language for generating classes and functions at compile time). In this context, a typedef makes sense because it's a way to get the "result" of a compile-time type factory or "algorithm" that "returns" a type.

In this strange meta-language (which few outside of Boost have mastered), a typedef is actually a variable.

What you're describing is less complex, but you're still trying to use the typedef as a variable. In this case, it's used as an input variable. So when other code uses the typedef, it's really not using that type directly. Rather, it's acting as a compile-time code generator, building classes and methods based on typedef'ed input variables. Even if you ignore C++ templates and just look at C typedefs, the effect is the same.

C++ and Generative Programming

C++ was designed to be a multi-paradign language (OO and procedural, but not functional until Boost came out). Interestingly enough, templates have evolved an unexpected paradign: generative programming. (Generative programming was around before C++, but C++ made it popular). Generative programs are actually meta-programs that - when compiled - generate the needed classes and methods, which are in turn compiled into executables.

C# and Generative Programming

Our tools are slowly evolving in the same direction. Of course, reflection emit can be used for "manual" generative programming, but it is quite painful. The way LINQ providers use expression trees is very generative in nature. T4 templates get really close but still fall short. The "compiler as a service" which will hopefully be part of C# vNext appears most promising of all, if it could be combined with some kind of type variable (such as a typedef).

This one piece of the puzzle is still missing: generative programs need some sort of automatic trigger mechanism (in C++, this is handled by implicit template instantiation).

However, it is explicitly not a goal of C# to have any kind of "code generator" in the C# language like C++ templates (probably for the sake of understandability; very few C++ programmers understand C++ templates). This will probably be a niche satisfied by T4 rather than C#.

Conclusion (repeating the Summary)

All of the above is to say this:

  • Typedefs are a variable used by code generators.
  • C# is being designed to avoid adding code generation language constructs.

Therefore, the concept of typedefs doesn't fit in well with the C# language.

Stephen Cleary
Extremely informative response, however it doesn't entail any information I didn't already know, nor does it actually answer my initial question. I was simply mentioning typedefs to give everyone an example of what I'm thinking/expecting. Aliases don't necessarily need to be compile time and can take many forms, such as derivation. If I could do this: "public class PeerId : int {}", that would suffice and solve my problem perfectly.
Bob
+2  A: 

Redefining fundamental types just for the sake of changing the name is C++ think and does not sit well with the more pure Object Orientated C#. Whenever you get the urge to shoehorn a concept from one language into another, you must stop and think whether or not it makes sense and try to stay native to the platform.

The requirement of being able to change the underlying type easily can be satisfied by defining your own value type. Coupled with implicit conversion operators and arithmetic operators, you have the power to define very powerful types. If you are worried about performance for adding layers on top of simple types, don't. 99% chance that it won't, and the 1% chance is that in case it does, it will not the be "low hanging fruit" of performance optimization.

Igor Zevaka