Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. VariantChangeType bug or maybe not?

VariantChangeType bug or maybe not?

Scheduled Pinned Locked Moved C / C++ / MFC
helpquestion
5 Posts 2 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Z Offline
    Z Offline
    Zdeslav Vojkovic
    wrote on last edited by
    #1

    ok guys, this is driving me crazy: #include "comdef.h" HRESULT fn(VARIANT v) { HRESULT hr = VariantChangeType(&v, &v, 0, VT_BSTR); return hr; } int main(int argc, char* argv[]) { variant_t v1(L"1"); variant_t v2(L"2"); fn(v1); fn(v2); // changes v1?? return 0; } now, when fn(v2); is called, the value of v1 is changed to "2". i believe that i'm doing something wrong, but i can't see what.

    S 1 Reply Last reply
    0
    • Z Zdeslav Vojkovic

      ok guys, this is driving me crazy: #include "comdef.h" HRESULT fn(VARIANT v) { HRESULT hr = VariantChangeType(&v, &v, 0, VT_BSTR); return hr; } int main(int argc, char* argv[]) { variant_t v1(L"1"); variant_t v2(L"2"); fn(v1); fn(v2); // changes v1?? return 0; } now, when fn(v2); is called, the value of v1 is changed to "2". i believe that i'm doing something wrong, but i can't see what.

      S Offline
      S Offline
      Stefan Pedersen
      wrote on last edited by
      #2

      Perhaps pass v to fn() by reference? i.e. HRESULT fn(VARIANT& v); "You can stand all night at a redlight anywhere in town, hailing Marys left and right but none of them slow down. I've seen the best of men go past. I don't wanna be the last..."

      Z 1 Reply Last reply
      0
      • S Stefan Pedersen

        Perhaps pass v to fn() by reference? i.e. HRESULT fn(VARIANT& v); "You can stand all night at a redlight anywhere in town, hailing Marys left and right but none of them slow down. I've seen the best of men go past. I don't wanna be the last..."

        Z Offline
        Z Offline
        Zdeslav Vojkovic
        wrote on last edited by
        #3

        That would work correctly, and i would do that if it was a "real" code. but the code in the snippet is perfectly legal c++ (or at least i think so) so i'm not sure what's the reason for such behavior

        S 1 Reply Last reply
        0
        • Z Zdeslav Vojkovic

          That would work correctly, and i would do that if it was a "real" code. but the code in the snippet is perfectly legal c++ (or at least i think so) so i'm not sure what's the reason for such behavior

          S Offline
          S Offline
          Stefan Pedersen
          wrote on last edited by
          #4

          You are right. Do I feel like an idiot or what? :) However, the reason for this strange behaviour (I think) is that the BSTR is deallocated within ChangeType and then reallocated. (It probably doesn't check whether it is changing into the same type, i.e. BSTR->BSTR) This means that the new pointer is lost since it was assigned to a temp. object. The _variant_t contains the old pointer that now points to deallocated memory. I.e. the _variant_t BSTR pointer is dangling after the fn() call. Then the ghost value is a result of the memory allocation implementation. "You can stand all night at a redlight anywhere in town, hailing Marys left and right but none of them slow down. I've seen the best of men go past. I don't wanna be the last..."

          Z 1 Reply Last reply
          0
          • S Stefan Pedersen

            You are right. Do I feel like an idiot or what? :) However, the reason for this strange behaviour (I think) is that the BSTR is deallocated within ChangeType and then reallocated. (It probably doesn't check whether it is changing into the same type, i.e. BSTR->BSTR) This means that the new pointer is lost since it was assigned to a temp. object. The _variant_t contains the old pointer that now points to deallocated memory. I.e. the _variant_t BSTR pointer is dangling after the fn() call. Then the ghost value is a result of the memory allocation implementation. "You can stand all night at a redlight anywhere in town, hailing Marys left and right but none of them slow down. I've seen the best of men go past. I don't wanna be the last..."

            Z Offline
            Z Offline
            Zdeslav Vojkovic
            wrote on last edited by
            #5

            yes, i came to the same conclusion during the lunch :) thanks for help, anyway

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups