Type aliases

[dom.k.black]

Is it still common practice to use type aliases (INT, PCHAR etc).

It looks ugly and breaks the syntax highlighting, are there any
advantages these days (MSVC++6.0 and later)? I could understand it,
maybe, back in the days when some compilers had 16 bit ints.

Also, if your products is heavily dependent on a 3rd party library
which just uses the raw types, does the aliasing help in any way at
all?

[Victor Bazarov]

do*********@googlemail.com wrote:

Is it still common practice to use type aliases (INT, PCHAR etc).

It depends what those aliases are for. INT instead of int makes
no sense, neither does PCHAR instead of char*. However, there are
probably some places where WORD is bettern than unsigned short
(like in a functional style cast) or DWORD instead of unsigned long
(for similar reasons). [you can see I've been working in Windows]

It looks ugly and breaks the syntax highlighting, are there any
advantages these days (MSVC++6.0 and later)? I could understand it,
maybe, back in the days when some compilers had 16 bit ints.

Uh... How do 16-bit ints play into the type aliasing?

Also, if your products is heavily dependent on a 3rd party library
which just uses the raw types, does the aliasing help in any way at
all?

No, but ask the reverse question.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Rolf Magnus]

Victor Bazarov wrote:

do*********@googlemail.com wrote:

>Is it still common practice to use type aliases (INT, PCHAR etc).

It depends what those aliases are for. INT instead of int makes
no sense, neither does PCHAR instead of char*.

IMHO, the funniest one is VOID instead of void.

However, there are probably some places where WORD is bettern than
unsigned short (like in a functional style cast) or DWORD instead of
unsigned long (for similar reasons). [you can see I've been working in
Windows]

But why the ugly ALL-UPPERCASE typedef names? Also, "word" can have
diffferent meanings. On ARM CPUs for example, a word is 32 bits wide, while
on x86, it is only 16 bits.
Nowadays, I prefer to use the typedefs from the C99 stdint.h header, which
hopefully make it into the next C++ standard too. Most C++ compilers have
it anyway.

[Victor Bazarov]

do*********@googlemail.com wrote:

On Mar 21, 1:53 pm, "Victor Bazarov" <[e-mail]:

>[e-mail] wrote:

>>Also, if your products is heavily dependent on a 3rd party library
which just uses the raw types, does the aliasing help in any way at
all?

No, but ask the reverse question.

If you mean does the aliasing do any harm, well I'd say it does. It is
ugly and it stops syntax highlighting working, to name two. If it has
absolutely no upside, then any downside is enough to say you shouldn't
use it.

No, I meant if your products are heavily dependent on a 3rd party
library that does use aliases (at least in their declarations) and
provide those aliases (of course), would it be beneficial to keep
using those aliases in your own code even if you don't intend to
call their functions? If not, why?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[dom.k.black]

On Mar 21, 4:02 pm, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:

On Mar 21, 1:53 pm, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:
Also, if your products is heavily dependent on a 3rd party library
which just uses the raw types, does the aliasing help in any way at
all?

No, but ask the reverse question.

If you mean does the aliasing do any harm, well I'd say it does. It is
ugly and it stops syntax highlighting working, to name two. If it has
absolutely no upside, then any downside is enough to say you shouldn't
use it.

No, I meant if your products are heavily dependent on a 3rd party
library that does use aliases (at least in their declarations) and
provide those aliases (of course), would it be beneficial to keep
using those aliases in your own code even if you don't intend to
call their functions? If not, why?

Well I use a number of third party libraries, a couple each have their
own aliases, and I would absolutely not base my own code on them.
Which one would I choose? And what would happen to my code if the
third party changed the definitions?

They have at least prefixed the aliases with a library specific prefix
(another reason I wouldn't base my own code on them), but they get
cast right at the lowest possible level. I tend to try to isolate the
interface in a single module as far as is practical.

The worst thing is when 2 libraries both use their own versions of the
standard aliases (INT, CHAR etc).

>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Joe Greer]

Rolf Magnus <ra******@t-online.dewrote in
news:fs*************@news.t-online.com:

>
But why the ugly ALL-UPPERCASE typedef names? Also, "word" can have
diffferent meanings. On ARM CPUs for example, a word is 32 bits wide,
while on x86, it is only 16 bits.
Nowadays, I prefer to use the typedefs from the C99 stdint.h header,
which hopefully make it into the next C++ standard too. Most C++
compilers have it anyway.

Consistency. Originally MS started doing that so they could decorate
pointer types with appropriate __far, __near, __declspec etc (depending on
memory model and other switches). The rest sort of carries from that. I'm
not claiming they have a place in modern code, but sometimes history has
its way with you regardless.

joe

[James Kanze]

On 21 mar, 13:59, [e-mail] wrote:

Is it still common practice to use type aliases (INT, PCHAR etc).

It never was, as far as I can tell (and my C/C++ experience goes
back to the early 1980's).

It looks ugly and breaks the syntax highlighting, are there
any advantages these days (MSVC++6.0 and later)? I could
understand it, maybe, back in the days when some compilers had
16 bit ints.

Most of the C I wrote was for 16 bit machines, and I've never
seen such conventions. They look like pure obfuscation to me.

Also, if your products is heavily dependent on a 3rd party
library which just uses the raw types, does the aliasing help
in any way at all?

Aliasing as in your examples actively hurts.

Aliasing can be useful if the names give additional semantic
information:
typedef int WidgitCount ;
, for example, especially when linked to types which can change
from one implementation to the next, e.g. off_t under Posix.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]