ostringstream Unicode problem

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

    ostringstream Unicode problem

    Sorry about the platform specific code here, but I include to show what I am
    doing. I am trying to create a char* directory listing.

    If I compile the code below as Unicode then I get memory addresses in
    strResponse. But it works fine if not compiled with Unicode. How would I
    edit the code to work under Unicode?

    WIN32_FIND_DATA stData;
    //do first find call
    HANDLE hReturn = ::FindFirstFile (TEXT("C:\\*.*" ), &stData);
    if (hReturn == INVALID_HANDLE_ VALUE) return -1;

    std::ostringstr eam ss;
    ss << stData.cFileNam e << "\r\n";

    while (::FindNextFile ( hReturn, &stData))
    {
    ss << stData.cFileNam e << "\r\n";
    }

    FindClose(hRetu rn);
    std::string strResponse = ss.str();

    stData.cFileNam e is a char buffer.

    Angus


  • Victor Bazarov

    #2
    Re: ostringstream Unicode problem

    Angus wrote:
    Sorry about the platform specific code here, but I include to show
    what I am doing. I am trying to create a char* directory listing.
    >
    If I compile the code below as Unicode then I get memory addresses in
    strResponse. But it works fine if not compiled with Unicode. How
    would I edit the code to work under Unicode?
    >
    WIN32_FIND_DATA stData;
    //do first find call
    HANDLE hReturn = ::FindFirstFile (TEXT("C:\\*.*" ), &stData);
    if (hReturn == INVALID_HANDLE_ VALUE) return -1;
    >
    std::ostringstr eam ss;
    ss << stData.cFileNam e << "\r\n";
    >
    while (::FindNextFile ( hReturn, &stData))
    {
    ss << stData.cFileNam e << "\r\n";
    }
    >
    FindClose(hRetu rn);
    std::string strResponse = ss.str();
    >
    stData.cFileNam e is a char buffer.
    You probably need to post this question to a Microsoft newsgroup.
    There is no such thing as "compilatio n as Unicode" defined in C++
    language Standard. I believe it's compiler- and platform-specific.
    Check out FAQ section 5 for the list of the suggested newsgroups.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask


    Comment

    • BobR

      #3
      Re: ostringstream Unicode problem


      Victor Bazarov wrote in message... [snipped]
      Angus wrote:
      If I compile the code below as Unicode then I get memory addresses in
      strResponse. But it works fine if not compiled with Unicode. How
      would I edit the code to work under Unicode?

      std::ostringstr eam ss;
      [ For OP (just an idea, I don't know) ]
      On the C++ side:

      A std::ostringstr eam 'defaults' to 'char'.
      It will need to be passed the parameters of the Unicode for it to be used.

      The 'footprint' is (from <sstream>):

      template <typename _CharT, typename _Traits, typename _Alloc>
      class basic_ostringst ream : public basic_ostream<_ CharT, _Traits>
      { /* .... */ };

      Fill in the [ ]s, at bare minimum fill in the first one:
      std::ostringstr eam< [Unicode char], [traits], [allocator] ss;

      If you don't know and can't find the info, you might try:

      std::ostringstr eam< wchar_t ss;

      [ Thanks for the use of your post, Victor. ]
      --
      Bob R
      POVrookie


      Comment

      • BobR

        #4
        Re: ostringstream Unicode problem [ Update ]


        BobR wrote in message...

        Just checked the wxWidgets docs. They say Unicode is two-bytes wide (wchar_t
        type), so, the following line should be the one used.

        std::ostringstr eam< wchar_t ss;

        Please let us know if it works.

        std::cout<<" sizeof(wchar_t) ="<<sizeof(wcha r_t)<<std::endl ;
        // out: sizeof(wchar_t) =2
        --
        Bob R
        POVrookie


        Comment

        • Victor Bazarov

          #5
          Re: ostringstream Unicode problem [ Update ]

          BobR wrote:
          BobR wrote in message...
          >
          Just checked the wxWidgets docs. They say Unicode is two-bytes wide
          (wchar_t type), so, the following line should be the one used.
          >
          std::ostringstr eam< wchar_t ss;
          >
          Please let us know if it works.
          That's

          std::basic_ostr ingstream<wchar _tss;

          or

          std::wostringst ream ss;
          >
          std::cout<<" sizeof(wchar_t) ="<<sizeof(wcha r_t)<<std::endl ;
          // out: sizeof(wchar_t) =2
          V
          --
          Please remove capital 'A's when replying by e-mail
          I do not respond to top-posted replies, please don't ask


          Comment

          • =?iso-8859-1?q?Kirit_S=E6lensminde?=

            #6
            Re: ostringstream Unicode problem

            On Jun 19, 4:16 am, "Angus" <nos...@gmail.c omwrote:
            Sorry about the platform specific code here, but I include to show what I am
            doing. I am trying to create a char* directory listing.
            >
            If I compile the code below as Unicode then I get memory addresses in
            strResponse. But it works fine if not compiled with Unicode. How would I
            edit the code to work under Unicode?
            >
            WIN32_FIND_DATA stData;
            //do first find call
            HANDLE hReturn = ::FindFirstFile (TEXT("C:\\*.*" ), &stData);
            if (hReturn == INVALID_HANDLE_ VALUE) return -1;
            Microsoft pushes the idea that _T and and their TEXT macros is all the
            difference that you need for Windows Unicode and Windows narrow
            character support. Unfortunately it isn't true (although it was more
            nearly so before they started to use the standard C++ libraries).
            >
            std::ostringstr eam ss;
            std::ostringstr eam is for char. If you want to compiler for both
            Unicode and narrow characters then you'll need to use conditional
            compilation to determine the correct type. For wchar_t this needs to
            be std::wostringst ream.
            ss << stData.cFileNam e << "\r\n";
            You will also need to use the TEXT or _T macros here (can't remember
            which does what as I don't use them I'm afraid).

            ss << ... << _T( "\r\n" );
            >
            while (::FindNextFile ( hReturn, &stData))
            {
            ss << stData.cFileNam e << "\r\n";
            >
            }
            >
            FindClose(hRetu rn);
            std::string strResponse = ss.str();
            >
            stData.cFileNam e is a char buffer.
            This will need to change between char and wchar_t depending on how
            you're compiling it.

            This is all very fidlly. Why are you even bothering with narrow
            character support? On Windows it seems pointless these days. If you're
            going to the bother of supporting Unicode compilation then just use
            that throughout and forget about narrow character support.

            You can still use narrow characters where you need to interact with
            legacy systems and to handle formats that are specified as 7/8 bit
            characters.


            K

            Comment

            • BobR

              #7
              Re: ostringstream Unicode problem [ Update ]


              Victor Bazarov <v.Abazarov@com Acast.netwrote in message...
              BobR wrote:
              Just checked the wxWidgets docs. They say Unicode is two-bytes wide
              (wchar_t type), so, the following line should be the one used.

              std::ostringstr eam< wchar_t ss;

              Please let us know if it works.
              >
              That's
              >
              std::basic_ostr ingstream<wchar _tss;
              >
              or
              >
              std::wostringst ream ss;
              >
              Pick one:
              a) Doooh, I can't believe I did that.
              b) Duh, my brain went on strike.
              c) all of the above.

              Thanks for the correction, Victor.

              --
              Bob R
              POVrookie


              Comment

              Working...