Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #70772

Re: Question on a C++ string

Subject Re: Question on a C++ string
Newsgroups comp.lang.c++
References <qu9hgc$nut$1@dont-email.me> <h6rbpeF9oi1U1@mid.individual.net> <qu9vdl$ibv$1@dont-email.me>
From Bart <bc@freeuk.com>
Message-ID <xH0OF.35843$Kj.20138@fx21.am4> (permalink)
Organization virginmedia.com
Date 2019-12-29 12:09 +0000

Show all headers | View raw


On 29/12/2019 10:33, T wrote:
> On 2019-12-29 02:00, Bo Persson wrote:
>> On 2019-12-29 at 07:35, T wrote:
>>> Hi All,
>>>
>>> I have four different way of converting a Raku/Perl6 string
>>> into a C++ string to pass to native call.  Three come out
>>> the same and one comes out with a 0x0000 (hex) at the end.
>>>
>>> The "say" functions shows me each byte in the converted
>>> string.  Which one is correct?
>>>
>>> The following is "abcdefg" converted to a C string,
>>> "wstr", etc. is the method I used and is not part
>>> of the C string:
>>>
>>> 97 98 99 100 101 102 103       wstr
>>> 97 98 99 100 101 102 103 0     to-c-str
>>> 97 98 99 100 101 102 103       CArray[uint8].new
>>> 97 98 99 100 101 102 103       CArray[uint16].new
>>>
>>> And why do I care if I am using "uint8" or "uint16"
>>> to convert visable text?  What about the one
>>> with the 0 at the end?
>>>
>>
>> A C string is always null-terminated, that is what *makes* it a 
>> string. Without the terminator it is an array of chars, which is 
>> something different.
>>
>> The C language string-functions use the null to find the end of the 
>> string. For example, strlen:
>>
>> "Returns the length of the given null-terminated byte string, that is, 
>> the number of characters in a character array whose first element is 
>> pointed to by str up to and not including the first null character.
>>
>> The behavior is undefined if str is not a pointer to a null-terminated 
>> byte string."
>>
>> https://en.cppreference.com/w/c/string/byte/strlen
>>
>>
>>      Bo Persson
> 
> Thank you.  Exactly the same as Modula2.
> 
> Is it the same for C++?
> 

These are the msdn ('msdn messagebox') docs for MessageBox:

   int MessageBox(
     HWND    hWnd,
     LPCTSTR lpText,
     LPCTSTR lpCaption,
     UINT    uType
   );

This is in a panel labelled 'C++', but has been around since it used to 
be C. Looking at those string types here:

   https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types

LCPCSTR ends up (if you follow the chain of typedefs) as either a type 
that points to sequence to 8-bit bytes, terminated by a 0 byte, or a 
sequence of 16-bit words, terminated by a 0 word.

This latter depends on whether the macro UNICODE is defined inside 
windows.h. It will call MessageBoxW if defined, and MessageBoxA if not.
This is rather interesting, since when calling from another language, 
windows.h doesn't exist, so there is no such macro.

In fact, there is no actual function called "MessageBox", that's just an 
artefact of windows.h.

Now, when I call MessageBox from my own non-C code, I directly call 
MessageBoxA with normal 8-bit zero-terminated strings. I assume the 
declaration of this function is as follows:

    int MessageBoxA(
       int hWnd,
       char* Text,
       char* Caption,
       unsigned int Type
    );

(I don't even use 'const char*', as 'const' is an artefact of the C 
language; it has no meaning at the binary level. Here 'int' is assumed 
to be 32 bits.)

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Question on a C++ string T <T@invalid.invalid> - 2019-12-28 22:35 -0800
  Re: Question on a C++ string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-29 09:33 +0000
    Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 01:45 -0800
      Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 01:49 -0800
        Re: Question on a C++ string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-29 11:04 +0000
        Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:57 -0800
          Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 14:57 -0800
    Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 01:50 -0800
      Re: Question on a C++ string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-29 11:08 +0000
        Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 11:50 -0800
          Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:57 -0800
            Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 15:00 -0800
      Re: Question on a C++ string Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:57 -0800
        Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 15:02 -0800
          Re: Question on a C++ string Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 01:28 +0200
      Re: Question on a C++ string Sam <sam@email-scan.com> - 2019-12-29 21:47 -0500
  Re: Question on a C++ string Bo Persson <bo@bo-persson.se> - 2019-12-29 11:00 +0100
    Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 02:33 -0800
      Re: Question on a C++ string Bart <bc@freeuk.com> - 2019-12-29 12:09 +0000
        Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 11:51 -0800
  Re: Question on a C++ string Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 12:17 +0200
    Re: Question on a C++ string Barry Schwarz <schwarzb@delq.com> - 2019-12-29 08:45 -0800
      Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 11:54 -0800
  Re: Question on a C++ string Öö Tiib <ootiib@hot.ee> - 2019-12-29 02:56 -0800
    Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 12:02 -0800
  Re: Question on a C++ string Barry Schwarz <schwarzb@delq.com> - 2019-12-29 08:39 -0800
    Re: Question on a C++ string T <T@invalid.invalid> - 2019-12-29 12:10 -0800

csiph-web