Am I being too C++ like?

Discussion in 'C Programming' started by nroberts, Jan 18, 2012.

  1. nroberts

    nroberts Guest

    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?
    nroberts, Jan 18, 2012
    #1
    1. Advertising

  2. nroberts

    Shao Miller Guest

    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
    Shao Miller, Jan 18, 2012
    #2
    1. Advertising

  3. nroberts

    Nobody Guest

    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.
    Nobody, Jan 19, 2012
    #3
  4. nroberts

    Philip Lantz Guest

    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...
    Philip Lantz, Jan 19, 2012
    #4
  5. On Jan 18, 9:53 pm, 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.  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*);
    >
    >

    In C, it's normal to hardcode simple structures like stacks. It's not
    clear to me whether this is a strong point or a weak point of the
    language, but it's generally easier to create a stack and stacktop
    index with whatever structure you're pushing and popping than to mess
    about with generic stack types. On feature is that your expression
    parser, or whatever it is you are using the stack for, does not have a
    dependency on a stack module.
    >
    > typedef struct base
    > {
    >   int type;
    >   // shared data among all valid inputs
    >
    > } Base;
    >

    This is C++ implemented in C. Effectively what you are doing is
    writing your own set of conventions for handling polymorphic data
    types, and implementing them in C. Which means that C isn't the right
    language for this approach. Sometimes it's necessary to use the wrong
    language because of other considerations. However it should be a last
    resort, and done sparingly.
    Malcolm McLean, Jan 19, 2012
    #5
  6. nroberts

    Jorgen Grahn Guest

    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 .
    Jorgen Grahn, Jan 19, 2012
    #6
  7. nroberts

    Rui Maciel Guest

    Malcolm McLean wrote:

    > In C, it's normal to hardcode simple structures like stacks. It's not
    > clear to me whether this is a strong point or a weak point of the
    > language, but it's generally easier to create a stack and stacktop
    > index with whatever structure you're pushing and popping than to mess
    > about with generic stack types.


    I believe it is a point where C is considerably weak. Better yet, it's a
    point where the C programming language could improve a great deal. If the C
    programming language supported function templates, even without supporting
    any form of template metaprogramming or non-type parameters, trully generic
    data structures would be possible without resorting to any coding voodoo.
    And this would be a good thing.

    Then again, if someone really requires templates and generic data structures
    then there is always C++.


    Rui Maciel
    Rui Maciel, Jan 19, 2012
    #7
  8. nroberts

    Rui Maciel Guest

    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:

    <snip/>

    From your description, it appears you tend to employ OO tricks in your code,
    mainly encapsulation and inheritance. That isn't necessarily the "C++ like"
    way of doing things, only the application of some principles associated with
    a particular programing paradigm.

    From this, I agree with you. It is a paradigm, not something unique to any
    particular programming language. Maybe some people see it as being
    something related to C++, as they associate OO with C++. Yet, C++ isn't the
    OO paradigm, and OO paradigm isn't the C++ programming language, nor Java or
    any other one.

    So, in the end the only question that I believe is relevant in this case is:
    does it matter? More specifically, are these OO tricks responsible for any
    problem? If they don't then why bother with them?


    Rui Maciel
    Rui Maciel, Jan 19, 2012
    #8
  9. nroberts

    BartC Guest

    "Jorgen Grahn" <> wrote in message
    news:...
    > 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
    BartC, Jan 19, 2012
    #9
  10. nroberts

    ImpalerCore Guest

    On Jan 18, 6:50 pm, Shao Miller <> 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.
    ImpalerCore, Jan 19, 2012
    #10
  11. nroberts

    Joe keane Guest

    In article <>,
    nroberts <> wrote:
    >I've seen both of these used a lot in various C projects, but has it
    >gone out of style or something?


    It's just good programming.

    Good C code resembles C++ written in C.
    Bad C code resembles fettucine alfredo.
    Joe keane, Jan 19, 2012
    #11
  12. "BartC" <> writes:
    > "Jorgen Grahn" <> wrote in message
    > news:...
    >> 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) <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"
    Keith Thompson, Jan 20, 2012
    #12
  13. nroberts

    Ian Collins Guest

    On 01/19/12 10:53 AM, 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...


    If you had used XView, you wouldn't be asking this question! XView was
    my introduction to OO programming in C.

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


    You are correct, what you are writing is OO C, not C++ like C. If it
    passes its tests and your colleagues understand it, go for it.

    --
    Ian Collins
    Ian Collins, Jan 20, 2012
    #13
  14. nroberts

    BartC Guest

    "Keith Thompson" <> wrote in message
    news:...
    > "BartC" <> writes:
    >> "Jorgen Grahn" <> 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
    BartC, Jan 20, 2012
    #14
  15. On Jan 20, 3:03 am, Ian Collins <> wrote:
    >
    > You are correct, what you are writing is OO C, not C++ like C.  If it
    > passes its tests and your colleagues understand it, go for it.
    >

    OO C is C++-like C.

    C++ provides support for object-orientation, C doesn't. Of course
    ultimately a design paradigm is independent of the language used to
    implement it, and you can emulate any language wtih any other (hence
    the claim sometimes made that every sufficiently large project
    contains a bug-ridden and informally specified implementation of
    Lisp). But it's a lot easier to use languages for the purposes for
    which they are intended.

    --
    Visit my website
    http://www.malcolmmclean.site11.com/www
    Malcolm McLean, Jan 20, 2012
    #15
  16. nroberts

    Eric Sosman Guest

    On 1/20/2012 8:44 AM, BartC wrote:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> "BartC" <> writes:
    >>> "Jorgen Grahn" <> 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
    d
    Eric Sosman, Jan 20, 2012
    #16
  17. On Jan 20, 2:08 pm, Eric Sosman <> 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
    Malcolm McLean, Jan 20, 2012
    #17
  18. nroberts

    Ian Collins Guest

    On 01/21/12 03:01 AM, Malcolm McLean wrote:
    > On Jan 20, 3:03 am, Ian Collins<> wrote:
    >>
    >> You are correct, what you are writing is OO C, not C++ like C. If it
    >> passes its tests and your colleagues understand it, go for it.
    >>

    > OO C is C++-like C.


    No, it's OO C. OO C was around before we had C++.

    > C++ provides support for object-orientation, C doesn't. Of course
    > ultimately a design paradigm is independent of the language used to
    > implement it, and you can emulate any language wtih any other (hence
    > the claim sometimes made that every sufficiently large project
    > contains a bug-ridden and informally specified implementation of
    > Lisp). But it's a lot easier to use languages for the purposes for
    > which they are intended.


    The key point is because of a lack of language support, OO C doesn't
    look like C++. The question could have been "Am I being too Java like?"

    --
    Ian Collins
    Ian Collins, Jan 20, 2012
    #18
  19. Eric Sosman <> 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) <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"
    Keith Thompson, Jan 20, 2012
    #19
  20. nroberts

    Kleuske Guest

    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
    Kleuske, Jan 20, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin
    Replies:
    0
    Views:
    469
    Martin
    Aug 4, 2004
  2. SB
    Replies:
    0
    Views:
    374
  3. Mike Foster
    Replies:
    0
    Views:
    902
    Mike Foster
    Jun 23, 2003
  4. Mark Parnell
    Replies:
    0
    Views:
    816
    Mark Parnell
    Jun 24, 2003
  5. Patrick Kowalzick
    Replies:
    5
    Views:
    470
    Patrick Kowalzick
    Mar 14, 2006
Loading...

Share This Page