Naming convention for structs and types

[Fernando D. Bozzo]

Hi:

I made this struct:


typedef struct justfname_s
{
char *value;
int len;
} justfname_t;


and want to know if it's correct to end struct's names with "_s" and types with "_t".
In what I've read until now, I didn't see any clear convention.

Thanks.-

[Rick C. Hodgin]

There are conventions people use apart from C standards. You can
also define structs without typedef commands if you switch to a
C++ compiler to compile your C code.

I typically use:

struct SWhatever
{
// members go here
};

And then in C++ you can reference it thusly:

SWhatever *w = malloc(sizeof(*w));
if (w)
{
// You're good
}

I use the SWhatever because it's a convention in C++ to use CWhatever
for classes.

It's not very popular in this comp.lang.c group to postulate using a
C++ compiler for C code, but I do very highly recommend it. It adds
a lot, and you lose nothing except possibly compile time (C++
compilers are often notably slower than C compilers).

Best regards,
Rick C. Hodgin

[luser droog]

The trailing _t is actually reserved for the implementation,
so I see (and use) a prefix like 's_' or 't_' instead more
often.

Establishing a convention for naming things in your code is
very very good. Make sure it's something you can type easily.

For my own code, I avoid extra decorations like this as much
as possible mostly because I have to shift to type '_'.

[Richard Heathfield]

The C Standard allows both, although some _t (e.g. size_t, time_t) are
reserved. The POSIX Standard uses _t quite a lot, and /may/ even reserve
all _t somewhere in its nearly 4000 pages, although I couldn't find any
such reservation when I had a quick look.

You could, of course, put the t at the front: t_justfname

This has the merit of being distinctive, while definitely being
different from any ISO C or POSIX type.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Richard Heathfield]

On 12/01/17 20:01, luser droog wrote:
<snip>

>
> The trailing _t is actually reserved for the implementation,

Certainly true for int*_t and uint*_t, but do you have a citation for
the more general claim?

[Thiago Adams]

On Thursday, January 12, 2017 at 5:48:38 PM UTC-2, Fernando D. Bozzo wrote:
> Hi:
>
> I made this struct:
>
>
> typedef struct justfname_s
> {
> char *value;
> int len;
> } justfname_t;
>
>
> and want to know if it's correct to end struct's names with "_s" and types with "_t".

You can use the same name.

typedef struct X
{
struct X* pNext;
} X;

[Keith Thompson]

Richard Heathfield <r...@cpax.org.uk> writes:
> On 12/01/17 20:01, luser droog wrote:
> <snip>
>>
>> The trailing _t is actually reserved for the implementation,
>
> Certainly true for int*_t and uint*_t, but do you have a citation for
> the more general claim?

I think it's a POSIX rule.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Consistency is the most important thing.

If you define a struct with both a tag name (the identifier following
the "struct" keyword) and a typedef name, there's no requirement for
them to differ. This is perfectly valid:

typedef struct justfname {
char *value;
int len;
} justfname;

and lets you refer to the type either as "struct justfname" or as
"justfname".

On the other hand, using the same identifier for both might confuse some
IDEs, particular search facilities.

If you're going to use a typedef, you also need a tag if you want to
refer to the type within its definition, particularly if the type
contains a pointer to itself. You could write:

typedef struct {
char *value;
int len;
} justfname;

but it's probably best to be consistent, using a tag whether there
happens to be a pointer member or not.

Finally, you don't have to use a typedef at all:

struct justfname {
char *value;
int len;
};

The type already has a perfectly good name, "struct justfname". Adding
a typedef merely gives it a second name, "justfname". In my opinion,
this saves a little typing, but that's not a good enough reason to give
something two separate names -- and have to think about conventions for
how those names relate to each other.

The counterargument is that it's worthwhile for the type to have a name
that's a single identifier. That's a perfectly valid position, and
plenty of good programmers use typedefs for that reason. <OT>And C++
lets you refer to the type as "justfname" even without a typedef.</OT>

[Richard Heathfield]

On 12/01/17 20:50, Keith Thompson wrote:
> Richard Heathfield <r...@cpax.org.uk> writes:
>> On 12/01/17 20:01, luser droog wrote:
>> <snip>
>>>
>>> The trailing _t is actually reserved for the implementation,
>>
>> Certainly true for int*_t and uint*_t, but do you have a citation for
>> the more general claim?
>
> I think it's a POSIX rule.

So do I, but I can't find any reference to it in the POSIX Standard.
That, of course, is not a matter for this group. It seems to me, though,
that luser_droog was claiming it was a C rule, and it was that claim (if
I have understood him correctly) for which I was seeking a citation.

[Keith Thompson]

Richard Heathfield <r...@cpax.org.uk> writes:
> On 12/01/17 20:50, Keith Thompson wrote:
>> Richard Heathfield <r...@cpax.org.uk> writes:
>>> On 12/01/17 20:01, luser droog wrote:
>>> <snip>
>>>>
>>>> The trailing _t is actually reserved for the implementation,
>>>
>>> Certainly true for int*_t and uint*_t, but do you have a citation for
>>> the more general claim?
>>
>> I think it's a POSIX rule.
>
> So do I, but I can't find any reference to it in the POSIX Standard.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html

Search for the phrase "ANY header" at the bottom of the table in section
2.2.2.

[...]

[Richard Heathfield]

On 12/01/17 21:26, Keith Thompson wrote:
> Richard Heathfield <r...@cpax.org.uk> writes:
>> On 12/01/17 20:50, Keith Thompson wrote:
>>> Richard Heathfield <r...@cpax.org.uk> writes:
>>>> On 12/01/17 20:01, luser droog wrote:
>>>> <snip>
>>>>>
>>>>> The trailing _t is actually reserved for the implementation,
>>>>
>>>> Certainly true for int*_t and uint*_t, but do you have a citation for
>>>> the more general claim?
>>>
>>> I think it's a POSIX rule.
>>
>> So do I, but I can't find any reference to it in the POSIX Standard.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>
> Search for the phrase "ANY header" at the bottom of the table in section
> 2.2.2.

Ah yes. Page 451 (of 3718). Sometimes the ISO C Standard looks
positively friendly. :-)

[jadi...@gmail.com]

On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:

There's not a definitive convention of struct names and typedefs other than
avoiding leading underscores. It can be frowned upon by some people to use
_t at the end, since the style is used in the C standard, so there's a small
possibility that future standards could clash.

One such contrived scenario would be making an unsigned 32-bit integer in
a struct from 2 unsigned 16-bit integers in a C90 compiler environment and
naming the struct type 'uint32_t'. Then C99 comes along and if you
#include <stdint.h> ...

Just to add another option is that you can make the struct type typedef
conditional using the preprocessor.

\code

struct justfname_s
{
char *value;
int len;

};

#if defined(ALIAS_MY_STRUCT_TYPES)
typedef struct justfname_s justfname_s;
#endif
\endcode

I prefer to use the full struct name in header and implementation files at
the library level, mostly because I run into structs that contain a
pointer to itself (linked list is the classic example), and I want to be
consistent.

I tend to use a typedef for struct types more in application level code
for brevity in files that include the library. Some struct identifiers
can be absurdly long! As a general rule, I never make typedef of struct
pointer types because I've been bitten by them too often (but will for
function pointer types, the syntax for declaring a function that returns
a function pointer is just too much for me).

Best regards,
John D.

[John Bode]

On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, Fernando D. Bozzo wrote:

There really isn't a clear convention. POSIX introduced the "_t"
suffix for type names; it's an open question as to whether that was a good
idea or not. After all, we got by *just fine* with plain old "int",
"float", "double", etc. Not sure what "uint8_t" buys you over just "uint8".

I'm not fond of the convention myself, at least not anymore. I would prefer
typedef names be meaningful in and of themselves without needing any special
suffix, although I'd use mixed case to set it apart visually:

typedef struct justfname { char *value; int len } JustFName;
...
JustFName name;

You can't use the tag name "justfname" without the "struct" keyword, so
adding "_s" to the end of it is a bit redundant. "struct justfname_s" just
adds visual clutter without adding any new information (kind like saying
"PIN number" or "ATM machine").

The main guideline is to be consistent. If you use the "_t" convention,
use it consistently. If you use mixed case, use it consistently.

[Keith Thompson]

John Bode <jfbod...@gmail.com> writes:
> On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, Fernando D. Bozzo wrote:
>> I made this struct:
>>
>>
>> typedef struct justfname_s
>> {
>> char *value;
>> int len;
>> } justfname_t;
>>
>>
>> and want to know if it's correct to end struct's names with "_s" and
>> types with "_t". In what I've read until now, I didn't see any clear
>> convention.
>

> There really isn't a clear convention. POSIX introduced the "_t"
> suffix for type names; it's an open question as to whether that was a good
> idea or not. After all, we got by *just fine* with plain old "int",
> "float", "double", etc. Not sure what "uint8_t" buys you over just "uint8".

It probably reduced the risk of conflicting with existing identifiers.
Pre-C99 code that used the specific name "uint8_t" was almost certainly
copying the upcoming C9x 8-bit type name; "uint8" might be an object
name. And it probably borrowed the "_t" suffix convention from POSIX.

[luser droog]

On Thursday, January 12, 2017 at 2:11:30 PM UTC-6, Richard Heathfield wrote:
> On 12/01/17 20:01, luser droog wrote:
> <snip>
> >
> > The trailing _t is actually reserved for the implementation,
>
> Certainly true for int*_t and uint*_t, but do you have a citation for
> the more general claim?
>

No. Quite possibly I have borrowed someone's opinion
from somewhere without sufficient skepticism.

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:

<snip>

>> typedef struct justfname_s
>> {
>> char *value;
>> int len;
>> } justfname_t;
>>
>>
>> and want to know if it's correct to end struct's names with "_s" and
>> types with "_t".
>> In what I've read until now, I didn't see any clear convention.
>
> There are conventions people use apart from C standards. You can
> also define structs without typedef commands if you switch to a
> C++ compiler to compile your C code.

Then what you are writing is not C.

> I typically use:
>
> struct SWhatever
> {
> // members go here
> };
>
> And then in C++ you can reference it thusly:
>
> SWhatever *w = malloc(sizeof(*w));
> if (w)
> {
> // You're good
> }

Exactly: you can do that "in C++".

> It's not very popular in this comp.lang.c group to postulate using a
> C++ compiler for C code, but I do very highly recommend it.

You can write C and compile it with C++, but you are suggesting writing
C++. Anyone following this advice will be writing code that won't
compile with a C compiler.

Using a typedef you could write C that will compile as C++ and still be
valid C.

<snip>
--
Ben.

[Keith Thompson]

Ben Bacarisse <ben.u...@bsb.me.uk> writes:
[...]

> Using a typedef you could write C that will compile as C++ and still be
> valid C.

You can do the same without using a typedef.

struct foo {
int n;
};
struct foo obj;

is valid C and valid C++. (It might not be considered *good* C++;
`foo obj;` probably would be but as you've pointed out that's not
valid C.)

On the other hand, writing code that compiles both as C and as C++ is
IMHO not useful as often as a lot of people think it is.

[Chris M. Thomasson]

On 1/12/2017 11:58 AM, Rick C. Hodgin wrote:
> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
>> Hi:
>>
>> I made this struct:
>>
>>
>> typedef struct justfname_s
>> {
>> char *value;
>> int len;
>> } justfname_t;
>>
>>
>> and want to know if it's correct to end struct's names with "_s" and types with "_t".
>> In what I've read until now, I didn't see any clear convention.
>
> There are conventions people use apart from C standards. You can
> also define structs without typedef commands if you switch to a
> C++ compiler to compile your C code.
>
> I typically use:
>
> struct SWhatever
> {
> // members go here
> };
>
> And then in C++ you can reference it thusly:
>
> SWhatever *w = malloc(sizeof(*w));

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6

What about the cast to SWhatever* and the missing std::?

In my experience, C++ does not really like for somebody to use
std::malloc without a cast.

;^)

[Richard Heathfield]

On 13/01/17 01:35, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:

<snip>

>> There are conventions people use apart from C standards. You can
>> also define structs without typedef commands if you switch to a
>> C++ compiler to compile your C code.
>
> Then what you are writing is not C.

Right.

>
>> I typically use:
>>
>> struct SWhatever
>> {
>> // members go here
>> };
>>
>> And then in C++ you can reference it thusly:
>>
>> SWhatever *w = malloc(sizeof(*w));
>> if (w)
>> {
>> // You're good
>> }
>
> Exactly: you can do that "in C++".

No, he can't, because in C++ he can't assign a void * value to an
SWhatever * without a cast. C++ is very fussy about things like that.

<snip>

[Rick C. Hodgin]

On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>
> > On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> <snip>
> >> typedef struct justfname_s
> >> {
> >> char *value;
> >> int len;
> >> } justfname_t;
> >>
> >>
> >> and want to know if it's correct to end struct's names with "_s" and
> >> types with "_t".
> >> In what I've read until now, I didn't see any clear convention.
> >
> > There are conventions people use apart from C standards. You can
> > also define structs without typedef commands if you switch to a
> > C++ compiler to compile your C code.
>
> Then what you are writing is not C.

Correct! (on a handful of such points ... syntax relaxations that
C++ provides for C-like code)

> > I typically use:
> >
> > struct SWhatever
> > {
> > // members go here
> > };
> >
> > And then in C++ you can reference it thusly:
> >
> > SWhatever *w = malloc(sizeof(*w));
> > if (w)
> > {
> > // You're good
> > }
>
> Exactly: you can do that "in C++".

As Chris Thomasson points out, you can't. You actually need:

SWhatever *w = (SWhatever*)malloc(sizeof(*w));

> > It's not very popular in this comp.lang.c group to postulate using a
> > C++ compiler for C code, but I do very highly recommend it.
>
> You can write C and compile it with C++, but you are suggesting writing
> C++. Anyone following this advice will be writing code that won't
> compile with a C compiler.

Correct. And, if I may add, who cares? Any person following this
advice would've switched from a C to C++ compiler by choice, and
then moved forward.

C's syntax in a half dozen areas is very clunky. C++ adds relaxations
which make it so much easier. And, it's what C should've been had
they done it right from the get-go.

> Using a typedef you could write C that will compile as C++ and still be
> valid C.

Typedefs are silly in this case. A "struct SWhatever" is all that's
needed with a C++ compiler. It simplifies C's clunky syntax and
removes the need for typedef.

Seriously, who wants to type:

typedef struct coughcoughchoke1 {
// members
} coughcoughchoke2;

When this will do:

struct awesomeness {
// members
}

? I guess there /are/ some people, right Ben? :-)

[Rick C. Hodgin]

Correct. My mistake in that post. That's actually one of the main
reasons I use a C++ compiler for writing C code (stricter typing).

I also think C's requirement of using the keyword struct everywhere
is lunacy. And requiring a typedef to not use it, and two names,
is even more lunacy. But hey, that's just me. :-)

[Chris M. Thomasson]

Okay.

> I also think C's requirement of using the keyword struct everywhere
> is lunacy.

Why?

> And requiring a typedef to not use it, and two names,
> is even more lunacy. But hey, that's just me. :-)

Yup. :^)

[Rick C. Hodgin]

struct Why?

struct Because struct it's struct very struct cluttered. struct It struct
becomes struct superfluous, struct or, struct extra struct unnecessary
struct information struct that struct doesn't struct really struct
add struct anything struct (as C++ demonstrates for us so very clearly
by it not requiring the keyword anywhere except the definition, which
is as it should be).

struct Best struct regards,
struct Rick struct C. struct Hodgin

[Chris M. Thomasson]

use C++ then? Ahh, struct it!

[Ian Collins]

On 01/13/17 08:58 AM, Rick C. Hodgin wrote:

<>

Other comments are all good.

> I use the SWhatever because it's a convention in C++ to use CWhatever
> for classes.

No it isn't a convention, it is an artifact of MFC naming many of us C++
programmers despise.

> It's not very popular in this comp.lang.c group to postulate using a
> C++ compiler for C code, but I do very highly recommend it. It adds
> a lot, and you lose nothing except possibly compile time (C++
> compilers are often notably slower than C compilers).

Not when compiling what amounts to C.

--
Ian

[Ian Collins]

A lot depends how you use the names. If you are going to stick to the
typedef name, I would use "Justfname" and possibly prepend the struct
name (if I named it) with and underscore to make it awkward to use! I
like the convention of using a capitalised name for types.

If you are going to use the typedef name, the only reason to name the
struct is if you want to include it within the structure declaration,
such as

typedef struct _justfname
{
char* value;
int len;
struct _justfname* parent;
} Justfname;

Otherwise I would just write

typedef struct
{
char* value;
int len;

} Justfname;


--
Ian

[Fernando D. Bozzo]

El viernes, 13 de enero de 2017, 4:27:17 (UTC+1), Rick C. Hodgin escribió:
<snip>

> C's syntax in a half dozen areas is very clunky. C++ adds relaxations
> which make it so much easier. And, it's what C should've been had
> they done it right from the get-go.
>

Because I'm new in this language, there is not much I can rebate, but I think that I one takes into account that C whas developed at the very beginning of the computer history, before personal computers, with many hardware restrictions and before OOP and many more advanced concepts, I think that Ritchie made a very good job with this.

I really enjoyed the reading of this paper and did make me understand some limitations and design decisions at that time:

https://www.bell-labs.com/usr/dmr/www/chist.html

Best Regards.-

[Fernando D. Bozzo]

I'm trying to mentally map some things between FoxPro (4th.gen.lang), which is what I know best for now, and C, because over the years I've switched from structured programming (xBase at 80's) mindset to OOP at 90's and for most things I like the OOP approach, clean concepts and maintanability.

For example, in VFP you have less data types than in C, so the recommended naming convention is the Hungarian which precedes any var name with the scope+type+var.name, like:

lcName => local/character/Name
ldBirth => local/date/Birth
toParams => local parameter/object/Params
...

I accept that every language is a different world and have their own rules, and normally one that most languajes have is a naming convention, some of them Microsoft influenced (which is not bad for me) and some Community driven, but the key question for me is that following a clear naming eases team development.
Even if many times I program alone outside my work, I tend to write code as if it where for another dev, and this good practices and others help a lot.

Back to case of typedef/struct, I have this clear:

1) Struct syntax (alone) require the use of a reference name => struct name {..}
2) Typedef syntax require the name of an alias => typedef int myint
3) The mix of 1 and 2 can be with or without the struct reference name

but I prefer to add always the reference name so it's one error-prone-less way to write in whatever condition, like:

a)
typedef struct _singlell
{
int key;
struct _name next;
} singlell

b)
typedef struct _myint
{
int value;
} myint

In b) I can take out the reference to _myint, but not in a) because the type references itself before the alias is created, so for not thinking every time in this special cases I go for sure and use the reference always, knowing that this will work in every situation.


Thanks all for the tips.

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:

<snip>

>> > There are conventions people use apart from C standards. You can
>> > also define structs without typedef commands if you switch to a
>> > C++ compiler to compile your C code.
>>
>> Then what you are writing is not C.
>
> Correct!

<snip>

>> You can write C and compile it with C++, but you are suggesting writing
>> C++. Anyone following this advice will be writing code that won't
>> compile with a C compiler.
>
> Correct. And, if I may add, who cares?

People who want to write C, of course. All the evidence suggests that
includes the OP to whom you gave this bad advice.

There is hardly any code posted here that could not be simplified by
writing it in C++ but what would be the point of that?

<snip>
--
Ben.

[David Brown]

On 13/01/17 04:26, Rick C. Hodgin wrote:
> On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>>
>>> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
>> <snip>
>>>> typedef struct justfname_s
>>>> {
>>>> char *value;
>>>> int len;
>>>> } justfname_t;
>>>>
>>>>
>>>> and want to know if it's correct to end struct's names with "_s" and
>>>> types with "_t".
>>>> In what I've read until now, I didn't see any clear convention.
>>>
>>> There are conventions people use apart from C standards. You can
>>> also define structs without typedef commands if you switch to a
>>> C++ compiler to compile your C code.
>>
>> Then what you are writing is not C.
>
> Correct! (on a handful of such points ... syntax relaxations that
> C++ provides for C-like code)
>

C++ provides a lot of possibilities that C does not have, even if you
stick to "C-like" programming (no OOP, exceptions, overloading,
templates, etc.). But then it is not C, it is a subset of C++.

And what "syntax relaxations" are you talking about?

>>> I typically use:
>>>
>>> struct SWhatever
>>> {
>>> // members go here
>>> };
>>>
>>> And then in C++ you can reference it thusly:
>>>
>>> SWhatever *w = malloc(sizeof(*w));
>>> if (w)
>>> {
>>> // You're good
>>> }
>>
>> Exactly: you can do that "in C++".
>
> As Chris Thomasson points out, you can't. You actually need:
>
> SWhatever *w = (SWhatever*)malloc(sizeof(*w));
>
>>> It's not very popular in this comp.lang.c group to postulate using a
>>> C++ compiler for C code, but I do very highly recommend it.
>>
>> You can write C and compile it with C++, but you are suggesting writing
>> C++. Anyone following this advice will be writing code that won't
>> compile with a C compiler.
>
> Correct. And, if I may add, who cares? Any person following this
> advice would've switched from a C to C++ compiler by choice, and
> then moved forward.

Then why not just write in C++ rather than picking a vague restricted
subset that is mostly like C, but not quite - and is missing a few
useful C features into the bargain?

>
> C's syntax in a half dozen areas is very clunky. C++ adds relaxations
> which make it so much easier. And, it's what C should've been had
> they done it right from the get-go.
>

Can you name these? You have given one example, but that is based on
your apparent misunderstanding about struct tags and typedefs in C.
What else are you referring to? (I am not saying that such benefits of
C++ over C do not exist, I am just asking which /you/ think are
particularly useful.)

>> Using a typedef you could write C that will compile as C++ and still be
>> valid C.
>
> Typedefs are silly in this case. A "struct SWhatever" is all that's
> needed with a C++ compiler. It simplifies C's clunky syntax and
> removes the need for typedef.
>
> Seriously, who wants to type:
>
> typedef struct coughcoughchoke1 {
> // members
> } coughcoughchoke2;
>
> When this will do:
>
> struct awesomeness {
> // members
> }
>
> ? I guess there /are/ some people, right Ben? :-)
>

Why not use:

typedef struct {
// members
} awesomeness;

There is no need to give the struct a tag in most cases (though you need
it for forward declarations for recursive types). It is simple, clear,
and defines the same name that is used in the same way whether you
compile as C or C++.

Also note that if you /want/ a struct tag, there is nothing wrong with:

typedef struct awesomeness {
// members
} awesomeness;

i.e., the same name for the tag and the typedef. Again, this is fine in
C and C++ and code using it can do so in exactly the same way.

[David Brown]

Some people prefer to have the struct keyword wherever they use a
struct. Similarly, they prefer to have a * when pointers are used.
Other people prefer to use typedef's and omit the struct, and perhaps
have typedefs for pointer types too.

Pick whichever form /you/ think makes your code clearer, your
programming easier, and your results less buggy. That applies whether
you write in C, C++, or a C-like subset of C++.

[David Brown]

On 12/01/17 21:11, Richard Heathfield wrote:
> On 12/01/17 20:01, luser droog wrote:
> <snip>
>>
>> The trailing _t is actually reserved for the implementation,
>
> Certainly true for int*_t and uint*_t, but do you have a citation for
> the more general claim?
>

It turns up in a few other standard types (size_t, ptrdiff_t, etc.). It
is not unreasonable to expect that it is a convention the C standards
would follow in the future for other new types. But it is not a
convention that is reserved in the C standards.

[Richard Heathfield]

Do you mean that you agree with him that using a C++ compiler for C code
is a good idea? If so, why, and what do you do with C code that isn't
legal C++, or that has different meanings in C and C++?

[Thiago Adams]

On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
[...]

> >>> I typically use:
> >>>
> >>> struct SWhatever
> >>> {
> >>> // members go here
> >>> };
> >>>
> >>> And then in C++ you can reference it thusly:

C++ needs to know the type name before enter
into the type definition for contructor, destructor operators..

struct X
{
X(){ }
~X(){ }
operator == (X* ) {}
//etc..
};

The same for C when we need

struct X
{
struct X * pNext;
}


An alternative syntax that could have been used for C is:

typedef struct X;
typedef struct { X *pNext; } X;

Today we can use: (very repetitive)

typedef struct X X;
typedef struct X { X *pNext; } X;

or a "Self" keyword for the type could exists.

[David Brown]

On 13/01/17 14:03, Thiago Adams wrote:
> On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
> [...]
>>>>> I typically use:
>>>>>
>>>>> struct SWhatever
>>>>> {
>>>>> // members go here
>>>>> };
>>>>>
>>>>> And then in C++ you can reference it thusly:
>
>
> C++ needs to know the type name before enter
> into the type definition for contructor, destructor operators..
>

Yes, but that is no longer the "sort-of C" subset of C++. When you are
using methods in your structs, you are clearly in C++ and not a language
that is a few syntax variations away from C.

> struct X
> {
> X(){ }
> ~X(){ }
> operator == (X* ) {}
> //etc..
> };
>
> The same for C when we need
>

As I mentioned - you need the tag for recursive structures.

> struct X
> {
> struct X * pNext;
> }
>
>
> An alternative syntax that could have been used for C is:
>
> typedef struct X;
> typedef struct { X *pNext; } X;
>
> Today we can use: (very repetitive)
>
> typedef struct X X;
> typedef struct X { X *pNext; } X;
>
> or a "Self" keyword for the type could exists.
>

If we wanted an alternative syntax in C, then the obvious choice would
be to allow "struct X { X * pNext; };" and make the "struct" keyword
optional when using the type - just like in C++. That would cause
conflicts for people who like to take advantage of the separate struct
tag namespace and write things like "struct X X;" to define a variable X
of type "struct X".

[Mr. Man-wai Chang]

On 13/1/2017 3:48 AM, Fernando D. Bozzo wrote:
> typedef struct justfname_s
> {
> char *value;
> int len;
> } justfname_t;
> and want to know if it's correct to end struct's names with "_s" and types with "_t".
> In what I've read until now, I didn't see any clear convention.

Check out Hungarian notation:
https://en.wikipedia.org/wiki/Hungarian_notation

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[Gareth Owen]

As I'm sure you're aware, it is reserved in POSIX.1

[David Brown]

I am aware of that since people mentioned it in this thread, but I was
not aware before that. I don't program to POSIX, so I'm not fussed
about that - but I appreciate that a great deal of C coding should
follow POSIX standards as well as the C standards. The original
"general claim" looked like it referred to the C standards rather than
anything else, so it is good to get it all cleared up.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> Pick whichever form /you/ think makes your code clearer, your
> programming easier, and your results less buggy. That applies whether
> you write in C, C++, or a C-like subset of C++.

Or, more commonly, use whatever convention already exists in the code
you're working on, whether you like it or not. If you're working by
yourself on your own project, impose whatever conventions you like. If
you're not (and that's the most common case), consistency is important.

[Rick C. Hodgin]

On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
> On 13/01/17 04:26, Rick C. Hodgin wrote:
> > On Thursday, January 12, 2017 at 8:35:47 PM UTC-5, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
> >>
> >>> On Thursday, January 12, 2017 at 2:48:38 PM UTC-5, Fernando D. Bozzo wrote:
> >> <snip>
> >>>> typedef struct justfname_s
> >>>> {
> >>>> char *value;
> >>>> int len;
> >>>> } justfname_t;
> >>>>
> >>>>
> >>>> and want to know if it's correct to end struct's names with "_s" and
> >>>> types with "_t".
> >>>> In what I've read until now, I didn't see any clear convention.
> >>>
> >>> There are conventions people use apart from C standards. You can
> >>> also define structs without typedef commands if you switch to a
> >>> C++ compiler to compile your C code.
> >>
> >> Then what you are writing is not C.
> >
> > Correct! (on a handful of such points ... syntax relaxations that
> > C++ provides for C-like code)
> >
>
> C++ provides a lot of possibilities that C does not have, even if you
> stick to "C-like" programming (no OOP, exceptions, overloading,
> templates, etc.). But then it is not C, it is a subset of C++.

I have said that in every post. I have said that if a person is
willing to move to a C++ compiler, then there are some benefits
from that migration. I have never tried to hide it.

> And what "syntax relaxations" are you talking about?

(1) Not using struct keyword everywhere, coupled to
(2) Not having to use typedef.
(3) Native bool type.
(4) Use of & types (int&, char&).
(5) Function overloading.
(6) Parameter initialization on definition line.

A few others I can't remember off the top of my head.

And some new benefits:
(7) Stricter typing.
(8) The class syntax (ptr->member and member() functions) if desired.
(9) Exception handling.

I prefer (7). I don't generally use (8) or (9), but it's nice to
know they are there. I've had to use (9) a couple times to catch
errors in Windows DLLs that were really non-issues, but would cause
the app to crash at runtime without catching their exceptions.

[David Brown]

You don't have to use "struct" keyword everywhere. When I program in C,
I rarely need it any more than in C++ - because I like to typedef my
structs. So this is a non-issue.

> (2) Not having to use typedef.

Having to write "typedef" when defining structs and enum types is such a
negligible issue that this is also a non-issue.

> (3) Native bool type.

C has _Bool, and after #include <stdbool.h> you have bool, true, false
just like in C++. So this is also a non-issue.

> (4) Use of & types (int&, char&).

Using references instead of pointers /is/ a useful feature, and I agree
it is clearly an advantage C++ has over C.

But that is moving from the "I use a C++ compiler to compile C" category
into "I use some features of C++ in my coding". It is not just a minor
tweak that is nice when you use a C++ compiler for C.

And if you are programming in C++, why not admit it and call it C++
rather than "C programming with a C++ compiler" ?

> (5) Function overloading.

The same applies here as with (4).

> (6) Parameter initialization on definition line.

What, like "int x = foo();" rather than "int x; x = foo();" or defining
your variables at the start of a function? (I'm thinking local
variables here.) C has supported that for so long that I don't know
when it was introduced. Freely mixing declarations and statements is
from C99. (The lack of such mixing is one of my key dislikes about C90.)

However, when you are using Microsoft's tools, their C99 support has
been very poor until quite recently (as far as I have heard - I have no
personal experience). So if you are comparing C as supported by
slightly out-of-date MS tools to C++, then I can see this point. But if
you are comparing /C/ to C++, then this is definitely a non-issue.

>
> A few others I can't remember off the top of my head.
>
> And some new benefits:
> (7) Stricter typing.

True - /if/ you are using C++ features.

> (8) The class syntax (ptr->member and member() functions) if desired.

That's C++, not C compiled by a C++ compiler.

> (9) Exception handling.

That's C++, not C compiled by a C++ compiler.

>
> I prefer (7). I don't generally use (8) or (9), but it's nice to
> know they are there. I've had to use (9) a couple times to catch
> errors in Windows DLLs that were really non-issues, but would cause
> the app to crash at runtime without catching their exceptions.
>

Basically, what you are saying is that you like some C++ features and
like to use them in your coding, even though you also /dislike/ certain
other C++ features and you avoid them.

That's fine - but you are programming in C++ with limitations. You are
not using a C++ compiler to compile your C code.

And that applies even if you think that some or all of these features
should be part of C.

[David Brown]

On 13/01/17 17:59, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> [...]
>> Pick whichever form /you/ think makes your code clearer, your
>> programming easier, and your results less buggy. That applies whether
>> you write in C, C++, or a C-like subset of C++.
>
> Or, more commonly, use whatever convention already exists in the code
> you're working on, whether you like it or not. If you're working by
> yourself on your own project, impose whatever conventions you like. If
> you're not (and that's the most common case), consistency is important.
>

Agreed.

[James Kuyper]

On 01/13/2017 01:43 AM, Ian Collins wrote:
...

> If you are going to use the typedef name, the only reason to name the
> struct is if you want to include it within the structure declaration,
> such as
>
> typedef struct _justfname
> {
> char* value;
> int len;
> struct _justfname* parent;
> } Justfname;

For that kind of purpose, I prefer:

typedef struct Justfname
{
char* value;
int len;
struct Justfname* parent;
} Justfname;

[supe...@casperkitty.com]

On Friday, January 13, 2017 at 11:49:19 AM UTC-6, James Kuyper wrote:
> For that kind of purpose, I prefer:
>
> typedef struct Justfname
> {
> char* value;
> int len;
> struct Justfname* parent;
> } Justfname;

How about

typedef struct Justfname Justfname;

struct Justfname
{
char* value;
int len;

Justfname* parent;
};

Though it wouldn't really matter what tag was used since there would be
no need to refer to it in any source file except in the above two spots.

[Rick C. Hodgin]

On Friday, January 13, 2017 at 12:47:52 PM UTC-5, David Brown wrote:
> On 13/01/17 18:20, Rick C. Hodgin wrote:
> > On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
> >> And what "syntax relaxations" are you talking about?
> >
> > (1) Not using struct keyword everywhere, coupled to
>
> You don't have to use "struct" keyword everywhere. When I program in C,
> I rarely need it any more than in C++ - because I like to typedef my
> structs. So this is a non-issue.

You do unless you use a typdef.

> > (2) Not having to use typedef.
>
> Having to write "typedef" when defining structs and enum types is such a
> negligible issue that this is also a non-issue.

We differ in opinions here.

> > (3) Native bool type.
>
> C has _Bool, and after #include <stdbool.h> you have bool, true, false
> just like in C++. So this is also a non-issue.

_Bool is not bool. It's close, but it doesn't have to be one byte.
And, it's not included with Visual Studio.

> > (4) Use of & types (int&, char&).

> > (5) Function overloading.

> > (6) Parameter initialization on definition line.
>
> What, like "int x = foo();" rather than "int x; x = foo();" or defining
> your variables at the start of a function? (I'm thinking local
> variables here.) C has supported that for so long that I don't know
> when it was introduced. Freely mixing declarations and statements is
> from C99. (The lack of such mixing is one of my key dislikes about C90.)

This:

int myfunc(int a, int b = 3, char* c = NULL);

With usage:

myfunc(5);

It automatically populates b and c for you.

> Basically, what you are saying is that you like some C++ features and
> like to use them in your coding, even though you also /dislike/ certain
> other C++ features and you avoid them.

I think C should have these features, as they are very C-like, and
are not really C++-like. C++-like features are in the class and its
many features.

> That's fine - but you are programming in C++ with limitations. You are
> not using a C++ compiler to compile your C code.

99% of what I write is C code. The 1% that's not is as I indicate
above. And, as I have stated repeatedly, even asking for some of
these features to be considered for inclusion on comp.std.c, I
believe these should be C features.

> And that applies even if you think that some or all of these features
> should be part of C.

I am not confined in my thinking of what C should be based on what
the C standard says. I look at C as a type of thing, rather than
the explicitly defined thing. I look at the C Standard as a thing,
and C itself to be more of a philosophy.

I intend to introduce these features into CAlive, and be done with
it. And my offering here to Fernando D. Bozzo is an offering to
simplify his programming life in C by using these few features of
a C++ compiler, and by switching to a C++ compiler to use them.

I have done this successfully since the 90s. It's just not "kosher"
with the C-strict group. And ... I'm not only okay with that, I am
more than okay with that because I look at strict C as a dying language
because it is too constrictive. C++ took great strides toward greater
simplicity, but went too far.

Something better meeting the needs of human beings is what's required.
And those are my goals with CAlive. And they've been the goals of a
few dozen other spawned off projects.

[James Kuyper]

On 01/13/2017 04:00 AM, Fernando D. Bozzo wrote:
...

> I'm trying to mentally map some things between FoxPro (4th.gen.lang), which is what I know best for now, and C, because over the years I've switched from structured programming (xBase at 80's) mindset to OOP at 90's and for most things I like the OOP approach, clean concepts and maintanability.
>
> For example, in VFP you have less data types than in C, so the recommended naming convention is the Hungarian which precedes any var name with the scope+type+var.name, like:
>
> lcName => local/character/Name
> ldBirth => local/date/Birth
> toParams => local parameter/object/Params

Hungarian notation has been proposed for and used in C programming, as
well. Many people adopted the practice, and many still use it, but I
don't think it's really caught on - I think there's a widespread (but
certainly NOT universal) opinion that it was a bad idea.

> ...
> I accept that every language is a different world and have their own rules, and normally one that most languajes have is a naming convention, some of them Microsoft influenced (which is not bad for me) and some Community driven, but the key question for me is that following a clear naming eases team development.
> Even if many times I program alone outside my work, I tend to write code as if it where for another dev, and this good practices and others help a lot.
>
> Back to case of typedef/struct, I have this clear:
>
> 1) Struct syntax (alone) require the use of a reference name => struct name {..}

What you call the reference name is referred to by the standard as a
struct tag. Unions and enumerations also have tags.

> 2) Typedef syntax require the name of an alias => typedef int myint
> 3) The mix of 1 and 2 can be with or without the struct reference name
>
> but I prefer to add always the reference name so it's one error-prone-less way to write in whatever condition, like:
>
> a)
> typedef struct _singlell
> {
> int key;
> struct _name next;

Was that intended to be:
struct _singlell *next;

Your comments below would make more sense with that declaration.

> } singlell

I would write that this way:

typedef struct singlell
{
int key;
struct singlell *next;

[Malcolm McLean]

On Friday, January 13, 2017 at 1:00:07 PM UTC, Richard Heathfield wrote:
> On 13/01/17 06:30, Ian Collins wrote:
>
> Do you mean that you agree with him that using a C++ compiler for C code
> is a good idea? If so, why, and what do you do with C code that isn't
> legal C++, or that has different meanings in C and C++?
>

It's a reasonable idea. It means you can cut and paste C routines into C++
programs. Also, some C++ compilers seem to throw wobblies when asked to
link with C. I got a complaint that the math library had been doubly defined,
for example. Eventually you fiddle with it and the link errors go away, but
that's not a productive use of programmer time.

C code that does something different in C++ is usually a bad idea, or joke
code. But you can have the problem that C works fine on what C++ folks
call PODs, plain old data, but breaks down when machinery is attached to
the data. In my view, a fundamental misdesign of C++, but impossible to
eradicate now. (C++ people are beginning to address the issue with the
"data" and "view" concept).

But the risk of accidentally using a C++ only construct in what is supposedly
C code outweighs the benefits of using a C++ compiler.

[Richard Heathfield]

On 13/01/17 18:43, Malcolm McLean wrote:
> On Friday, January 13, 2017 at 1:00:07 PM UTC, Richard Heathfield wrote:
>> On 13/01/17 06:30, Ian Collins wrote:
>>
>> Do you mean that you agree with him that using a C++ compiler for C code
>> is a good idea? If so, why, and what do you do with C code that isn't
>> legal C++, or that has different meanings in C and C++?
>>
> It's a reasonable idea. It means you can cut and paste C routines into C++
> programs.

That's a bad idea in itself! Compile the C as C, and link it into the
C++ program. Why duplicate the code?

> Also, some C++ compilers seem to throw wobblies when asked to
> link with C.

Not when you ask nice.

> I got a complaint that the math library had been doubly defined,
> for example. Eventually you fiddle with it and the link errors go away, but
> that's not a productive use of programmer time.

But you write it down somewhere, and then other people look up what
you've written, and they don't have to fiddle.

> C code that does something different in C++ is usually a bad idea, or joke
> code.

I don't write C code with the intent of being able to compile it in C++.
As a consequence, sometimes it isn't legal C++ code. It isn't joke code,
either, so presumably you're saying it's a bad idea. Why?

[David Brown]

On 13/01/17 19:02, Rick C. Hodgin wrote:
> On Friday, January 13, 2017 at 12:47:52 PM UTC-5, David Brown wrote:
>> On 13/01/17 18:20, Rick C. Hodgin wrote:
>>> On Friday, January 13, 2017 at 6:50:00 AM UTC-5, David Brown wrote:
>>>> And what "syntax relaxations" are you talking about?
>>>
>>> (1) Not using struct keyword everywhere, coupled to
>>
>> You don't have to use "struct" keyword everywhere. When I program in C,
>> I rarely need it any more than in C++ - because I like to typedef my
>> structs. So this is a non-issue.
>
> You do unless you use a typdef.
>
>>> (2) Not having to use typedef.
>>
>> Having to write "typedef" when defining structs and enum types is such a
>> negligible issue that this is also a non-issue.
>
> We differ in opinions here.

Apparently so.

Nonetheless, you certainly don't get to count (1) and (2) as two
different issues - it is a single combined point that I believe most
people would consider minor.

>
>>> (3) Native bool type.
>>
>> C has _Bool, and after #include <stdbool.h> you have bool, true, false
>> just like in C++. So this is also a non-issue.
>
> _Bool is not bool. It's close, but it doesn't have to be one byte.
> And, it's not included with Visual Studio.

_Bool in C works like bool in C++. In neither case do they have to be
single byte (not that the size of "byte" is fixed in C). In practice,
both /are/ a single byte. I certainly know of no C/C++ compiler that
implements C _Bool in any other way than C++ bool.

The failings of MSVC to implement 20 year old C standards is not a
failing of C. It /is/ a reason to use MSVC C++ mode rather than MSVC C
mode to compile your C code - if you are stuck with only a very limited
C compiler. But you should be clear that C /has/ a native Boolean type
that is exactly like that of C++, even if you are unable to use it with
your choice of C compiler.

>
>>> (4) Use of & types (int&, char&).
>>> (5) Function overloading.
>>> (6) Parameter initialization on definition line.
>>
>> What, like "int x = foo();" rather than "int x; x = foo();" or defining
>> your variables at the start of a function? (I'm thinking local
>> variables here.) C has supported that for so long that I don't know
>> when it was introduced. Freely mixing declarations and statements is
>> from C99. (The lack of such mixing is one of my key dislikes about C90.)
>
> This:
>
> int myfunc(int a, int b = 3, char* c = NULL);
>
> With usage:
>
> myfunc(5);
>
> It automatically populates b and c for you.

This is a different thing - it is default parameters. And that goes
along with most of your points as a useful feature of C++ - but nothing
to do with using a C++ compiler to compile C code.

>
>> Basically, what you are saying is that you like some C++ features and
>> like to use them in your coding, even though you also /dislike/ certain
>> other C++ features and you avoid them.
>
> I think C should have these features, as they are very C-like, and
> are not really C++-like. C++-like features are in the class and its
> many features.

I don't disagree that they might be /useful/ in C, and that these
features are all nice points in C++. Whether they are "C-like" is much
less clear, as is the question of whether C would be a "better" language
if they were included. I suspect that if they were considered
sufficiently C-like, and sufficiently useful in C style programming,
then compilers such as gcc would allow at least some of them as
extensions. (It already allows a little flexibility of some features
between C and C++ and between different standards of C and C++.)

The fact that these features are considered integral parts of C++, but
are not part of C at all, suggests that by definition they are C++-like
and not C-like.

>
>> That's fine - but you are programming in C++ with limitations. You are
>> not using a C++ compiler to compile your C code.
>
> 99% of what I write is C code. The 1% that's not is as I indicate
> above. And, as I have stated repeatedly, even asking for some of
> these features to be considered for inclusion on comp.std.c, I
> believe these should be C features.
>
>> And that applies even if you think that some or all of these features
>> should be part of C.
>
> I am not confined in my thinking of what C should be based on what
> the C standard says. I look at C as a type of thing, rather than
> the explicitly defined thing. I look at the C Standard as a thing,
> and C itself to be more of a philosophy.
>

C /is/ defined by the standards. That is what C is.

I believe I understand what you are trying to say here, I just don't
think you are using the right words to describe the way you like to
program. Structured procedural programming, perhaps? I am not sure.

> I intend to introduce these features into CAlive, and be done with
> it. And my offering here to Fernando D. Bozzo is an offering to
> simplify his programming life in C by using these few features of
> a C++ compiler, and by switching to a C++ compiler to use them.

For the umpteenth time, it is not an "offering" - this is not a temple.
You are giving advice or suggestions, like everyone else.

If he is interested in C programming, your advice is bad - you are
suggesting he breaks from the language that all other C programmers use.
If he is interested in C++ programming, your advice is bad - you are
suggesting he hobbles his programming and misses most of the point of
the language. /You/ can choose to program in a language that is mostly
C but with some C++ bits thrown in - but it is not something that should
be recommended to someone starting out in C programming.

[Rick C. Hodgin]

On Friday, January 13, 2017 at 3:42:22 PM UTC-5, David Brown wrote:
> On 13/01/17 19:02, Rick C. Hodgin wrote:
> > I intend to introduce these features into CAlive, and be done with
> > it. And my offering here to Fernando D. Bozzo is an offering to
> > simplify his programming life in C by using these few features of
> > a C++ compiler, and by switching to a C++ compiler to use them.
>

> For the umpteenth time, it is not an "offering"...

By definition it is an offering, David:

http://www.dictionary.com/browse/offering

noun
4. something presented for inspection or sale.

verb
2. to propose or put forward for consideration

I have offered this option / alternative to Fernando D. Bozzo for his
inspection. He can look it over and decide if the advice is good or
not.

I continue to pray for you, David.

[Malcolm McLean]

On Friday, January 13, 2017 at 6:52:14 PM UTC, Richard Heathfield wrote:
> On 13/01/17 18:43, Malcolm McLean wrote:
>
> > Also, some C++ compilers seem to throw wobblies when asked to
> > link with C.
>
> Not when you ask nice.
>

The problem is that modern compilers have a whole massive list of options,
If the options are not set up correctly, it fails with confusing
messages (currently my XCode compiler is reporting a fail because
some post-processing script doesn't find the right file, but in fact
produces a workable plug-in).
Then half the time the options are not set directly but via CMake,
which is effectively a programming language for building IDE files.

When things go wrong, as they frequently do, it is very time-consuming.

[supe...@casperkitty.com]

On Friday, January 13, 2017 at 2:42:22 PM UTC-6, David Brown wrote:
> C /is/ defined by the standards. That is what C is.

By that definition, are there any programs for freestanding implementations
which are not semantically equivalent to one of the following:

int main(void) { while(1); } // Guaranteed not to do anything

int main(void) { int x; x++; } // Allowed by the Standard to do anything

The second program might qualify as conforming (an implementation could
defines the effects of incrementing an uninitialized variable and
returning from main) but would certainly not be strictly conforming. The
former program would be strictly conforming, but not terribly useful.

Anything useful that could be done on freestanding implementations would
require the use of features not defined by the Standard. If the term C
does not include anything beyond the Standard, what would be the point of
defining freestanding implementations at all?

[Ian Collins]

On 01/14/17 02:00 AM, Richard Heathfield wrote:
> On 13/01/17 06:30, Ian Collins wrote:
>> On 01/13/17 08:58 AM, Rick C. Hodgin wrote:
>>
>> <>
>>
>> Other comments are all good.
>>
>>> I use the SWhatever because it's a convention in C++ to use CWhatever
>>> for classes.
>>
>> No it isn't a convention, it is an artifact of MFC naming many of us C++
>> programmers despise.
>>
>>> It's not very popular in this comp.lang.c group to postulate using a
>>> C++ compiler for C code, but I do very highly recommend it. It adds
>>> a lot, and you lose nothing except possibly compile time (C++
>>> compilers are often notably slower than C compilers).
>>
>> Not when compiling what amounts to C.
>
> Do you mean that you agree with him that using a C++ compiler for C code
> is a good idea?

In general, no it isn't a good idea. If you have a C++ compiler, you
may as well use C++...

> If so, why, and what do you do with C code that isn't
> legal C++, or that has different meanings in C and C++?

The times where I have (as I've mentioned here before) is where I have
been using some form of simulation for devices that requires C++. The
compromise there was not using code that has different meanings in C and
C++.

--
Ian

[Ian Collins]

In a word, bollocks. If C++ compilers "throw wobblies when asked to
link with C", no hosted C++ program would ever link. What do you think
system libraries are written in, Martian?

--
Ian

[BartC]

He didn't say it can't be done, but that it can give problems.

Of course, if your entire job is spent day in and day out using and
configuring all these different tools, then you're going to think it's easy.

To a more casual user, the problems may be insurmountable.

--
Bartc

[Ian Collins]

In a word, more bollocks. Just writing a simple C++ hello world program
and then doing

CC helloWorld.cc

will be linking C and C++ libraries. There are no "massive list of
options", it just works.

--
Ian

[Malcolm McLean]

Exactly.

The program consists of both C and C++ files, both of which need to be
compiled and linked. Firstly you've got to specify C linkage, which
you wouldn't necessarily know unless someone had told you. Then as
I said,a few weeks ago I got an error claiming the math library
functions had been multiply defined. The C code in question wasn't
mine, and I actually resolved the issue by changing the file extension
to C++ and compiling as C++. Doubtless with more fiddling I would have
found the underlying reason, but it's not a good use of my time.

It helps if you either always use the same set up, or if you've got
someone whose job it is to configure programs so that they work.
But for many people, these don't apply. It's very easy to underestimate
the costs of using a library, however.

[Ian Collins]

Exactly what?

> The program consists of both C and C++ files, both of which need to be
> compiled and linked. Firstly you've got to specify C linkage, which
> you wouldn't necessarily know unless someone had told you.

Only if you want C++ functions to link to C. If a C++ programmer didn't
know about linkage, he/she shouldn't be programming.

> Then as
> I said,a few weeks ago I got an error claiming the math library
> functions had been multiply defined. The C code in question wasn't
> mine, and I actually resolved the issue by changing the file extension
> to C++ and compiling as C++. Doubtless with more fiddling I would have
> found the underlying reason, but it's not a good use of my time.

So there was an issue with some third party C code, nothing to do with C++.

> It helps if you either always use the same set up, or if you've got
> someone whose job it is to configure programs so that they work.

Anyone form a summer student up should be able to manage that.

> But for many people, these don't apply. It's very easy to underestimate
> the costs of using a library, however.

It's even easier to underestimate the costs of reimplementing a library

--
Ian

[Chris M. Thomasson]

On 1/13/2017 10:43 AM, Malcolm McLean wrote:
> On Friday, January 13, 2017 at 1:00:07 PM UTC, Richard Heathfield wrote:
>> On 13/01/17 06:30, Ian Collins wrote:
>>
>> Do you mean that you agree with him that using a C++ compiler for C code
>> is a good idea? If so, why, and what do you do with C code that isn't
>> legal C++, or that has different meanings in C and C++?
>>
> It's a reasonable idea. It means you can cut and paste C routines into C++
> programs. Also, some C++ compilers seem to throw wobblies when asked to
> link with C. I got a complaint that the math library had been doubly defined,
> for example. Eventually you fiddle with it and the link errors go away, but
> that's not a productive use of programmer time.

True. IMHO, these are some good points you raise Malcolm.

> C code that does something different in C++ is usually a bad idea, or joke
> code. But you can have the problem that C works fine on what C++ folks
> call PODs, plain old data, but breaks down when machinery is attached to
> the data. In my view, a fundamental misdesign of C++, but impossible to
> eradicate now. (C++ people are beginning to address the issue with the
> "data" and "view" concept).
>
> But the risk of accidentally using a C++ only construct in what is supposedly
> C code outweighs the benefits of using a C++ compiler.

Well, I remember accidentally compiling a C library with a C++ compiler,
and thought this thing is totally screwed! Found the problem a couple of
minutes later, recompiled and BAM! Everything worked, compiled, and
rendered a correct image after 103 minutes or so.

I was in a state of panic when I thought that the compilation was
correct in its list of errors. Then, a C compiler rescued me. And by the
way, the code was never meant to be C++.

[Fernando D. Bozzo]

El viernes, 13 de enero de 2017, 19:03:43 (UTC+1), James Kuyper escribió:
<snip>

> >
> > a)
> > typedef struct _singlell
> > {
> > int key;
> > struct _name next;
>
> Was that intended to be:
> struct _singlell *next;

Yes! I mean that. Mistyped it when changing from "_name" to "_singlell" and forgot the internal struct.

[Malcolm McLean]

Depends what the library is doing and who you have.

Some functions you have the skills to implement very quickly and easily,
others you don't. I'm currently in two minds about Open CV - if I was
doing full on image recognition then I'd use it, but I'm not, I only
want a few lines and corners and other features.

[BartC]

If I try this program, which I believe is C++:

$ cat hello.cc
#include <iostream>

int main(void) {
std::cout << "HELLO WORLD" << "\n";
}

And then use your suggestion (but with "cc" as "CC" is not found), I get
this:

$ cc hello.cc
/tmp/ccXxAgos.o: In function `main':
hello.cc:(.text+0xe): undefined reference to `std::cout'
hello.cc:(.text+0x13): undefined reference to `std::basic_ostream<char,
std::char_traits<char> >& std::operator<< <std::char_traits<char>
>(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
hello.cc:(.text+0x22): undefined reference to `std::basic_ostream<char,
std::char_traits<char> >& std::operator<< <std::char_traits<char>
>(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
/tmp/ccXxAgos.o: In function
`__static_initialization_and_destruction_0(int, int)':
hello.cc:(.text+0x52): undefined reference to `std::ios_base::Init::Init()'
hello.cc:(.text+0x67): undefined reference to `std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status

What is CC or cc? I don't even know. But if I try:

g++ hello.cc

then it works.

I'm sorry, but things *do* go wrong, even if you clearly don't believe me.

--
Bartc

[Malcolm McLean]

On Saturday, January 14, 2017 at 12:59:30 AM UTC, Bart wrote:
> On 13/01/2017 22:18, Ian Collins wrote:
> > On 01/14/17 11:00 AM, BartC wrote:
>
> >> To a more casual user, the problems may be insurmountable.
> >
> > In a word, more bollocks. Just writing a simple C++ hello world program
> > and then doing
> >
> > CC helloWorld.cc
> >
> > will be linking C and C++ libraries. There are no "massive list of
> > options", it just works.
>
> If I try this program, which I believe is C++:
>
> $ cat hello.cc
> #include <iostream>
>
> int main(void) {
> std::cout << "HELLO WORLD" << "\n";
> }
>
> And then use your suggestion (but with "cc" as "CC" is not found), I get
> this:
>
> $ cc hello.cc
>

> hello.cc:(.text+0x13): undefined reference to `std::basic_ostream<char,
> std::char_traits<char> >& std::operator<< <std::char_traits<char>
>

> I'm sorry, but things *do* go wrong, even if you clearly don't believe me.
>

That's the sort of thing that makes trouble shooting difficult.

A pure C compiler would simply report std as an unidentified symbol
and :: as a syntax error. Because the compiler is not C++ naive
it throws that at you. char_traits<char> is a red herring, but how
are you to know unless you've got bitter experience?

[Ben Bacarisse]

Do you not know how to find out? My system has a manual system for
explaining commands.

> But if I try:
>
> g++ hello.cc
>
> then it works.
>
> I'm sorry, but things *do* go wrong, even if you clearly don't believe
> me.

Ian was calling your claim of insurmountable problems linking C and C++
bollocks and yet here you are, surmounting them with ease. Surely even
the most casual user would eventually find out the name of the
compiler.

--
Ben.

[Ian Collins]

Well if you don't know the names of the compilers on your system, why
bother?

--
Ian

[Ian Collins]

On 01/14/17 02:12 PM, Malcolm McLean wrote:
> On Saturday, January 14, 2017 at 12:59:30 AM UTC, Bart wrote:
>> On 13/01/2017 22:18, Ian Collins wrote:
>>> On 01/14/17 11:00 AM, BartC wrote:
>>
>>>> To a more casual user, the problems may be insurmountable.
>>>
>>> In a word, more bollocks. Just writing a simple C++ hello world program
>>> and then doing
>>>
>>> CC helloWorld.cc
>>>
>>> will be linking C and C++ libraries. There are no "massive list of
>>> options", it just works.
>>
>> If I try this program, which I believe is C++:
>>
>> $ cat hello.cc
>> #include <iostream>
>>
>> int main(void) {
>> std::cout << "HELLO WORLD" << "\n";
>> }
>>
>> And then use your suggestion (but with "cc" as "CC" is not found), I get
>> this:
>>
>> $ cc hello.cc
>>
>> hello.cc:(.text+0x13): undefined reference to `std::basic_ostream<char,
>> std::char_traits<char> >& std::operator<< <std::char_traits<char>
>>
>> I'm sorry, but things *do* go wrong, even if you clearly don't believe me.
>>
> That's the sort of thing that makes trouble shooting difficult.

Utter nonsense. It's the sort off thing that happens when someone
without a clue uses the wrong tool.

--
Ian

[Chris M. Thomasson]

Agreed. IMVHO, the art of being able to adapt ones "self-style" to an
existing teams "foreign" coding style is an _essential_ skill for anyone
to posses.

[Thiago Adams]

On Friday, January 13, 2017 at 1:00:42 PM UTC-2, David Brown wrote:
> On 13/01/17 14:03, Thiago Adams wrote:
> > On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
> > [...]
> >>>>> I typically use:
> >>>>>
> >>>>> struct SWhatever
> >>>>> {
> >>>>> // members go here
> >>>>> };
> >>>>>
> >>>>> And then in C++ you can reference it thusly:
> >
> >
> > C++ needs to know the type name before enter
> > into the type definition for contructor, destructor operators..

Although the name is "typedef" a better name would be
typealias.
Typedef is always a alias for type. This alias can have
pointers and qualifiers.

So:

typedef struct X { int i; } X, *X2;

X is a alias for struct X and X2 is a
alias for pointer to struct X.
X2 is not a new type.

typedef int int;
int is a alias for int

C and C++ are equal on this.

We cannot create a new type "X pointer".
We can only create type X.

I cannot create a constructor and
destructor for a "type pointer" in C++ because
"type pointer" cannot be created.

So C++ invented "smart pointers" (fake pointers)
to change the semantics of pointers creating
fake pointers classes.
In C++ I cannot override on typedef for int as
well only override on classes and enuns.

Is this "alias" behavior what we really want?
Or the possibility to create new types with new
properties would be much more useful?

We could create
typedef int meters;
typedef int seconds;

and they could be different types, not alias for int.
You can convert meters to int but not to seconds.

Could we have "pointer to X" as a new type?

[supe...@casperkitty.com]

On Friday, January 13, 2017 at 8:29:05 PM UTC-6, Thiago Adams wrote:
> Is this "alias" behavior what we really want?
> Or the possibility to create new types with new
> properties would be much more useful?
>
> We could create
> typedef int meters;
> typedef int seconds;
>
> and they could be different types, not alias for int.
> You can convert meters to int but not to seconds.
>
> Could we have "pointer to X" as a new type?

Extending that principle, it would be useful to be able to allow a
compiler to assume that, in the absence of evidence to the contrary,
a "meters*" won't be used to access a "seconds", nor will a "second*"
be used to access a "meters", but an "int*" could be used to access
either type, and a "meters*" or "seconds*" could be used to access an
"int".

For that to be workable, the aliasing rules would need to be adjusted in
some other ways, but such adjustments would allow more optimizations while
reducing the number of situations requiring "-fno-strict-aliasing".

[BartC]

On 14/01/2017 01:36, Ben Bacarisse wrote:
> BartC <b...@freeuk.com> writes:
>
>> On 13/01/2017 22:18, Ian Collins wrote:

>>> In a word, more bollocks. Just writing a simple C++ hello world program
>>> and then doing
>>>
>>> CC helloWorld.cc

>> I'm sorry, but things *do* go wrong, even if you clearly don't believe
>> me.
>
> Ian was calling your claim of insurmountable problems linking C and C++
> bollocks and yet here you are, surmounting them with ease. Surely even
> the most casual user would eventually find out the name of the
> compiler.

This was the simplest of all possible tasks, yet Ian dished out the
wrong advice, or advice that that didn't work. Suggesting CC when cc
doesn't exist, and cc is apparently a synonym for gcc. Yet this was
supposed to be a C++ program.

man CC and man cc say nothing about CC or cc but show info about gcc.

Now imagine this advice was buried inside a makefile for hidden in a
script behind variables.

--
Bartc

[Gareth Owen]

BartC <b...@freeuk.com> writes:

> On 13/01/2017 22:18, Ian Collins wrote:
>> On 01/14/17 11:00 AM, BartC wrote:
>

> $ cc hello.cc

> What is CC or cc? I don't even know. But if I try:
>
> g++ hello.cc
>

> I'm sorry, but things *do* go wrong, even if you clearly don't believe me.

Really???
Your complaint is "If I want my C++ code to link I have to know the name
of my C++ compiler and call it"? Why not point out that

python hello.cc

doesn't work either?

Even by your standards, that's embarrassing.

[BartC]

Ian said this:

>Just writing a simple C++ hello world program
> and then doing
>
> CC helloWorld.cc

>will be linking C and C++ libraries. ... it just works.

Obviously it didn't.

I tried it out because I was puzzled by the use of the .cc extension,
and was wondering why he would use what looks like a C compiler (even I
can vaguely recall cc from Unix) on what he said was C++ code.

And even if somehow CC had worked and managed to produce an executable,
I still don't see how this is linking a C library, as the program makes
use of std::cout.

In short, there were half a dozen points of confusion in about as many
lines, and people are making out that it's /me/ talking bollocks!

--
Bartc

[Jean-Marc Bourguet]

BartC <b...@freeuk.com> writes:

> I tried it out because I was puzzled by the use of the .cc extension, and
> was wondering why he would use what looks like a C compiler (even I can
> vaguely recall cc from Unix) on what he said was C++ code.

CC (as opposed to cc, Unix is case sensitive) is the traditional name of
the C++ compiler on Unix. It was used for instance by CFront (cfront was
the executable generated C, CC was the driver calling cfront and then the C
compiler) and Sun's compiler. I've seen other compilers installing a
compatibility link for CC to their true name.

Numerous extensions have been used for C++ source, I've met .c, .C, .c++,
.cc, .cxx, .cpp. And for headers: .h, .H, .h++, .hh, .hxx, .hpp, .inc
(often for a special purpose); some are using specialized headers for
inlines: .inl, .ixx, .ipp; and specialized headers for templates: .txx,
.tpp. And obviously the standard headers have no extension, and some have
followed the example (Qt for instance).

Yours,

--
Jean-Marc

[David Brown]

On 13/01/17 19:03, James Kuyper wrote:
> On 01/13/2017 04:00 AM, Fernando D. Bozzo wrote: ...
>> I'm trying to mentally map some things between FoxPro
>> (4th.gen.lang), which is what I know best for now, and C, because
>> over the years I've switched from structured programming (xBase at
>> 80's) mindset to OOP at 90's and for most things I like the OOP
>> approach, clean concepts and maintanability.
>>
>> For example, in VFP you have less data types than in C, so the
>> recommended naming convention is the Hungarian which precedes any
>> var name with the scope+type+var.name, like:
>>
>> lcName => local/character/Name ldBirth => local/date/Birth toParams
>> => local parameter/object/Params
>
> Hungarian notation has been proposed for and used in C programming,
> as well. Many people adopted the practice, and many still use it, but
> I don't think it's really caught on - I think there's a widespread
> (but certainly NOT universal) opinion that it was a bad idea.

There are two types of Hungarian notation. "Systems Hungarian notation"
is when you name your variables or functions in terms of the types.
"unsigned long ulCount;", and so on. It was popular on Windows for a
while, and is also used in some embedded programming. It made sense
when it was invented for BCPL which had no types, and has some merit if
you are limited to poor editors/IDEs and small screen space (such as in
the days of DOS and early Windows) as you often have no convenient
access to the declarations of variables and functions. But for most
work now you have easy access to the declarations, and thus little use
for cluttering your names with duplicate information. And there is a
widespread (but unfortunately not universal) opinion that unnecessary
clutter is bad.

I find two cases of "Systems Hungarian" particularly annoying. One is
its use in function names. Because C has nothing like namespaces it is
common to prefix names in a library, module, or other grouping -
queuePush(), queuePop(), queueFlush() for example. But if you use
Systems Hungarian, you lose that nice grouping as they are now named
bQueuePush(), iQueuePop() and vQueueFlush() for returning bool, int and
void.

The second annoying case is prefix "g" for globals and "l" for local
variables. If you can't see the definition of your local variable your
function is too long, and if you don't already know such fundamental
aspects of your variables, you should not be using them!


"Apps Hungarian notation" is about adding more application-related
information to your names, to give information that is not already there
as part of the type. The common example is to name strings received
from the outside as "usName" for "unsafe string", and after it has been
sanitised (to avoid SQL injection attacks or whatever), you then have
"ssName" for "safe string". I haven't seen this sort of notation in use
as much, though it can be helpful for some code.

[David Brown]

On 14/01/17 03:28, Thiago Adams wrote:
> On Friday, January 13, 2017 at 1:00:42 PM UTC-2, David Brown wrote:
>> On 13/01/17 14:03, Thiago Adams wrote:
>>> On Friday, January 13, 2017 at 9:50:00 AM UTC-2, David Brown wrote:
>>> [...]
>>>>>>> I typically use:
>>>>>>>
>>>>>>> struct SWhatever
>>>>>>> {
>>>>>>> // members go here
>>>>>>> };
>>>>>>>
>>>>>>> And then in C++ you can reference it thusly:
>>>
>>>
>>> C++ needs to know the type name before enter
>>> into the type definition for contructor, destructor operators..
>
> Although the name is "typedef" a better name would be
> typealias.

Agreed.

I would like that, as it gives a good deal more type-safety in the
language (at the cost of making some things more verbose). You can do
it in C++ with classes, but in C you can only make your new types using
struct wrappers:

typedef struct { int meters; } meters;

The usage then gets very verbose, and you still don't have any good way
to avoid assigning a length in meters to a time in seconds.

[David Brown]

You are using a different OS than Ian, who works in Solaris. Perhaps it
is standard in the Solaris world to make CC a symbolic link to the basic
system C++ compiler. On Linux, c++ is the common choice. (Symbolic
links are used because it could point to different versions of the
compiler, or different compilers.)

I don't think it is unreasonable to expect someone to know how to invoke
/their/ C++ compiler on /their/ system, if they want to program in C++.

And .cc is a common choice of extension for C++ files, along with .cpp,
.cxx, .c++ and .C

>
> And even if somehow CC had worked and managed to produce an executable,
> I still don't see how this is linking a C library, as the program makes
> use of std::cout.

There are many libraries involved in the final executable here - both
static libraries and dynamic libraries. Many of them will be in C.

>
> In short, there were half a dozen points of confusion in about as many
> lines, and people are making out that it's /me/ talking bollocks!
>

The confusion is only in your mind - because you work so hard to create it.

[Fernando D. Bozzo]

<snip>

Hi David:

Thanks for your answer, didn't know that existed 2 types of this notation, just used the System one I now know.

When you are using non-strict typed languages (like xBase) it's really useful to use this notation, because the same variable can be of type DATE but later can be of type CHAR or FLOAT, so keep some safety which can't be forced by the compiler, this naming really help developers to not confuse them.

(I'm talking from the xBase data types perspective here, because I know that at the end the data type is only numeric or char.)

One of many cases in which this is useful is when dealing with dates, which in xBase can be used in 3 different ways:
- Julian dates (numeric) => You need to convert it to date
- Char dates ("2017/01/14") => You need to convert it to date
- Standard dates ({^2017/01/14}) => {^2017/02/28} + 1 will return {^2017/03/01}

So, if yout program receive a date from the DOS command line, it always will be char (as every other parameter received in the same way), so you define your parameter as tcBirthday, but then you convert to xBase date so you get ldBirthday and this way you never mix tcBirthday with ldBirthday and you know some info about them:

- tcBirthday is a parameter (t) of type character (c) meant to store a birthday
- ldBirthday is a (l)ocal variable of type date meant to store a birthday

If you add that intellisense doesn't let you know the type of the data (except when debugging), thes this naming convention is almost critical to use.

[Gareth Owen]

BartC <b...@freeuk.com> writes:

>>Just writing a simple C++ hello world program
>> and then doing
>>
>> CC helloWorld.cc
>
>>will be linking C and C++ libraries. ... it just works.
>
> Obviously it didn't.

He said CC. You typed cc. Do you see the difference?
CC is a common name for a C++ compiler. (Not on your system, though)
cc is a common name for a C compiler. (Including your system).

Do you see the difference?

You assumed that he meant cc, and then told him he was wrong.

> I tried it out because I was puzzled by the use of the .cc extension,
> and was wondering why he would use what looks like a C compiler (even
> I can vaguely recall cc from Unix)

But not CC, evidently. That you assumed they were the same is you
problem, not his. As I said, your problem was not knowing that CC is a
C++ compiler.

> on what he said was C++ code.

So, guess what tool he used to build it.
Clue - not cc, the C compiler.

> And even if somehow CC had worked and managed to produce an
> executable, I still don't see how this is linking a C library, as the
> program makes use of std::cout.

Because the startup code will be a C library, and that will be linked too.
Because Unix kernels us the C-library-entry-point to start code.

[Gareth Owen]

David Brown <david...@hesbynett.no> writes:

>> In short, there were half a dozen points of confusion in about as many
>> lines, and people are making out that it's /me/ talking bollocks!
>>
>
> The confusion is only in your mind - because you work so hard to create it.

I no longer think he's working hard to create it. I think his state of
perpetual bafflement comes to him naturally.

[BartC]

I used to do a lot of customer support. I know the sort of things people
have difficulty with, and used to write user and reference manuals with
that in mind.

Now, in all the years I've been frequenting this group, I don't recall
the name 'CC' ever coming up. Compared with 'gcc' which might be almost
every other post.

Nor have I have ever comes across the file extension '.cc'.

This is exactly the sort of thing I would have added notes about if I
was doing the posting.

(Nice touch BTW of having .cc meaning a C++ source file, and cc meaning
a C compiler. You don't want to make this stuff too obvious!)

--
Bartc

[Ben Bacarisse]

BartC <b...@freeuk.com> writes:

> On 14/01/2017 01:36, Ben Bacarisse wrote:
>> BartC <b...@freeuk.com> writes:
>>
>>> On 13/01/2017 22:18, Ian Collins wrote:
>
>>>> In a word, more bollocks. Just writing a simple C++ hello world program
>>>> and then doing
>>>>
>>>> CC helloWorld.cc
>
>>> I'm sorry, but things *do* go wrong, even if you clearly don't believe
>>> me.
>>
>> Ian was calling your claim of insurmountable problems linking C and C++
>> bollocks and yet here you are, surmounting them with ease. Surely even
>> the most casual user would eventually find out the name of the
>> compiler.
>
> This was the simplest of all possible tasks, yet Ian dished out the
> wrong advice, or advice that that didn't work.

No he didn't. You are in full-blown politician mode. We both know he
was giving a counter-example, not "dishing out advice".

<snip>
--
Ben.

[Gareth Owen]

BartC <b...@freeuk.com> writes:

> I used to do a lot of customer support.

That chimes with my experience of customer support.

[Gareth Owen]

BartC <b...@freeuk.com> writes:

> (Nice touch BTW of having .cc meaning a C++ source file, and cc
> meaning a C compiler. You don't want to make this stuff too obvious!)

I use .cpp exclusively.
Nevertheless .cc meaning C++ is incredibly common.

That you've never seen it before is ... unremarkable.

[David Brown]

On 14/01/17 15:00, BartC wrote:
> On 14/01/2017 13:27, Gareth Owen wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>>>> In short, there were half a dozen points of confusion in about as many
>>>> lines, and people are making out that it's /me/ talking bollocks!
>>>>
>>>
>>> The confusion is only in your mind - because you work so hard to
>>> create it.
>>
>> I no longer think he's working hard to create it. I think his state of
>> perpetual bafflement comes to him naturally.
>
> I used to do a lot of customer support. I know the sort of things people
> have difficulty with, and used to write user and reference manuals with
> that in mind.
>
> Now, in all the years I've been frequenting this group, I don't recall
> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
> every other post.

CC for the C++ compiler is definitely a unixism. It is not unreasonable
that you don't know it if you are not familiar with Unix, and if you are
a DOS/Windows user you might even still believe that "cc" and "CC" would
refer to the same program.

Not knowing the command name for your own C++ compiler is, however,
ridiculous.

>
> Nor have I have ever comes across the file extension '.cc'.

I am sure you would have found that with the first hit on a google
search for "file extension .cc". You might also find the Wikipedia page
for C++ a good introduction. Among other things, it tells you that
".cc" is a common file extension for C++ files.

>
> This is exactly the sort of thing I would have added notes about if I
> was doing the posting.

I believe Ian assumed the readers had at least basic familiarity with
C++, C++ files, and C++ compilers.

[David Brown]

The name "Hungarian notation" can be used for many things - I'm sure you
can think of other uses too, and give them different names.

>
> When you are using non-strict typed languages (like xBase) it's
> really useful to use this notation, because the same variable can be
> of type DATE but later can be of type CHAR or FLOAT, so keep some
> safety which can't be forced by the compiler, this naming really help
> developers to not confuse them.

Yes, that's a little like BCPL which did not have types and was why the
notation was invented (if my history here is correct). I haven't seen
it much used in Python, however, even though you don't declare the types
of variables. (In Python, objects all have types - but you declare
variables or their types before use.)

>
> (I'm talking from the xBase data types perspective here, because I
> know that at the end the data type is only numeric or char.)
>
> One of many cases in which this is useful is when dealing with dates,
> which in xBase can be used in 3 different ways: - Julian dates
> (numeric) => You need to convert it to date - Char dates
> ("2017/01/14") => You need to convert it to date - Standard dates
> ({^2017/01/14}) => {^2017/02/28} + 1 will return {^2017/03/01}
>
> So, if yout program receive a date from the DOS command line, it
> always will be char (as every other parameter received in the same
> way), so you define your parameter as tcBirthday, but then you
> convert to xBase date so you get ldBirthday and this way you never
> mix tcBirthday with ldBirthday and you know some info about them:
>
> - tcBirthday is a parameter (t) of type character (c) meant to store
> a birthday - ldBirthday is a (l)ocal variable of type date meant to
> store a birthday
>
> If you add that intellisense doesn't let you know the type of the
> data (except when debugging), thes this naming convention is almost
> critical to use.
>

That sounds like a reasonable use of the notation. If it adds helpful
information that is not part of the language itself, that's good. If it
duplicates something that is more accurately and reliably expressed in
the language (such as the type in C), it's bad.

[BartC]

On 14/01/2017 15:18, David Brown wrote:
> On 14/01/17 15:00, BartC wrote:
>> On 14/01/2017 13:27, Gareth Owen wrote:
>>> David Brown <david...@hesbynett.no> writes:
>>>
>>>>> In short, there were half a dozen points of confusion in about as many
>>>>> lines, and people are making out that it's /me/ talking bollocks!
>>>>>
>>>>
>>>> The confusion is only in your mind - because you work so hard to
>>>> create it.
>>>
>>> I no longer think he's working hard to create it. I think his state of
>>> perpetual bafflement comes to him naturally.
>>
>> I used to do a lot of customer support. I know the sort of things people
>> have difficulty with, and used to write user and reference manuals with
>> that in mind.
>>
>> Now, in all the years I've been frequenting this group, I don't recall
>> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
>> every other post.
>
> CC for the C++ compiler is definitely a unixism. It is not unreasonable
> that you don't know it if you are not familiar with Unix, and if you are
> a DOS/Windows user you might even still believe that "cc" and "CC" would
> refer to the same program.

It just seems perverse. How would you say 'cc' or 'CC' over the phone
when instructing someone what to type?

>
> Not knowing the command name for your own C++ compiler is, however,
> ridiculous.

Where did you get that idea? I said I resorted 'g++' when cc and CC
didn't work.

But Linux seems confused about it itself; typing man cc, man CC or man
gcc or man g++ all bring up the same page:

gcc - GNU project C and C++ compiler

Which suggests that gcc does both. However it appears that gcc and g++
can't be used interchangeably, despite the man page saying that invoking
gcc on a file with a C++ extension (eg. .cc) will compile it as g++.
(And invoking g++ on a .c file doesn't seem to work with my C programs
either.)

(BTW the man info for gcc is about 350 pages!)

--
Bartc

[Malcolm McLean]

The point is the trivial is important. No-one is born knowing that
cc is the C compiler and .cc is the C++ extension. Or what
std::char_trait<char> is supposed to be achieving and why it might
appear in an error message.

Either someone hand holds you through the process, in which case you
get the same problems as soon as you get a step wrong, or you fiddle
and look things up and write short exploratory programs and do web
searches, and at the end of several hours, you've got the answer,
but you've run through hours of work time.

[Tim Rentsch]

John Bode <jfbod...@gmail.com> writes:

> On Thursday, January 12, 2017 at 1:48:38 PM UTC-6, Fernando D. Bozzo wrote:
>> Hi:
>>
>> I made this struct:
>>
>>
>> typedef struct justfname_s
>> {
>> char *value;
>> int len;
>> } justfname_t;
>>
>>
>> and want to know if it's correct to end struct's names with "_s" and
>> types with "_t". In what I've read until now, I didn't see any clear
>> convention.
>
> [...] You can't use the tag name "justfname" without the "struct"
> keyword, so adding "_s" to the end of it is a bit redundant.

Let me offer a counterpoint here. There can be tag names without
having a 'struct', because 'enum' and 'union' also use tags. The
namespace for tags is shared between enum, struct and union, so
a trailing "_s" is not as redundant as it might seem: it serves
to distinguish which of the three categories applies to the tag
in question (and similarly, eg, "_e" or "_u", would identify an
enum or a union). I recommend adopting some stylistic rule (to
be clear, for tag names) like the "_s" convention for just this
reason. Personally I think the "_s" differentiator is okay for
this, but the key point is to have a scheme that makes enum tags,
struct tags, and union tags, be distinct from each other.

[Gareth Owen]

BartC <b...@freeuk.com> writes:

> It just seems perverse. How would you say 'cc' or 'CC' over the phone
> when instructing someone what to type?

"type see see - just the letter 'see' twice in lowercase"
"type capital see, capital see"

I honestly can't believe I answered that question, since you were
clearly trying to make a rhetorical point.

Worth pointing out what a freaking terrible rhetorical point it was.

I am now kill-filing you, as you are clearly dimmer than a Toc-H lamp.

[Gareth Owen]

Malcolm McLean <malcolm...@btinternet.com> writes:

> Either someone hand holds you through the process,

"How do I link my C++ objects to C objects?"

"Run your system's C++ compiler."

So complex..

[Ian Collins]

On 01/15/17 12:48 AM, BartC wrote:
> On 14/01/2017 11:28, Gareth Owen wrote:
>> BartC <b...@freeuk.com> writes:
>>
>>> On 13/01/2017 22:18, Ian Collins wrote:
>> >> On 01/14/17 11:00 AM, BartC wrote:
>>>
>>> $ cc hello.cc
>>> What is CC or cc? I don't even know. But if I try:
>>>
>>> g++ hello.cc
>>>
>>> I'm sorry, but things *do* go wrong, even if you clearly don't believe me.
>>
>> Really???
>> Your complaint is "If I want my C++ code to link I have to know the name
>> of my C++ compiler and call it"? Why not point out that
>>
>> python hello.cc
>>
>> doesn't work either?
>>
>> Even by your standards, that's embarrassing.
>>
> Ian said this:
>
> >Just writing a simple C++ hello world program
> > and then doing
> >
> > CC helloWorld.cc
>
> >will be linking C and C++ libraries. ... it just works.
>
> Obviously it didn't.

It does on my system...

> I tried it out because I was puzzled by the use of the .cc extension,
> and was wondering why he would use what looks like a C compiler (even I
> can vaguely recall cc from Unix) on what he said was C++ code.

I assumed a basic level of intelligence and knowledge of the tools on
your system. I see now I overestimated both.

> And even if somehow CC had worked and managed to produce an executable,
> I still don't see how this is linking a C library, as the program makes
> use of std::cout.

How do you think the output gets delivered to the console?

> In short, there were half a dozen points of confusion in about as many
> lines, and people are making out that it's /me/ talking bollocks!

There is only one - your ignorance of your tools.

--
Ian

[BartC]

On 14/01/2017 18:50, Gareth Owen wrote:
> BartC <b...@freeuk.com> writes:
>
>> It just seems perverse. How would you say 'cc' or 'CC' over the phone
>> when instructing someone what to type?
>
> "type see see - just the letter 'see' twice in lowercase"
> "type capital see, capital see"

But why such a cause of confusion in the first place?

You ask someone to read back what they typed - 'see see' - 'is that
upper case see see, or lower case see see'?

It's a source of confusion.

And an unbelievable lack of imagination: Let's see, our C compiler is
called 'cc' (in lower case); what can we possible call the C++ one? I
know, how about calling it exactly the same as the C compiler, but in
upper case?'!

Which also mean a lot of capslocking on and off everytime you have to
type CC program.cc!

Actually I really don't care, if Linux/Unix people want to do these
ridiculous things. And if they're paid by the hour, then one can
understand why they want the slowest tools, most complicated and
fiddliest tools they can find!

> I honestly can't believe I answered that question, since you were
> clearly trying to make a rhetorical point.
>
> Worth pointing out what a freaking terrible rhetorical point it was.
>
> I am now kill-filing you, as you are clearly dimmer than a Toc-H lamp.

Thank god for that. But you do seem to mainly come on here to have a go
at people. Without me, who's left, fir, Malcolm or Rick?


--
Bartc

[Ben Bacarisse]

Gareth Owen <gwo...@gmail.com> writes:
<snip>
> ... you are clearly dimmer than a Toc-H lamp.

I haven't heard that phrase for years!

--
Ben.

[Malcolm McLean]

One of the characteristics of software engineering is that you can
be professor or, as I am, a doctor with a doctorate in a computational
subject. You're presented with a new system, and you don't know
how to log on.

Other fields tend not to have that problem. Either there are conventions
long established, such as how to make air traffic control ware of your
intention to land, and so on, or it's physically intuitive - the#
throttle might work in a slightly different way on another model
of aircraft, but it's still obvious that it's a throttle.

Software has conventions which are not established, and no real way
of examining the software to see which are in use. It's made much
worse by thing such as the proliferation of languages and libraries,
many of which do much the same sort of thing, just with slightly
different syntax for for loops because someone thought it would
be nice to have a "ranged for" and so on. You can learn the conventions
for a small subset of the software you happen to use, that then
sometimes gives people feelings of superiority - I remember as young
man being told how to set the number of lines in the cursor on DOS
by a friend. He smiled proudly and said that was the result of years
of knowledge. I didn't disabuse him.

[Ian Collins]

On 01/15/17 08:48 AM, BartC wrote:
> On 14/01/2017 18:50, Gareth Owen wrote:
>> BartC <b...@freeuk.com> writes:
>>
>>> It just seems perverse. How would you say 'cc' or 'CC' over the phone
>>> when instructing someone what to type?
>>
>> "type see see - just the letter 'see' twice in lowercase"
>> "type capital see, capital see"
>
> But why such a cause of confusion in the first place?
>
> You ask someone to read back what they typed - 'see see' - 'is that
> upper case see see, or lower case see see'?
>
> It's a source of confusion.

For the simple minded, maybe.

I suppose you fine cl.exe a more intuitive name?

CC has been the Solaris C++ compiler since it was still SunOS.
--
Ian

[Ian Collins]

On 01/15/17 09:28 AM, Malcolm McLean wrote:
> On Saturday, January 14, 2017 at 7:10:44 PM UTC, Ian Collins wrote:
>> On 01/15/17 12:48 AM, BartC wrote:
>>
>>> In short, there were half a dozen points of confusion in about as many
>>> lines, and people are making out that it's /me/ talking bollocks!
>>
>> There is only one - your ignorance of your tools.
>>
> One of the characteristics of software engineering is that you can
> be professor or, as I am, a doctor with a doctorate in a computational
> subject. You're presented with a new system, and you don't know
> how to log on.

So you ask.

--
Ian

[Chris M. Thomasson]

On 1/13/2017 3:57 PM, Chris M. Thomasson wrote:
> On 1/13/2017 10:43 AM, Malcolm McLean wrote:
>> On Friday, January 13, 2017 at 1:00:07 PM UTC, Richard Heathfield wrote:
>>> On 13/01/17 06:30, Ian Collins wrote:
>>>
>>> Do you mean that you agree with him that using a C++ compiler for C code
>>> is a good idea? If so, why, and what do you do with C code that isn't
>>> legal C++, or that has different meanings in C and C++?
>>>
>> It's a reasonable idea. It means you can cut and paste C routines into
>> C++
>> programs.

just make sure that the std:: evaporates into thin air before you use it
in a C compiler, wrt freely exchanging C and C++ free-functions.


[...]

[Keith Thompson]

Thiago Adams <thiago...@gmail.com> writes:
[...]

> typedef int int;
> int is a alias for int

[...]

That's illegal; you can't use a keyword as a typedef name.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[David Brown]

On 14/01/17 17:31, BartC wrote:
> On 14/01/2017 15:18, David Brown wrote:
>> On 14/01/17 15:00, BartC wrote:
>>> On 14/01/2017 13:27, Gareth Owen wrote:
>>>> David Brown <david...@hesbynett.no> writes:
>>>>
>>>>>> In short, there were half a dozen points of confusion in about as
>>>>>> many
>>>>>> lines, and people are making out that it's /me/ talking bollocks!
>>>>>>
>>>>>
>>>>> The confusion is only in your mind - because you work so hard to
>>>>> create it.
>>>>
>>>> I no longer think he's working hard to create it. I think his state of
>>>> perpetual bafflement comes to him naturally.
>>>
>>> I used to do a lot of customer support. I know the sort of things people
>>> have difficulty with, and used to write user and reference manuals with
>>> that in mind.
>>>
>>> Now, in all the years I've been frequenting this group, I don't recall
>>> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
>>> every other post.
>>
>> CC for the C++ compiler is definitely a unixism. It is not unreasonable
>> that you don't know it if you are not familiar with Unix, and if you are
>> a DOS/Windows user you might even still believe that "cc" and "CC" would
>> refer to the same program.
>
> It just seems perverse. How would you say 'cc' or 'CC' over the phone
> when instructing someone what to type?

"cc in small letters" or "CC in capital letters" ? Or type it in the
chat window in Skype? Send it by email? I don't know - phones are such
extraordinarily poor ways to communicate such things that I would use
one of a range of alternatives. But if I /had/ to use a phone, I can't
imagine that would be a serious problem.

>
>>
>> Not knowing the command name for your own C++ compiler is, however,
>> ridiculous.
>
> Where did you get that idea? I said I resorted 'g++' when cc and CC
> didn't work.

So you knew how to run your C++ compiler, but instead you copied Ian's
comment about how /he/ runs /his/ C++ compiler, and then complained it
didn't work?

>
> But Linux seems confused about it itself; typing man cc, man CC or man
> gcc or man g++ all bring up the same page:
>
> gcc - GNU project C and C++ compiler
>
> Which suggests that gcc does both. However it appears that gcc and g++
> can't be used interchangeably, despite the man page saying that invoking
> gcc on a file with a C++ extension (eg. .cc) will compile it as g++.
> (And invoking g++ on a .c file doesn't seem to work with my C programs
> either.)
>
> (BTW the man info for gcc is about 350 pages!)
>

gcc is the "GNU compiler collection" - it is not just a C compiler. The
package includes support for a number of languages, including C and C++.
The binary "gcc" is a /driver/ - it is not the compiler itself. It
calls the appropriate pre-processor, then the appropriate compiler, and
then the linker - all depending on the flags and files passed to it.
The compiler to use is chosen based on the file extension - .c files get
the C compiler, .cc and .cpp files get the the C++ compiler, etc. If it
is called with the name "g++", the C++ and C libraries are linked in
automatically. If it is called with the name "gcc", the C libraries
alone are linked in automatically.

[Keith Thompson]

BartC <b...@freeuk.com> writes:
[...]

> Now, in all the years I've been frequenting this group, I don't recall
> the name 'CC' ever coming up. Compared with 'gcc' which might be almost
> every other post.
>
> Nor have I have ever comes across the file extension '.cc'.

[...]

And now you have. Is learning new things painful for you?