Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Am I being too C++ like?

Reply
Thread Tools

Am I being too C++ like?

 
 
Ian Collins
Guest
Posts: n/a
 
      01-20-2012
On 01/21/12 09:17 AM, Kleuske wrote:
> On Fri, 20 Jan 2012 09:08:01 -0500, Eric Sosman saw fit to publish the
> following:
>
>> On 1/20/2012 8:44 AM, BartC wrote:

>
> <snip>
>
>>> But if I create a new typedef T, and then declare:
>>>
>>> T a;
>>>
>>> I can't see at a glance whether T is a number, struct, and anything
>>> else. That seemed to be the point of JG's remark. In this case it
>>> *does* hide some information.

>>
>> Not very effectively, since you need to rediscover at least
>> some of the "hidden" information before you can use `a'.
>>
>> a = 42; // legal?
>> *a |= 42; // legal?
>> a.fizz = 42; // legal?
>> a->buzz = 42; // legal?
>> puts(a); // legal?
>> longjmp(a, 42); // legal?
>> a(42); // legal?
>>
>> As a matter of personal taste I rather like typedef aliases
>> for struct types (and less often, union types), and I intensely dislike
>> them for data pointer types (but sometimes use them for function
>> pointers). For scalar types, I use typedef not so much for opacity but
>> for portability, using<limits.h> and #if to find a type with suitable
>> range and publishing the result as a typedef name. But these are just
>> my preferences, not binding on anyone and not enshrined in a style
>> standard.

>
> In many cases a well_chosen name can actually _add_ some information. Consider
> something like:
>
> typedef unsigned int ipaddr_t;
>
> and speculate what variables of this type are used for.
>
> PS. Target platform allows the assumption sizeof(unsigned int)==4.


Why assume?

typedef uint32_t ipaddr_t;

--
Ian Collins
 
Reply With Quote
 
 
 
 
Kleuske
Guest
Posts: n/a
 
      01-20-2012
On Sat, 21 Jan 2012 09:23:06 +1300, Ian Collins saw fit to publish the
following:

> On 01/21/12 09:17 AM, Kleuske wrote:
>> On Fri, 20 Jan 2012 09:08:01 -0500, Eric Sosman saw fit to publish the
>> following:
>>
>>> On 1/20/2012 8:44 AM, BartC wrote:

>>
>> <snip>
>>
>>>> But if I create a new typedef T, and then declare:
>>>>
>>>> T a;
>>>>
>>>> I can't see at a glance whether T is a number, struct, and anything
>>>> else. That seemed to be the point of JG's remark. In this case it
>>>> *does* hide some information.
>>>
>>> Not very effectively, since you need to rediscover at least
>>> some of the "hidden" information before you can use `a'.
>>>
>>> a = 42; // legal?
>>> *a |= 42; // legal?
>>> a.fizz = 42; // legal?
>>> a->buzz = 42; // legal?
>>> puts(a); // legal?
>>> longjmp(a, 42); // legal?
>>> a(42); // legal?
>>>
>>> As a matter of personal taste I rather like typedef aliases
>>> for struct types (and less often, union types), and I intensely
>>> dislike them for data pointer types (but sometimes use them for
>>> function pointers). For scalar types, I use typedef not so much for
>>> opacity but for portability, using<limits.h> and #if to find a type
>>> with suitable range and publishing the result as a typedef name. But
>>> these are just my preferences, not binding on anyone and not enshrined
>>> in a style standard.

>>
>> In many cases a well_chosen name can actually _add_ some information.
>> Consider something like:
>>
>> typedef unsigned int ipaddr_t;
>>
>> and speculate what variables of this type are used for.
>>
>> PS. Target platform allows the assumption sizeof(unsigned int)==4.

>
> Why assume?
>
> typedef uint32_t ipaddr_t;


That's better.

--
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9
 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      01-20-2012
On 20-Jan-12 14:23, Ian Collins wrote:
> On 01/21/12 09:17 AM, Kleuske wrote:
>> In many cases a well_chosen name can actually _add_ some information.
>> Consider something like:
>>
>> typedef unsigned int ipaddr_t;
>>
>> and speculate what variables of this type are used for.
>>
>> PS. Target platform allows the assumption sizeof(unsigned int)==4.

>
> Why assume?
>
> typedef uint32_t ipaddr_t;


That won't work; IP addresses can be 128 bits, so that should be
"typedef uint128_t ipaddr_t;".

Kleuske must have a system with CHAR_BIT>=32, which is the only way his
ipaddr_t can hold any IP address _and_ sizeof(unsigned int)==4 can be true.

If you incorrectly assumed an IP address was always 32 bits, though,
this shows yet another benefit to using typedefs to reflect the logical
data type: it helps you find (and correct) all the places in your code
that only work with IPv4.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-20-2012
On 01/21/12 11:28 AM, Stephen Sprunk wrote:
> On 20-Jan-12 14:23, Ian Collins wrote:
>> On 01/21/12 09:17 AM, Kleuske wrote:
>>> In many cases a well_chosen name can actually _add_ some information.
>>> Consider something like:
>>>
>>> typedef unsigned int ipaddr_t;
>>>
>>> and speculate what variables of this type are used for.
>>>
>>> PS. Target platform allows the assumption sizeof(unsigned int)==4.

>>
>> Why assume?
>>
>> typedef uint32_t ipaddr_t;

>
> That won't work; IP addresses can be 128 bits, so that should be
> "typedef uint128_t ipaddr_t;".


An IPv6 address is a completely different beast from an IPv4 (commonly
known as just IP) address. It's common (almost ubiquitous) to use a
typename like ipaddr_t to refer to an IPv4 address and a different
represent ion for an IPv6 address.

--
Ian Collins
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-20-2012
On 1/20/2012 5:28 PM, Stephen Sprunk wrote:
> On 20-Jan-12 14:23, Ian Collins wrote:
>> On 01/21/12 09:17 AM, Kleuske wrote:
>>> In many cases a well_chosen name can actually _add_ some information.
>>> Consider something like:
>>>
>>> typedef unsigned int ipaddr_t;
>>>
>>> and speculate what variables of this type are used for.
>>>
>>> PS. Target platform allows the assumption sizeof(unsigned int)==4.

>>
>> Why assume?
>>
>> typedef uint32_t ipaddr_t;

>
> That won't work; IP addresses can be 128 bits, so that should be
> "typedef uint128_t ipaddr_t;".
>
> Kleuske must have a system with CHAR_BIT>=32, which is the only way his
> ipaddr_t can hold any IP address _and_ sizeof(unsigned int)==4 can be true.
>
> If you incorrectly assumed an IP address was always 32 bits, though,
> this shows yet another benefit to using typedefs to reflect the logical
> data type: it helps you find (and correct) all the places in your code
> that only work with IPv4.


"All" is over-optimistic, I think. A difficulty is that
typedef aliases are in fact just aliases, not types in their own
right. Given `typedef int Foo;' and `typedef int Bar;', I still
have only the single type `int', not three types. For example,
I can pass a `Foo*' argument to a function's `Bar*' parameter.

Add C's promiscuity about silent conversion between numeric
types, and a typedef-aliased scalar turns out to be a rather weak
enforcer of purity. IP addresses may start out in `ipaddr_t' places,
but they won't stay there: By the time the code base gets to version
2.0 (maybe even 1.5), you will inevitably find "leakage" into types
not so helpfully named. If the compiler doesn't forbid something,
some programmer will do it.

Structs (and unions), by contrast, offer more in the way of
enforcability. If you make the `ipaddr_t' some kind of a struct,
the compiler will object to any attempts at smuggling it around as
some other struct, even a struct with the same element types and
layout. It's still not 100% bulletproof because `void*' is nearly
as promiscuous as numeric types are, but you'll get considerably
better "coverage" against type leaks.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-21-2012
Stephen Sprunk <(E-Mail Removed)> writes:
> On 20-Jan-12 14:23, Ian Collins wrote:
>> On 01/21/12 09:17 AM, Kleuske wrote:
>>> In many cases a well_chosen name can actually _add_ some information.
>>> Consider something like:
>>>
>>> typedef unsigned int ipaddr_t;
>>>
>>> and speculate what variables of this type are used for.
>>>
>>> PS. Target platform allows the assumption sizeof(unsigned int)==4.

>>
>> Why assume?
>>
>> typedef uint32_t ipaddr_t;

>
> That won't work; IP addresses can be 128 bits, so that should be
> "typedef uint128_t ipaddr_t;".
>
> Kleuske must have a system with CHAR_BIT>=32, which is the only way his
> ipaddr_t can hold any IP address _and_ sizeof(unsigned int)==4 can be true.


Obviously that refers to IPV4 addresses, which are 32 bits.

> If you incorrectly assumed an IP address was always 32 bits, though,
> this shows yet another benefit to using typedefs to reflect the logical
> data type: it helps you find (and correct) all the places in your code
> that only work with IPv4.


Do you know of any systems that support uint128_t?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      01-21-2012
On 2012-01-21, Keith Thompson <(E-Mail Removed)> wrote:
> Do you know of any systems that support uint128_t?


gcc
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-21-2012
William Ahern <william@wilbur.25thandClement.com> writes:
> Kaz Kylheku <(E-Mail Removed)> wrote:
>> On 2012-01-21, Keith Thompson <(E-Mail Removed)> wrote:
>> > Do you know of any systems that support uint128_t?

>
>> gcc

>
> GCC has __uint128_t and __int128_t on a few platforms, but there's no
> typedefs for uint128_t or int128_t. And there's no UINT128_C, INT128_C, or
> equivalents, which makes it difficult to use 128-bit constants.


I hope Kaz is aware that I won't necessarily see anything he posts
here, even if it's a direct response to something I posted, since
I killfiled him a couple of months ago.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Kleuske
Guest
Posts: n/a
 
      01-21-2012
On Fri, 20 Jan 2012 16:28:43 -0600, Stephen Sprunk saw fit to publish the
following:

> On 20-Jan-12 14:23, Ian Collins wrote:
>> On 01/21/12 09:17 AM, Kleuske wrote:
>>> In many cases a well_chosen name can actually _add_ some information.
>>> Consider something like:
>>>
>>> typedef unsigned int ipaddr_t;
>>>
>>> and speculate what variables of this type are used for.
>>>
>>> PS. Target platform allows the assumption sizeof(unsigned int)==4.

>>
>> Why assume?
>>
>> typedef uint32_t ipaddr_t;

>
> That won't work; IP addresses can be 128 bits, so that should be
> "typedef uint128_t ipaddr_t;".
>
> Kleuske must have a system with CHAR_BIT>=32, which is the only way his
> ipaddr_t can hold any IP address _and_ sizeof(unsigned int)==4 can be
> true.


The object of the little example was to show how a typedef alias can benefit
treadability of code. Its intention was _not_ to provide a watertight
solution portable over ipv4 and ipv6 architectures, but to illustrate a
point.

I am sorry if you missed that.

--
.... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-21-2012
On Fri, 2012-01-20, BartC wrote:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:
>>> "Jorgen Grahn" <(E-Mail Removed)> wrote in message

>
>>>> I'd skip the typedef -- if something is a struct, I want to see
>>>> that immediately. People typedef the weirdest things, so I feel I
>>>> cannot assume such a name is a struct, and not a pointer or something.
>>>
>>> Couldn't you make exactly the same argument for *anything* defined with
>>> typedef?

>>
>> Not quite.
>>
>> A typedef for a struct type just creates a new name (like "foo") for
>> something that already has a name (like "struct foo"). It typically
>> provides no new information, nor does it hide information that
>> should be hidden;

>
> But if I create a new typedef T, and then declare:
>
> T a;
>
> I can't see at a glance whether T is a number, struct, and anything else.
> That seemed to be the point of JG's remark. In this case it *does* hide some
> information.


I haven't followed your reasoning, and haven't yet read the followup
postings. But the thing is: I avoid creating typedefs for /anything/
in C. I may use them as convenience aliases within a translation
unit, but that's about it.

(I use typedefs in C++ though, but they are more well-behaved there
for various reasons.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Path Too Long Exception being thrown before HTTPHandler gets request Seth ASP .Net 3 01-02-2011 12:33 AM
Java & LAMP - being better or being popular ? heather.fraser@gmail.com Java 14 10-17-2007 03:50 AM
Java Interview Questions: Am I Being Too Difficult? Spammay Blockay Java 69 04-15-2006 04:08 AM
Form still being submitted despite being invalid =?Utf-8?B?TWFyayBQYXJ0ZXI=?= ASP .Net 4 07-25-2005 02:46 PM
Event handler is being detached without being released Moshe Katz Javascript 2 05-02-2004 06:42 AM



Advertisments