mersenneforum.org  

Go Back   mersenneforum.org > Extra Stuff > Programming

Reply
 
Thread Tools
Old 2005-07-25, 13:44   #1
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22·5·373 Posts
Default Inlining

I have a weird problem with my VC++ compiler.

If, in file A I call routine XYZ(), and XYZ is declared __inline inside
file B, then the @#^&% LINKER reports that XYZ is an unresolved
symbol, even though I declare extern int __inline XYZ() inside file A.

Yet if I pull XYZ out of file B and into file A, everything is just fine.
If I remove the __inline declaration, everything is again fine.

Yech! It seems that inline routines must have the same source-level
scope as the code calling those routines.

Can anyone offer advice? I don't want to put all the source in one file...
R.D. Silverman is offline   Reply With Quote
Old 2005-07-25, 13:53   #2
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

2×7×11×41 Posts
Default

Could the inlined code be placed into a .h file and then included in the source? The declaration would not be required in this case.
rogue is offline   Reply With Quote
Old 2005-07-25, 14:40   #3
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22×5×373 Posts
Default

Quote:
Originally Posted by rogue
Could the inlined code be placed into a .h file and then included in the source? The declaration would not be required in this case.
Yes and no. File A calls routines in B and C. File B calls routines in C.
If I include B and C in A, and also include C in B, we get duplicates
and the linker complains again.

And (purely as a matter of personal taste) I dislike putting executable
code in .h files. They should be for data, structs, #defines, and other
header info, but not subroutines (in my opinion)

The point is how to get VC++ to do what it should. Perhaps there are
special flags/syntax for dealing with this scope issue.
R.D. Silverman is offline   Reply With Quote
Old 2005-07-25, 18:44   #4
Wacky
 
Wacky's Avatar
 
Jun 2003
The Texas Hill Country

32×112 Posts
Default

Quote:
Originally Posted by R.D. Silverman
Yes and no. File A calls routines in B and C. File B calls routines in C.
If I include B and C in A, and also include C in B, we get duplicates
and the linker complains again.
The standard practice is to either use #pragma once (which I don't like because it is too non-portable) or the standard construct

--- file my_header.h ---

#ifndef __MYHEADER_H__
#define __MYHEADER_H__ 1

.... header contents here ....

#endif

--- end of file ---

Quote:
And (purely as a matter of personal taste) I dislike putting executable
code in .h files. They should be for data, structs, #defines, and other
header info, but not subroutines (in my opinion)
I concur about executable code in headers. It used to be a strict rule back in the "dark ages" (1970's). We also used to define both public and private header files, thereby exposing only the minimum detail necessary for the interface.
However such practice is now considered obsolete by some. One of the problems is that C++ requires that the entire data structure be visible and it is a pain to write all of the extra boilerplate necessary to implement trivial functions in a separate file.
Unfortunately (IMHO), practices that are virtually required in one language have a way of migrating to others, even when they are not a good idea.

Last fiddled with by Wacky on 2005-07-25 at 18:46
Wacky is offline   Reply With Quote
Old 2005-07-25, 18:53   #5
akruppa
 
akruppa's Avatar
 
"Nancy"
Aug 2002
Alexandria

2,467 Posts
Default

Inlining has to be done at compile-time, not at linking time, so they indeed need to be in the same source module. Inlined function should always be declared static, the Intel compiler complains if they aren't, VC apparantly considers any inline function static by default (hence the unresolved symbol error).

Alex
akruppa is offline   Reply With Quote
Reply

Thread Tools


All times are UTC. The time now is 23:22.

Tue May 18 23:22:23 UTC 2021 up 40 days, 18:03, 0 users, load averages: 1.57, 1.71, 1.79

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.