CONST ???

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Russ

    CONST ???

    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::SetHou rs' : 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

    #2
    Re: CONST ???

    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 <russk2@eticomm .net> wrote:
    [color=blue]
    >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::SetHou rs' : 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[/color]

    Comment

    • TT \(Tom Tempelaere\)

      #3
      Re: CONST ???

      "Russ" <russk2@eticomm .net> wrote in message
      news:jrkoe092kr qbd2l652au7fghl br7k1h4ds@4ax.c om...[color=blue]
      > 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::SetHou rs' : 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?[/color]

      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


      Comment

      • TT \(Tom Tempelaere\)

        #4
        Re: CONST ???

        "TT (Tom Tempelaere)" <_/\/_0§P@|/\|titi____AThot mail.com|/\|@P§0_/\/_>
        wrote in message news:7u_Gc.1778 01$rA7.8732798@ phobos.telenet-ops.be...[color=blue]
        > "Russ" <russk2@eticomm .net> wrote in message
        > news:jrkoe092kr qbd2l652au7fghl br7k1h4ds@4ax.c om...[color=green]
        > > 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::SetHou rs' : 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?[/color]
        >
        > I'm not a managed c++ writer, but I'd say that C++-references and C#[/color]
        objects[color=blue]
        > 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.[/color]

        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


        Comment

        • Russ

          #5
          Re: CONST ???

          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.SetHour s (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____AThot mail.com|/\|@P§0_/\/_> wrote:
          [color=blue]
          >"TT (Tom Tempelaere)" <_/\/_0§P@|/\|titi____AThot mail.com|/\|@P§0_/\/_>
          >wrote in message news:7u_Gc.1778 01$rA7.8732798@ phobos.telenet-ops.be...[color=green]
          >> "Russ" <russk2@eticomm .net> wrote in message
          >> news:jrkoe092kr qbd2l652au7fghl br7k1h4ds@4ax.c om...[color=darkred]
          >> > 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::SetHou rs' : 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?[/color]
          >>
          >> I'm not a managed c++ writer, but I'd say that C++-references and C#[/color]
          >objects[color=green]
          >> 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.[/color]
          >
          >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
          >[/color]

          Comment

          • TT \(Tom Tempelaere\)

            #6
            Re: CONST ???

            "Russ" <russk2@eticomm .net> wrote in message
            news:q3l5f0p7na r9f5t09kqjnlkc1 eqre96dv9@4ax.c om...[color=blue]
            > Tom, thanks for your comments. I appreciate it because I got no
            > response at all in the framework NG.[/color]

            That would not be the group to ask. You should try

            microsoft.publi c.dotnet.langua ges.vc

            for managed C++.
            [color=blue]
            > 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.SetHour s (c2.Hours);" becomes[/color]

            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.
            [color=blue]
            > "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.[/color]

            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




            Comment

            Working...