Re: static inline functions - possible?

Discussion in 'C++' started by Balog Pal, Jul 31, 2009.

  1. Balog Pal

    Balog Pal Guest

    "Stephen Howe" <sjhoweATdialDOTpipexDOTcom>
    >
    > Is it possible to have static inline member functions of a class?


    Why not?

    > I dont ever recall seeing "static" and "inline" together.


    With member functions you rarely spell "inline", as just defining the
    function within the class makes it inline implicitly. And you must include
    the definition of functions just as the definition of the class, so
    separation here brings little more pain than just doing the definitions
    right at the place.

    > if so, how is it done ?


    The same way as the regular, just add 'inline' at front. :) Note, that for
    member functions you do NOT say 'static', ever, at the implementation point
    if it is outside the class def.
     
    Balog Pal, Jul 31, 2009
    #1
    1. Advertising

  2. Balog Pal wrote:
    > With member functions you rarely spell "inline", as just defining the
    > function within the class makes it inline implicitly. And you must include
    > the definition of functions just as the definition of the class, so
    > separation here brings little more pain than just doing the definitions
    > right at the place.


    It's a question of style, but many people prefer separating the
    declaration of a class from the implementation of its inline functions,
    to keep the header tidy and clean. (After all, the class declaration
    often doubles as a kind of "reference manual" to the usage of the class,
    especially in the lack of better documentation, or if the documentation
    is impractical to read.)

    If you implement the inline function inside the class declaration,
    then you can indeed skip the 'inline' keyword, ie:

    //-------------------------------------------------------------
    // Something.hh
    //-------------------------------------------------------------
    class Something
    {
    public:
    // Implicitly inline, doesn't need the keyword:
    int value() const { return something; }
    };
    //-------------------------------------------------------------

    But if you want to separate the the declaration and the implementation
    in the header, you have to specify the 'inline' keyword in the
    implementation:

    //-------------------------------------------------------------
    // Something.hh
    //-------------------------------------------------------------
    class Something
    {
    public:
    int value() const;
    };

    // 'inline' is required here:
    inline int Something::value() const { return something; }
    //-------------------------------------------------------------

    As you said, it makes no difference whether the function is also
    static or not. Just add the 'static' keyword in the declaration (the
    implementation doesn't need it).
     
    Juha Nieminen, Jul 31, 2009
    #2
    1. Advertising

  3. Balog Pal

    Balog Pal Guest

    "Juha Nieminen" <>
    > Balog Pal wrote:
    >> With member functions you rarely spell "inline", as just defining the
    >> function within the class makes it inline implicitly. And you must
    >> include
    >> the definition of functions just as the definition of the class, so
    >> separation here brings little more pain than just doing the definitions
    >> right at the place.

    >
    > It's a question of style, but many people prefer separating the
    > declaration of a class from the implementation of its inline functions,
    > to keep the header tidy and clean. (After all, the class declaration
    > often doubles as a kind of "reference manual" to the usage of the class,
    > especially in the lack of better documentation, or if the documentation
    > is impractical to read.)


    Yea, and for many cases the inline implementation documents what the
    function does. :)
    Where if it wouldn't there are good chances it is not fit for inlining
    anyway.

    Headers are good as dox, but you're better off to use doxygen or like
    system -- so directly reading becomes only task of who changes it, the rest
    can read the derived html, that well separates&jons the declarations, the
    code, the attached text, no matter how it is spread in the source files.

    I worked with those separated inlines -- at a time made some myself, my net
    conclusion is it makes things worse.
     
    Balog Pal, Jul 31, 2009
    #3
  4. Balog Pal wrote:
    > I worked with those separated inlines -- at a time made some myself, my net
    > conclusion is it makes things worse.


    Makes what worse?
     
    Juha Nieminen, Jul 31, 2009
    #4
  5. Balog Pal

    Balog Pal Guest

    "Juha Nieminen" <>
    > Balog Pal wrote:
    >> I worked with those separated inlines -- at a time made some myself, my
    >> net
    >> conclusion is it makes things worse.

    >
    > Makes what worse?


    readability, understandability, maitainance...
     
    Balog Pal, Jul 31, 2009
    #5
  6. Balog Pal wrote:
    > "Juha Nieminen" <>
    >> Balog Pal wrote:
    >>> I worked with those separated inlines -- at a time made some myself, my
    >>> net
    >>> conclusion is it makes things worse.

    >> Makes what worse?

    >
    > readability, understandability, maitainance...


    IMO the readability of a class declaration suffers if all the inline
    functions are implemented inside the declaration. They tend to make the
    class declaration very large (in lines of code).

    If the class is very small (in number of inline member functions) and
    all the inline functions are one-liners, then it's ok, but not otherwise.
     
    Juha Nieminen, Jul 31, 2009
    #6
  7. Balog Pal

    Balog Pal Guest

    "Juha Nieminen" <> az alábbiakat írta a következo
    hírüzenetben: w3Hcm.219$...
    > Balog Pal wrote:
    >> "Juha Nieminen" <>
    >>> Balog Pal wrote:
    >>>> I worked with those separated inlines -- at a time made some myself, my
    >>>> net
    >>>> conclusion is it makes things worse.
    >>> Makes what worse?

    >>
    >> readability, understandability, maitainance...

    >
    > IMO the readability of a class declaration suffers if all the inline
    > functions are implemented inside the declaration. They tend to make the
    > class declaration very large (in lines of code).
    >
    > If the class is very small (in number of inline member functions) and
    > all the inline functions are one-liners, then it's ok, but not otherwise.


    Exactly :), that is how calsses shall better look. If there is a ton of
    functions, and you want the compiler inline fat functions, I'd guess the
    problems will not come from organizing them in the header, and will hardly
    be cured by extracting those inlines.

    And classes with non-obvoius interface need doxy-like tools even more.
     
    Balog Pal, Jul 31, 2009
    #7
  8. Balog Pal wrote:

    > "Juha Nieminen" <> az alábbiakat írta a következo
    > hírüzenetben: w3Hcm.219$...
    >> Balog Pal wrote:
    >>> "Juha Nieminen" <>
    >>>> Balog Pal wrote:
    >>>>> I worked with those separated inlines -- at a time made some
    >>>>> myself, my net conclusion is it makes things worse.
    >>>> Makes what worse?
    >>>
    >>> readability, understandability, maitainance...

    >>
    >> IMO the readability of a class declaration suffers if all the inline
    >> functions are implemented inside the declaration. They tend to make
    >> the class declaration very large (in lines of code).
    >>
    >> If the class is very small (in number of inline member functions)
    >> and all the inline functions are one-liners, then it's ok, but not
    >> otherwise.

    >
    > Exactly :), that is how calsses shall better look. If there is a ton
    > of functions, and you want the compiler inline fat functions, I'd
    > guess the problems will not come from organizing them in the header,
    > and will hardly be cured by extracting those inlines.


    When I have eight functions each a page long, I don't like them inside
    the declaration. Rips the context apart.

    Gerhard
     
    Gerhard Fiedler, Aug 1, 2009
    #8
  9. Balog Pal

    Ian Collins Guest

    Gerhard Fiedler wrote:
    >
    > When I have eight functions each a page long, I don't like them inside
    > the declaration. Rips the context apart.


    When I have eight functions each a page long, I know I've done something
    wrong!

    --
    Ian Collins
     
    Ian Collins, Aug 1, 2009
    #9
  10. Balog Pal wrote:
    >> IMO the readability of a class declaration suffers if all the inline
    >> functions are implemented inside the declaration. They tend to make the
    >> class declaration very large (in lines of code).
    >>
    >> If the class is very small (in number of inline member functions) and
    >> all the inline functions are one-liners, then it's ok, but not otherwise.

    >
    > Exactly :), that is how calsses shall better look. If there is a ton of
    > functions, and you want the compiler inline fat functions, I'd guess the
    > problems will not come from organizing them in the header, and will hardly
    > be cured by extracting those inlines.


    I'm not talking about one-liners vs. 100-liners.

    Many functions which may be desirable to be inlined because of
    efficiency are often 3-5 lines long, sometimes even a bit more. Add to
    this the space taken by the curly braces, plus possibly all the function
    parameters not fitting one single line, and you will have short
    functions taking considerable amounts of visual space.
     
    Juha Nieminen, Aug 1, 2009
    #10
  11. On Fri, 31 Jul 2009 12:08:45 GMT, Juha Nieminen
    <> wrote:

    >Balog Pal wrote:
    >> With member functions you rarely spell "inline", as just defining the
    >> function within the class makes it inline implicitly. And you must include
    >> the definition of functions just as the definition of the class, so
    >> separation here brings little more pain than just doing the definitions
    >> right at the place.

    >
    > It's a question of style, but many people prefer separating the
    >declaration of a class from the implementation of its inline functions,
    >to keep the header tidy and clean. (After all, the class declaration
    >often doubles as a kind of "reference manual" to the usage of the class,
    >especially in the lack of better documentation, or if the documentation
    >is impractical to read.)


    Me included - a habit formed in languages like Modula 2 and Ada, and
    an objection I have to some other languages. Even if your editor can
    do "folding", can you assume that everyone elses can? And what about
    printed listings?

    Then again, there's always Doxygen.
     
    Stephen Horne, Aug 2, 2009
    #11
  12. On Fri, 31 Jul 2009 14:25:05 +0200, "Balog Pal" <> wrote:

    >I worked with those separated inlines -- at a time made some myself, my net
    >conclusion is it makes things worse.


    From call sites, you only see the name. If the code is a better quick
    description than the name, you probably shouldn't be using a function
    at all - you are reducing the readability of callers for no good
    reason. Having the code there at the declaration site should ideally
    be redundant - clutter and distraction, rather than informative - and
    therefore that clutter should be moved somewhere else.

    Of course one problem with replying in threads like this is that you
    can end up giving a falsely polarised misrepresentation of your actual
    views. On a different day, and reading different posts first, I might
    easily have made the same point you did.

    Also, Java and C# require all method definitions to be kept with the
    declarations, IIRC, whereas Ada takes the opposite view with strict
    separation of specifications and bodies. The fact that different
    languages take different extremist viewpoints without the world ending
    probably suggests that it's a bit of a non-issue.
     
    Stephen Horne, Aug 2, 2009
    #12
  13. On Sat, 1 Aug 2009 00:35:32 -0500, Gerhard Fiedler <>
    wrote:

    >When I have eight functions each a page long, I don't like them inside
    >the declaration. Rips the context apart.


    Why on Earth are you inlining page-long functions? That's a pretty
    fair size limit for non-inlined functions.

    For me, the issue is more width than length - can I reasonably fit the
    whole definition on a single line. As soon as the one-line rule
    breaks, I already need five lines, including the blank ones, as...

    void mymethod1 () { ... }
    void mymethod2 () { ... }

    becomes...

    void mymethod1 ()
    {
    ...
    }

    void mymethod2 ()
    {
    ...
    }

    An occasional multi-liner isn't a disaster, but if it really needs
    multiple lines, it probably shouldn't be inline anyway.
     
    Stephen Horne, Aug 2, 2009
    #13
  14. On Sat, 01 Aug 2009 18:10:44 +1200, Ian Collins <>
    wrote:

    >Gerhard Fiedler wrote:
    >>
    >> When I have eight functions each a page long, I don't like them inside
    >> the declaration. Rips the context apart.

    >
    >When I have eight functions each a page long, I know I've done something
    >wrong!


    Not necessarily - moving complexity to the call-graph doesn't
    eliminate it, and some functions really are just do-this then do-that
    then do-the-other. A comment at the top of each chunk may make more
    sense than splitting it up.

    But page-long *inline* member functions...

    To me, it suggests an ex-Java or C# programmer who hasn't absorbed a
    certain key fact about C++.
     
    Stephen Horne, Aug 2, 2009
    #14
  15. Balog Pal

    Ian Collins Guest

    Stephen Horne wrote:
    > On Sat, 01 Aug 2009 18:10:44 +1200, Ian Collins <>
    > wrote:
    >
    >> Gerhard Fiedler wrote:
    >>> When I have eight functions each a page long, I don't like them inside
    >>> the declaration. Rips the context apart.

    >> When I have eight functions each a page long, I know I've done something
    >> wrong!

    >
    > Not necessarily - moving complexity to the call-graph doesn't
    > eliminate it, and some functions really are just do-this then do-that
    > then do-the-other. A comment at the top of each chunk may make more
    > sense than splitting it up.


    One or two may be, but eight?

    > To me, it suggests an ex-Java or C# programmer who hasn't absorbed a
    > certain key fact about C++.


    Or a PHP programmer.

    --
    Ian Collins
     
    Ian Collins, Aug 2, 2009
    #15
  16. On Sun, 02 Aug 2009 15:50:24 +1200, Ian Collins <>
    wrote:

    >Stephen Horne wrote:
    >> On Sat, 01 Aug 2009 18:10:44 +1200, Ian Collins <>
    >> wrote:
    >>
    >>> Gerhard Fiedler wrote:
    >>>> When I have eight functions each a page long, I don't like them inside
    >>>> the declaration. Rips the context apart.
    >>> When I have eight functions each a page long, I know I've done something
    >>> wrong!

    >>
    >> Not necessarily - moving complexity to the call-graph doesn't
    >> eliminate it, and some functions really are just do-this then do-that
    >> then do-the-other. A comment at the top of each chunk may make more
    >> sense than splitting it up.

    >
    >One or two may be, but eight?


    I have a current example where the number is closer twenty. A DSL - a
    source-to-source translater. Each method is basically just dumping out
    a chunk of text with occasional substitutions etc using lots of stream
    insertion.

    Of course your reaction might well be that I should be using template
    text files/resources with substitution markers, and getting most of
    that out of the code completely. The reason I haven't done that yet is
    that another DSL I'm writing is designed to handle template output
    jobs such as this, and provide a bit more than a simple
    substitute-these-markers transformation. Sadly, you can't use a DSL
    until you've written the b*****d thing.

    The worst thing is that I thought my existing regular grammar/state
    machine compositing code would do the job - didn't think it through
    properly. Now I have an issue which implies a significant change to
    that model. What was supposed to be just-add-parser-and-text-output
    has become a heada^H^H^H^H^H^H^H an interesting theory/design problem.
     
    Stephen Horne, Aug 2, 2009
    #16
  17. Balog Pal

    James Kanze Guest

    On Jul 31, 12:52 pm, "Balog Pal" <> wrote:
    > "Stephen Howe" <sjhoweATdialDOTpipexDOTcom>
    > > Is it possible to have static inline member functions of a
    > > class?


    > Why not?


    > > I dont ever recall seeing "static" and "inline" together.


    > With member functions you rarely spell "inline", as just
    > defining the function within the class makes it inline
    > implicitly. And you must include the definition of functions
    > just as the definition of the class, so separation here brings
    > little more pain than just doing the definitions right at the
    > place.


    At least in the places I've worked, putting the definition
    inside the class has been forbidden. (There are several reasons
    for this, and they don't apply everywhere, but on the whole, I'd
    go along with the rule, at least for definitions in exported
    header files.)

    > > if so, how is it done ?


    > The same way as the regular, just add 'inline' at front. :)
    > Note, that for member functions you do NOT say 'static', ever,
    > at the implementation point if it is outside the class def.


    Yes, and you don't say "inline", usually, if the implemention is
    inside the class. But both are allowed on the same function, in
    any order.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Aug 2, 2009
    #17
  18. Balog Pal

    James Kanze Guest

    On Jul 31, 2:25 pm, "Balog Pal" <> wrote:
    > "Juha Nieminen" <>


    > > Balog Pal wrote:
    > >> With member functions you rarely spell "inline", as just
    > >> defining the function within the class makes it inline
    > >> implicitly. And you must include the definition of
    > >> functions just as the definition of the class, so
    > >> separation here brings little more pain than just doing the
    > >> definitions right at the place.


    > > It's a question of style, but many people prefer separating
    > > the declaration of a class from the implementation of its
    > > inline functions, to keep the header tidy and clean. (After
    > > all, the class declaration often doubles as a kind of
    > > "reference manual" to the usage of the class, especially in
    > > the lack of better documentation, or if the documentation is
    > > impractical to read.)


    > Yea, and for many cases the inline implementation documents
    > what the function does. :)


    Perhaps with the help of a few macros:). (I'm thinking of the
    usual programming by contract technique. I've heard of people
    who defined special macros, along the lines of "PRECONDITION()",
    "POSTCONDTION()", and "INVARIANT()", and insisted that the
    non-virtual public function be in the class definition, so that
    the invocation of such macros be visible. For various reasons,
    I've never used this technique, however.)

    > Where if it wouldn't there are good chances it is not fit for
    > inlining anyway.


    > Headers are good as dox, but you're better off to use doxygen
    > or like system -- so directly reading becomes only task of who
    > changes it, the rest can read the derived html, that well
    > separates&jons the declarations, the code, the attached text,
    > no matter how it is spread in the source files.


    You're even better off doing things in the correct order:
    writing the documentation first (e.g. as cweb, or using a tool
    like Rose), and generating the header files from it. And
    depending on the tool, it might not easily support such code in
    the header functions (Rose doesn't), at least if you want to
    make your header files "derived objects", not edited later.

    > I worked with those separated inlines -- at a time made some
    > myself, my net conclusion is it makes things worse.


    It probably depends on what you're doing. Putting code in the
    class definition doesn't make reading the class definition
    simpler, except for almost trivial classes (functional objects,
    etc.). Or, of course, if that code really is part of the
    "documentation".

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Aug 2, 2009
    #18
  19. Balog Pal

    James Kanze Guest

    On Aug 1, 8:10 am, Ian Collins <> wrote:
    > Gerhard Fiedler wrote:


    > > When I have eight functions each a page long, I don't like
    > > them inside the declaration. Rips the context apart.


    > When I have eight functions each a page long, I know I've done
    > something wrong!


    Just to be iconoclastic: I'd say that depends on the size of a
    page. A long, long time ago, a "page", meant a screenful on a
    80x24 character terminal---a class with eight functions, none of
    which are more than 24 lines long, sounds acceptable to me. (On
    the other hand, I once worked with a person who used an
    exceptionally small font on a Sparc---his "screenful" pages were
    something like 200x100 characters. And he used them. The
    results definitely weren't what I would consider acceptable.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Aug 2, 2009
    #19
  20. Balog Pal

    Ian Collins Guest

    James Kanze wrote:
    > On Aug 1, 8:10 am, Ian Collins <> wrote:
    >> Gerhard Fiedler wrote:

    >
    >>> When I have eight functions each a page long, I don't like
    >>> them inside the declaration. Rips the context apart.

    >
    >> When I have eight functions each a page long, I know I've done
    >> something wrong!

    >
    > Just to be iconoclastic: I'd say that depends on the size of a
    > page.


    :)

    > A long, long time ago, a "page", meant a screenful on a
    > 80x24 character terminal---a class with eight functions, none of
    > which are more than 24 lines long, sounds acceptable to me. (On
    > the other hand, I once worked with a person who used an
    > exceptionally small font on a Sparc---his "screenful" pages were
    > something like 200x100 characters. And he used them. The
    > results definitely weren't what I would consider acceptable.)


    I use 30" panels and a 12 point font, so a page is about 112 lines.

    --
    Ian Collins
     
    Ian Collins, Aug 2, 2009
    #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. Replies:
    3
    Views:
    473
  2. Daniel Vallstrom
    Replies:
    2
    Views:
    1,961
    Kevin Bracey
    Nov 21, 2003
  3. Sean
    Replies:
    4
    Views:
    680
    Rolf Magnus
    Apr 30, 2006
  4. Martin Wells

    Static inline functions with static local variables

    Martin Wells, Oct 6, 2007, in forum: C Programming
    Replies:
    10
    Views:
    719
    Army1987
    Oct 8, 2007
  5. Rahul
    Replies:
    3
    Views:
    463
    James Kanze
    Feb 28, 2008
Loading...

Share This Page