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

Groups > comp.lang.c++ > #71369 > unrolled thread

C++ variable names

Back to article view | Back to comp.lang.c++

Contents

  C++ variable names T <T@invalid.invalid> - 2020-01-15 18:31 -0800
    Re: C++ variable names Daniel <danielaparker@gmail.com> - 2020-01-15 18:42 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 18:46 -0800
        Re: C++ variable names Daniel <danielaparker@gmail.com> - 2020-01-15 21:30 -0800
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:52 -0800
        Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-15 23:44 -0700
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 22:59 -0800
            Re: C++ variable names Bo Persson <bo@bo-persson.se> - 2020-01-16 08:44 +0100
              Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:48 -0800
              Re: C++ variable names David Brown <david.brown@hesbynett.no> - 2020-01-16 10:08 +0100
            Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-16 00:43 -0700
              Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:51 -0800
                Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-16 01:39 -0700
                  Re: C++ variable names T <T@invalid.invalid> - 2020-01-16 14:01 -0800
      Re: C++ variable names Lynn McGuire <lynnmcguire5@gmail.com> - 2020-01-16 15:48 -0600
        Re: C++ variable names Öö Tiib <ootiib@hot.ee> - 2020-01-16 14:11 -0800
          Re: C++ variable names Lynn McGuire <lynnmcguire5@gmail.com> - 2020-01-17 18:52 -0600
          Re: C++ variable names Manfred <noname@add.invalid> - 2020-01-18 16:22 +0100
            Re: C++ variable names Öö Tiib <ootiib@hot.ee> - 2020-01-18 10:41 -0800
            Re: C++ variable names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 05:31 -0800
        Re: C++ variable names David Brown <david.brown@hesbynett.no> - 2020-01-16 23:32 +0100
        Re: C++ variable names legalize+jeeves@mail.xmission.com (Richard) - 2020-01-19 19:13 +0000
    Re: C++ variable names red floyd <no.spam@its.invalid> - 2020-01-15 18:45 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 18:47 -0800
      Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:51 -0800
        Re: C++ variable names red floyd <no.spam@its.invalid> - 2020-01-15 22:44 -0800
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:00 -0800
    Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 19:40 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 19:58 -0800
        Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 20:12 -0800
      Re: C++ variable names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 23:18 -0500
        Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 20:20 -0800
          Re: C++ variable names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 12:06 -0800
            Re: C++ variable names T <T@invalid.invalid> - 2020-01-16 14:02 -0800
        Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 20:31 -0800
          Re: C++ variable names David Brown <david.brown@hesbynett.no> - 2020-01-16 11:09 +0100
    Re: C++ variable names Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:52 +0000
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 19:59 -0800
        Re: C++ variable names Bo Persson <bo@bo-persson.se> - 2020-01-16 06:33 +0100
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:53 -0800
    Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 06:18 +0100
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:54 -0800
        Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 06:59 +0100
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 22:31 -0800
            Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-16 00:15 -0800
            Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 11:25 +0100
              Re: C++ variable names Mister2U@honorific.org - 2020-01-16 11:47 +0000
                Re: C++ variable names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-16 13:31 +0100
                  Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-16 15:51 -0800
                    Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-16 15:51 -0800
                    Re: C++ variable names Manfred <invalid@add.invalid> - 2020-01-17 01:31 +0100
    Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:48 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 21:55 -0800
        Re: C++ variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-16 00:01 -0800
      Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 22:28 -0800
        Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 22:31 -0800
    Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 23:16 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:26 -0800
        Re: C++ variable names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-15 23:34 -0800
          Re: C++ variable names T <T@invalid.invalid> - 2020-01-15 23:53 -0800
            Re: C++ variable names Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2020-01-16 03:04 -0700
    C++ variable names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 11:51 -0800
      Re: C++ variable names T <T@invalid.invalid> - 2020-01-16 13:58 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#71369 — C++ variable names

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

[toc] | [next] | [standalone]

#71370

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

[toc] | [prev] | [next] | [standalone]

#71372

On 2020-01-15 18:42, 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
> 


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)?

[toc] | [prev] | [next] | [standalone]

#71383

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

[toc] | [prev] | [next] | [standalone]

#71387

On 2020-01-15 21:30, Daniel wrote:
> 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
> 
> 
> 

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?

[toc] | [prev] | [next] | [standalone]

#71397

On Wed, 15 Jan 2020 18:46:12 -0800, T <T@invalid.invalid> wrote:

>On 2020-01-15 18:42, 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
>> 
>
>
>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)?

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

[toc] | [prev] | [next] | [standalone]

#71398

On 2020-01-15 22:44, Louis Krupp wrote:
> On Wed, 15 Jan 2020 18:46:12 -0800, T <T@invalid.invalid> wrote:
> 
>> On 2020-01-15 18:42, 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
>>>
>>
>>
>> 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)?
> 
> 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
> 

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

[toc] | [prev] | [next] | [standalone]

#71403

On 2020-01-16 at 07:59, T wrote:
> On 2020-01-15 22:44, Louis Krupp wrote:
>> On Wed, 15 Jan 2020 18:46:12 -0800, T <T@invalid.invalid> wrote:
>>
>>> On 2020-01-15 18:42, 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
>>>>
>>>
>>>
>>> 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)?
>>
>> 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
>>
> 
> 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.

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.


> 
> 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
> 

[toc] | [prev] | [next] | [standalone]

#71405

On 2020-01-15 23:44, Bo Persson wrote:
> On 2020-01-16 at 07:59, T wrote:
>> On 2020-01-15 22:44, Louis Krupp wrote:
>>> On Wed, 15 Jan 2020 18:46:12 -0800, T <T@invalid.invalid> wrote:
>>>
>>>> On 2020-01-15 18:42, 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
>>>>>
>>>>
>>>>
>>>> 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)?
>>>
>>> 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
>>>
>>
>> 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.
> 
> 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 paper I am writing deal with WinAPI call.
I personally adore Fedora, but most of
my customers are Windows.

[toc] | [prev] | [next] | [standalone]

#71412

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.

[toc] | [prev] | [next] | [standalone]

#71404

On Wed, 15 Jan 2020 22:59:58 -0800, T <T@invalid.invalid> wrote:

>On 2020-01-15 22:44, Louis Krupp wrote:
>> On Wed, 15 Jan 2020 18:46:12 -0800, T <T@invalid.invalid> wrote:
>> 
>>> On 2020-01-15 18:42, 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
>>>>
>>>
>>>
>>> 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)?
>> 
>> 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
>> 
>
>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.

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

[toc] | [prev] | [next] | [standalone]

#71406

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

[toc] | [prev] | [next] | [standalone]

#71411

On Wed, 15 Jan 2020 23:51:44 -0800, T <T@invalid.invalid> wrote:

>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.

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

Louis

[toc] | [prev] | [next] | [standalone]

#71428

On 2020-01-16 00:39, Louis Krupp wrote:
> On Wed, 15 Jan 2020 23:51:44 -0800, T <T@invalid.invalid> wrote:
> 
>> 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.
> 
> Can you give an example of what you're talking about?
> 
> Louis
> 

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 );

[toc] | [prev] | [next] | [standalone]

#71425

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

[toc] | [prev] | [next] | [standalone]

#71430

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.
> > 
> > Daniel
> 
> 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>

[toc] | [prev] | [next] | [standalone]

#71449

On 1/16/2020 4:11 PM, Öö 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.
>>>
>>> Daniel
>>
>> 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>

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

Lynn

[toc] | [prev] | [next] | [standalone]

#71453

On 1/16/2020 11:11 PM, Öö 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.
>>>
>>> Daniel
>>
>> 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.
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.

[toc] | [prev] | [next] | [standalone]

#71454

On Saturday, 18 January 2020 17:22:30 UTC+2, Manfred  wrote:
> On 1/16/2020 11:11 PM, Öö 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.
> >>>
> >>> Daniel
> >>
> >> 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.

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.

[toc] | [prev] | [next] | [standalone]

#71486

Manfred <noname@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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web