|
There is no such thing. You'd do something like:
class C
{
public:
static int m_stat_var;
static int stat_func() { return 1; }
};
int C::m_stat_var = C::stat_func();
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
[removed]
modified 27-Nov-11 9:31am.
|
|
|
|
|
That's Just The Way It's Done. It's similar to the situation when you write "extern int n;" in a header file. You still need to actually declare the variable "int n;" in a .cpp file.
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
[removed]
modified 27-Nov-11 9:31am.
|
|
|
|
|
Well, I can't really answer that since I don't know C#, so don't know what you mean by a static constructor.
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
Nish [BusterBoy] wrote:
Why am I re-declaring the static int
You're not redeclaring it. The .h file declares it - the .cpp allocates storage for it. If you omitted it from the .cpp file you'd get an unresolved reference link error.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
|
I think I said "picky picky".
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
You are not redeclaring it but you are just declaring it. As it is static it resides even if your class object has not been constructed. It is like using static variables in functions or global vars. IMO the compiler initialises them to zero if you don't do the essentials. So here just after your class def you should initialize it otherwise the compiler spews errors.
Atul
Sonork 100.13714 netdiva
|
|
|
|
|
|
Static Constructor...The idea is kinda weird ..How are they implemented in C#?
Atul
Sonork 100.13714 netdiva
|
|
|
|
|
I'm a not exactly a veteran in C++, but I know my way around. I want to get into Windows programming, rather than console. I've heard of SDK and MFC. What is what and which do I want and what advantages are there to each? From what I've seen, SDK is much simpler, but is it better?
|
|
|
|
|
SDK first to understand how Windows works "under the hood." Once you have a grasp of that, then learn MFC, which is a C++ OO wrapper of the Win32 API.
Sorry about the brevity of this response - gotta go see my Valentine!
Jon Sagara
What about ?
Sonork ID: 100.9999 jonsagara
|
|
|
|
|
Ok, that answers one question. But the other is, where do I learn these SDK functions? What is the search term to use? I've crawled the web for about an hour now and I can't find anything. What is a good tutorial that defines all the functions and does a good job explaining everything. Thanks.
|
|
|
|
|
Try msdn.microsoft.com
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Anonymous wrote:
But the other is, where do I learn these SDK functions?
The Win32 programming bible "Programming Windows" by Charles Petzold covers Win32 SDK.
There is a good tutorial at Relisoft
Happy Windows Programming!!
Atul
Sonork 100.13714 netdiva
|
|
|
|
|
|
If your program is GUI intensive go for MFC which makes things a lot easier. But if you are doing some winsock stuff use plain SDK. The MFC socket classes have their own problems.
Nish
Nish was here, now Nish has gone;
He left his soul, to turn you on;
Those who knew Nish, knew him well;
Those who didn't, can go to hell.
I like to on the Code Project
Sonork ID 100.9786 voidmain
www.busterboy.org
|
|
|
|
|
You should absolutely start at the API level. Don't even think about getting into MFC until you are comfortable using the straight APIs. (Yes, I know, others will disagree with me; my opinion is based on my own experience and that of other programmers I know.)
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
FWIW Mike, I agree completely.
|
|
|
|
|
Couldn't agree with you more.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Bingo.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I know you have plenty of replies, but in a question like this it's best to have many answers to one problem so you can better make the decision yourself.
Like all have said already...Start with SDK...it doesn't hide anything from you.
SDK code is longer in source, but actually complies smaller...lots in some cases. MFC is basically a wrapper for the SDK...you'll hear that lots. It performs steps which you would normally have to do yerself, but maybe not always nessecary. These steps make developement quicker in MFC, but only once you understand the ins/outs of SDK.
Start with SDK...definetly...then move to MFC definetly.
Try designing MDI applications in SDK and you'll soon discover MFC is awesome. Plus Visual C++ tools cater to MFC more so than SDK. AppWizard generates a hello world for SDK and entire app (just fill in the blanks) in MFC.
MFC has helper classes which are awesome...CString to mention a few...will assist you big time. ClassWizard another great feature...message maps, my god i could go forever.
Why do i sound pro-mfc...I spent alot of time in SDK not wanting to change, cuz...well it's human nature to go with what you feel comfortable with. Once i did, I never want to go back...it's almost as easy as Visual Basic..it's incredible.
SDK is the hard part MFC is a snap...go with the SDK->MFC route. Only use pure SDK if you want less dependables and optimal speed and size.
Just my opnion...later!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I'd agree with pretty well everyone. Do at least some SDK stuff first as a 'training' exercise. If you need heavy GUI support though go striaght to MFC. The effort it saves is worth the fact that you won't have much of a clue about what is going on under the hood. One caveat I'd add though is that MFC is a bit flaky in places (someone rightly mentioned WinSock which is absolute pants under MFC) and it's not nice wading through the src to find out whether it's you or Bill's little Elves that have cocked up. Especially if you don't really know what you're doing.
i1.2sqrt(u).bcos(ur)sec(c)
but
b4.isqrt(u).ru/16
|
|
|
|
|
Is it possible to create a MDI Application that when executed (by default) opens 3 empty documents. The 1st document being CListView and the next 2 documents to be of CHtmlView?
If this is possible can anyone give me some pointers or some sample code.
Thanks!!
Rob Jones
|
|
|
|