Scope resolution operator question

[Jack]

I want to write code that can be compiled as C and C++. In the Windows
API, there are many macros that help with scope resolution. For
example:

#ifdef __cplusplus
#define SNDMSG ::SendMessage
#else
#define SNDMSG SendMessage
#endif

If compiled as C++ code, the scope resolution operator is used. I can
see how that can be useful in some circumstances, but I don't think I
need it for my particular situation. But I don't know, that's why I'm
posting.

I'm writing some simple wrappers in the following form:

// MyWrappers.h

#ifdef __cplusplus
extern "C"
{
#endif

__inline int MyWrapper()
{
// Global function: Any need for scope resolution operator?
return (int)SendMessage( NULL, WM_USER, 0, 0 );
}

#ifdef __cplusplus
extern "C"
}
#endif

// eof

Is there any situation where not using the scope resolution operator
would cause problems?

Thanks,
Jack

 

[Phlip]

I want to write code that can be compiled as C and C++.

Exactly why?

Suggestion: Write in clean C, and your code will compile as C++.

When the time comes to ... do whatever you think your extra work will
achieve, then if your code is clean, you can easily upgrade to ... whatever.

In the Windows
API, there are many macros that help with scope resolution. For
example:

#ifdef __cplusplus
#define SNDMSG ::SendMessage
#else
#define SNDMSG SendMessage
#endif

There are just so many reasons that's not a good role model.

Is there any situation where not using the scope resolution operator
would cause problems?

The Windows API does that because of another bad MS decision. In MFC, a
class such as CWnd presents a member SendMessage(), with the same name. Many
OS-level objects have MFC representations, and these all duplicate their
function names as method names.

Of course SendMessage() soon dispatches to ::SendMessage(). So MS must
relentlessly disambiguate their SDK from their own MFC.

This is their burden. You should emulate very little of MFC, and you should
not replicate any of it. So if your own system has a C style wrapper on C++
code, or vice versa, it should give explicitely different names to different
functions. Even when they have a similar purpose.

 

[Jack]

Exactly why?

Suggestion: Write in clean C, and your code will compile as C++.

When the time comes to ... do whatever you think your extra work will
achieve, then if your code is clean, you can easily upgrade to ... whatever.


There are just so many reasons that's not a good role model.


The Windows API does that because of another bad MS decision. In MFC, a
class such as CWnd presents a member SendMessage(), with the same name. Many
OS-level objects have MFC representations, and these all duplicate their
function names as method names.

Of course SendMessage() soon dispatches to ::SendMessage(). So MS must
relentlessly disambiguate their SDK from their own MFC.

This is their burden. You should emulate very little of MFC, and you should
not replicate any of it. So if your own system has a C style wrapper on C++
code, or vice versa, it should give explicitely different names to different
functions. Even when they have a similar purpose.

Language recommendations, explanations about MFC, and pedantic
opinions aside, all I want to know is this:
Will not using the scope resolution operator ever cause problems with
this function?

__inline int MyWrapper()
{
// Global function: Any need for scope resolution operator?
return (int)SendMessage( NULL, WM_USER, 0, 0 );
}

Thanks,
Jack

 

[Phlip]

Language recommendations, explanations about MFC, and pedantic
opinions aside, all I want to know is this:
Will not using the scope resolution operator ever cause problems with
this function?

__inline int MyWrapper()
{
// Global function: Any need for scope resolution operator?
return (int)SendMessage( NULL, WM_USER, 0, 0 );
}

I just told you. You mistook it for a pedantic opinion.

 

[Jonathan Mcdougall]

Will not using the scope resolution operator ever cause problems with
this function?

__inline int MyWrapper()
{
// Global function: Any need for scope resolution operator?
return (int)SendMessage( NULL, WM_USER, 0, 0 );
}

If MyWrapper() is in the global namespace, no, it wouldn't do anything
different. However, if MyWrapper() is in a namespace or in a class,
enclosing scopes will be searched for first and the wrong function
might get chosen.


Jonathan

 

[Jack]

I just told you. You mistook it for a pedantic opinion.

You did? Maybe my news reader didn't download that part of your post.
Could you give me an example where the MyWrapper() function would have
problems because of its lack of a scope resolution operator?

Btw, I write code in C and C++. I need reusable code for both. I'm not
using MFC. I hate MFC. Please don't mention it again. I have MFC (and
lactose) intolerance. The MyWrapper() function does not have the
same name as the global function it calls. The MyWrapper() function is
not a member function of a class.

Thanks,
Jack

 

[Jack]

If MyWrapper() is in the global namespace, no, it wouldn't do anything
different. However, if MyWrapper() is in a namespace or in a class,
enclosing scopes will be searched for first and the wrong function
might get chosen.

Yes, it is definitely global. I thought that made sense, but I needed
the confirmation. Thanks dude.

L8