No typedef and no Include. . .

r2d2-proton

Are these VBA programmers writing the .Net framework and languages

Many of you probably already know this, as I'm arriving late to the party.

I wanted to use the typedef equivalent but apparently not in C#. Then of course I thought I'd try the #include -- maybe so, if I wanted comments (I gather).

The end result:

Common.cs

using System;

namespace <yoursHere>
{
using ID = System.Int32;

public class objID
{
private ID itsID;

public objID( ID theID )
{
itsID = theID;
}

public ID ID
{
get { return itsID; }
set { itsID = value; }
}
}
}

Did I miss something

Jim Perry

r2d2-proton wrote:

Did I miss something

Depends on what you were trying to accomplish.

r2d2-proton

typedef UINT classID;

class AClass
{
classID itsID;
}

Shawn Hargreaves - MSFT

Why not just:

class AClass
{
public uint itsID;
}

The reasons why you need typedef in C generally don't apply in .NET languages, so you might as well just use the type you want directly rather than trying to set up an alias for it.

r2d2-proton

class AClass
{
private int32 itsID;

public int32 ID
{
get { return itsID; }
set { itsID = value; }
}
}

class AListClass : List<AClass>
{
Add(..)
Remove(...)

AClass Get( int32 theID )
{
:
:
}
}

// somewhere over the rainbow. . .

int32 tmpID = 7;

AClass theClass = theListClass.Get( tmpID );

Obviously this is a narrow example. But it sure would be nice to define a type for "itsID" other than via an intrinsic type.

I guess I could use an enum from 1 to infinity (and beyond!).

dczraptor

I don't see what you would gain from creating an alias for an int. I would just name your variables properly to avoid readability issues.

Bjoern Graf

If you only want to allow positive intergers (and zero) - as the typedef UINT classID suggests - why not use uint (AKA System.UInt32)

r2d2-proton

LOL

I appreciate the comments, they were fun to read.

Johnnylightbulb

The SortedList<T, K> generic class seems like the best thing for this, you wouldn't even need AListClass unless additional logic was added.

int tmpID = 7;

SortedList<int, AClass> myList = new SortedList<int, AClass>();

myList.Add(tmpID, new AClass());

..then..

AClass theClass = myList[tmpID];

Jon Watte

I don't see what you would gain from creating an alias for an int.

It is actually useful. For example, assume that you marshal these IDs to a network packet using type reflection. Inside the code, the "ID" type of objects might be initially started out as an uint. However, after the program is done, you realize that you only have 45 different IDs, and thus you want to change all the code that deals with an "ID" to use bytes, such that they will save 3 bytes on the wire each time they are marshalled.

Trying to sort out which "uint" are used for ID, an which are used for other semantics, after the fact, is pretty hard. Being able to pre-declare semantics is quite useful, and often makes for more readable code.

#include is not needed, because the language and build system will magically find references between source files within the same assembly, and will find references to other assemblies if you add those assemblies as references (thus, references are the moral equivalent of both an #include and a library add for the linker).

r2d2-proton

I only mentioned the #include because I didn't want to repeat the below statement (and the others I had planned to use) in every file that needed them:

using objID = System.Int32;

Now I have a Common.cs file with the format stated above. I'm not sure if that's the best way or not, but I'll use it until something better is offered.