|
When programming in C++, do you always put :: in front of every Windows API call to indicate it's in the global namespace, or you you think this makes the code ugly ?
|
|
|
|
|
Defenestration wrote: do you always put :: in front of every Windows API
No.
Defenestration wrote: indicate it's in the global namespace, or you you think this makes the code ugly ?
But why the hell do you want to use the API's in Global Namespace?
Is there some specific API that you are talking about?
You need to google first, if you have "It's urgent please" mentioned in your question.
 _AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: Is there some specific API that you are talking about?
Any of the Windows API functions.
_AnShUmAn_ wrote: But why the hell do you want to use the API's in Global Namespace?
Suppose you have a class which has a member function with the same signature as one of the Windows API functions. If you call this function, without the :: in front, from within one of the class member functions, it will call the class member function instead of the Windows API function. Putting :: in front, causes the Windows API function to be called. So, unless you mean to call the member function, you should really put :: in front of all Windows API functions to ensure they get called.
Admittedly, it's unlikely you'll create a member function with the same name and signature as a Windows API function, but it's possible.
|
|
|
|
|
Defenestration wrote: So, unless you mean to call the member function, you should really put :: in front of all Windows API functions to ensure they get called.
Yes, other wise the compiler won't be able to figure out which function do you want to call.
Defenestration wrote:
Admittedly, it's unlikely you'll create a member function with the same name and signature as a Windows API function, but it's possible.
Yes. But then you can certainly change the member function name to something else by prefixing or suffixing it.
You need to google first, if you have "It's urgent please" mentioned in your question.
_AnShUmAn_
|
|
|
|
|
The problem with not putting the :: in front of Win API's when calling them is that you could introduce a subtle bug; the code would compile OK with you thinking your code was calling the Win API, but instead would actually be calling the member function by mistake.
|
|
|
|
|
Defenestration wrote: with you thinking your code was calling the Win API
no, a developer should take care which version should be called, the global one or the other one in the class and should use :: accordingly
You need to google first, if you have "It's urgent please" mentioned in your question.
_AnShUmAn_
|
|
|
|
|
Thanks for helping me to think it through. In summary then:
:: only needs to be placed in front of Win API functions when they are called from within class member functions, otherwise it's not necessary (ie. when calling a Win API function outside of a class).
modified on Tuesday, December 9, 2008 2:41 AM
|
|
|
|
|
If you need to call the function declared in global namespace, then use the scope resolution operator, suffixing the API. If you don't do this, the local version of the API will be called.
For example, when you write an MFC app, something like MessageBox is provided to you by both - the MFC application framework and is as well available in the global namespace. A call to MessageBox will end up calling the one provided by the application framework, whereas ::MessageBox will call the one in the global namespace.
There's nothing special to it, just used to specify the scope of the API being called.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Defenestration wrote: When programming in C++, do you always put :: in front of every Windows API call
Yes.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
How about C and C++ standard library function calls ?
|
|
|
|
|
The scope resolution operator is C++ specific, thus you cannot use it in C.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
But you can call C library functions from C++ programs. So in this case, would you prefix C library function calls with :: ?
|
|
|
|
|
Defenestration wrote: So in this case, would you prefix C library function calls with :: ?
My point is you can't!
Try prefixing a call to e.g. strlen() with the scope resolution operator. You'll get a compiler error.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: My point is you can't!
Try prefixing a call to e.g. strlen() with the scope resolution operator. You'll get a compiler error.
Not if the source filename extension is .cpp
modified on Tuesday, December 9, 2008 5:18 AM
|
|
|
|
|
|
Hi all,
i want to know the difference between DLLImport attribute and creating a COMpointer and creating the instance then acessing the function of a dll...
Thanks in advance.
vikas da
|
|
|
|
|
DLL call in Compile Time
#pragmma comment(lib,"dll name")
Call at run time use
LoadLibrary()
function
|
|
|
|
|
i want to know whats the difference between the two
1.DllImport attribute
2.Coreate instance..with com pointer
to acess a exposed fuinction of a dll
vikas da
|
|
|
|
|
tasumisra wrote: i want to know the difference between DLLImport attribute and creating a COMpointer and creating the instance then acessing the function of a dll...
The comparison doesn't make sense, since a COM server may reside in a DLL. That DLL exposes at least two functions: DllRegisterServer() and DllUnregisterServer() that is called in order to register or unregister the COM server.
You cannot "create a COM pointer and call DllRegisterServer".
When you're calling ::CoCreateInstance(), or some equivalent, the server doesn't have to be located inside a DLL; it may be an out-of-process server that resides in an executable file (.exe).
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I'm sorry to trouble everyone, I have a feeling this should be a simple answer but I'm missing something.
I need to take in from a Rich Edit Box on my dialog box a string which can be a string in Chinese, Japanese, English, German, etc.
I'm currently using this:
char TextArray[SIZE]={0};
m_RichEditBox.GetWindowText(TextArray, SIZE);
When I encounter a Multi-char string (like the Chinese or Japanese ones), the string TextArray is filled with "????" instead (Yes, Question marks, in case you thought you saw wrongly)
I have tried to declare TextArray as a
TCHAR , tried to convert it to a wchar, tried to declare as a CString, but so far nothing has worked.
I have checked, I do not have _UNICODE declared, and since _MBCS is default in VC6, shouldn't I get some result instead of "????" ?
Or is my problem the fact I'm using VC6?
Thanks in advance, and if you need more info, feel free to ask.
Jeffrey
|
|
|
|
|
Hi Jeffrey,
I would like to ask you a few questions.
- If you want to process Japanese or German text (Unicode?!), why do you do an _MBCS build?
- Are you able to type in German text in the Rich Edit control?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Hi Rajesh
Aren't Japanese, Chinese and Korean Double byte and thus MBCS?
I read this page and many others that led me to think so:
[^]
My main focus are the Asian text for now. If I need Unicode for German, then I'll do another program for it later, I'm sorry for the confusion and perhaps my lack of understanding on it.
Are you telling me I should do a unicode build to handle both double byte and other non-double-byte text?
I can cut and copy any text I can get on Wordpad into my Rich Edit Control with no problems, but I cannot seem change my language settings when my program is in focus and is the main window, thus I cannot type directly into the rich edit control. Does this help to diagnose my problem?
Thanks
|
|
|
|
|
JJeffrey wrote: My main focus are the Asian text for now. If I need Unicode for German, then I'll do another program for it later, ...
But why welcome pain? Won't a Unicode build solve your problem? Perhaps I'm not understanding your requirements or something like that...
But I just opened VC6, created a dialog based app with a rich edit control (CRichEditCtrl) on it and then did a Unicode build. The first time, I wasn't able to copy or type in Japanese into the rich edit control, even though I've got the language installed on my machine and it displayed ????.
I then remembered it was the old cow-doo with VC6 which requires a manual hack, and opened the .RC file of the project in a text editor to find this particular piece of code:
CONTROL "",IDC_RICHEDIT1,"RICHEDIT",ES_AUTOHSCROLL | WS_BORDER |
WS_TABSTOP,60,83,150,61which I replaced with
CONTROL "",IDC_RICHEDIT1,"RICHEDIT20W",ES_AUTOHSCROLL | WS_BORDER |
WS_TABSTOP,60,83,150,61
A new build and off I go with my app ready to handle Japanese and German Unicode text.
JJeffrey wrote: Aren't Japanese, Chinese and Korean Double byte and thus MBCS?
I suggest that you read up on Unicode. From the link you gave me:
Note: New Windows applications should use Unicode to avoid the inconsistencies of varied code pages and for ease of localization.
Hope that would help. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Maybe I'm just too embedded into the notion that Unicode is Unicode, MBCS is MBCS and never the twain should they meet... Guess that idea is obsolete now.
I tried the "hack" with my MBCS build but nothing changed. I'll take some time to convert to a Unicode build and try again.
Thanks for your time and sorry for fustrating you.
|
|
|
|
|
JJeffrey wrote: I'll take some time to convert to a Unicode build and try again.
I'd very strongly recommend that you do it.
JJeffrey wrote: Thanks for your time and sorry for fustrating you.
Me frustrated? Not at all.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
