Now, if the function isPowerofTwo is a reusable function, wouldn''t you put it in a .h file?? Which is the same as a member inline.

You aren''t going to type the function again for every cpp file, are u?

The bottom line is, every cpp file needs to see the definition of the inline function to compile. You cannot hide the implementation details in another cpp file.

Cool, I just solved my enum problem . Had to set "treat enums like int" in my project settings (BCB5). Then I didn''t have to include headers in other headers because of enum. I just could specify my enums using the keyword "enum" e.g.:

TDataSet* GetDataSet(enum ETSection Section, int iDataSet);

So the enum ETSection is declared (not yet defined) for my function.

Then I added some needed forward declaration of my classes.
That''s how I could reduce my header dependency to zero!

But now I have to drop my pretty cool inline interface .
Because my inline-accessor functions need defined (not just declared) classes to work.
But my application isn''t *that* speed dependent, so I prefer header independency to that little performance hit.

quote:

---

Original post by Void
Now, if the function isPowerofTwo is a reusable function, wouldn''t you put it in a .h file?? Which is the same as a member inline.

You aren''t going to type the function again for every cpp file, are u?

---

Not if you want to avoid dependencies. Redundancy (copying code multiple places) is a valid way to reduce dependency. If you''re working on a small project, sure, have a global utility header that everybody includes. If you have a large project that takes 8 hours to compile, you might be better off retyping that function for every file that uses it--especially if you''ve put it in a header file that every module includes (bad design), but only 2 or 3 modules actually use that particular function.

quote:

---

The bottom line is, every cpp file needs to see the definition of the inline function to compile. You cannot hide the implementation details in another cpp file.

---

This is true only if your inline function has external linkage. This is why I avoid inlines with external linkage.

It may bother you, but sometimes elegance must often be sacrificed in order to reduce dependency.

quote:

---

Original post by Stoffel
It may bother you, but sometimes elegance must often be sacrificed in order to reduce dependency.

---

I see your point..

quote:

---

Original post by Stoffel

Not if you want to avoid dependencies. Redundancy (copying code multiple places) is a valid way to reduce dependency. If you''re working on a small project, sure, have a global utility header that everybody includes. If you have a large project that takes 8 hours to compile, you might be better off retyping that function for every file that uses it--especially if you''ve put it in a header file that every module includes (bad design), but only 2 or 3 modules actually use that particular function.

---

I think it''s important to try to split your headers if you have such a problem. Doing this, less modules inlude the same header.
Retype the same function only if there''s *no other way* to do it (I never had such a case). Redundancy should be avoided whereever it''s possible. My opinion .

quote:

---

Original post by Stoffel

Not if you want to avoid dependencies. Redundancy (copying code multiple places) is a valid way to reduce dependency. If you''re working on a small project, sure, have a global utility header that everybody includes. If you have a large project that takes 8 hours to compile, you might be better off retyping that function for every file that uses it--especially if you''ve put it in a header file that every module includes (bad design), but only 2 or 3 modules actually use that particular function.

---

I think it''s important to try to split your headers if you have such a problem. Doing this, less modules inlude the same header.
Retype the same function only if there''s *no other way* to do it (I never had such a case). Redundancy should be avoided whereever it''s possible. My opinion .