c++ and win 32 api

[Your Uncle]

I would think that this would qualify as a FAQ around here, for which I do
not see a hyperlink. Anyways, one of the reasons I made a commitment to
learning C was that I wanted to be near windows but not anchored to it. An
expression like
#define WIN_32
is perfectly kosher c. I have said elsewhere that the double colon token
was the 42nd Parallel between c and c*. I have a good politician's
understanding of what separates ISO C and ISO C++ . How the heck does the
c++ crowd differentiate itself from windows? In particular, can you access
win 32 api "legally?" My guess is that the answer to this question is going
to be similar to the speed limit on I-94 in Wisconsin when you can only tune
in the Jesus station and the corporate country one. "To have the pedal to
the medal is strictly verboten, and the cops will occasionally inflict a
speed levy, but everyone who has to penetrate the cheese barrier does so."
fu

 

[red floyd]

= How the heck does the
c++ crowd differentiate itself from windows?

Simple. If the API in question is not in the Standard, then it's system
specific.

In particular, can you access
win 32 api "legally?"

By using the Windows API. It's just not on-topic in comp.lang.c++,
that's all.

 

[Your Uncle]

Simple. If the API in question is not in the Standard, then it's system
specific.

Is the set of API's in the standard non-empty? fu

 

[Ian Collins]

Is the set of API's in the standard non-empty? fu

The subject appears to be operating system APIs. These are OT in any
pure language group and they invariably have their own groups.

C++ standard library (APIs) are defined in the C++ standard and by
inclusion, the C standard, so the set isn't empty.

 

[Your Uncle]

The subject appears to be operating system APIs. These are OT in any
pure language group and they invariably have their own groups.

C++ standard library (APIs) are defined in the C++ standard and by
inclusion, the C standard, so the set isn't empty.

Non-empty sets in the standard IS the definition of topical. furunculus

 

[Noah Roberts]

Non-empty sets in the standard IS the definition of topical. furunculus

The standard library does indeed have sets and they can be either empty
or non-empty, though not both at the same time.

 

[Howard]

Is the set of API's in the standard non-empty? fu

? I don't understand what you're trying to say here.


But in regards to your original question(s), when we speak of C++ in _this_
newsgroup, we're talking about the language itself, as defined by the
"Standard". The Standard does not include any third-party libraries, or
anything related to a specific compiler, platform, or related software.

The Windows API is a C library. (Actually, a set of C libraries, I think,
such as GDI and WinSDK, etc.) But you are free to write C++ programs which
interface with C libraries. It's perfectly "legal" to do so, and your code
is still valid "C++" (although it may no longer be portable). But it
becomes off-topic for this newsgroup when one begins to ask questions
_specific_ to that software (or any other third-party library, except
perhaps Boost).

So when you see someone say that someone else's posted example code "is not
C++" because it's full of Windows API stuff, what they mean is that the code
includes third-party stuff that we just don't discuss here. But we _will_
help with the code if it's just a C++ _language_issue, and not something
which requires knowledge of the API.

For example, if an API call is expecting a char* parameter, but we can see
you're passing a char instead, that's really a language issue, and we'll
help you by pointing out your error. (Provided of course that we can tell,
from either your code or comments, that a char* _is_ what the API is
expecting. We won't go looking that up ourselves.)

-Howard

 

[David Lindauer]

Non-empty sets in the standard IS the definition of topical. furunculus

just include windows.h and call the api functions the same way you would in C.
Some people prefer to do things like this:

::SetWindowText(...)

where the :: is a safety measure that tells the compiler to ignore any similar
function which may be defined in an inherited class... but it isn't a
requirement if you know none of your inherited classes override the windows api
functions you want to use.

David

 

[Your Uncle]

just include windows.h and call the api functions the same way you would
in C.
Some people prefer to do things like this:

::SetWindowText(...)

where the :: is a safety measure that tells the compiler to ignore any
similar
function which may be defined in an inherited class... but it isn't a
requirement if you know none of your inherited classes override the
windows api
functions you want to use.

That, unlike the previous reply to which I can reply categorically, went
past me at 100 mph. I've been in the thankless underworld of c long enough
that I feel I need to apply for refugee status. Please indulge me with a
continued explanation. fu

 

[David Lindauer]

That, unlike the previous reply to which I can reply categorically, went
past me at 100 mph. I've been in the thankless underworld of c long enough
that I feel I need to apply for refugee status. Please indulge me with a
continued explanation. fu

the :: scope operator is used to clarify the location of an identifier, e.g.:

mystruct::myclassmember

or

mynamespace::myidentififier

That way, you can get to identifiers which aren't strictly in scope.

I'm not sure what the strict definition of what happens when there is nothing
on the left hand side of the ::, but basically it will get you to a scope
outside the current namespace/class scope. This is by definition in the C++
language...

on to the off-topic part: it so happens that windows headers and windows
compilers are arranged so that the identifiers in the header file will show up
in this scope outside the current namespace/class scope (assuming you haven't
included the headers inside another namespace).

Now some object-oriented windowing systems will name classes and/or member
functions similarly to what the underlying OS call is named... for example a
Window object may have a function called SetWindowText. So for example if you
inherit from this Window object, then try to call SetWindowText from a member
function you are writing, you may intend to use the windows API but end up
calling the member function instead. That has obvious ramifications... to
avoid such ambiguity, some people like to qualify all os calls with the ::
operator when they do intend to do an OS call.

David

 

[Rolf Magnus]

the :: scope operator is used to clarify the location of an identifier,
e.g.:

mystruct::myclassmember

or

mynamespace::myidentififier

That way, you can get to identifiers which aren't strictly in scope.

I'm not sure what the strict definition of what happens when there is
nothing on the left hand side of the ::,

The name is searched in the global namespace.

but basically it will get you to a scope outside the current
namespace/class scope.

.... unless you are in the global namespace.

Now some object-oriented windowing systems will name classes and/or member
functions similarly to what the underlying OS call is named... for example
a Window object may have a function called SetWindowText.

AFAIK, you might run into trouble when using names defined in the Win32 API
for your own functions in some namespace or class, because the Win32 API is
using a lot of #define hackery, so the function name might actually be a
macro that is replaced with another name silently.

 

[Your Uncle]

The name is searched in the global namespace.


... unless you are in the global namespace.



AFAIK, you might run into trouble when using names defined in the Win32
API
for your own functions in some namespace or class, because the Win32 API
is
using a lot of #define hackery, so the function name might actually be a
macro that is replaced with another name silently.

Thank you for the replies. A source snippet might help:

/////////////////////////////////////////////////////////////////////////////
// The one and only CTja31App object

CTja31App theApp;

/////////////////////////////////////////////////////////////////////////////
// CTja31App initialization

BOOL CTja31App::InitInstance(){ ; }
/* end source */
I believe this is kosher c++ . How does one find a context to talk about
this stuff without the whole message map? fu

 

[Noah Roberts]

AFAIK, you might run into trouble when using names defined in the Win32 API
for your own functions in some namespace or class, because the Win32 API is
using a lot of #define hackery, so the function name might actually be a
macro that is replaced with another name silently.

min and max are defined as macros. This means many of the standard
functions get bashed by the preproc. You often have to undef min and
max after including a win32 api header.

 

[red floyd]

min and max are defined as macros. This means many of the standard
functions get bashed by the preproc. You often have to undef min and
max after including a win32 api header.

We're OT, but if you define NOMINMAX before including windows.h, you
don't get the evil macros.