inline command

Started by
41 comments, last by CProgrammer 20 years, 7 months ago
quote:Original post by Cedric
quote:Original post by CProgrammer
When is it generally good to use the inline command?

1. Don''t.
2. (For experts) Not yet.
3. If you really want to, profile first, and look try it for yourself. You can get some marginal gains that way.
quote:In my opinion, the inline mechanism is of great importance in the support of encapsulation/information hiding and the design of abstract data types

How do you support that opinion? What you wrote doesn''t make sense to me, but I don''t know you...

Cédric


Wrong. Using the inline keyword isn''t necessarily an optimization. It''s a way of telling the compiler "yes, this function is in the header file. Don''t complain about it being present int multiple object files."

Having small member functions like getters/setters in your header without the inline keyword might work for you on your compiler anyways, but don''t take it for granted.
Advertisement
quote:Original post by Anonymous Poster
Wrong. Using the inline keyword isn't necessarily an optimization. It's a way of telling the compiler "yes, this function is in the header file. Don't complain about it being present int multiple object files."

Yeah, but apart from lazyness, the goal of putting a function in a header file (that is, away from the rest of the class' implementation) is , AFAIK, optimization. I don't know of any design argument in favor of putting the body of the function in the header that doesn't involve optimization.

In fact, I don't remember ever writing the inline keyword at all, since I've hardly ever gone that far into optimization.
quote:Having small member functions like getters/setters in your header without the inline keyword might work for you on your compiler anyways, but don't take it for granted.

I don't have the Standard, but I would be surprised if the inline keyword is supposed to be mandatory. Can anyone confirm/infirm?

Cédric

[edited by - Cedric on September 3, 2003 10:50:02 PM]
I'm pretty sure that all compilers must recognize the keyword(s), but they do not have to implement them. The standard says that the inline keyword is only a suggestion. The compiler is free to ignore you. Like MSVC does a "cost/benefit" analysis, if it's worth it it inlines it, if not than it doesn't.

I've heard the inline keyword likened to a macro (sort of). Wherever that function is called, the body of it is placed directly into the code, instead of calling the function. Obvious differences/benefits are that it's in C++, so you have the benefit of type safety, encapsulation, yada yada. It's also done in the object code, not the source code. (I think)

Bottom line is that's what it does. You're all (or should be) analytical thinkers. It doesn't take a rocket scientist to know that sometimes this is good - sometimes bad. The good news is that you don't really have to know when it's which. As I stated most compilers determine that for you, so you can inline everything and it will only do it on what works best. Conversely, some compilers (MSVC, Intel, Borland I think) will inline functions that should be, but you didn't specify.

[edited by - random_acts on September 3, 2003 11:14:01 PM]
"Being Irish he had an abiding sense of tragedy that sustainted him through the temporary periods of joy." -- W.B. Yeats
I believe there is a __forceinline keyword (it was given to me on this board). That could be fun to play with when using recursive functions .
____________________________________________________________AAAAA: American Association Against Adobe AcrobatYou know you hate PDFs...
quote:Original post by Cedric
I don''t have the Standard, but I would be surprised if the inline keyword is supposed to be mandatory. Can anyone confirm/infirm?
Inline is part of the standard that must be implemented in compilers. Inlining the function with ''inline''-keyword isn''t mandatory, but the behaviour described by AP is.
I still think that my link to MSDN should had ended this discussion.
As for my comment on the inline function mechanism and information hiding, it should be in any introductory C++ text.

See §2.3 of C++ Primer by Stanley Lippman and Josee Lajoie.

Consider this definition:

class test
{
private:
size_t m_size;
};

Because m_size is within the private section of the class, we need to declare a public member function to provide users with access to it.

class test
{
public:
...
size_t size() const
{
return m_size;
}
...
private:
size_t m_size;
...
};

Now, assuming there is the following definition:

test tmp;

consider this:

size_t size1 = tmp.size(); // if m_size were private

int tmp_size2 = tmp.m_size; // if m_size were public

The first definition requires a function call, whereas the second involves only a direct memory access. Generally, a function call is significantly more expensive than a direct memory access. So, is this a design flaw with encapsulation? Does information hiding impose a significant, perhaps prohibitive, expense on the run-time efficiency of a program? No, because there is a solution, in the form of the inline function mechanism. An inline function is expanded in place at its point of call. So, generally, an inline function does not involve any function call at all. With our example, the initialisation of size1 will not actually involve a function call, but instead is inline-expanded during compilation into a direct memory access, i.e. the same sort of thing as size2's initialisation:

// pseudo
size_t size1 = tmp.size(); -> size_t size1 = tmp.m_size;

When a method is defined within a class definition, as it is with size(), it is automatically inlined. Alternatively, there is an inline keyword.

[ Google || Start Here || ACCU || STL || Boost || MSDN || GotW || MSVC++ Library Fixes || BarrysWorld || E-Mail Me ]

[edited by - Lektrix on September 4, 2003 7:12:00 AM]
[ Google || Start Here || ACCU || STL || Boost || MSDN || GotW || CUJ || MSVC++ Library Fixes || BarrysWorld || [email=lektrix@barrysworld.com]E-Mail Me[/email] ]
quote:Original post by haro
That''s actually wrong. An inline function will almost invariably increase the size of code. Let''s say the function for multiply takes 7 instructions, and x*y takes 3 instructions (register, mul, store). That means if you put "x*y" in your code 4 times it will take 12 instructions, while if you had used it as a function call takes only 7+3 instructions = 10.


Ummm, you are completely leaving out the fact that calling the function four times will result in the function call overhead being put in the code four times. Calling a function always takes more than 3 instructions, thus even if you use this function a billion times inlining it is still more efficient. This only goes for tiny functions though. Accessors/setters being the classic example.

Marijn

quote:In my opinion, the inline mechanism is of great importance in the support of encapsulation/information hiding and the design of abstract data types

I argue its the opposite. By injecting the body contents at the point of the callsite, you have to recompile if you change the class in a DLL. If you exported from a DLL then you could use the new class without having to recompile.

Inline is not some magic potion that should be attached to everything. Actually I think there is a LOT of misinformation going around about it, I will try to dig up some reputable links on inline. I know Effective C++ discusses it somewhat.

And really, don't use __forceinline, mostly because %99.9999999999999 you are NOT smarter than the damn compiler (the remainder of people not included would be compiler vendors, C++ ubergurus and John Carmack)! I don't even think Spirit uses __forceinline when it generates a grammar statically, and it runs fast as hell.

Here is my question, in practice is there a difference? What is it?

class C{public://implicit inline here?void f() { printf("C::F()"); }};//vs.class C{public:void f();};voidC::f(){ printf("C::F()");}


I have not looked at how Boost is set up, I think it is the latter for a reason though.

Edit:
The former portion is an implicit inline. The latter is treated normally unless you append inline to the definition.

http://www.parashift.com/c++-faq-lite/inline-functions.html

Read it, good discussion of how inlining isn't always faster and isn't always as simple as "for small functions".

[edited by - antareus on September 4, 2003 8:05:55 AM]

[edited by - antareus on September 4, 2003 8:06:32 AM]
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
quote:Original post by Cedric
quote:Having small member functions like getters/setters in your header without the inline keyword might work for you on your compiler anyways, but don''t take it for granted.

I don''t have the Standard, but I would be surprised if the inline keyword is supposed to be mandatory. Can anyone confirm/infirm?


I can confirm that I''ve had code that wouldn''t link because of missing inline tags (compiler was MINGW32).

This topic is closed to new replies.

Advertisement