Sunday, December 29, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

T <T@invalid.invalid>: Dec 28 10:35PM -0800

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?
 
Many thanks,
-T
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 29 09:33AM

On Sun, 2019-12-29, T wrote:
 
> 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?
 
You have "C++ string" in the subject line, but this question seems to
be as offtopic as the other recent ones from you. I don't see how to
help you with this problem, from a comp.lang.c++ point of view.
 
From a C perspective, a string is a pointer to the first char in a
sequence, and the string ends with a char 0 marker. That's probably
the one your Windows API wants, if it's a C API like someone wrote.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 29 01:45AM -0800

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
[...]
> From a C perspective, a string is a pointer to the first char in a
> sequence, and the string ends with a char 0 marker. That's probably
> the one your Windows API wants, if it's a C API like someone wrote.
 
No, from a C perspective "A string is a contiguous sequence of
characters terminated by and including the first null character."
 
What you're describing is a pointer to a string (which is what is
typically passed to functions).
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
T <T@invalid.invalid>: Dec 29 01:49AM -0800

On 2019-12-29 01:45, Keith Thompson wrote:
>> the one your Windows API wants, if it's a C API like someone wrote.
 
> No, from a C perspective "A string is a contiguous sequence of
> characters terminated by and including the first null character."
 
Do I need the chr(0) at the end?
 
T <T@invalid.invalid>: Dec 29 01:50AM -0800

On 2019-12-29 01:33, Jorgen Grahn wrote:
> You have "C++ string" in the subject line, but this question seems to
> be as offtopic as the other recent ones from you. I don't see how to
> help you with this problem, from a comp.lang.c++ point of view.
 
What I need to know is the construction of a C++ string
Bo Persson <bo@bo-persson.se>: Dec 29 11:00AM +0100

On 2019-12-29 at 07:35, T wrote:
 
> 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
Paavo Helde <myfirstname@osa.pri.ee>: Dec 29 12:17PM +0200

On 29.12.2019 8: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.
 
In C++ a string means an object of class std::string. Its internal
representation is not fixed and may depend on the compiler, its version
and macro definitions. Suspecting you are talking about C strings instead.
 
In C, a string is commonly represented just as an array of characters.
The length of the array may be indicated by a terminating zero
character, or the length might be passed separately.
 
The type of the characters depends on the string encoding. Nowadays
there are only a handful of encodings worth considering: ASCII, UTF-8,
UTF-16 and UCS-4 (aka UTF-32). Note that ASCII is a proper subset of UTF-8.
 
> 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?
 
In principle this "say" may not show the terminating zero byte even if
it is present. I'm not familiar with Perl internals.
 
Anyway, this depends on the SDK function you are passing this string to.
If it does not take string length as a separate parameter, then it most
likely expects it to be zero-terminated. I guess in Perl you can always
add the zero terminator manually to the string before or after conversion.
 
 
> 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?
 
It depends on the interface which string encoding it expects.
 
For example, in Windows, the SDK functions ending with "W" take string
arguments in UTF-16 encoding, so for them I guess you need the last
method, maybe with manually added zero terminator.
 
The Windows SDK functions ending with "A" are best avoided for anything
else than fixed ASCII strings, as they use some random code page and
call "W" variants internally anyway.
T <T@invalid.invalid>: Dec 29 02:33AM -0800

On 2019-12-29 02:00, Bo Persson wrote:
> 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++?
"Öö Tiib" <ootiib@hot.ee>: Dec 29 02:56AM -0800

On Sunday, 29 December 2019 08:36:08 UTC+2, T wrote:
 
> 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.
 
Why do not you ask your questions about Raku from its community?
Seems that it exists? <https://raku.org/community/>
Most of the people posting or reading this group do not really care
about it and the few that do can find the appropriate forums just
fine.
 
 
> 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?
 
Where Windows API has LPCWSTR there must be pointer that points
at buffer that contains zero-terminated UTF-16LE encoded text.
Code points in UTF-16 are 16 bit. When someone wants to
manipulate numeric values of those then it makes sense to use
8 bit or 16 bit integers for that.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 29 11:04AM

On Sun, 2019-12-29, T wrote:
 
>> No, from a C perspective "A string is a contiguous sequence of
>> characters terminated by and including the first null character."
 
> Do I need the chr(0) at the end?
 
Didn't we both just say so?
 
Yes. Assuming the API function you're calling really expects a C
string.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 28 04:02PM -0800

On 12/28/2019 1:22 PM, Keith Thompson wrote:
> pointer, use nullptr or NULL. (In some low-level code, you might
> store pointer values in integers.) As for `if (parm)`, that's
> valid for any scalar type.
 
Fwiw, I remember using 0xDEADBEEF as a special place holder for a
pointer in some lock-free algorithms. The pointer would have the value
of 0xDEADBEEF in order to indicate a condition that was in progress to
the algorihtm.
T <T@invalid.invalid>: Dec 28 05:14PM -0800

On 2019-12-27 17:50, James Kuyper wrote:
> context where it will be converted to a pointer type, it's also
> important to understand that null pointer constants are not the same
> thing as null pointers.
 
Thank you!
T <T@invalid.invalid>: Dec 28 05:16PM -0800

On 2019-12-28 11:11, Manfred wrote:
> If you are still using Perl, then this means the Perl interpreter, but I
> guess the Perl doc should give some info on how to use pointers in
> native calls.
 
It does. Raku's documents are really badly written at the moment.
 
https://docs.perl6.org/language/nativecall#Basic_use_of_pointers
 
They are a migraine to figure out.
T <T@invalid.invalid>: Dec 28 05:17PM -0800

On 2019-12-27 17:46, Bart wrote:
> At what level are you coding, assembly?
 
https://docs.raku.org/language/nativecall
Bart <bc@freeuk.com>: Dec 29 01:42AM

On 29/12/2019 01:17, T wrote:
> On 2019-12-27 17:46, Bart wrote:
>> At what level are you coding, assembly?
 
> https://docs.raku.org/language/nativecall
 
 
So, this seems to be (or was) Perl6, and it already has a foreign
function interface. Then you need to investigate how such calls are done
using Raku's FF interface. For example it says this:
 
"Note that a NULL string pointer can be passed by passing the Str type
object; a NULL return will also be represented by the type object."
 
Doesn't mean much to me, but in any case it's not really to do with C or
C++ (half of WinAPI was originally C but MS renamed all those C
interfaces as C++ at some point.)
 
I'm surprised there isn't a ready-made set of 'bindings' to WinAPI,
rather than having to create your own (there are some 10,000 WinAPI
functions plus 1000s of structs, types, macros and messages).
 
Even if you did know that a NULL pointer was passed as an all-zeros 32-
or 64-bit value or whatever, it would be unwise to go that low level;
you should use whatever Raku suggests is used as a null pointer.
T <T@invalid.invalid>: Dec 28 06:39PM -0800

On 2019-12-28 17:42, Bart wrote:
 
> Even if you did know that a NULL pointer was passed as an all-zeros 32-
> or 64-bit value or whatever, it would be unwise to go that low level;
> you should use whatever Raku suggests is used as a null pointer.
 
Perl 5 has a WinAPI, but Perl6/Raku does not yet.
 
Native Call's documentation is terrible. You have to experiment until
you get it right.
 
I do believe that to pass a NULL, you just put "$" without
the quotes as the variable to be passed. But I haven't
tested it yet. It is also undocumented.
Ned Latham <nedlatham@woden.valhalla.oz>: Dec 28 10:37PM -0600

Keith Thompson wrote:
> > unsigned integers for functions that require pointer parameters,
> > and if (parm) to test them.
 
> Why? Can you share some examples?
 
Why? In what way does the above need elucidation?
 
> If a function takes a pointer parameter, you need to pass a pointer
> value to it. There are cases where it might make sense to cast
> an integer to void*, but they're rare.
 
Irelevant.
 
> If you need to pass a null
> pointer, use nullptr or NULL.
 
Why? (void*) (well okay (defined_type*), actually) does perfectly well,
and it does away with the clumsiness of switching between constant
and variable.
 
> (In some low-level code, you might
> store pointer values in integers.)
 
Indeed.
 
> As for `if (parm)`, that's
> valid for any scalar type.
 
Precisely.
Ned Latham <nedlatham@woden.valhalla.oz>: Dec 28 10:37PM -0600

> pointer in some lock-free algorithms. The pointer would have the value
> of 0xDEADBEEF in order to indicate a condition that was in progress to
> the algorihtm.
 
Good one.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 28 09:12PM -0800

>> > and if (parm) to test them.
 
>> Why? Can you share some examples?
 
> Why? In what way does the above need elucidation?
 
You indicated that it's useful to know how a null pointer is
represented. How is it useful? Most of the time, the representation
doesn't matter.
 
>> value to it. There are cases where it might make sense to cast
>> an integer to void*, but they're rare.
 
> Irelevant.
 
Irrelevant to what exactly?
 
 
> Why? (void*) (well okay (defined_type*), actually) does perfectly well,
> and it does away with the clumsiness of switching between constant
> and variable.
 
Do you mean "(void*)0"? Yes, that's a valid null pointer constant, but
why do you prefer it to NULL or nullptr? What do you mean by "switching
between constant and variable"?
 
 
>> As for `if (parm)`, that's
>> valid for any scalar type.
 
> Precisely.
 
Precisely what? If parm is of pointer type, `if (parm)` tests whether
it's a null pointer or not, regardless of how it's represented. You
seemed to be using that as an example of why it's useful to know how
pointers are represented. It isn't.
 
Perhaps I'm missing something. What exactly was your point?
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Ned Latham <nedlatham@woden.valhalla.oz>: Dec 29 04:45AM -0600

Keith Thompson wrote:
 
> You indicated that it's useful to know how a null pointer is
> represented. How is it useful? Most of the time, the representation
> doesn't matter.
 
Knowing it's useful in that it enables me to use it.
 
> > > an integer to void*, but they're rare.
 
> > Irrelevant.
 
> Irrelevant to what exactly?
 
Except for that last phrase "but they're rare", your statement amounts to
an acceptance (inadveratant, I'm sure) of what I'm saying. You agree that
"there are cases"; their rarity or otherwise is irrelevanbt.
 
> > and it does away with the clumsiness of switching between constant
> > and variable.
 
> Do you mean "(void*)0"?
 
Not particularly. (void*) applies safely to variables on systems where
sizeof(int) == sizeof(void*).
 
> Yes, that's a valid null pointer constant, but
> why do you prefer it to NULL or nullptr? What do you mean by "switching
> between constant and variable"?
 
Pointer arithmetic.
 
> > > valid for any scalar type.
 
> > Precisely.
 
> Precisely what?
 
It's valid for pointers. If that's useful, use it.
 
> seemed to be using that as an example of why it's useful to know how
> pointers are represented. It isn't.
 
> Perhaps I'm missing something. What exactly was your point?
 
I've stated it in every post in this thread. Knowing how NUL is
represented can be useful.
Daniel <danielaparker@gmail.com>: Dec 28 06:09PM -0800

> >std::vector<std::optional<T>> is inferior to some other way of storing a
> >collection of optional values? What other way are you thinking of?
 
> I give up
 
Fair enough. That's the way it goes sometimes.
 
Best regards,
Daniel
boltar@nowhere.org: Dec 29 09:00AM

On Sat, 28 Dec 2019 21:01:02 +0000
>10:54:48 -0800) of the requirement in the standard that the contents of
>optionals are to be subsumed within the storage of the option, and so
>are not to give rise to any additional allocations on the heap, and the
 
Thats all well and good, but if the contained object DOES do its own further
dynamic allocations or assignments then there will be allocations on the heap.
 
>same applies to variants (discriminated unions), of which optionals
>are just a specialization: variants act in a similar way to C-style
>unions (but with type safety). In most uses they will be significantly
 
The whole point of C unions is that they're NOT type safe. A type safe union
is a contradiction.
 
>more efficient than your earlier suggestion of using inheritance with
>virtual functions, and more convenient to write: visitors for
>std::visit are reasonably easy to write in C++17.
 
Don't get me started on the visitor pattern - an absolute joke of a "solution"
looking for a problem.
 
>Your condescending posts to those who have taken the trouble to explain
>this to you a number of times seems to show that have the emotional age
>of a teenager.
 
If thats your opinion then do kindly go fuck yourself you patronising cunt
(as Flibble might say).
Paavo Helde <myfirstname@osa.pri.ee>: Dec 29 12:21PM +0200


> The whole point of C unions is that they're NOT type safe. A type safe union
> is a contradiction.
 
In case you haven't noticed yet we are talking C++ here, not C. A major
strength of C++ is to build higher level abstractions, in particular
typesafe and zero overhead abstractions over low-level unsafe primitives
like C unions.
fir <profesor.fir@gmail.com>: Dec 28 06:22PM -0800

i got so terrible problems last half of year i was like unable to concentrate on coding, still not feeling well to be honest but i think maybe i can back for a while
 
the idea is to maybe upbuild (build it up) my assembler (so called organic assembler) so maybe i will show that project and maybe some more specific questions/topics will appear
 
vurrent version to download:
 
http://minddetonator.htw.pl/org-asm.zip
 
(for windows32, i mean it runs as win32 console tool and assembles win32 executables)
 
i added some example pice of asm code in it
as sorta example how to use it
 
 
 
main:
 
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
call test_1M_loop
 
 
ret
 
////////////////////////
 
 
 
test_1M_loop:
nop
nop
mov esi 1000000
rdtsc
push edx
push eax
loop:
//==================
 
nop
nop
nop
// mov ebx esi
// add ebx 19
// mov edx 1000
// mov eax 1000
// div edax ebx
 
//=================
dec esi
jne loop
rdtsc
pop ebx
pop ecx
sub eax ebx
sbb edx ecx
call print_eax
ret
 
////////////////////////////
 
 
inner_test:
 
ret
 
//////////////////////////////
 
@ note_eax: "\x0d\x0a rdtsc eax = %d \x00"
 
print_eax:
push eax
push note_eax
call msvcrt.printf
pop eax
pop eax
ret
 
 
 
this pice of asm makes loop of 1M rolls and
measures how many cycles it takes by rtdsc command
 
this itself may be interesting for someone who would like to toy a bit and measure what amount of cycles given assembly comands and routines take on your cpu
 
for example gien loop with 3 nops gives that result (here on my old cpu)
 
 
 
rdtsc eax = 2000103
 
rdtsc eax = 2000117
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2000082
 
rdtsc eax = 2042404
 
rdtsc eax = 2415266
 
rdtsc eax = 2266271
 
if i delete that 3 nops it gives
 
 
 
rdtsc eax = 1000125
 
rdtsc eax = 1000111
 
rdtsc eax = 1000083
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
rdtsc eax = 1000083
 
rdtsc eax = 1000083
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
rdtsc eax = 1000076
 
so it shows that 1 nop takes only like 0.33 cycle, and that dec esi and jne jump itself take only one cycle
 
if someone is interested how fast things execute that kind of tests may be usefull
(it could be done in more popular assemblers but the entry level of my own may be easier, for me its easier for sure)
 
things can be tested easily, for example if i want to test rand() i just put a line
 
call msvcrt.rand
 
instead of that 3 nops and i get the result
 
 
 
rdtsc eax = 28016989
 
rdtsc eax = 28000112
 
rdtsc eax = 28043897
 
rdtsc eax = 28001589
 
rdtsc eax = 28001498
 
rdtsc eax = 28105077
 
rdtsc eax = 28000161
 
rdtsc eax = 28001904
 
rdtsc eax = 28016415
 
rdtsc eax = 28024360
 
rdtsc eax = 28000084
 
rdtsc eax = 28012999
 
rdtsc eax = 28026061
 
rdtsc eax = 28002849
 
so its 27 cycles..and so on
 
 
if someone would like to toy with my assembler i could improve it (i not typed all possiblemnemonic register combinations yet as it seems to be posiibly thousands of them)
 
i need yet also make some improve,ments in syntax of that asm... im quite satisfied as to cyntax of code (which i a bit refreshed if compared to intel by rejecting periods and turning square brackets into round brackets but i quess i still need to work on data format and also repair some holes here
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 28 03:56PM -0800

On 12/28/2019 12:53 AM, Bonita Montero wrote:
>> boundaries. The two halfs are interesting.
 
> That was only relevant to MP P4-Xeons but not to the P4 desktop-CPUs.
> On the latter all threads shared a single L2-cache.
 
Good to hear.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)