basically there is 'struct' in C++ for compatibility to C.

the *only* difference is that in a struct all members are public by default, and in a class the members are private, by default.

as for your questions:
1) no
2) yes
3) none

you can write classes that are PODs (see wikipedia on 'plain old datatype). and as a rule of thumb, in C++ you only pay for what you use.

In C++ the only difference between a class
and a struct is that it's members are private
by default in a class and public by default
in a struct.

I don't know about C# though, not got around
to play with that one yet.

Given the above replies, Liort, what language are you using?

For the C# in you...

As has been stated, structs are value types, which means that at compile time, a new copy is created and the new copy is returned from or passed to functions that you may call. Structs may still however be cast to an object, which would make them a reference type for that instance.

Classes are always reference types, which mean there is one copy of each instance and they are passed and returned as reference values always.

The other key things to remember have also been stated already: structs be default are public, have public inheritance, and have public members, and classes by default are private and have private members.

For example:

struct Shape{    int _id;    Shape(int id)    {        _id = id;    }}

In this struct _id and Shape(int id) are both public as well as the struct. Now for the class:

class Shape{    int _id;    Shape(int id)    {        _id = id;    }}

In this case the class, constructor, and _id field are all private, unless you declare them as public.

1. (Answer) C# is built on classes, though you may find instances when a struct is good to use. The ideal container for C# though is the class. Use classes in C#.

2. (Answer) Obviously you can inherit from a struct, it is not so different from the C++ struct.

3. (Answer) There is no performance difference between the two. The Microsoft .NET framework, Common Language Interface, and Just In Time compiler set takes care of all managed (.NET) code and uses pattern matching to create the most optimal compilation at compile time, then when you run it, it does some more optimizations for you. Now if you choose to make your code unmanaged, then you're left to your ability to program well, but I wouldn't advise going in that direction unless you have a very good reason to do so. Let Microsoft .NET be your friend.

Quote:
As has been stated, structs are value types, which means that at compile time,

It's not really at compile time, the actual copying occurs at runtime.

Quote:
Structs may still however be cast to an object, which would make them a reference type for that instance.

Yes, and for further clarification this process is known as "boxing" the value type. The inverse process is called "unboxing." Technically it does not make the struct a reference type at all, it places the value of the struct in a reference type, giving an instance the semblance of referential behavior. It is misleading to imply the fundamental type changes, as that is never possible.

Quote:
The other key things to remember have also been stated already: structs be default are public, have public inheritance, and have public members, and classes by default are private and have private members.

This is not the case in C#, it applies only to C++. In C#, any aggregate member without an access specifier is private. There is furthermore no concept of access-qualified inheritance in C#. This renders your following example irrelevant to C#.

As for the OP (in C#):

Quote:
1. Is struct better off being used than class?

It's never better to use struct or class in C# in general. Both are equally useful and have their appropriate contexts; the nature of your intended uses of the object matters in determining if it should be a struct or a class. Typically size is considered as well (since copying a value type involves the copy of all members, there can be a performance consideration there).

Your first focus should be semantics, however. If you intend to pass this object around and modify its state, and have that state reflected elsewhere (e.g., referential semantics), you will likely want to use a class.

Quote:
2. Can i inherit from a struct like i do with classes?

Structs, in C#, are implicitly sealed -- that is, they cannot be derived from. Additionally, they cannot be derived from another type (there are special case exception for type machinery required to support the CLR; you should not in general concern yourself with these). However, they are permitted to implement interfaces.

Quote:
3. Performance wise what are the benefits?

Structs incur a cost when they are copied; that cost is proportional to the size of the struct. Structs, however, exist on the stack unless they are boxed or a reference type member, and as a result do not place (as much) pressure on the garbage collector. Classes, as reference types, are cheaper to copy but must be garbage collected.

In general, the performance considerations are not worth worrying until you have identifier a particular class or struct as a potential performance bottleneck. Their performance characteristics are not necessarily black and white.

And finally, to clarify some points the previous poster raised:

Quote:
1. (Answer) C# is built on classes, though you may find instances when a struct is good to use. The ideal container for C# though is the class. Use classes in C#.

2. (Answer) Obviously you can inherit from a struct, it is not so different from the C++ struct.

3. (Answer) There is no performance difference between the two. The Microsoft .NET framework, Common Language Interface, and Just In Time compiler set takes care of all managed (.NET) code and uses pattern matching to create the most optimal compilation at compile time, then when you run it, it does some more optimizations for you. Now if you choose to make your code unmanaged, then you're left to your ability to program well, but I wouldn't advise going in that direction unless you have a very good reason to do so. Let Microsoft .NET be your friend.

For (1) I would say to prefer classes. For (2) you are wrong as far as C# goes, see above. For (3) you are misguided; there are clear performance implications between class and struct in C#, they are just not simple. The CLR is not permitted to change the fundamental type (class or struct) of a type at all.

The recommended way to code in C++ is to favor value semantics.
The recommended way to code in C# is to favor reference semantics.

Both languages can do both. Java can only do the later.

I personally prefer value semantics, since it is deterministic, doesn't require a GC, doesn't cause annoying side-effects, etc.
Just be careful not to copy your objects when it's not needed.