Re: const char* typedefs

[Paige DePol <lual@...>]

Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great Paige DePol once stated:
>> However, as I was thinking about it during this conversation I also realised
>> that whenever I see "const char*" I just think "C String". A shorter name is
>> always nicer, and "ccstr" also concisely summarises the object to me.
> 
>  Okay, so "ccstr" is "typdedef char const *ccstr" [1] but does that imply
> that "cstr" is "typedef char *cstr"?  If so, then there's only a single
> character difference between two different types so typos might be hard to
> decern (maybe---it may be that the compiler might catch instances of ccstr
> when a cstr was meant, but not so much the other way around).

The only typedef I created was for 'const char *', I figure 'char *' on its
own is fine, and if you're actually dealing with individual characters then
my concept of a "C String" as an opaque pointer wouldn't apply. So really I
just wanted to use the typedef for the 'const char *' variant as that is the
one that is typically used to represent a static string of const chars.


>  My only other argument against it is that "char *" is *so* idiomatic for a
> "string" that it seems silly to hide it just to save some typing [7].

Right, which is why I didn't create a typedef for 'char *' by itself.


>  -spc (Who realizes that "const char *" is more idiomatic than 
> 	"char const *" but does the later anyway ... )

I guess I prefer my qualifier before the type as well.


Holy chained footnotes, Batman! 

> [1]	Why "char const" and not "const char"?  Because "const" actually
> 	binds to the right (except when it's at the leftmost position).
> 	[snip]

I will have to admit that with really complex declarations with multiple uses
of 'const' I can get confused with what exactly is being declared at times!


> [1]	which is a constant pointer to a function, said function takes two
> 	FILE *s which are themselves constant [3] and guarenteed not to
> 	point to the same thing [4].
> [4]	That's what "restrict" is for.

That is an interesting qualifier I did not know about... However, you stated
that it is guaranteed they won't point to the same memory. By guaranteed you
mean the programmer is the one making that guarantee, and the compiler will
trust that blindly... and if they do alias the result is undefined [1]. 


> [5]	Because C makes it too easy to conflate pointers with arrays.

Aren't they essentially the same thing though? Array syntax is really just
sugar for pointer manipulation.


> [7]	We read code more than write it. Spend the extra few seconds writing it.

Wouldn't this advice apply to "unsigned int" vs "uint" typedefs as well then?
I guess one sticking point for me is why is "uint" okay but a shortcut for
'const char*' not?

I can see a typedef that isn't self-explanatory (like my original 'l_str')
being a problem, but if the typedef name is really just a shorter version of
the longer name then I don't see why it should be so wrong.

All that said, I am getting the distinct impression that using a typedef for
C strings is something that should not be done... okay, more than just an
impression really. Seriously though, I will take everything that has been
said under advisement... this has been enlightening and I do appreciate all
the feedback as I would like to make my code as clean as possible.

~Paige

[1] https://en.wikipedia.org/wiki/Restrict