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

Groups > comp.lang.c > #15924 > unrolled thread

Am I being too C++ like?

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

Contents

  Am I being too C++ like? nroberts <roberts.noah@gmail.com> - 2012-01-18 13:53 -0800
    Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-01-18 18:50 -0500
      Re: Am I being too C++ like? Nobody <nobody@nowhere.com> - 2012-01-19 04:13 +0000
      Re: Am I being too C++ like? ImpalerCore <jadill33@gmail.com> - 2012-01-19 09:09 -0800
    Re: Am I being too C++ like? Philip Lantz <prl@canterey.us> - 2012-01-18 21:42 -0800
    Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-19 12:30 +0000
      Re: Am I being too C++ like? "BartC" <bc@freeuk.com> - 2012-01-19 15:17 +0000
        Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-19 18:44 -0800
          Re: Am I being too C++ like? "BartC" <bc@freeuk.com> - 2012-01-20 13:44 +0000
            Re: Am I being too C++ like? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-20 09:08 -0500
              Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-20 07:58 -0800
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 11:25 -0800
              Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-20 20:17 +0000
                Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 09:23 +1300
                  Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-20 22:00 +0000
                  Re: Am I being too C++ like? Stephen Sprunk <stephen@sprunk.org> - 2012-01-20 16:28 -0600
                    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 11:43 +1300
                    Re: Am I being too C++ like? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-20 18:02 -0500
                    Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 16:12 -0800
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-01-21 00:13 +0000
                        Re: Am I being too C++ like? William Ahern <william@wilbur.25thandClement.com> - 2012-01-20 17:37 -0800
                          Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 22:25 -0800
                            Re: Am I being too C++ like? gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-21 16:07 +0000
                              Re: Am I being too C++ like? Bill Reid <hormelfree@gmail.com> - 2012-01-23 17:26 -0800
                          Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-01-21 18:00 +0000
                            Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-21 21:25 +0000
                              Re: Am I being too C++ like? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-11 23:46 +0200
                                Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 22:56 +0000
                                  Re: Am I being too C++ like? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:34 +0200
                            Re: Am I being too C++ like? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-21 22:42 +0100
                            Re: Am I being too C++ like? James Kuyper <jameskuyper@verizon.net> - 2012-01-21 21:22 -0500
                              Re: Am I being too C++ like? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-22 14:56 +0100
                        Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:29 +1300
                    Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-21 11:36 +0000
                Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-22 12:13 +0000
                  Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-22 12:39 +0000
                    Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 23:45 +0000
                      Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-24 16:54 +0000
              Re: Am I being too C++ like? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-22 04:43 -0800
                Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-22 15:29 +0000
            Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-21 11:58 +0000
            Re: Am I being too C++ like? Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
    Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-19 04:23 -0800
      Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 14:39 +0000
      Re: Am I being too C++ like? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-22 05:14 -0800
        Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 23:42 +0000
    Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 14:51 +0000
    Re: Am I being too C++ like? jgk@panix.com (Joe keane) - 2012-01-19 23:04 +0000
    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-20 16:03 +1300
      Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-20 06:01 -0800
        Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 08:03 +1300
          Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-21 12:31 -0800
            Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:18 +1300
    Re: Am I being too C++ like? cri@tiac.net (Richard Harter) - 2012-01-20 05:22 +0000
    Re: Am I being too C++ like? Marco <prenom_nomus@yahoo.com> - 2012-01-21 07:29 -0800
      Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-24 12:13 +0000
        Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 14:32 -0800
          Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 15:32 -0800
            Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 19:46 -0800
            Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-01-31 23:54 -0500
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 22:24 -0800
            Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:28 -0800
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 11:23 -0800
                Re: Am I being too C++ like? Stephen Sprunk <stephen@sprunk.org> - 2012-02-01 15:01 -0600
                  Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-01 14:09 -0800
                    Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 14:44 -0800
                  Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-02-01 17:36 -0500
                Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 12:45 -0800
                  Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-08 21:41 +0000
                    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-09 17:42 +1300
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-03-09 08:12 +0000
                        Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-09 12:01 +0000
                  Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-03-08 14:19 -0800
                    Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:32 -0800
                  Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-09 04:18 -0800
                    Re: Am I being too C++ like? Ike Naar <ike@iceland.freeshell.org> - 2012-03-09 13:04 +0000
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-03-10 01:02 +0000
                        Re: Am I being too C++ like? Ike Naar <ike@iceland.freeshell.org> - 2012-03-10 07:59 +0000
                          Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-10 21:17 +1300
                      Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-10 02:39 -0800
                    Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:51 -0800
                      Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-10 02:54 -0800
              Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-10 12:27 +1300
            Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-02-01 07:41 +0000
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 11:24 -0800
          Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-01 21:55 +0000

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

#15924 — Am I being too C++ like?

I'm working on a C project and I come from C++ background.  I used to
work with C 10 years ago though when I was first learning various
languages and used things like Xlib, Xt, etc...

I keep getting told that what I write is more C++ like.  I find it odd
because I'm actually using C keywords I rarely if ever use in C++ like
union.  But two main examples come to mind:

First, I use opaque types to encapsulate data so I can depend on the
integrity of my structures.  For example, when making a stack I had a
header like so:

struct stack;
typedef struct stack Stack;

Stack* createList();
void* popFront(Stack*);
void pushBack(Stack*);

etc...

Another example is when I'm parsing an unknown string into one of
several possibilities:

typedef struct base
{
  int type;
  // shared data among all valid inputs
} Base;

typedef struct variant_a
{
  Base base;
  // particular data members
} VariantA;

... more variants...

typedef union blob
{
  int type;
  Base base;
  VariantA a;
 ...etc...
} Blob;

Blob * parse(char const*);

I've seen both of these used a lot in various C projects, but has it
gone out of style or something?  I suppose it's kind of OOesque, but
I've always thought of that as one paradigm for use in any
language...not something unique to any particular one.  Is that an
unpopular conception?  If I were to do something similar in C++ it
would look absolutely nothing like the above...why do people think
it's C++ like?  Are they full of it or am I?  Both?  Neither?

[toc] | [next] | [standalone]

#15930

On 1/18/2012 16:53, nroberts wrote:
> I'm working on a C project and I come from C++ background.  I used to
> work with C 10 years ago though when I was first learning various
> languages and used things like Xlib, Xt, etc...
>
> I keep getting told that what I write is more C++ like.  I find it odd
> because I'm actually using C keywords I rarely if ever use in C++ like
> union.  But two main examples come to mind:
>

If you're typing legitimate C, then perhaps they're merely thinking of 
style.

> First, I use opaque types to encapsulate data so I can depend on the
> integrity of my structures.  For example, when making a stack I had a
> header like so:
>
> struct stack;
> typedef struct stack Stack;
>
> Stack* createList();
> void* popFront(Stack*);
> void pushBack(Stack*);
>
> etc...
>

Some notes about the above...

You've got an interesting mix of styles with your 'struct' tag and 
'typedef' type.  In C code that I've seen, it's more common to have:

   struct stack;
   typedef struct stack stack;

Or:

   struct stack;
   typedef struct stack stack_t;

In my own current, personal preference (which is not reflective of any C 
community that I'm aware of), when I do not wish anyone to use the 
'struct' keyword, I type something like:

   struct s_stack_;
   typedef struct s_stack_ s_stack;
   /* ... */
   struct s_stack_ {
       ...
     };
   /* We'll never see 's_stack_' again */

Or if people might or might not care to use the 'struct' keyword is:

   struct stack;
   typedef struct stack s_stack;
   /* ... */
   struct stack {
       ...
     };
   /* ... */
   /* People can do */
   struct stack foo;
   /* Or they can do */
   s_stack bar;

You're using the so-called "Pascal Case" for the 'typedef' type.  This 
might not be un-C-like, but I've seen more C++ code with this style than 
I have seen C code with it.

You're using the so-called "Camel Case" for the functions' identifiers. 
  This might not be un-C-like, but I've seen more C++ code with this 
style than I have seen C code with it.

"When In Rome..." I think it's good to follow any established style 
guidelines that might exist for a project.  If it's completely up to 
you, please just be consistent. :)

If you don't specifically require an empty parameter list, please use 
'void' inside your function declarations for functions having no parameters.

   Stack * create_list(void);

> Another example is when I'm parsing an unknown string into one of
> several possibilities:
>
> typedef struct base
> {
>    int type;
>    // shared data among all valid inputs
> } Base;
>

Call me old-fashioned, but '//' comments always strike me as C++-like, 
though they've been in Standard C since C99.  They're extremely common 
and people report them to be quite handy.

> typedef struct variant_a
> {
>    Base base;
>    // particular data members
> } VariantA;
>

Something about 'xxx_yyy_zzz' strikes me as C-like and something about 
'XxxYyyZzz' strikes me as C++-like.  The cause for this association 
probably amounts to little more than the introductory books' examples 
for these languages, when I first read them.  It's a pretty trivial 
association.

> ... more variants...
>
> typedef union blob
> {
>    int type;
>    Base base;
>    VariantA a;
>   ...etc...
> } Blob;
>
> Blob * parse(char const*);
>
> I've seen both of these used a lot in various C projects, but has it
> gone out of style or something?  I suppose it's kind of OOesque, but
> I've always thought of that as one paradigm for use in any
> language...not something unique to any particular one.  Is that an
> unpopular conception?  If I were to do something similar in C++ it
> would look absolutely nothing like the above...why do people think
> it's C++ like?  Are they full of it or am I?  Both?  Neither?

"Are they...?"  They are.  If you want to strive for "C-like," you could 
study all of the code examples in a C Standard and try to pick out 
patterns.  Then again, that might just be reflective of those authors' 
preferences! ;)

- Shao Miller

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

#15934

On Wed, 18 Jan 2012 18:50:10 -0500, Shao Miller wrote:

> Call me old-fashioned, but '//' comments always strike me as C++-like, 
> though they've been in Standard C since C99.  They're extremely common 
> and people report them to be quite handy.

OTOH, they really shouldn't be used in "public" headers unless those
headers would otherwise require C99 support, as it (gratuitously)
precludes using -std=c89 for compiling any code which uses those headers.

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

#15957

On Jan 18, 6:50 pm, Shao Miller <sha0.mil...@gmail.com> wrote:
> On 1/18/2012 16:53, nroberts wrote:
>
> > I'm working on a C project and I come from C++ background.  I used to
> > work with C 10 years ago though when I was first learning various
> > languages and used things like Xlib, Xt, etc...
>
> > I keep getting told that what I write is more C++ like.  I find it odd
> > because I'm actually using C keywords I rarely if ever use in C++ like
> > union.  But two main examples come to mind:
>
> If you're typing legitimate C, then perhaps they're merely thinking of
> style.
>
> > First, I use opaque types to encapsulate data so I can depend on the
> > integrity of my structures.  For example, when making a stack I had a
> > header like so:
>
> > struct stack;
> > typedef struct stack Stack;
>
> > Stack* createList();
> > void* popFront(Stack*);
> > void pushBack(Stack*);
>
> > etc...
>
> Some notes about the above...
>
> You've got an interesting mix of styles with your 'struct' tag and
> 'typedef' type.  In C code that I've seen, it's more common to have:
>
>    struct stack;
>    typedef struct stack stack;
>
> Or:
>
>    struct stack;
>    typedef struct stack stack_t;
>
> In my own current, personal preference (which is not reflective of any C
> community that I'm aware of), when I do not wish anyone to use the
> 'struct' keyword, I type something like:
>
>    struct s_stack_;
>    typedef struct s_stack_ s_stack;
>    /* ... */
>    struct s_stack_ {
>        ...
>      };
>    /* We'll never see 's_stack_' again */
>
> Or if people might or might not care to use the 'struct' keyword is:
>
>    struct stack;
>    typedef struct stack s_stack;
>    /* ... */
>    struct stack {
>        ...
>      };
>    /* ... */
>    /* People can do */
>    struct stack foo;
>    /* Or they can do */
>    s_stack bar;

My preference in the code that I write is to cater to both crowds with
a preprocessor symbol.

\code snippet
struct c_stack
{
  ...
};

#if defined(C_ALIAS_TYPES)
/*! \brief Alias the <tt>struct c_stack</tt> type. */
typedef struct c_stack c_stack;
#endif
\endcode

All the library code is written using the 'struct c_stack' style, but
the documentation examples may define C_ALIAS_TYPES in its Makefile to
make the example code less verbose.  The preprocessor symbol doesn't
have any granularity for those that want to mix and match type usage.

> You're using the so-called "Pascal Case" for the 'typedef' type.  This
> might not be un-C-like, but I've seen more C++ code with this style than
> I have seen C code with it.
>
> You're using the so-called "Camel Case" for the functions' identifiers.
>   This might not be un-C-like, but I've seen more C++ code with this
> style than I have seen C code with it.

I have seen this when the interface is designed before the language is
chosen.  For example, the XML DOM specification is written in OMG
IDL.  If one were to write a C language binding, is it better to
following the naming convention of the standard, or a naming
convention more commonplace to the language?

> "When In Rome..." I think it's good to follow any established style
> guidelines that might exist for a project.  If it's completely up to
> you, please just be consistent. :)

Yep.

> If you don't specifically require an empty parameter list, please use
> 'void' inside your function declarations for functions having no parameters.
>
>    Stack * create_list(void);
>
> > Another example is when I'm parsing an unknown string into one of
> > several possibilities:
>
> > typedef struct base
> > {
> >    int type;
> >    // shared data among all valid inputs
> > } Base;
>
> Call me old-fashioned, but '//' comments always strike me as C++-like,
> though they've been in Standard C since C99.  They're extremely common
> and people report them to be quite handy.

They can be particularly handy in Doxygen documentation when writing
literal C examples because writing */ in a Doxygen C code sample will
make things go awry.

\code
/*!
 * \brief Something useful.
 * \param arg1
 * \param arg2
 * \return blah blah
 * ...
 *
 * Usage:
 *
 * \code
 * int main(void)
 * {
 *   // These style of comments are a necessity, unless you put the
 *   // example in its own file and include it using '\include'.
 *   useful_function( arg1, arg2 );
 *
 *   return 0;
 * }
 */
\endcode

> > typedef struct variant_a
> > {
> >    Base base;
> >    // particular data members
> > } VariantA;
>
> Something about 'xxx_yyy_zzz' strikes me as C-like and something about
> 'XxxYyyZzz' strikes me as C++-like.  The cause for this association
> probably amounts to little more than the introductory books' examples
> for these languages, when I first read them.  It's a pretty trivial
> association.
>
> > ... more variants...
>
> > typedef union blob
> > {
> >    int type;
> >    Base base;
> >    VariantA a;
> >   ...etc...
> > } Blob;
>
> > Blob * parse(char const*);
>
> > I've seen both of these used a lot in various C projects, but has it
> > gone out of style or something?  I suppose it's kind of OOesque, but
> > I've always thought of that as one paradigm for use in any
> > language...not something unique to any particular one.  Is that an
> > unpopular conception?  If I were to do something similar in C++ it
> > would look absolutely nothing like the above...why do people think
> > it's C++ like?  Are they full of it or am I?  Both?  Neither?
>
> "Are they...?"  They are.  If you want to strive for "C-like," you could
> study all of the code examples in a C Standard and try to pick out
> patterns.  Then again, that might just be reflective of those authors'
> preferences! ;)

Yep, the inertia of a project (and its people) should be considered
before attempting to alter its trajectory.  The question is, how much
mass do you have?

Best regards,
John D.

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

#15935

nroberts wrote:
> I keep getting told that what I write is more C++ like.  I find it odd
> because I'm actually using C keywords I rarely if ever use in C++ like
> union.

Do they mean this as a criticism, or simply as an observation?

Maybe you should just consider it a compliment and move on...

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

#15949

On Wed, 2012-01-18, nroberts wrote:
> I'm working on a C project and I come from C++ background.  I used to
> work with C 10 years ago though when I was first learning various
> languages and used things like Xlib, Xt, etc...
>
> I keep getting told that what I write is more C++ like.  I find it odd
> because I'm actually using C keywords I rarely if ever use in C++ like
> union.  But two main examples come to mind:
>
> First, I use opaque types to encapsulate data so I can depend on the
> integrity of my structures.  For example, when making a stack I had a
> header like so:
>
> struct stack;
> typedef struct stack Stack;
>
> Stack* createList();
                    ^
		    void

> void* popFront(Stack*);
> void pushBack(Stack*);

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.

And I wouldn't hide the contents of struct Stack unless I had specific
reasons.

  I'm doing it now in a piece of code I'm refactoring, but it's
  because the interpretation of the contents of my struct has been a
  source of bugs and confusion in the past.  Now you can't get at it
  except through a few well-defined and documented functions.

If you do it /everywhere/ it looks odd to me, especially the
createStack() which implies malloc()ed memory which you always have to
remember to handle manually. I'm usually not willing to pay that price.

> Another example is when I'm parsing an unknown string into one of
> several possibilities:

...

> I've seen both of these used a lot in various C projects, but has it
> gone out of style or something?  I suppose it's kind of OOesque, but
> I've always thought of that as one paradigm for use in any
> language...not something unique to any particular one.

For what it's worth, the Foo_function(struct Foo*, int arg) idiom
is something I used for years before I learned C++.  But most C code I
see uses no particular idiom ... unless 'ad hoc' is one.

/Jorgen

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

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

#15956

"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message 
news:slrnjhg375.1ls.grahn+nntp@frailea.sa.invalid...
> On Wed, 2012-01-18, nroberts wrote:

>> struct stack;
>> typedef struct stack Stack;

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

-- 
Bartc 

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

#15964

"BartC" <bc@freeuk.com> writes:
> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message 
> news:slrnjhg375.1ls.grahn+nntp@frailea.sa.invalid...
>> On Wed, 2012-01-18, nroberts wrote:
>
>>> struct stack;
>>> typedef struct stack Stack;
>
>> 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; usually the code that refers to the type already
depends on the fact that it's a struct.  (For a truly opaque type,
a typedef makes sense; the standard FILE is an example.)

On the other hand, a typedef for a numeric type is typically
parameterized, and may refer to different types depending on
the platform.  Examples from the standard library include size_t
and ptrdiff_t.

Typedefs can also be useful for types that might be overly complex
to write out; for example:

    typedef void (*signal_handler)(int);

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

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

#15975

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnfwfbxfcx.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> 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.

-- 
bartc 

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

#15976

On 1/20/2012 8:44 AM, BartC wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnfwfbxfcx.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> 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.

     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.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#15979

On Jan 20, 2:08 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> 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).
>
Say we want an array of ten function pointers that return int and take
a void *.

the syntax is

int (*myftable[10])(void *ptr);

that's really too difficult.

typedef int (*myfpointer)(void *ptr);

myfpointer myftable[10];

is a lot easier to understand.
--
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

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

#15983

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
[...]
>     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).

[...]

You could typedef the function type itself rather than the
pointer-to-function type:

    typedef void signal_handler(int);

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

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

#15984

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.

-- 
Four thousand throats may be cut in one night by a running man.
		-- Klingon Soldier, "Day of the Dove", stardate unknown

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

#15985

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

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

#15990

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

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

#15994

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

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

#15996

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

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

#15999

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
esosman@ieee-dot-org.invalid

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

#16001

Stephen Sprunk <stephen@sprunk.org> 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) kst-u@mib.org  <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"

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

#16002

On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
> Do you know of any systems that support uint128_t?

gcc

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

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

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

csiph-web