|
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
|
|
|
|
|
You know, just recently I did use your iostream article to read and write to a richtextbox which was giving me garbage when done with fread. Then I totally forgot about it, since I dont do too much of file IO. Thanks for the reminder. Wont hurt to re-read the article again either
Thanks,
ns
|
|
|
|
|
I'm making a W32 image viewer dialog and I resize the window according to each picture dimension.
I've got a problem with the scroll bars as their dimension is part of the client area. Thus I have to get the Horz. ScrollBar width in order to resize correctly.
I would also need to know if the scroll bar is visible or not in order to hide/show it only when necessary.
I found the GetScrollInfo and GetScrollBarInfo that could help me solve those 2 problems but they only are an indirect way to get the informations I need.
Is there a better API way to:
- Get the width/Height of a scroll bar
- Know if a scrollbar is shown/Hidden
The answer would probably be the same under MFC but I can't make a MFC dialog for thsi project.
Thanks
|
|
|
|
|
Yarp wrote:
I've got a problem with the scroll bars as their dimension is part of the client area.
If you're just using WS_HSCROLL/VSCROLL, the scrollbars are not part of client area.
Use GetSystemMetrics to get the scrollbar height/width.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Hi Tomasz, I just found your reply today while lurking through this forum. THnak you for your reply. Fortunately I recalled the GetSystemMetrics function this week end but I'm still very intersted by your answer.
Yes, I'm just using those 2 styles, and that's true they are not part of the client area - there's a not missing here. Is there any style that would include the scroll bar size within the client area ?
Yarp
http://www.senosoft.com/
|
|
|
|
|
yarp wrote:
Is there any style that would include the scroll bar size within the client area ?
No. If you need scrollbars *within* client area, then you have to abandon WS_HSCROLL/WS_VSCROLL and place scrollbar controls yourselft. Note that this will require repositioning them in WM_SIZE.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Ok, then I can live with the WS_*SCROLL scroll styles. Adding a scrollbar control would be of no benefit to me.
I was very surprised last week when after resizing my client area I found it had the proper size minus the H. scroll bar width. All is clear now. I'm a Borland CBuilder programmer at the origin - now moving to MSVC - that's why I've still a lot to learn about the GUI API.
... and that's why I need a W32 Window, my project is still half CBuilder, a quarter MFC, a quarter W32. Very Interesting too to mary those techniques but somtimes a bit messy 
Thanks
Yarp
http://www.senosoft.com/
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
