|
Inline tells the compiler that you would like to place the actual code of a function "inline" with the code you are calling it from instead of making a jump to a farther away location in memory. It may allow faster execution, but it requires more memory because multiple copies of the same code are used.
Functions that do a simple calculation or simply return a variable are good choices for inline. However, it may or may not be used for your public functions. It is an optional directive and the compiler decides whether to use it or not.
|
|
|
|
|
Also, you cannot use inline functions for callbacks (for an obvious reason), nor you can't inline functions that take a variable number of parameters.
my 2 cents 
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
Actually you can use inline functions for callback. In this case the compiler (if he decided to inline the thing at all) automatically creates a not-inlined version of the function.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there  )
|
|
|
|
|
To add to what the others have said, inline functions are also useful when you've got a class that's a minimal wrapper around some data (doesn't really do much with it but hold it together; this happens a lot when OOPing Win32 APIs...) and you want to be all nice and proper about it, so you make all data members private or protected. Instead of going to all the bother of writing out a separate CPP file with the access functions, since they're not going to be doing any validation or conversion anyway, just add them all to the header file as inline functions.
(oh yeah, no matter if you use the inline keyword or not, in order for the compiler to actually expand it, the function does have to be in the header file, or at least some file included where it's used.)
---
Shog9
Actually I use to find learning in bars when drinking really useful.
It sort of makes a language liquid. - Colin Davies, Thinking in English?
|
|
|
|
|
IMHO you shouldn't even bother worrying about it. The compiler will inline functions as part of its normal optimization when it sees that they are very short and fast.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Is there a way to control the order in which global objects are constructed?
I have a global debug object in my main module and a few global objects in another module that are getting constructed before the debug object.
Todd Smith
|
|
|
|
|
Todd Smith wrote:
Is there a way to control the order in which global objects are constructed?
No. If you need some explicit order, declare object as static in accessor function returning a pointer or reference. This way, you have the guarantee of proper initialization.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
there's no reliable way for this...
one thing you can do is to make your debug object a Singleton
and then call it's CDebugClass::Instance() method to initialize the instance in a point in your code where you know it'll be initialized before other objects, such as CMyApp::InitInstance if using MFC.
class CDebugClass
{
...
static CDebugClass & Instance();
...
};
CDebugClass & CDebugClass::Instance()
{
static CDebugClass theInstance;
return theInstance;
}
-Wes
Sonork ID 100.14017 wtheronjones
|
|
|
|
|
The standard clearly points out that the initialisation order of global objects is not deterministic.
However if you don't need to be portable you could use the #pragma init_seg() compiler statement. This works fine and is enough in most cases.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there  )
|
|
|
|
|
I have a text file (listfile.txt) with a list of filenames(no paths, just abc.bmp). This I got by doing dir/b in the dos command. Now I want to read these into some sort of array so I can put them in a database field as a sequence of records. SO my question is - what MFC functions do I have that will open my listfile.txt, read from it line by line , putting each line into an array element?
I was reading about fopen and fgets but I'd like CStrings if I can do it that way. I think the entries are null terminated plus carriage return and line feed (or maybe not linefeed ). I'm on win2K. Hope my question makes sense.
Thanks,
ns
|
|
|
|
|
|
That looks ideal. Many thanks,
ns
|
|
|
|
|
Please never, ever use fopen and fgets again. Read my articles on the iostream library instead.
If you must use MFC strings instead of standard ones, then the MFC reading stuff which Mike suggested is the way to go.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
[quote]Please never, ever use fopen and fgets again. Read my articles on the iostream library instead.
[/quote]
I agree about the use of CString with fgets(), -- but otherwise an old foggy like me will NEVER do without those functions.
|
|
|
|
|
Mel wrote:
but otherwise an old foggy like me will NEVER do without those functions.
Why not ? Do they actually do anything that iostreams does not, or is it just old habits dying hard ?
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
iostreams have their place, but often you have to resort to fread-style method (e.g. iostream->Read() ) In these cases, its just simpler to use FILE to begin with. For example, it took me a long time to determine how to write a numeric value and read it back with ostream.
ostream stream;
// open for writine not shown
int some_value = 10;
stream << some_value; // this is simple and pretty straight forward
but try to read it back fails:
istream stream;
// open for reading not shown here
stream >> some_value; // this does not work!
stream.Read(&some_value,sizeof(int)); // this works
So, I might as well have done this:
FILE *fp = fopen(...);
// write the value
fwrite( &some_value,1,sizeof(int),fp);
// now read it back
fread(&some_value,1,sizeof(int),fp);
This, to me, is a lot simple and more consistant than the preceeding iostream stuff. iostream has the advantage in writing and reading strings. But it is clumsy when working with binary data.
I might also add that I can use the same FILE pointer to read and write. Maybe I'm wrong, but I don't think you can do that with iostreams.
|
|
|
|
|
Mel wrote:
stream >> some_value; // this does not work!
It should. Why does it not work ? I do stuff like this with file streams all the time.
Mel wrote:
Maybe I'm wrong, but I don't think you can do that with iostreams.
You're wrong. You can create an istream, and ostream, or an iostream which does both.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
After the values of x1 and x2 are read, their valus are not the same as when they were written. The values after reading are: x1 = 1020 and x2 = 20.
[code]
#include "stdafx.h"
#include<fstream.h>
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
// TODO: Place code here.
fstream os;
int x1 = 10;
int x2 = 20;
os.open("test.dat", ios::out | ios::trunc | ios::binary);
if(os.is_open())
{
os << x1 << x2;
os.close();
os.open("test.dat", ios::in | ios::binary);
if(os.is_open())
{
os >> x1 >> x2;
os.close();
cout << "x1: " << x1 << " x2: " << x2;
}
}
return 0;
}
[/code]
|
|
|
|
|
Oh - they probably need some whitespace between them.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
This worked:
os << x1 << " " << x2;
os >> x1 >> x2;
But why should I have to do that?? This is a binary file, not a text file. I don't need to do that with FILE. Or is it just the M$ VC6 compiler?
I stepped into the << and >> operators and found that the M$ VC6 implementation of the << operator converts the binary data to text with sprintf(buf,"%d",number) and writes that string to the file. Then the >> operator uses strtol() to convert it back again. So it appears that when these two operators are used, the ios::binary flag is ignored.
|
|
|
|
|
I have no idea, I've never used another iostreams implimentation, or read what the standard says. But I think it should work without the space in binary mode, yes.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Christian Graus wrote:
Please never, ever use fopen and fgets again.
you ignored me last time, so i'll ask again.
what does iostream do that stream I/O can't ?
-c
Though the cough, hough and hiccough so unsought would plough me through,
enough that I o'er life's dark lough my thorough course pursue.
--Stuart Kidd
|
|
|
|
|
Chris Losinger wrote:
you ignored me last time, so i'll ask again.
No, I didn't. I posted a reply, I remember it clearly.
Chris Losinger wrote:
what does iostream do that stream I/O can't ?
1. If you encounter an exception, it will close the file and flush the buffer first.
2. I don't see any examples that help me here - is the fopen stuff able to stream all sorts of data types ? I notice the examples in MSDN are not valid C++, they have void main 
3. I am certain that the C style file stuff does not allow me to define my own custom stream, stream my own custom types, or provide my own modifers. Does it have modifiers at all ?
4. I just found some docs and fprintf, if it's the only way to write numbers, etc. has to qualify for one of the most ugly and hard to debug constructs I have ever seen.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
1. ok, that's handy.
2. fwrite takes a void * pointer, data types are meaningless.
3. this is apples and oranges. with fopen, you get (or put) a stream of bytes - break it up however you like.
4. yes, we know you don't like printf formatting but, for many people, it just feels right.
ok. so i can see how coming from iostreams to C I/O would seem ugly and primitive. but, from the other direction, iostreams seems fluffy and prissy.
-c
Though the cough, hough and hiccough so unsought would plough me through,
enough that I o'er life's dark lough my thorough course pursue.
--Stuart Kidd
|
|
|
|
|
Chris Losinger wrote:
so i can see how coming from iostreams to C I/O would seem ugly and primitive
Damn straight !!!
Chris Losinger wrote:
from the other direction, iostreams seems fluffy and prissy.
I guess so. And I guess I'm a hypocrite for decrying C# as too prissy in favour of C++, but in the end, it's all the same, we're all creatures of habit, aren't we ?
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
