Microsoft abandons the C language

M

Malcolm McLean

בת×ריך ×™×•× ×©×œ×™×©×™, 28 ב×וגוסט 2012 11:03:02 UTC+1, מ×ת Bart:
But try and use something more recent, such as GDI Plus, and it's all
defined in terms of classes. How the hell do you access those from C? Or
from my language (which just copies whatever C has to do!)? How would COM
help here?
COM has a C interface. Whilst I've forgotten the details, basically you query
the base object with a string requesting the "interface", and get a list
of function pointers back. It's horrible, but you can make it work.
 
B

BartC

Malcolm McLean said:
בת×ריך ×™×•× ×©×œ×™×©×™, 28 ב×וגוסט 2012 11:03:02 UTC+1, מ×ת Bart:
COM has a C interface. Whilst I've forgotten the details, basically you
query
the base object with a string requesting the "interface", and get a list
of function pointers back. It's horrible, but you can make it work.

People kept telling me that tkinter (the graphics API) could be used from C,
but no-one ever had any examples! (I think in that case, it had to work by
passing control of your program to a TCL interpreter; actually executing
your C application (perhaps a million lines of mission-critical code) was
secondary to displaying a couple of buttons in a window!)

With COM, people are telling me the same thing, but can never pinpoint
exactly how it would help calling that method in that C++ class...
 
J

James Kuyper

On 08/28/2012 07:14 AM, David Brown wrote:
....
I don't know how many votes they get (or even to what extent the
committee uses votes), but being a major toolchain vendor, they get a
lot of influence on the committee. That seems only reasonable.

As I understand it (any committee members who are reading this feel free
to correct me) the members of the ISO committee are national standards
organizations, one per country, with one vote each. For reasons I'm not
sure of, ANSI (the US member) seems to have influence greatly
disproportional to it's voting power.
Within ANSI, membership is open to foreign citizens, which is why many
people whose own country doesn't have a standards organization sitting
on the ISO committee participate through ANSI instead. Non-voting
membership is free, voting membership costs money and imposes attendance
requirements at meetings, but no organization can purchase more than one
voting membership (except for "Self", the organization that you can
register as representing if you are not actually representing anyone but
yourself). The cost and attendance requirements are trivial for most
companies, but a bit onerous for an individual. Despite that, a large
fraction of the committee's members are individuals who are paying their
own way.

Microsoft may have had a lot of informal influence, but formally, at
least, they could not have had more than one vote.
 
B

BruceS

Am 28.08.2012 07:47, schrieb Ansel:

you seem to have run out of arguments here

I have already seen quite a number of "interesting" people in NG, but I
rarely have seen somebody as rude as you.

Welcome to Usenet, Jens. This is hardly a feature of this ng
specifically. My suggestion, which you can treat as you like, is to have
a sort of "black list" and "white list". Those who (in your opinion) add
nothing to the conversation, you simply ignore, whether automatically
through your newsreader or manually. Those who are nearly always worth
reading, you look for first, especially when time is short. The rest,
read when you have the time, not when you don't. My own lists would be
of little value to you, and possibly insult/compliment some here without
purpose, but I can say that there are regulars to this group in each.
 
J

Jens Gustedt

Am 28.08.2012 16:10, schrieb BruceS:
Welcome to Usenet, Jens. This is hardly a feature of this ng
specifically. My suggestion, which you can treat as you like, is to have
a sort of "black list" and "white list". Those who (in your opinion) add
nothing to the conversation, you simply ignore, whether automatically
through your newsreader or manually. Those who are nearly always worth
reading, you look for first, especially when time is short. The rest,
read when you have the time, not when you don't. My own lists would be
of little value to you, and possibly insult/compliment some here without
purpose, but I can say that there are regulars to this group in each.

Bruce, thanks, but that is (basically) what I already do. But often
there is not such a clear cut, some of these egos all of a sudden are
able to produce valid contributions.

And I have taken the habit to mark such things when they are directed
towards me personally. Just to not to leave the impression that I
pretend to not having seen it and also to ensure that anybody notices.

Jens
 
M

Melzzzzz

On Mon, 27 Aug 2012 20:02:58 -0700 (PDT)
That presumably applies to C too. In that case why all the fuss in
this

thread? Or maybe:













(from an expert in writing C compilers specific to Windows) using
COM isn't

as simple as you seem to be implying.

He was talking about reimplementing his compiler so that it ran as a
metro app (which is pretty crazy to even think about, and as he's
been told, he doesn't need to do that; the desktop still exists in
Windows 8). He wasn't talking about using COM in general.
But, seeing as you're the expert, perhaps you can give an example
in writing

a simple task in C to run under Windows, without using 'stone-age'
DLLs and

without a console. Such as Hello, World (just an alert box will
do). You

might need to explain exactly how the executable that the C is
compiled to,

actually talks to Windows.

When I said "stone age" I was referring to DLL-exported functions,
not about DLLs themselves. COM components are DLLs anyway (or EXEs
sometimes).

Anyway, the easiest way to create a COM component in C++ is with ATL.
There isn't an equivalent for C, but you can do it without ATL (be it
C or C++), although you have to do manually a lot of the things VS
does for you.

First thing is to create an interface in an IDL (Interface Definition
Language) file for the functionality you need:

[uuid(CBC6B4ED-107C-43b3-BA0A-054E6430F435), object]
interface IHelloCom : IUnknown
{
HRESULT SayHello();
}

Then you compile the IDL file with the MIDL compiler, which creates
the equivalent interfaces in C or C++. For C++ it gives:

MIDL_INTERFACE("CBC6B4ED-107C-43b3-BA0A-054E6430F435")
IHelloCom : public IUnknown
{
public:
virtual HRESULT STDMETHODCALLTYPE SayHello( void) = 0;

};

For C it gives:

typedef struct IHelloComVtbl
{
BEGIN_INTERFACE

HRESULT ( STDMETHODCALLTYPE *QueryInterface )(
IHelloCom * This,
/* [in] */ REFIID riid,
/* [annotation][iid_is][out] */
__RPC__deref_out void **ppvObject);

ULONG ( STDMETHODCALLTYPE *AddRef )(
IHelloCom * This);

ULONG ( STDMETHODCALLTYPE *Release )(
IHelloCom * This);

HRESULT ( STDMETHODCALLTYPE *SayHello )(
IHelloCom * This);

END_INTERFACE
} IHelloComVtbl;

interface IHelloCom
{
CONST_VTBL struct IHelloComVtbl *lpVtbl;
};

Then you need to implement the interface:

class __declspec(uuid("7A5F33E4-F4B8-4932-9207-1EF2B642C910"))
HelloCom : public IHelloCom {
public:
// IUnknown methods:
HRESULT __stdcall QueryInterface(REFIID riid, void** ppvObject)
{ ... } ULONG __stdcall AddRef() { ... }
ULONG __stdcall Release() { ... }

// IHelloCom methods:
HRESULT __stdcall SayHello()
{
MessageBox(nullptr, L"Hello COM!", L"Hello COM", 0);
return S_OK;
}
};

I don't really know how to do that one in C.

In C you would populate IHelloComVtbl with pointers to functions
taking first parameter IHelloCom , you wouldn't need HelloCom
as it would be identical to IHelloCom.
You also need to implement IClassFactory so that COM can instantiate
our HelloCom class:

class HelloComFactory : public IClassFactory
{
public:
// ...
// same IUnknown methods
// ...

// IClassFactory methods:
HRESULT __stdcall CreateInstance(IUnknown* pUnkOuter, REFIID
riid, void** ppvObject) {
if (pUnkOuter != nullptr)
return CLASS_E_NOAGGREGATION;

HelloCom* pObject = new HelloCom();

Here you would allocate with malloc and assign lpVtbl pointer.

And this could be the client:

int main()
{
CoInitialize(nullptr);

IHelloCom* pHelloCom;
HRESULT hr = CoCreateInstance(
__uuidof(HelloCom),
nullptr,
CLSCTX_INPROC_SERVER,
__uuidof(IHelloCom),
reinterpret_cast<void**>(&pHelloCom)
);

if (FAILED(hr))
return -1;

pHelloCom->SayHello(); // or IHelloCom_SayHello(pHelloCom) in C

Or pHelloCom->lpVtbl->SayHello(pHelloCom)
if you want to allow subclassing.
It looks way involved but it does have advantages for any real app,
and like I said it's easier with ATL.

If you want to do it in C than there is no help from libraries.
COM is actually microsoft virtual table implementation as
their C++ compiler does job you would do manually in C;)

Cheers!
 
R

rashid

#include <stdbool.h>
#include <complex.h>
#include <stdint.h>

inline void foo(uint32_t *restrict p) { }

int main(void) {
bool b = false;
int size = 20;
uint32_t vla[size];
double complex x;
foo(vla);
return 0;
}

I don't know how well MSVC supports the various versions of the C++
standard. My guess (and it's no more than that) is that they're working
on C++11 support.

Look Keith, most of this is NOT C OR C++. You probably use an extension
language with all this strange stuff. For example, in C you cannot have
vla[size] where size is a variable. You must do
#define size 20
instead.

Maybe in high level languages like PERL you can do that.
[...]
??? Are you a crazy? Or you only use JAVA? __Most__ modern software
development relies on C/C++.

Perhaps this is just a confusion about terminology.

No, I don't think so. You name any common modern sofware - Excel or
Acrobat or Skype or Firefox or anything - it is ALL coded mainly in C/C++.

I feel like people in this forum operate, using a set of rules I don't
understand. Like a parallel universe!
Even if you're right, you really should be more polite. Being
simultaneously rude and wrong is not good for your reputation here.

Sorry but if someone deliberately spreads lies, I will politely call him
out on it.
 
A

Anders Wegge Keller

Look Keith, most of this is NOT C OR C++.

To my untrained eyes, that looks like correct C11. Maybe even C99,
but there are some features that I've never used, so I cannot say for
sure.
You probably use an extension language with all this strange
stuff. For example, in C you cannot have vla[size] where size is a
variable. You must do #define size 20 instead.

VLA's have been part of C since C99. Have you been living under a
rock for the past 13 years?

..
Sorry but if someone deliberately spreads lies, I will politely call
him out on it.

I'll get the popcorn going, while I wait to see what Nemesis have
prepared for you.
 
R

Rui Maciel

Ansel said:
Well if vendors just bowed to ISO, then there would be no check-n-balance.
"Absolute power corrupts absolutely".

Nonsense. The standards are set by those who participate in the
standardisation process, and that includes the vendors. In fact, I suspect
that the new C standard was set mainly by people who represented these
vendors.

Apparently ISO did not get MS's
committal sign-off on the standard before it went to the printing press
(?) that they would implement it in its entirety? Live and learn? Did they
fair better with C 11 (or whatever the newest C standard is)? ISO in need
of some management consulting?

Bullshit. Microsoft was heavily involved in the creation of the new
standard for C and C++. With C, apparently it has sent a participant to at
least all the WG14 meetings where a minute was recorded.

http://www.open-std.org/JTC1/SC22/WG14/www/meetings


Rui Maciel
 
J

James Kuyper

#include <stdbool.h>
#include <complex.h>
#include <stdint.h>

inline void foo(uint32_t *restrict p) { }

int main(void) {
bool b = false;
int size = 20;
uint32_t vla[size];
double complex x;
foo(vla);
return 0;
}

I don't know how well MSVC supports the various versions of the C++
standard. My guess (and it's no more than that) is that they're working
on C++11 support.

Look Keith, most of this is NOT C OR C++. You probably use an extension
language with all this strange stuff. For example, in C you cannot have
vla[size] where size is a variable. You must do
#define size 20
instead.

This "strange language" is called C99. It's been the official version of
C for the last 12 years (though implementation of C99 has been slow),
and has just been replaced as the official version of C by an even
stranger language called C2011.

....
No, I don't think so. You name any common modern sofware - Excel or
Acrobat or Skype or Firefox or anything - it is ALL coded mainly in C/C++.

Where is this language defined? I know of a language named C, another
distinct language named C++, but there's no language that I'm aware of
named C/C++. How does it differ from C? How does it differ from C++? Is
it standardized? If so, who issued the standard, and what is the
official standard's designation? It's not an ANSI standard, nor an ISO
standard - I just checked.
 
J

Jens Gustedt

Am 28.08.2012 20:35, schrieb Anders Wegge Keller:
To my untrained eyes, that looks like correct C11. Maybe even C99,
but there are some features that I've never used, so I cannot say for
sure.

It *is* all valid C99, Keith constructed it like that for a purpose.

Sorry rashid, but you completely missed the point.

Jens
 
V

Vincenzo Mercuri

Il 28/08/2012 21:11, Jens Gustedt ha scritto:
Am 28.08.2012 20:35, schrieb Anders Wegge Keller:

It *is* all valid C99, Keith constructed it like that for a purpose.

Sorry rashid, but you completely missed the point.

What is odd is that both gcc (4.7.1) and clang (3.2) will fail
when linking. They probably choose not to inline, then they look
for an "external symbol" for `foo()' but won't find it. I wonder
whether the Standard can justify such a failure.
 
M

Melzzzzz

Il 28/08/2012 21:11, Jens Gustedt ha scritto:

What is odd is that both gcc (4.7.1) and clang (3.2) will fail
when linking. They probably choose not to inline, then they look
for an "external symbol" for `foo()' but won't find it. I wonder
whether the Standard can justify such a failure.

It will fail only on debug builds because gcc than does not honor
inlining. With optimizations it will compile...
 
V

Vincenzo Mercuri

Il 28/08/2012 22:29, Melzzzzz ha scritto:
It will fail only on debug builds because gcc than does not honor
inlining. With optimizations it will compile...

Compiling with optimizations enabled means forcing inlining. It will
also compile defining that function as "static inline" or providing
an "extern" declaration and a definition for it. The Standard says that
"It is unspecified whether a call to the function uses the inline
definition or the external definition". Does the Standard suggest that
we should provide both an "inline" and an "external" definition?
If yes, that would be "strange".
 
M

Melzzzzz

Il 28/08/2012 22:29, Melzzzzz ha scritto:

Compiling with optimizations enabled means forcing inlining. It will
also compile defining that function as "static inline" or providing
an "extern" declaration and a definition for it. The Standard says
that "It is unspecified whether a call to the function uses the inline
definition or the external definition". Does the Standard suggest that
we should provide both an "inline" and an "external" definition?
If yes, that would be "strange".

Agreed, this is bug in gcc/clang. g++ links happily
inline functions with debug build, so it must be bug in c backend
as they are different in gcc.
 
J

James Kuyper

On 08/28/2012 05:09 PM, Vincenzo Mercuri wrote:
....
Compiling with optimizations enabled means forcing inlining.

Not necessarily - a sufficiently smart compiler might realize that,
depending upon the context, a given piece of code could execute more
efficiently if not inlined.
... It will
also compile defining that function as "static inline" or providing
an "extern" declaration and a definition for it. The Standard says that
"It is unspecified whether a call to the function uses the inline
definition or the external definition". Does the Standard suggest that
we should provide both an "inline" and an "external" definition?
If yes, that would be "strange".

It might seem strange, but "it is unspecified" which definition gets
called, and you've got serious problems if you don't define the one that
actually gets called. Different calls to the same function within a
single translation unit could call each; the same call could call a
different version each time it's executed. That's the power of
"unspecified". I would therefore consider it strongly recommended that
you provide both definitions. C's pre-processing statements can be used
to ensure that both definitions are equivalent, while actually writing
the definition only once.

You can also avoid the issue entirely by using "static inline".
 
V

Vincenzo Mercuri

Il 28/08/2012 23:16, Melzzzzz ha scritto:
Agreed, this is bug in gcc/clang. g++ links happily
inline functions with debug build, so it must be bug in c backend
as they are different in gcc.

Mmm.. it looks like another subtle difference between C and C++.
Compilation with the Intel Compiler succeeds. I can't say about
Solaris cc.
 
K

Keith Thompson

rashid said:
#include <stdbool.h>
#include <complex.h>
#include <stdint.h>

inline void foo(uint32_t *restrict p) { }

int main(void) {
bool b = false;
int size = 20;
uint32_t vla[size];
double complex x;
foo(vla);
return 0;
}

I don't know how well MSVC supports the various versions of the C++
standard. My guess (and it's no more than that) is that they're working
on C++11 support.

Look Keith, most of this is NOT C OR C++. You probably use an extension
language with all this strange stuff. For example, in C you cannot have
vla[size] where size is a variable. You must do
#define size 20
instead.

It's not C++. It is perfectly valid C. It uses features that aren't
defined by the old 1990 ISO C standard, but that were introduced by
the 1999 standard. (The 1999 standard has officially been superseded
by the 2011 standard, but I didn't use any C11-specific features).

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> is a good
draft of the C99 standard; it includes the standard itself, as published
by ISO, with the contents of the three Technical Corrigenda merged into
it.

For your reference:

The type _Bool is described in 6.2.5 paragraph 2. <stdbool.h>, which
defines the identifiers `bool`, `false`, and `true`, is described in
section 7.16.

Complex types are described in 6.2.5p11; operations on them are
described elsewhere, particularly in section 6.5. <complex.h> is in
section 7.3.

<stdint.h>, which defines uint32_t, is described in section 7.18.

Inline functions are described in 6.7.4. I actually seem to have
made a mistake with that (with gcc, the program compiles but doesn't
link); changing `inline void foo` to `static inline void foo`
fixes that problem.

Variable length arrays, or VLAs, are described in 6.7.5.2p5.

The latest draft of the C11 standard is
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>.
It describes all the same features, possibly in differently numbered
sections. Complex numbers and VLAs have been made optional in
C11, so in that sense my program is not entirely portable to all
conforming C implementations. It's probably too early to tell how
many implementations will actually omit these features.

My program (with the added `static`) compiles, links, and
executes correctly with `gcc -std=c99 -pedantic` or with
`gcc -std=c11 -pedantic`, using gcc version 4.7.0.

Do us all a favor and educate yourself before accusing others of
spouting nonsense, or doing so yourself.

[...]
No, I don't think so. You name any common modern sofware - Excel or
Acrobat or Skype or Firefox or anything - it is ALL coded mainly in C/C++.

I feel like people in this forum operate, using a set of rules I don't
understand. Like a parallel universe!

That may well be true. I suggest you try to learn the rules by which
the rest of us operate.

I just tried to clarify what "C/C++" actually means. Your claim
that those applications are "coded mainly in C/C++" is meaningless
unless you explain just what you mean by "C/C++". Are you saying
that they're coded in a mixture of C and C++? Are they compiled
with a C compiler or with a C++ compiler? How does "C/C++" differ
from C? How does it differ from C++?
Sorry but if someone deliberately spreads lies, I will politely call him
out on it.

You've been anything but polite -- or correct.
 
V

Vincenzo Mercuri

Il 28/08/2012 23:24, James Kuyper ha scritto:
On 08/28/2012 05:09 PM, Vincenzo Mercuri wrote:
...

Not necessarily - a sufficiently smart compiler might realize that,
depending upon the context, a given piece of code could execute more
efficiently if not inlined.

Of course, I didn't mean that as a general rule for optimizations.
That's true for gcc though.
It might seem strange, but "it is unspecified" which definition gets
called, and you've got serious problems if you don't define the one that
actually gets called. Different calls to the same function within a
single translation unit could call each; the same call could call a
different version each time it's executed. That's the power of
"unspecified". I would therefore consider it strongly recommended that
you provide both definitions. C's pre-processing statements can be used
to ensure that both definitions are equivalent, while actually writing
the definition only once.

Thanks, that's exactly what I wanted to know :)
You can also avoid the issue entirely by using "static inline".

Indeed, this will always make it compile.
 
K

Keith Thompson

Vincenzo Mercuri said:
Il 28/08/2012 21:11, Jens Gustedt ha scritto:

What is odd is that both gcc (4.7.1) and clang (3.2) will fail
when linking. They probably choose not to inline, then they look
for an "external symbol" for `foo()' but won't find it. I wonder
whether the Standard can justify such a failure.

Changing `inline void foo` to `static inline void foo` avoids
that problem. (I compiled with `gcc -c` before posting; I should
have tried linking as well.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,082
Messages
2,570,589
Members
47,211
Latest member
Shamestone

Latest Threads

Top