Microsoft abandons the C language

[Vincenzo Mercuri]

Il 28/08/2012 23:37, Keith Thompson ha scritto:

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.)

Yes indeed, thank you.

 

[Ian Collins]

It's not C++. It is perfectly valid C.

Keith,

Your troll filter is due for a recalibration

 

[ais523]

rashid ha scritto:

#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.

looks like legitimate INTERCAL to me.

It isn't. Admittedly, INTERCAL compilers never reject any program ever
nowadays, and this one doesn't even produce diagnostics, but you get an
instant (and expected) syntax error upon running it, which is about
not-INTERCAL as you can get.

 

[Jens Gustedt]

Am 28.08.2012 21:39, schrieb Vincenzo Mercuri:

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 does. The point that Keith seems to have missed is that an "inline"
definition in C always needs a sort of "instantiation" in just one
compilation unit. Adding this one should do the trick:

void foo(uint32_t *restrict p);

Jens

 

[Vincenzo Mercuri]

Il 29/08/2012 00:15, Jens Gustedt ha scritto:

Am 28.08.2012 21:39, schrieb Vincenzo Mercuri:

It does. The point that Keith seems to have missed is that an "inline"
definition in C always needs a sort of "instantiation" in just one
compilation unit. Adding this one should do the trick:

void foo(uint32_t *restrict p);

Yes, that works because it specifies external linkage for `foo()'.
I think that "static inline" was what he meant to write originally.
Thank you Jens.

 

[Keith Thompson]

Keith,

Your troll filter is due for a recalibration

Quite possibly. I like to give the benefit of the doubt initially;
occasionally it even works out.

 

[Keith Thompson]

Yes, that works because it specifies external linkage for `foo()'.
I think that "static inline" was what he meant to write originally.
Thank you Jens.

It's not what I meant to write, but it's certainly what I should
have meant to write. I'm not as familiar with how C handles inline
functions as I should be.

 

[Vincenzo Mercuri]

Il 29/08/2012 02:15, Keith Thompson ha scritto:

It's not what I meant to write, but it's certainly what I should
have meant to write. I'm not as familiar with how C handles inline
functions as I should be.

I see. Well, I bet the most of us are not so familiar with how C
handles inline functions. In such situations, one of the first things
that comes to mind is: "buggy compiler". This discussion was very
interesting to me, I learnt something new. So, I must thank you

 

[Nick Keighley]

On Mon, 27 Aug 2012 15:03:17 -0700, Keith Thompson wrote:




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++..

1. how do you know? Do Microsoft or Skype give you access to their
source code?
2. there is no such langauge as C/C++ so they can't be coded in it. Do
you mean "largely coded in C and C++"?

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

seems like plain english to me...

<snip>

 

[Nick Keighley]

Le 28/08/12 00:35, Keith Thompson a écrit :



Interesting Mr Thompson.

I remember that I cited the same paragraph in this same group some
years ago, and I was flamed by Mr Heathfield and the other regulars
that maintained that "standard c" means C90 (As microsoft does now).

Well, better late than never!

P.S.
Specifically here is a message that I wrote around November 28, 2009,
and your answer below:

 >
 > >       »This second edition cancels and replaces the first
 > >       edition, ISO/IEC 9899:1990, as amended and corrected by
 > >       ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
 > >       ISO/IEC 9899/COR2:1996.«
 >
 > >     ISO/IEC 9899:1999 (E)
 >
 > >   This means that C is the language specified by ISO/IEC
 > >   9899:1999 (E). »ISO/IEC 9899:1990« is canceled.
 >
 > In theory, yes.  In practice, conforming C90 compilers are still
 > much more common than conforming C99 compilers.  Many compilers
 > implement large parts of C99, but others, still in common use,
 > implement almost none of it (more precisely, almost none of the
 > differences between C90 and C99).

I see no flame. Which part of that is factually wrong?

 

[Nick Keighley]

Keith Thompson wrote:

Take the slash as meaning "or". It's a quick way of addressing users of C
and C++ recognizing that you can do whatever in either language,

well no they are very different languages

but that
the language isn't really that important to the overall thought.

....and hence thuis is not so

E.g., "Well if you don't want to use C#, you can use C/C++".

or Java or Fortran or...

Also, using just the C
subset of C++ is akin to writing something in C.

quite. It doesn't look anything like idiomatic C++

It's hard to be enthusiastic about boring old C though. Yeah, it may be the
simplest way to deliver a library of simple functions, but so what? Why
bother worrying about the lonely C standard when C++ is almost a supersetof
it and you're using a C++ compiler anyway?

C++'s name mangling makes linking to other languages difficult. C++'s
exceptions probably make life difficult as well.

Providing a C interface makes your library highly portable.

I think of C as a kind of least common denominator.

which is its strength

While I shun
"sophisticated" C++ libraries (BOOST comes to mind), I welcome *select* C
code. *Very* simple C++ classes and such are acceptable to me too.

does the STL qualify? I begin to wonder if you can actually program in
C++.

C++ code
(even much of C code) from projects, I consider to be pretty much "write
once, can't reuse" code.

sounds poorly written

IOW, mostly C++ ends up being great for abstracting
within a project, but too big of a pill to reuse in another project.

considering C++ was supposed to be good at this...

Library
development is much harder than application program development

cf. Brooks

 

[Jens Gustedt]

Am 29.08.2012 10:01, schrieb David Brown:

Usually when you have an "inline" function, you do not want external
linkage. As with all functions that you don't explicitly want exported
from the compile unit, you should add "static". It is very rare to see
an "inline" function that should not have been declared "static inline".

Hm, I use inline functions a lot and my mileage seems to be completely
different from yours.

I have small to medium sized functions in headers as inline, and I
don't want them to be repeated in every compilation unit, so I don't
have them static.

I use the "instantiation" syntax of C99 to force the generation of the
symbol in exactly one .c file. So I am always sure that everything
will link well together, e.g when I compile without optimization for
debugging (and the compiler doesn't inline) or when I occasionally
take a pointer to the function.

AFAKS this model is the reason that the "inline" feature was included
in C. For everything else we could have stayed with "static". To me,
"static inline" makes not much sense since it doesn't bring in
anything new.

Jens

 

[James Kuyper]

On 08/29/2012 04:01 AM, David Brown wrote:
....

Usually when you have an "inline" function, you do not want external
linkage. As with all functions that you don't explicitly want exported
from the compile unit, you should add "static". It is very rare to see
an "inline" function that should not have been declared "static inline".

When an inline function has external linkage, the compiler has the
freedom to choose whether to use the internal definition or the external
one. Presumably, the compiler will either a) keep things simple by
always making the same choice or b) try to make a context-dependent
decision about which definition it would be best to use. Assuming you
trust the compiler to make good decisions about such things, giving it
that choice should produce code that is no worse than it would have been
had the choice not been available, and possibly better.

I seldom bother inlining functions, but on the rare occasions when I
have done so, it I've gone the external inline route, for that reason.

 

[James Kuyper]

....
C++'s name mangling makes linking to other languages difficult. C++'s
exceptions probably make life difficult as well.

Providing a C interface makes your library highly portable.

Keep in mind that a C++ library can provide a C interface, without using
actual C code, just by declaring the interface functions extern "C".
Those interface functions can use any C++-specific feature that doesn't
involve the function signature.

 

[Les Cargill]

Am 29.08.2012 10:01, schrieb David Brown:

[...]
Yes, that works because it specifies external linkage for `foo()'.
I think that "static inline" was what he meant to write originally.
Thank you Jens.

It's not what I meant to write, but it's certainly what I should
have meant to write. I'm not as familiar with how C handles inline
functions as I should be.

Usually when you have an "inline" function, you do not want external
linkage. As with all functions that you don't explicitly want exported
from the compile unit, you should add "static". It is very rare to see
an "inline" function that should not have been declared "static inline".

Hm, I use inline functions a lot and my mileage seems to be completely
different from yours.

I have small to medium sized functions in headers as inline, and I
don't want them to be repeated in every compilation unit, so I don't
have them static.

The inline directive specifically asks that the thing be repeated for
every ... call to them. That's more or less the definition of it -
"treat this as if is were a '#define...' macro using different syntax."

That's not *exactly* right, but it's a good first approximation.

I use the "instantiation" syntax of C99 to force the generation of the
symbol in exactly one .c file. So I am always sure that everything
will link well together, e.g when I compile without optimization for
debugging (and the compiler doesn't inline) or when I occasionally
take a pointer to the function.

AFAKS this model is the reason that the "inline" feature was included
in C. For everything else we could have stayed with "static". To me,
"static inline" makes not much sense since it doesn't bring in
anything new.

I see that the opposite way - the instantiation(s) and visibility of an
identifier are mostly disjoint properties.

 

[Stephen Sprunk]

Am 29.08.2012 10:01, schrieb David Brown:

Hm, I use inline functions a lot and my mileage seems to be completely
different from yours.

I have small to medium sized functions in headers as inline, and I
don't want them to be repeated in every compilation unit, so I don't
have them static.

I think you (or perhaps your compiler) have this backwards.

"extern inline" (or just "inline", since "extern" is default for
functions) will create a function body with external linkage _and_ tell
the compiler to inline calls. So, if you use this in a header file that
is included in ten different source files, you will end up with TEN
function bodies with external linkage.

"static inline" will NOT create a function body with external linkage,
but it still tells the compiler to inline calls. So, if you use this in
a header file that is included in ten different source files, you will
end up with ZERO function bodies with external linkage.

I use the "instantiation" syntax of C99 to force the generation of the
symbol in exactly one .c file. So I am always sure that everything
will link well together, e.g when I compile without optimization for
debugging (and the compiler doesn't inline) or when I occasionally
take a pointer to the function.

AIUI, explicit inline directives are not an "optimization"; if your
compiler ignores them, it is not conforming.

It is only an "optimization" for the compiler to inline calls (and
possibly remove function bodies) when there are NOT any "inline" directives.

AFAKS this model is the reason that the "inline" feature was included
in C. For everything else we could have stayed with "static". To me,
"static inline" makes not much sense since it doesn't bring in
anything new.

"static" suppresses the generation of (potentially redundant) function
bodies that will never be called.

If your compiler ignores valid "inline" directives, then it becomes
necessary for ONE of the function definitions to be "extern", so that a
function body is generated, but the rest should be "static".

S

 

[Vincenzo Mercuri]

Il 29/08/2012 15:21, Stephen Sprunk ha scritto:
[..]

"extern inline" (or just "inline", since "extern" is default for
functions)

[..]

This is not correct, in C99-C11 at least. Just "inline" won't specify
external linkage. That's why gcc or clang will fail when linking.
You need to create an "alternative external definition" for that function,
this way:

inline void foo(uint32_t *restrict p){}
extern void foo(uint32_t *restrict p);

or directly define it as:

extern inline void foo(uint32_t *restrict p){}

 

[Vincenzo Mercuri]

Il 29/08/2012 15:37, Vincenzo Mercuri ha scritto:

Il 29/08/2012 15:21, Stephen Sprunk ha scritto:
[..]

"extern inline" (or just "inline", since "extern" is default for
functions)

[..]

This is not correct, in C99-C11 at least. Just "inline" won't specify
external linkage. [..]

Sorry, I said it wrong. "inline" alone does specify external linkage,
but it does not provide an external definition, so "extern inline" and
"inline" are not equivalent. If you reference an "inline function" with
external linkage you also must provide an external definition, in the
same or another translation unit.

 

[Jens Gustedt]

Am 29.08.2012 14:57, schrieb Les Cargill:

Am 29.08.2012 10:01, schrieb David Brown:

On 29/08/2012 02:15, Keith Thompson wrote:
[...]
Yes, that works because it specifies external linkage for `foo()'.
I think that "static inline" was what he meant to write originally.
Thank you Jens.

It's not what I meant to write, but it's certainly what I should
have meant to write. I'm not as familiar with how C handles inline
functions as I should be.


Usually when you have an "inline" function, you do not want external
linkage. As with all functions that you don't explicitly want exported
from the compile unit, you should add "static". It is very rare to see
an "inline" function that should not have been declared "static inline".

Hm, I use inline functions a lot and my mileage seems to be completely
different from yours.

I have small to medium sized functions in headers as inline, and I
don't want them to be repeated in every compilation unit, so I don't
have them static.

The inline directive specifically asks that the thing be repeated for
every ... call to them. That's more or less the definition of it -
"treat this as if is were a '#define...' macro using different syntax."

That's not *exactly* right, but it's a good first approximation.

No that is not how C99 and C11 see it. C11 says for the intention behind
inline:

Making a function an inline function suggests that calls to the
function be as fast as possible. The extent to which such
suggestions are effective is implementation-defined.

I makes not much suggestions of how this goal should be achieved,
either.

I see that the opposite way -

it is not completely clear to me what you mean by oposite, here

the instantiation(s) and visibility of an identifier are mostly
disjoint properties.

sure, but what is the connection?

Fact is that the inline keyword added to a static function doesn't
force anything and doesn't change the observable behavior of the
program.

Replacing static by inline changes the observable behavior.

Adding inline to the definition of an extern function that is placed
in a header file can change a non-conforming program into a conforming
one.

Jens

 

[Jens Gustedt]

Am 29.08.2012 15:21, schrieb Stephen Sprunk:

I think you (or perhaps your compiler) have this backwards.

no, at least if you assume that gcc or clang have it backwards

"extern inline" (or just "inline", since "extern" is default for
functions) will create a function body with external linkage _and_ tell
the compiler to inline calls. So, if you use this in a header file that
is included in ten different source files, you will end up with TEN
function bodies with external linkage.

what would then be the purpose of inline? To make no difference at all?

"static inline" will NOT create a function body with external
linkage,

nobody said that

but it still tells the compiler to inline calls.

as a hint, C11:

Making a function an inline function suggests that calls to the
function be as fast as possible. The extent to which such
suggestions are effective is implementation-defined.

So, if you use this in
a header file that is included in ten different source files, you will
end up with ZERO function bodies with external linkage.

If it doesn't do that, you will end up with plenty copies of your
function, one for every unit. Not with external linkage, correct, but
again, nobody said that.

AIUI, explicit inline directives are not an "optimization"; if your
compiler ignores them, it is not conforming.

It is only an "optimization" for the compiler to inline calls (and
possibly remove function bodies) when there are NOT any "inline" directives.


"static" suppresses the generation of (potentially redundant) function
bodies that will never be called.

right, but doesn't supress the generation of redundant function bodies
that *get* called.

Jens