Thread: C++/CLI oddities

I just got a C++/CLI book a couple days ago, and so far there are a few things that confuse me (the first four aren't really important, just confusing MS decisions).

1. First of all, why is there both an enum struct and an enum class if they're both the same.

2. Why did MS remove default arguments for ref classes?

3. Why do ref classes not support friends?

4. Why is there no private or protected inheritance for ref classes? (Not such a big deal as, in my experience, it is rarely used; but still...)

5. My book says value classes are created directly on the stack, but what if you did something like this:

Code:

value class Foo
{
//...
}
int main()
{
  Foo^ bar = gcnew Foo;
}

This compiles, but is it created on the managed heap? The book only says, "...when a new instance of the data type is created, it is allocated either to the stack or CRT heap."

6. What is the difference between the two different ways of operator overloading in C++/CLI? There is the traditional (or close to) ISO C++ way, as well as static operators; e.g.,

Code:

//(almost) ISO C++
Foo% operator++(int) //also works with Foo& return, but only for value types
{
}
//C++/CLI new syntax
static Foo^ operator++(const Foo^ lhs)
{
}

If I use the latter version, it only works with handles (^) and if I define both, then only the former is called.

I could go on with some complaints and design rationale questions, but I'll leave it at that for now

Most of your questions seem to revolve around the managed constructs. First you have to consider .NET. .NET was designed with other languages in mind. The managed parts of C++/CLI are simply the parts that connect to .NET and potentially other languages. The reason they work different than standard C++ is that they are .NET constructs, not C++ constructs. You still have standard classes to work with when you want those features, and in most cases you can simply wrap the managed stuff if you don't like it. But C++/CLI MUST support both in order to be a .NET programming language.

Originally Posted by JaWiB

I just got a C++/CLI book a couple days ago, and so far there are a few things that confuse me (the first four aren't really important, just confusing MS decisions).

That's why I'll always consider C++/CLI a glue language and stick with C# for real .Net development.

1. First of all, why is there both an enum struct and an enum class if they're both the same.

Probably to keep the struct/class parallel from C++, or something like that.

2. Why did MS remove default arguments for ref classes?

.Net only supports overloading, but not default arguments. It is easy to emulate default arguments using overloading, but MS apparently decided not to secretly generate functions.

3. Why do ref classes not support friends?

.Net doesn't support the concept of friends. It uses internal visibility for similar purposes.

4. Why is there no private or protected inheritance for ref classes? (Not such a big deal as, in my experience, it is rarely used; but still...)

.Net only supports public inheritance.

5. My book says value classes are created directly on the stack, but what if you did something like this:

Code:

  Foo^ bar = gcnew Foo;

This compiles, but is it created on the managed heap? The book only says, "...when a new instance of the data type is created, it is allocated either to the stack or CRT heap."

You create a boxed object, i.e. a small managed wrapper containing the value class.

6. What is the difference between the two different ways of operator overloading in C++/CLI? There is the traditional (or close to) ISO C++ way, as well as static operators;

One is basically inherited from C++, the other is probably the .Net way of doing things. (Check C# to see how operators are overloaded there. I believe they're static members, mostly.)

Ok, so basically everything I dislike about C++/CLI is what MS changed from C++ to be compatible with other .NET languages. That makes sense

What I'm getting from that is that you hate .NET. How would you go about providing .NET support to a more standardized C++ then?

> How would you go about providing .NET support to a more standardized C++ then?

Change .NET, not C++ (only joking, of course)

I don't hate .NET, I just dislike how everything in C++/CLI is so similar to C++, but somehow maddeningly different. I guess I'll just get used to it