CONST ???

[Russ]

I just ran into something that absolutely blows my mind! Consider the
following:

class Class1 {
public:

void SetHours (const double& h) { Hours = h; }

double Hours;
};

public __gc class Class2 {
public:

double Hours;
};

Now, in C++ Managed extensions do this:

Class1 c1;
Class2 c2;

c1.Hours = c2.hours; // Works fine
c1.SetHours (c2.Hours); // Fails

The error is "C2664: 'Class1::SetHours' : cannot convert parameter 1
from 'double' to 'const double &'".

Say What!!??!!

Somewhere it says this is because c2.Hours is a managed type. Why
should that matter? This breaks the whole const mechanism. In the
case above I can get around it by using the direct copy (c1.Hours =
c2.hours), but suppose the members of Class1 were protected or
private? The whole reason for using const is to tell the compiler
that it cannot modify the input value. Why in the world would
Microsoft want to break this mechanism????

To get around this I must modify all the access member functions of my
unmanaged DLL to not use const? Or create a whole bunch of
intermediate variables and do a double copy? It does not make any
sense. Why doesn't the compiler handle that job automatically?

Russ

[Russ]

Oops. never mind. Just realized that I posted this in the wrong group.
I will repost elsewhere.

Russ

On Wed, 07 Jul 2004 16:07:48 -0400, Russ <ru****@eticomm.net> wrote:

I just ran into something that absolutely blows my mind! Consider the
following:

class Class1 {
public:

void SetHours (const double& h) { Hours = h; }

double Hours;
};

public __gc class Class2 {
public:

double Hours;
};

Now, in C++ Managed extensions do this:

Class1 c1;
Class2 c2;

c1.Hours = c2.hours; // Works fine
c1.SetHours (c2.Hours); // Fails

The error is "C2664: 'Class1::SetHours' : cannot convert parameter 1
from 'double' to 'const double &'".

Say What!!??!!

Somewhere it says this is because c2.Hours is a managed type. Why
should that matter? This breaks the whole const mechanism. In the
case above I can get around it by using the direct copy (c1.Hours =
c2.hours), but suppose the members of Class1 were protected or
private? The whole reason for using const is to tell the compiler
that it cannot modify the input value. Why in the world would
Microsoft want to break this mechanism????

To get around this I must modify all the access member functions of my
unmanaged DLL to not use const? Or create a whole bunch of
intermediate variables and do a double copy? It does not make any
sense. Why doesn't the compiler handle that job automatically?

Russ

[TT \(Tom Tempelaere\)]

"Russ" <ru****@eticomm.net> wrote in message
news:jr********************************@4ax.com...

I just ran into something that absolutely blows my mind! Consider the
following:

class Class1 {
public:

void SetHours (const double& h) { Hours = h; }

double Hours;
};

public __gc class Class2 {
public:

double Hours;
};

Now, in C++ Managed extensions do this:

Class1 c1;
Class2 c2;

c1.Hours = c2.hours; // Works fine
c1.SetHours (c2.Hours); // Fails

The error is "C2664: 'Class1::SetHours' : cannot convert parameter 1
from 'double' to 'const double &'".

Say What!!??!!

Somewhere it says this is because c2.Hours is a managed type. Why
should that matter? This breaks the whole const mechanism. In the
case above I can get around it by using the direct copy (c1.Hours =
c2.hours), but suppose the members of Class1 were protected or
private? The whole reason for using const is to tell the compiler
that it cannot modify the input value. Why in the world would
Microsoft want to break this mechanism????

To get around this I must modify all the access member functions of my
unmanaged DLL to not use const? Or create a whole bunch of
intermediate variables and do a double copy? It does not make any
sense. Why doesn't the compiler handle that job automatically?

I'm not a managed c++ writer, but I'd say that C++-references and C# objects
don't mix (I mean to say that C++ references won't bind to a garabage
collected class or member of it) because of garbage collection.

Cheers,
---
Tom Tempelaere

[TT \(Tom Tempelaere\)]

"TT (Tom Tempelaere)" <_/\/_0§P@|/\|titi____AThotmail.com|/\|@P§0_/\/_>
wrote in message news:7u**********************@phobos.telenet-ops.be...

"Russ" <ru****@eticomm.net> wrote in message
news:jr********************************@4ax.com...

I just ran into something that absolutely blows my mind! Consider the
following:

class Class1 {
public:

void SetHours (const double& h) { Hours = h; }

double Hours;
};

public __gc class Class2 {
public:

double Hours;
};

Now, in C++ Managed extensions do this:

Class1 c1;
Class2 c2;

c1.Hours = c2.hours; // Works fine
c1.SetHours (c2.Hours); // Fails

The error is "C2664: 'Class1::SetHours' : cannot convert parameter 1
from 'double' to 'const double &'".

Say What!!??!!

Somewhere it says this is because c2.Hours is a managed type. Why
should that matter? This breaks the whole const mechanism. In the
case above I can get around it by using the direct copy (c1.Hours =
c2.hours), but suppose the members of Class1 were protected or
private? The whole reason for using const is to tell the compiler
that it cannot modify the input value. Why in the world would
Microsoft want to break this mechanism????

To get around this I must modify all the access member functions of my
unmanaged DLL to not use const? Or create a whole bunch of
intermediate variables and do a double copy? It does not make any
sense. Why doesn't the compiler handle that job automatically?
I'm not a managed c++ writer, but I'd say that C++-references and C#

objects don't mix (I mean to say that C++ references won't bind to a garabage
collected class or member of it) because of garbage collection.

Perhaps this would be possible in an unsafe code section, or if you pin the
object before binding the reference. But again, I'm not a managed C++-writer
so you'll have to double check me on this.

Cheers,
---
Tom Tempelaere

[Russ]

Tom, thanks for your comments. I appreciate it because I got no
response at all in the framework NG.

The thing is, that the access function:

void SetHours (const double& h) { Hours = h; }

is an inline function, meaning that in a release mode compile it
resolves to a direct assignment. So "c1.SetHours (c2.Hours);" becomes
"C1.Hours = C2.Hours". Notice that this is exactly the code that DOES
work. So it seems like an artifical rejection.

Also, even if it was not an inline function the compiler could simply
create a temporary unmanaged local variable, making it equivalent to:

double temp = C2.Hours;
C1.SetHours (temp);

Of course I can do that too, but that should be the job of the
compiler.

Thanks again, Russ
On Wed, 07 Jul 2004 22:09:36 GMT, "TT \(Tom Tempelaere\)"
<_/\/_0§P@|/\|titi____AThotmail.com|/\|@P§0_/\/_> wrote:

"TT (Tom Tempelaere)" <_/\/_0§P@|/\|titi____AThotmail.com|/\|@P§0_/\/_>
wrote in message news:7u**********************@phobos.telenet-ops.be...

"Russ" <ru****@eticomm.net> wrote in message
news:jr********************************@4ax.com...

> I just ran into something that absolutely blows my mind! Consider the
> following:
>
> class Class1 {
> public:
>
> void SetHours (const double& h) { Hours = h; }
>
> double Hours;
> };
>
> public __gc class Class2 {
> public:
>
> double Hours;
> };
>
> Now, in C++ Managed extensions do this:
>
> Class1 c1;
> Class2 c2;
>
> c1.Hours = c2.hours; // Works fine
> c1.SetHours (c2.Hours); // Fails
>
> The error is "C2664: 'Class1::SetHours' : cannot convert parameter 1
> from 'double' to 'const double &'".
>
> Say What!!??!!
>
> Somewhere it says this is because c2.Hours is a managed type. Why
> should that matter? This breaks the whole const mechanism. In the
> case above I can get around it by using the direct copy (c1.Hours =
> c2.hours), but suppose the members of Class1 were protected or
> private? The whole reason for using const is to tell the compiler
> that it cannot modify the input value. Why in the world would
> Microsoft want to break this mechanism????
>
> To get around this I must modify all the access member functions of my
> unmanaged DLL to not use const? Or create a whole bunch of
> intermediate variables and do a double copy? It does not make any
> sense. Why doesn't the compiler handle that job automatically?

I'm not a managed c++ writer, but I'd say that C++-references and C#

objects

don't mix (I mean to say that C++ references won't bind to a garabage
collected class or member of it) because of garbage collection.

Perhaps this would be possible in an unsafe code section, or if you pin the
object before binding the reference. But again, I'm not a managed C++-writer
so you'll have to double check me on this.

Cheers,
---
Tom Tempelaere

[TT \(Tom Tempelaere\)]

"Russ" <ru****@eticomm.net> wrote in message
news:q3********************************@4ax.com...

Tom, thanks for your comments. I appreciate it because I got no
response at all in the framework NG.
That would not be the group to ask. You should try

microsoft.public.dotnet.languages.vc

for managed C++.
The thing is, that the access function:

void SetHours (const double& h) { Hours = h; }

is an inline function, meaning that in a release mode compile it
resolves to a direct assignment. So "c1.SetHours (c2.Hours);" becomes
That is not an issue. The C++ language specs need to be in effect, otherwise
it wouldn't be C++ anymore. So inlining should have the same observable
behaviour (C++ rules) and in this case that is not the case. I think that
this is the issue here, although I'm neither a C++ language nor MS-managed
C++ expert so you should really ask someone else.
"C1.Hours = C2.Hours". Notice that this is exactly the code that DOES
work. So it seems like an artifical rejection.
Also, even if it was not an inline function the compiler could simply
create a temporary unmanaged local variable, making it equivalent to:

double temp = C2.Hours;
C1.SetHours (temp);

Of course I can do that too, but that should be the job of the
compiler.

Indeed, and a C++ compiler has strict rules to adhere to. If observable
behaviour would change due to inlining then that would be a problem.

Cheers,
---
Tom Tempelaere