I want to know if the practice is the best. Do I need to place inline keyword inside class definition or outside member function definition. For example
class A { public: A(); ~A();
inline void Test(); // should place inline here?
};
inline void A::Test() // should place inline here? { {
> I want to know if the practice is the best. Do I need to place inline > keyword inside class definition or outside member function > definition. For example
> class A > { > public: > A(); > ~A();
> inline void Test(); // should place inline here? no need > };
> inline void A::Test() // should place inline here? > { > {
yes, you need.
another way is to define func in class. class A{ public: void Test(){...};
Immortal Nephi writes: > I want to know if the practice is the best. Do I need to place inline > keyword inside class definition or outside member function > definition. For example
> class A > { > public: > A(); > ~A();
> inline void Test(); // should place inline here?
No.
> };
> inline void A::Test() // should place inline here?
Immortal Nephi wrote: > I want to know if the practice is the best. Do I need to place inline > keyword inside class definition or outside member function > definition. For example
> class A > { > public: > A(); > ~A();
> inline void Test(); // should place inline here? > };
> inline void A::Test() // should place inline here? > { > {
If you want to define your inline member function outside the class definition (as in your example above), you only need to specify 'inline' in the member definition (the second 'inline' in your example)
Andrey Tarasevich wrote: > If you want to define your inline member function outside the class > definition (as in your example above), you only need to specify 'inline' > in the member definition (the second 'inline' in your example)
If this is the case, why is the keyword 'inline' even supported inside class definitions? Isn't it completely obsolete and a no-op there? (Basically there's not even one single case where specifying that keyword in the class definition makes a difference.)
On Jul 6, 10:30 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Andrey Tarasevich wrote: > > If you want to define your inline member function outside > > the class definition (as in your example above), you only > > need to specify 'inline' in the member definition (the > > second 'inline' in your example) > If this is the case, why is the keyword 'inline' even > supported inside class definitions? Isn't it completely > obsolete and a no-op there? (Basically there's not even one > single case where specifying that keyword in the class > definition makes a difference.)
You can specify inline on either the definition or any declaration which precedes it, and the function will be inline. Current practice is to specify it on the definition, but at least one earlier compiler I used required it to be specified on the first declaration that appeared.
Of course, current best pratice is not to use inline at all, so the problem doesn't occur.
-- James Kanze (GABI Software) email:james.ka...@gmail.com 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
On Jul 6, 5:20 pm, joseph cook <joec...@gmail.com> wrote:
> > Of course, current best practice is not to use inline at all, so > > the problem doesn't occur. > Why do you say this?
Because it increases coupling.
> In-lining functions in a header file can be critical for > performance reasons.
Really? I never use it, and I've not had any performance problems.
If you do actually have a performance problem, and the profiler shows that it is in a tight loop where you do call a non-inlined function, then inlining it is a simple and cheap optimization. Using inline before the profiler says you have to, however, is premature optimization.
-- James Kanze (GABI Software) email:james.ka...@gmail.com 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
> On Jul 6, 5:20 pm, joseph cook <joec...@gmail.com> wrote: >>> Of course, current best practice is not to use inline at all, so >>> the problem doesn't occur.
>> Why do you say this?
> Because it increases coupling.
>> In-lining functions in a header file can be critical for >> performance reasons.
> Really? I never use it, and I've not had any performance > problems.
> If you do actually have a performance problem, and the profiler > shows that it is in a tight loop where you do call a non-inlined > function, then inlining it is a simple and cheap optimization. > Using inline before the profiler says you have to, however, is > premature optimization.
Inlining things in headers is a technique that saves programmer's time both for initial development, for use of the header, and for maintainance (which reportedly constitutes about 80% of all programming work).
I agree that doing inlining for reasons of performance would be premature optimization, of the kind that might even influence runtime in a negative way, and bring in unwanted coupling and have other undesirable effect.
However, used as a means for programmer productivity, not as premature optimization, its effect on coupling is generally negligible. It can even reduce the number of files that must be opened and read during a build. I think the programmer who's afraid of using std::vector just because it's perceived as a large header & requires full def of element type, is seriously misguided.
Cheers,
- Alf
-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote: > * James Kanze: > [...] >> If you do actually have a performance problem, and the profiler >> shows that it is in a tight loop where you do call a non-inlined >> function, then inlining it is a simple and cheap optimization. >> Using inline before the profiler says you have to, however, is >> premature optimization.
> Inlining things in headers is a technique that saves programmer's time > both for initial development, for use of the header, and for > maintainance (which reportedly constitutes about 80% of all programming > work).
I think that if this is really your issue (hardly, but I'll assume you have some measurements) then you (or your users in the case e.g. of libraries, for which I've often heard the "header-only is easier" claim) are likely to work with a severely limited environment and toolset. To me, creating one more file is just a matter of issuing ":e filename" and the file contents get initialized automatically with all that can be written automatically. Similarly for building. As to maintenance I really don't understand: what time do you save?
> Alf P. Steinbach wrote: >> * James Kanze: > > [...] >>> If you do actually have a performance problem, and the profiler >>> shows that it is in a tight loop where you do call a non-inlined >>> function, then inlining it is a simple and cheap optimization. >>> Using inline before the profiler says you have to, however, is >>> premature optimization.
>> Inlining things in headers is a technique that saves programmer's time >> both for initial development, for use of the header, and for >> maintainance (which reportedly constitutes about 80% of all >> programming work).
> I think that if this is really your issue (hardly, but I'll assume you > have some measurements) then you (or your users in the case e.g. of > libraries, for which I've often heard the "header-only is easier" claim) > are likely to work with a severely limited environment and toolset. To > me, creating one more file is just a matter of issuing ":e filename" and > the file contents get initialized automatically with all that can be > written automatically. Similarly for building.
It's also easy to write Perl. ;-)
> As to maintenance I > really don't understand: what time do you save?
For things that are defined in the header file you only need to look at one file, affecting continuity, and you see the relevant definition in context.
Cheers, & hth.,
- Alf
-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
> * James Kanze: > > On Jul 6, 5:20 pm, joseph cook <joec...@gmail.com> wrote: > >>> Of course, current best practice is not to use inline at all, so > >>> the problem doesn't occur. > >> Why do you say this? > > Because it increases coupling. > >> In-lining functions in a header file can be critical for > >> performance reasons. > > Really? I never use it, and I've not had any performance > > problems. > > If you do actually have a performance problem, and the profiler > > shows that it is in a tight loop where you do call a non-inlined > > function, then inlining it is a simple and cheap optimization. > > Using inline before the profiler says you have to, however, is > > premature optimization. > Inlining things in headers is a technique that saves > programmer's time both for initial development, for use of the > header, and for maintainance (which reportedly constitutes > about 80% of all programming work).
I don't know where you get that from. It is a nightmare with regards to maintenance, easily doubling the effort required. (To begin with, if you don't know if the function is inlined or not, you don't even know in which file to look for it. And of course, if you have to modify it, then all of the client code needs to be recompiled.)
> I agree that doing inlining for reasons of performance would > be premature optimization, of the kind that might even > influence runtime in a negative way, and bring in unwanted > coupling and have other undesirable effect. > However, used as a means for programmer productivity, not as > premature optimization, its effect on coupling is generally > negligible.
If it's used in a template, it's negligible, because the template code has to be included anyway (at least with most current compilers). If it's not a template, however, the effect in practice can be quite high.
Obviously, it's only one factor: you can write impossible to maintain code without a single inline function, and carefully used, you can minimize the impact. But globally, all of the coding guidelines I've seen for application code forbid inline functions---and usually also require user defined implementations of the functions the compiler will generate by default as well, since the compiler generated versions are inline. (The rules for library code are somewhat different, since you often have to guess where the client code's bottlenecks might occur.)
> It can even reduce the number of files that must be opened and > read during a build. I think the programmer who's afraid of > using std::vector just because it's perceived as a large > header & requires full def of element type, is seriously > misguided.
That, certainly. But std::vector is (hopefully) stable code, which isn't evolving while you're working. So you won't end up having to recompile everything because there was a small correction in the implementation somewhere. (If you upgrade your comp
