C++ variable names

[T]

Hi All,

Sorry for the homework assignment.

Would some kind individual please fill in
the C++ variables names that go with these
C variable names?

int8_t in C
int16_t in C
int32_t in C
int64_t in C
uint8_t in C
uint16_t in C
uint32_t in C
uint64_t in C
float in C

Do I just drop the "_t"?

Many thanks,
-T

[Daniel]

On Wednesday, January 15, 2020 at 9:32:02 PM UTC-5, T wrote:
> Hi All,

>
> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
>
> int8_t in C

...

>
> Do I just drop the "_t"?
>

In general it's considered to be bad practice to adorn a variable name
with type information.

Daniel

[red floyd]

On 1/15/20 6:31 PM, T wrote:
> Hi All,
>
> Sorry for the homework assignment.
>

> <redacted>

Please see FAQ 5.2. Do your own homework.

[T]

I am getting this list from:

https://docs.raku.org/language/nativetypes#Types_with_native_representation_and_size

What do you recommend (I clearly have no idea
what I am doing)?

[T]

I have no idea where to find FAQ 5.2. I am
completely at your mercy here.

Do you have a link for me?

[Chris M. Thomasson]

Fwiw, *_t postfix conflicts with POSIX namespace.

[Ben Bacarisse]

T <T...@invalid.invalid> writes:

> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
>
> int8_t in C
> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C
> float in C
>
> Do I just drop the "_t"?

They have the same names in C++. Depending on what header file you
include to get them, they may be in the std:: namespace, but the name
itself is the same.

--
Ben.

[T]

Can I just drop them then?

And can you give me a reference to the POSIX namespace?
The folks I am dealing with won't take my word for it.

Are the names the same in C++ if I drop the _t?

[T]

Thank you!

Also, what is the _t and can I drop it?

[Chris M. Thomasson]

On 1/15/2020 7:58 PM, T wrote:
> On 2020-01-15 19:40, Chris M. Thomasson wrote:
>> On 1/15/2020 6:31 PM, T wrote:
>>> Hi All,
>>>
>>> Sorry for the homework assignment.
>>>
>>> Would some kind individual please fill in
>>> the C++ variables names that go with these
>>> C variable names?
>>>
>>> int8_t in C
>>> int16_t in C
>>> int32_t in C
>>> int64_t in C
>>> uint8_t in C
>>> uint16_t in C
>>> uint32_t in C
>>> uint64_t in C
>>> float in C
>>>
>>> Do I just drop the "_t"?
>>>
>>
>> Fwiw, *_t postfix conflicts with POSIX namespace.
>>
>
> Can I just drop them then?

Take a deep look at:

http://www.cplusplus.com/reference/cstdint

When dealing with POSIX, the *_t can be an interesting thing indeed.

You need to use the correct type name to use any type.

>
> And can you give me a reference to the POSIX namespace?

Take ptread_mutex_t:

https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html

Well, the damn *_t is in the POSIX namespace. However, if not using
POSIX, then this is mute.

[James Kuyper]

POSIX reserves such postfixes for the purpose of identifying types.
These are types. POSIX mandates support for a compiler that conforms to
the C standard, so there is no such conflict.

[T]

Any problem dropping the _t then?

[Chris M. Thomasson]

On 1/15/2020 8:18 PM, James Kuyper wrote:
> On 1/15/20 10:40 PM, Chris M. Thomasson wrote:
>> On 1/15/2020 6:31 PM, T wrote:
>>> Hi All,
>>>
>>> Sorry for the homework assignment.
>>>
>>> Would some kind individual please fill in
>>> the C++ variables names that go with these
>>> C variable names?
>>>
>>> int8_t in C
>>> int16_t in C
>>> int32_t in C
>>> int64_t in C
>>> uint8_t in C
>>> uint16_t in C
>>> uint32_t in C
>>> uint64_t in C
>>> float in C
>>>
>>> Do I just drop the "_t"?
>>>
>>
>> Fwiw, *_t postfix conflicts with POSIX namespace.
>
> POSIX reserves such postfixes for the purpose of identifying types.

I was advised a long time ago to drop any *_t wrt keeping Kosher within
the POSIX namespace.

[Bonita Montero]

> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
> int8_t in C
> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C
> float in C

That are all no variable-names but type-names ! Hrhr. ;-)

[Daniel]

On Wednesday, January 15, 2020 at 9:46:21 PM UTC-5, T wrote:

> What do you recommend (I clearly have no idea what I am doing)?

What do you need to do? In the expression

int8_t x;

int8_t is the name of a type (an 8-bit integer value), x is the name of a
variable of type int8_t. Are you looking for a naming convention for
variables? Something else?

Daniel

[Bo Persson]

There is no magic here.

An identifier can contain a-z, A-Z, 0-9, and underscores. A name like
int64_t contains a combination of lowercase letters, digits, and
underscore. Nothing special about that.



The _t is just a convention that (generally) indicates that the
identifier is a typedef in the C library, like

typedef short int16_t;
typedef unsigned int uint32_t;



Variable names are also identifiers and have the same format as type
names. You can just choose whatever name you want, like


int32_t x;


or some better name than x, that tells us what the variable is supposed
to be used for.

As the _t is used in some typedef-names, it is generally a good idea not
to use it in other names.


Bo Persson

[Keith Thompson]

Those are type names. not variable names. The [u]int*_t names
are defined in the C standard header <stdint.h>, imported into
C++ as <cstdint>. float is a reserved word and the name of a
floating-point type.

They're all exactly the same in C and in C++ (except that the *_t
type names might be in the std:: namespace in C++).

The "_t" suffix is simply part of the name. I don't know why
you'd want to drop it. (It's a convention indicating that it's a
type name, but it's not a convention that's universally followed.)
As mentioned later in the thread, POSIX reserves _t suffixes for some
purposes, but since POSIX is based on C and all these identifiers
are defined by the C standard, there is no conflict.

For example, dropping the "_t" from int8_t would give you int8, which is
not defined anywhere in C or C++. You can certainly define something
called "int8" if you like, just as you can define something called
"foo42" if you like.

Since you mentioned "variables", it's possible that you're asking
for good names for variables of these types. If so, each variable
should have a name that reflects the meaning of that variable.

It's possible that I've misunderstood what you're asking.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

I also don't know what you mean by "FAQ 5.2". Question 5.2 in the
comp.lang.c FAQ <http://www.c-faq.com> is about null pointers and is
not relevant here. The most current C++ FAQ <https://isocpp.org/faq>
doesn't number its questions.

[T]

The names are the same in C and C++. I would like
now to know if I should include the _t in either or both?

[T]

Hi Bo,

Thank you. I will include the _t!

-T

[T]

oops. I meant type names.

:'(

[T]

You hit it perfectly. Thank you!

[Bonita Montero]

>>> Would some kind individual please fill in
>>> the C++ variables names that go with these
>>> C variable names?
>>> int8_t in C
>>> int16_t in C
>>> int32_t in C
>>> int64_t in C
>>> uint8_t in C
>>> uint16_t in C
>>> uint32_t in C
>>> uint64_t in C
>>> float in C

>> That are all no variable-names but type-names ! Hrhr. ;-)

> oops.  I meant type names.

Ok, except float all types are preceded with "std::" in C++.
float has the same typename.

[Chris M. Thomasson]

On 1/15/2020 9:48 PM, Keith Thompson wrote:
> T <T...@invalid.invalid> writes:
>> Sorry for the homework assignment.

[...]

> The "_t" suffix is simply part of the name. I don't know why
> you'd want to drop it. (It's a convention indicating that it's a
> type name, but it's not a convention that's universally followed.)
> As mentioned later in the thread, POSIX reserves _t suffixes for some
> purposes, but since POSIX is based on C and all these identifiers
> are defined by the C standard, there is no conflict.
>
> For example, dropping the "_t" from int8_t would give you int8, which is
> not defined anywhere in C or C++. You can certainly define something
> called "int8" if you like, just as you can define something called
> "foo42" if you like.

Oh yes. We need the to use *_t when we need to use a standard type that
has that suffix. We must use the right name. However, perhaps this is to
dated, I was advised to stay away from adding _t to any new type I
create. Therefore:

struct foo_t
{
int bad;
};

struct foo
{
int better;
};

I got into the habit. Especially typedefs and/or macros. No *_t when
working with POSIX. using a std type, no problem. However, do not create
a new type with *_t, damn it.

[...]

[T]

Thank you!

This got it?

C C++
float_t std::float_t
double_t std::double_t

[T]

Thank you!

[red floyd]

On 1/15/20 9:51 PM, Keith Thompson wrote:
> red floyd <no....@its.invalid> writes:
>> On 1/15/20 6:31 PM, T wrote:
>>> Sorry for the homework assignment.
>>>
>>> <redacted>
>>
>> Please see FAQ 5.2. Do your own homework.
>
> I also don't know what you mean by "FAQ 5.2". Question 5.2 in the
> comp.lang.c FAQ <http://www.c-faq.com> is about null pointers and is
> not relevant here. The most current C++ FAQ <https://isocpp.org/faq>
> doesn't number its questions.
>

I'm referring to the original C++ FAQ lite.

http://www.dietmar-kuehl.de/mirror/c++-faq/how-to-post.html#faq-5.2

[Louis Krupp]

That page seems to have nothing to do with C++ and a lot to do with an
implementation of Perl6. Are you really using Perl6?

Louis

[T]

Exactly.

I am writing my own paper on how to use Raku's
NativeCall with Win API functions. One of the
chapters is matching up C and C++ types to Raku
native types. To do so, I need their proper names.

I just need the corresponding C++ names for the
C types shown on that page.

The reason for the C++ names is because M$ shows their
functions as C++ calls.

:-)

-T

[T]

Very funny!

[Chris M. Thomasson]

On 1/15/2020 6:31 PM, T wrote:
> Hi All,

>
> Sorry for the homework assignment.
>

> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
>
> int8_t in C

> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C
> float in C
>

> Do I just drop the "_t"?
>

> Many thanks,
> -T


When creating a new type at this early stage is your learning process,
use hyper-verbose names for things to get a feel. Try to name your types
something nice and descriptive:

No struct rs, or struct r. Something more on par with:

struct room_settings
{
int some_setting_ambient_light_0;
int some_setting_1;
};

struct room
{
struct room_settings settings;
};

Actually, think of programming a little text adventure game. Its great
fun! Try to beat Beyond Zork... ;^)

Create a 5 room puzzle, with encounters, and all sorts of fun stuff.

[T]

Huh? I just want the equivalent C++ name of some
C names for a paper I am writing for Raku's NativeCall

[Chris M. Thomasson]

Oh shi%. Nevermind. For some reason, I thought you were learning C.

[Bo Persson]

If you limit yourself to Windows, this becomes a lot easier as you can
just look up what the built in types are there - you can use short for
16 bits, int and unsigned for 32-bits, and long long when you need 64-bits.

The _t-types in the standard libary are for when *you* want to write a
library for a wide set of systems and you don't know what type is 32
bits wide (if any).

One (very small) advantage of using int32_t is that it will not compile
if you happen to try out your code on a 36-bit computer. But that never
happens anyway if you use Windows.

[Louis Krupp]

I'm working on the assumption that you're testing your code with a C++
compiler. If I were you, I would try the C types. If they work (and I
can't think of a reason why they wouldn't), I would ask myself if
there's a reason to change them. As far as I can tell, they're valid
C++:

https://en.cppreference.com/w/cpp/header/cstdint

This program runs with no surprises:

===
#include <cstdint>
#include <iostream>

int main()
{
std::cout
<< sizeof(int8_t)
<< " "
<< sizeof(int16_t)
<< " "
<< sizeof(uint32_t)
<< "\n";
}
===

(I think it's cool that you're using Perl6.)

Louis

[T]

The paper I am writing deal with WinAPI call.
I personally adore Fedora, but most of
my customers are Windows.

[T]

On 2020-01-15 23:43, Louis Krupp wrote:
> On Wed, 15 Jan 2020 22:59:58 -0800, T <T...@invalid.invalid> wrote:
>
>> I just need the corresponding C++ names for the
>> C types shown on that page.
>>
>> The reason for the C++ names is because M$ shows their
>> functions as C++ calls.
>
> I'm working on the assumption that you're testing your code with a C++
> compiler.

Actually, no. NativeCall is a Raku module that interfaces
with C system function such as Win API calls.
I test with Raku.

But to get NativeCall working properly, you have
to know what is going on with the C++ declarations
that M$ gives you so you can match up Raku's types.

Thank you for the code though.

-T

[T]

Only as much as I need to run NativeCall.

C is for folks way smarter than me. I don't
know how your guys do it without going insane.
My hat is off to you guys.

[Keith Thompson]

T <T...@invalid.invalid> writes:
> On 2020-01-15 21:48, Keith Thompson wrote:

[45 lines deleted]

>
> You hit it perfectly. Thank you!

You don't need to post multiple responses just to say "Thank you",
and if you do, you don't need to quote the entire parent article.
I appreciate the sentiment (and you're welcome), and in this
case letting me know that I had guessed correctly is valuable,
but multiple long posts are a lot to read through.

In the case of a long thread, a single reply thanking everyone is
more than sufficient.

[Keith Thompson]

T <T...@invalid.invalid> writes:
[...]

> This got it?
>
> C C++
> float_t std::float_t
> double_t std::double_t

float_t and double_t are fairly obscure types defined in <math.h>
in C, and in <cmath> or <math.h> in C++. float_t is at least as
wide as float, and might be wider and faster; similarly for double_t.
(For example, float_t might be defined as double if double operations
are faster than float operations.) See the C standard (I think
you have N1570) section 7.12. I don't know that there would be
any reason to refer to them in Raku.

The predefined floating-point types in both C and C++ are float,
double, and long double.

I'm really not sure what this whole discussion is about. The types
in the standard library have names defined by the standard library
as specified in the language standard. You just use those names.
It doesn't make sense to talk about changing them.

If you weren't aware, most of the C standard library headers
are incorporated into the C++ standard library. Each <foo.h>
C header is available in C++ as <cfoo>, with the declarations in
the std:: namespace. With very few exceptions, they're the same.
Any decent C++ reference should explain all this.

No offense, but I get the feeling that you have some fundamental
misconception that led you to think that, for example, referring to
int32_t as int32 might make some kind of sense.

Hopefully this means you won't have to post a new question about
size_t and ptrdiff_t, since the answers will be exactly the same.

[Louis Krupp]

Can you give an example of what you're talking about?

Louis

[David Brown]

On 16/01/2020 08:44, Bo Persson wrote:

> If you limit yourself to Windows, this becomes a lot easier as you can
> just look up what the built in types are there - you can use short for
> 16 bits, int and unsigned for 32-bits, and long long when you need 64-bits.
>

I believe even MSVC, with its poor support for C99, has <stdint.h>.
There are /no/ advantages in using types like "short" and "long long"
over the standard sized types when you want specific sized types. If
you want a signed 16-bit type, you use "int16_t" - you don't write
something completely different ("short") and assume it matches, even if
that assumption is perfectly valid. This is about writing code in a way
that is clear - it cannot possibly be misinterpreted by any compiler, or
by any reader. If you write "long", the size can change between
platforms - and even on the one platform, programmers used to different
platforms might misread it. If you write "uint32_t", there is no
possibility of mistakes.

This is why these types were added to C - use them.

> The _t-types in the standard libary are for when *you* want to write a
> library for a wide set of systems and you don't know what type is 32
> bits wide (if any).
>
> One (very small) advantage of using int32_t is that it will not compile
> if you happen to try out your code on a 36-bit computer. But that never
> happens anyway if you use Windows.
>

A marginally more realistic advantage is that "int8_t" won't compile on
platforms with CHAR_BIT greater than 8 (and unlike 36-bit computers,
such processors are in wide use today - though not, obviously, running
Windows). And "int64_t" won't compile on platforms that don't support
64-bit types (for some limited compilers that don't support full C99).

In general, if you want a size-specific type, along with the additional
guarantees of two's complement integers with no padding bits, use the
size-specific types in <stdint.h>. Then you get what you ask for, the
code is clear, and you'll get a hard failure if the compiler can't give
you what you want.

[Louis Krupp]

Don't sell yourself short. You can do this. Besides, what have you got
against going insane?

I think you'll find learning C a whole lot easier than doing whatever
it is you're trying to do *without* knowing anything substantial about
C.

Louis

[David Brown]

On 16/01/2020 05:31, Chris M. Thomasson wrote:
> On 1/15/2020 8:18 PM, James Kuyper wrote:

>> On 1/15/20 10:40 PM, Chris M. Thomasson wrote:
>>> On 1/15/2020 6:31 PM, T wrote:
>>>> Hi All,
>>>>
>>>> Sorry for the homework assignment.
>>>>
>>>> Would some kind individual please fill in
>>>> the C++ variables names that go with these
>>>> C variable names?
>>>>
>>>> int8_t in C
>>>> int16_t in C
>>>> int32_t in C
>>>> int64_t in C
>>>> uint8_t in C
>>>> uint16_t in C
>>>> uint32_t in C
>>>> uint64_t in C
>>>> float in C
>>>>
>>>> Do I just drop the "_t"?
>>>>
>>>

>>> Fwiw, *_t postfix conflicts with POSIX namespace.
>>
>> POSIX reserves such postfixes for the purpose of identifying types.
>
> I was advised a long time ago to drop any *_t wrt keeping Kosher within
> the POSIX namespace.
>

I think there may be a bit of confusion here in what people mean by
"drop the _t".

When you define your own types, you are free to pick whatever names you
want - as long as you don't conflict with other standards or
requirements. Unless you are writing POSIX code, you can freely use _t
names (except for those that conflict with the C or C++ standards).

But these types are /not/ personal types - they are defined in the C and
C++ standards. You cannot "drop the _t". They have defined names, and
you need to use those names if you use those types.

If you are not using C99 - perhaps because your compiler doesn't support
it - and you don't have <stdint.h> (many pre-C99 compilers have
<stdint.h>), then you should define these types yourself or use a
generic "stdint.h". That way your code is understandable by all C
programmers, and portable to other compilers. So you should still be
using the _t names.

>
>> These are types. POSIX mandates support for a compiler that conforms to
>> the C standard, so there is no such conflict.
>>
>

[Bonita Montero]

> Thank you!
> This got it?
> C           C++
> float_t     std::float_t
> double_t    std::double_t

In another post in the Win32-newsgroup you said that you don't need to
learn C for your talss. Now you want to know how cerain types are mapped
from C to C++. That's even beyond C. I think you should get a copy of
"The C Programming Language" and learn C. C is a simple language which
someone can learn in a week. Just google for
"The C Programming language" doctype:pdf
to find an older copy of the book. That's not up to date but there were
no revolutionary changes with C like in C++.

[Mist...@honorific.org]

On Thu, 16 Jan 2020 11:25:45 +0100
Bonita Montero <Bonita....@gmail.com> wrote:
>> Thank you!
>> This got it?
>> C           C++
>> float_t     std::float_t
>> double_t    std::double_t
>
>In another post in the Win32-newsgroup you said that you don't need to
>learn C for your talss. Now you want to know how cerain types are mapped
>from C to C++. That's even beyond C. I think you should get a copy of
>"The C Programming Language" and learn C. C is a simple language which
>someone can learn in a week. Just google for

Someone familiar with programming can learn most of it in a week - but good
luck getting them to understand pointer arithmetic and double/triple
indirection and the relationship between pointers and arrays properly in that
time however. The latter still trips up even seasoned C programmers occasionally
and yes, I am speaking from experience :)

[Bonita Montero]

> Someone familiar with programming can learn most of it in a week - but
> good luck getting them to understand pointer arithmetic and double/triple
> indirection and the relationship between pointers and arrays properly in

> that time however. ...

My first language was BASIC on my Sinclair ZX Spectrum, then GFA Basic
on my Atari ST. Then I learned Borland C on my Atari ST in a week with
all that topics in a week. And I was 14 then and if somesone so young
can learn C in a weel so comprehensive, a mature person can manage it
at least as good.

[James Kuyper]

T wrote:

> Would some kind individual please fill in
> the C++ variables names that go with these
> C variable names?
>
> int8_t in C
> int16_t in C
> int32_t in C
> int64_t in C
> uint8_t in C
> uint16_t in C
> uint32_t in C
> uint64_t in C

Those are not variable names. Those are typedef names declared in <stdint.h>. A typedef name is an alias for some other type.
If you put the preprocessing directive

#include <stdint.h>

in a C++ program, those exact same typedef names will be introduced into the global namespace. Most C code that uses those names will need little or no modification to have the exact behavior in C++. And if modification is needed, it won't involve changing those names.

If you use <cstdint> rather than <stdint.h> in C++ code, those typedefs will be declared in the std:: namespace, which is somewhat safer, but the cost of that increased safety is that you will sometimes have to write std::int8_t rather than plain int8_t. The necessity of doing so is precisely what makes it safer.

> float in C

That, on the other hand, is a C keyword that is also a C++ keyword, with precisely the same meaning in both languages.

> Do I just drop the "_t"?

No.

[James Kuyper]

T wrote:
> Any problem dropping the _t then?

Yes. It's the same problem that happens when you drop a
part of any other name. My name, for instance, is "James".
If you drop the 's', you get "Jame". The problem with
that? "Jame" isn't my name.
Similarly, if you drop the _t from int16_t, it's no longer
the name of a typedef declared in <stdint.h> for an
integer type with exactly 16 bits, 2's complement
representation, and no padding bits. Without the _t, it's
Just an identifier reserved for use by users, who might or
might not have already declared it as having some
particular meaning.

[Lynn McGuire]

On 1/15/2020 8:42 PM, Daniel wrote:
> On Wednesday, January 15, 2020 at 9:32:02 PM UTC-5, T wrote:
>> Hi All,
>>

>> Would some kind individual please fill in
>> the C++ variables names that go with these
>> C variable names?
>>
>> int8_t in C
>

> ...

>>
>> Do I just drop the "_t"?
>>

> In general it's considered to be bad practice to adorn a variable name
> with type information.
>
> Daniel

Huh ? Don't tell that to Hungarian notation folks.
https://en.wikipedia.org/wiki/Hungarian_notation

Lynn

[T]

On 2020-01-16 11:51, James Kuyper wrote:
> T wrote:
>
>> Would some kind individual please fill in
>> the C++ variables names that go with these
>> C variable names?
>>
>> int8_t in C
>> int16_t in C
>> int32_t in C
>> int64_t in C
>> uint8_t in C
>> uint16_t in C
>> uint32_t in C
>> uint64_t in C
>
> Those are not variable names. Those are typedef names declared in <stdint.h>. A typedef name is an alias for some other type.

My bad

> If you put the preprocessing directive
>
> #include <stdint.h>
>
> in a C++ program, those exact same typedef names will be introduced into the global namespace. Most C code that uses those names will need little or no modification to have the exact behavior in C++. And if modification is needed, it won't involve changing those names.
>
> If you use <cstdint> rather than <stdint.h> in C++ code, those typedefs will be declared in the std:: namespace, which is somewhat safer, but the cost of that increased safety is that you will sometimes have to write std::int8_t rather than plain int8_t. The necessity of doing so is precisely what makes it safer.
>
>> float in C
>
> That, on the other hand, is a C keyword that is also a C++ keyword, with precisely the same meaning in both languages.
>
>> Do I just drop the "_t"?
>
> No.
>

Thank you!

[T]

Long version:
http://vpaste.net/iYhgq

Short version:

my DWORD $dwFlags = FORMAT_MESSAGE_FROM_SYSTEM +|
FORMAT_MESSAGE_IGNORE_INSERTS;
my DWORD $lpSource = NULL;
my DWORD $dwMessageId = $ErrorNumber; # error nubmer from the
calling function
my DWORD $dwLanguageId = LANG_USER_DEFAULT; # 0 is the delault
system language, maybe

my DWORD $nSize = 1024; # number of bytes in $lpBuffer, maybe
my BYTES $lpBuffer = CArray[BYTE].new( 0 xx $nSize );
my DWORD $va_list = NULL;
my Str $ErrorString = "";
my DWORD $RtnCode = 0;
my DWORD $LastError = 0;


sub FormatMessageW( DWORD, DWORD, DWORD, DWORD, CArray[BYTE] is rw,
DWORD is rw, DWORD )
is native("Kernel32")
is symbol("FormatMessageW")
returns DWORD
{ * };

$RtnCode = FormatMessageW( $dwFlags, $lpSource, $dwMessageId,
$dwLanguageId, $lpBuffer, $nSize, $va_list );

[T]

Got it!

[Öö Tiib]

Yes, but the Hungarian notation guys are frowned upon in majority of
collectives. By
<https://en.wikipedia.org/wiki/Hungarian_notation#Notable_opinions>
Bjarne Stroustrup does not recommend it.
It can be tricky for three star programmer to understand what they
do without such notation OTOH it is unclear if it does help.
<https://wiki.c2.com/?ThreeStarProgrammer>

[David Brown]

Did you read the link you posted?

The original idea of "Hungarian notation" is what Wikipedia labels "Apps
Hungarian". The variable naming prefix is about the way the variable
should be used - like using "usName" for an "unsafe string" holding a
name, and "ssName" for the "safe" version, after escaping to block SQL
injection attacks and other unpleasantness. The point is to give
semantic information in addition to the name and the type, making it
easier to spot mistakes.

What Wikipedia calls "Systems Hungarian", used regularly in the Windows
world, was a misunderstanding of this that got out of hand, trying to
use prefixes for the types of variables. That might make a little sense
in a language with no declaration of types, but is clearly absurd in a
language where programs will have hundreds and thousands of types.

[Chris M. Thomasson]

On 1/16/2020 4:31 AM, Bonita Montero wrote:
>> Someone familiar with programming can learn most of it in a week - but
>> good luck getting them to understand pointer arithmetic and double/triple
>> indirection and the relationship between pointers and arrays properly in
>> that time however. ...
>
> My first language was BASIC on my Sinclair ZX Spectrum, then GFA Basic
> on my Atari ST.

I learned BASIC first as well, back in 1984-85, was born in late 1977.
Using the cartridge in my Atari 800XL. I was thinking, what the hell is
BASIC!? I was a little kid. Then on Christmas, I received a spiral bound
book that thought me the language. LOGO was fun as well.

[Chris M. Thomasson]

On 1/16/2020 3:51 PM, Chris M. Thomasson wrote:
> On 1/16/2020 4:31 AM, Bonita Montero wrote:
>>> Someone familiar with programming can learn most of it in a week - but
>>> good luck getting them to understand pointer arithmetic and
>>> double/triple
>>> indirection and the relationship between pointers and arrays properly in
>>> that time however. ...
>>
>> My first language was BASIC on my Sinclair ZX Spectrum, then GFA Basic
>> on my Atari ST.
>
> I learned BASIC first as well, back in 1984-85, was born in late 1977.
> Using the cartridge in my Atari 800XL. I was thinking, what the hell is
> BASIC!? I was a little kid. Then on Christmas, I received a spiral bound
> book that thought me the language. LOGO was fun as well.

PILOT was really fun as well.

[Manfred]

On 1/17/20 12:51 AM, Chris M. Thomasson wrote:
> was born in late 1977. Using the cartridge in my Atari 800XL.

The Matrix is around us all.

[Lynn McGuire]

I won't be showing you my three star programming then.

Lynn

[Manfred]

Note that, as far as I read somewhere, the Hungarian notation was
initially introduced to indicate the "intention or kind" of a variable
or function, which is not that silly of an idea - in fact you always use
the variable name to indicate its purpose, the Hungarian decoration
introduced some kind of naming convention with this respect.
For example, I read it was initially used to identify the coordinate
system some point would belong to (page, print margins, ...) in MS
Office applications.

It ended up being misused to encode the variable type in its name, which
is indeed questionable at best, and definitely unfit for generic
programming.

[Öö Tiib]

I have also only read about it somewhere. Charles Simonyi is over 70
years old, probably the idea has changed over time. By my impression
it was invented to have notation of "kind" of variable in BCPL
programming language (ancestor of C) that did not have types.
That made indeed perfect sense in type-less language but why should
same used in C or C++, where we have static types?

> For example, I read it was initially used to identify the coordinate
> system some point would belong to (page, print margins, ...) in MS
> Office applications.

There can be lot of meta information about variables and types of
those so it is perhaps hard to mangle that into variable name.
Different people have different idea what is important enough
to indicate it and how to indicate it and so it is perhaps best
to indicate nothing. IDEs tend to show type of variable under
cursor anyway.

> It ended up being misused to encode the variable type in its name, which
> is indeed questionable at best, and definitely unfit for generic
> programming.

I haven't seen a single case where it did not feel cryptic and
hard to follow.

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<qvqlni$ofi$2...@dont-email.me> thusly:

>Huh ? Don't tell that to Hungarian notation folks.
> https://en.wikipedia.org/wiki/Hungarian_notation

It was always a bad idea. Even MS has disavowed it at this point.
The C# coding style guidelines specifically tell you *not* to use
this.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Tim Rentsch]

Manfred <non...@add.invalid> writes:

> On 1/16/2020 11:11 PM, <<D6 F6 [05b6]>> Tiib wrote:
>
>> On Thursday, 16 January 2020 23:48:52 UTC+2, Lynn McGuire wrote:
>>
>>> On 1/15/2020 8:42 PM, Daniel wrote:
>>>
>>>> On Wednesday, January 15, 2020 at 9:32:02 PM UTC-5, T wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Would some kind individual please fill in
>>>>> the C++ variables names that go with these
>>>>> C variable names?
>>>>>
>>>>> int8_t in C
>>>>
>>>> ...
>>>>
>>>>> Do I just drop the "_t"?
>>>>
>>>> In general it's considered to be bad practice to adorn a variable name
>>>> with type information.
>>>

>>> Huh ? Don't tell that to Hungarian notation folks.
>>> https://en.wikipedia.org/wiki/Hungarian_notation
>>
>> Yes, but the Hungarian notation guys are frowned upon in majority of
>> collectives. By
>> <https://en.wikipedia.org/wiki/Hungarian_notation#Notable_opinions>
>> Bjarne Stroustrup does not recommend it.
>> It can be tricky for three star programmer to understand what they
>> do without such notation OTOH it is unclear if it does help.
>> <https://wiki.c2.com/?ThreeStarProgrammer>
>
> Note that, as far as I read somewhere, the Hungarian notation was
> initially introduced to indicate the "intention or kind" of a variable
> or function, which is not that silly of an idea - in fact you always
> use the variable name to indicate its purpose, the Hungarian
> decoration introduced some kind of naming convention with this
> respect.

In languages with static typing, type names can (and IMO should)
be used to indicate the purpose of identifiers declared with
those type names. Redundantly adding type or purpose information
to an identifier name is, well, redundant.

These comments don't apply to the orginal context (BCPL) of
Hungarian notation, since BCPL doesn't have any notion of
static typing.

> For example, I read it was initially used to identify the coordinate
> system some point would belong to (page, print margins, ...) in MS
> Office applications.

Hungarian notation predates Microsoft as a company, let alone
Microsoft word. It may be the case the Hungarian notation was
used to indicate a coordinate value (as opposed to, say, a string
length), but it was certainly not initially in any Microsoft
product.