#define

[G G]

#define _PROTOTYPE(function, params) function params


how does this work?

[Alf P. Steinbach]

On 04.07.2019 06:21, G G wrote:
> #define _PROTOTYPE(function, params) function params
>
>
> how does this work?

It defines a pure text substitution rule, called a macro.

`params` is intended to be a parenthesized list of arguments.

Note that names starting with underscore followed by uppercase are
reserved to the implementation, so if this is not code from the C++
implementation it's UB.


Cheers!,

- Alf

[Öö Tiib]

On Thursday, 4 July 2019 07:21:17 UTC+3, G G wrote:
> #define _PROTOTYPE(function, params) function params
>
>
> how does this work?

Studying C++ by asking meaning of each individual keyword
or preprocessor directive (perhaps found in some system
library implementation file) will be quite long and difficult
way.

Better find some good textbook or tutorial about the language.
About preprocessor look at that for example:
http://www.cplusplus.com/doc/tutorial/preprocessor/

[G G]

ok
but there is a preprocessor section in both the books i'm reading
and that looked odd

and both books say that the directives are really not the c++ way
templates are a better thought for c++, so they say. but they continue
on to say one should learn about those directives because one
may see them in c programs.

this particular one just looks odd to me.

#define _PROTOTYPE(function, params) function params

when it sees _PROTOTYPE(function, params) it replaces it with the
words function params, i can't imagine that compiling

[Keith Thompson]

Given the name, my guess is that this is one of two alternative
definitions, used so that you can write code that will compile either
with a compiler that supports prototype, or with one that won't. If so,
it's useless for C++, which has (practically) *always* supported
prototypes. I've seen such macro definitions in code that needs to be
compiled with pre-ANSI (pre-1989) C compilers.

If you're trying to learn how to use the preprocessor in C++, you're
probably using a very poor example. And by not showing any context,
you've made it difficult for us to say much about it without guessing.

Where did you see this macro?

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[G G]

>
> Where did you see this macro?
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>

http://www.minix3.org/documentation/AppendixB.pdf

line 00034

[Öö Tiib]

Can you notice that it is Minix 3 implemented in C programming
language. C is (somewhat compatible but) different programming
language than C++. C is great programming language but knowledge
of it is not required (and can sometimes be detrimental) for
studying C++.

Learning C++ by studying C source code is therefore wrong. Even
when the techniques that you learn happen to work in both languages
(and the set of such techniques diminishes over time) these are
often not considered optimal for C++ and so can be reasonably
frowned upon by experienced C++ programmers.

Also taking something as complex as (even most trivial) operating
system is way over head task for most beginners. Minix 3 is Unix
clone and so no way among most trivial of operating systems.

[G G]

On Friday, July 5, 2019 at 7:10:24 PM UTC-4, Öö Tiib wrote:
> On Saturday, 6 July 2019 01:40:40 UTC+3, G G wrote:
> > >
> > > Where did you see this macro?
> > >
> > > --
> > > Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
> >
> >
> > http://www.minix3.org/documentation/AppendixB.pdf
> >
> > line 00034
>
> Can you notice that it is Minix 3 implemented in C programming
> language.

yes

[G G]

i stop at line 34. preprocessor macros

are you say those preprocessor statement would not work in C++?

[Keith Thompson]

G G <gdo...@gmail.com> writes:
>>
>> Where did you see this macro?
>

> http://www.minix3.org/documentation/AppendixB.pdf
>
> line 00034

That's C, not C++. And it's *old* C, designed to work with pre-ANSI C
compilers. It might or might not even compile as C++.

The macro is defined as:

#define _PROTOTYPE(function, params) function params

for ANSI C mode, and as:
#define _PROTOTYPE(function, params) function()
for pre-ANSI mode.

So if I have a function named "foo" that takes two int arguments and
returns an int result, I might write:
int _PROTOTYPE(foo, (int x, int y))
In ANSI C mode, that would expand to:
int foo(int x, int y)
and in pre-ANSI mode it would expand to
int foo()

It's useless for modern C, or for C++. You'd just write the
prototype directly and not worry about obsolete C compilers.

Yes, it would work for C++ -- but only if the tests that determine
the value of _ANSI were updated. They're not even correct for C99
or C11, much less for C++. (C99 defines __STDC__ as 199901L, not 1).

If you're trying to learn C, then (a) this is the C++ newsgroup,
and (b) this is not a good place to start. If you're trying to
learn C++, then this *definitely* is not a good place to start.
It's a demonstration of what C programmers had to deal with in the
old days before the standard. Standards were written precisely so
programmers would no longer have to do this kind of thing.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>

[Öö Tiib]

No. I trust that C99 and C++11 preprocessors are quite fully
compatible. I was saying that most macro usages valid in C will
be rightfully frowned upon by experienced C++ programmers. Don't
snip next time without reading. If you can't read, study that art
first.

[James Kuyper]

On Friday, July 5, 2019 at 7:23:03 PM UTC-4, G G wrote:
> On Friday, July 5, 2019 at 7:20:02 PM UTC-4, G G wrote:
> > On Friday, July 5, 2019 at 7:10:24 PM UTC-4, Öö Tiib wrote:

...

> > > > http://www.minix3.org/documentation/AppendixB.pdf
> > > >
> > > > line 00034
> > >
> > > Can you notice that it is Minix 3 implemented in C programming
> > > language.
> >
> > yes
>
> i stop at line 34. preprocessor macros
>
> are you say those preprocessor statement would not work in C++?

The #define itself works the same way in both languages. However, which
definition is given to that macro depends upon whether __STDC__ is
#defined, and also upon how it is defined. The double underscores at
the beginning mean that__STDC__ is a reserved identifier for C++, but
the C++ standard specifies nothing about what value it has. So yes, the
wrong definition for that prototype might be chosen.

More directly to the point, those preprocessor directives (the two
#defines for PROTOTYPE, as well at the #if, #else, and #endif that
determine which #define to execute), solve a problem that has never
existed in C++: backwards compatibility with pre-standard C compilers.
If you're making any significant use of any feature that is specific to
C++, compatibility with pre-standard C compilers is simply an
impossibility. Even in C code, the ability to compile with pre-standard
compilers ceased being a significant issue for most developers a long
time ago - the first C standard is 30 years old - older than many
(most?) of the people writing C code.

[Kenny McCormack]

In article <f9a9ebfd-3e26-4756...@googlegroups.com>,
James Kuyper <james...@alumni.caltech.edu> wrote:
...

>impossibility. Even in C code, the ability to compile with pre-standard
>compilers ceased being a significant issue for most developers a long
>time ago - the first C standard is 30 years old - older than many
>(most?) of the people writing C code.

I seriously doubt that. Aren't more C programmers old farts like us?

(By "us", I mean people who post to comp.lang.c)

Most recruiters these days consider C++ "legacy". C is essentially in the
same category as Cobol.

--
"Everything Roy (aka, AU8YOG) touches turns to crap."
--citizens of alt.obituaries--

[Szyk Cech]

W dniu 06.07.2019 o 17:05, Kenny McCormack pisze:

> Most recruiters these days consider C++ "legacy". C is essentially in the
> same category as Cobol.

Nope! Operating systems are wirten in pure C.
C++ exists from window manager level (like KDE) in every serious
programs upt to the games.

True wise programmers write only in C or C++ - this is clear to me when
we talk about Java, C# and Python creators - I can bet they write at
least 90% of they code in C/C++. These temptators think that other
people are far more stupid than them. They are mecenaries of black force
(what ever it is). Wise man should distinct them from tech visioners.

[Melzzzzz]

On 2019-07-06, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <f9a9ebfd-3e26-4756...@googlegroups.com>,
> James Kuyper <james...@alumni.caltech.edu> wrote:
> ...
>>impossibility. Even in C code, the ability to compile with pre-standard
>>compilers ceased being a significant issue for most developers a long
>>time ago - the first C standard is 30 years old - older than many
>>(most?) of the people writing C code.
>
> I seriously doubt that. Aren't more C programmers old farts like us?
>
> (By "us", I mean people who post to comp.lang.c)
>
> Most recruiters these days consider C++ "legacy". C is essentially in the
> same category as Cobol.

Not even close. C is for libraries, scripts are to call those libraries.
>


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Martijn van Buul]

* James Kuyper:

> Even in C code, the ability to compile with pre-standard compilers ceased
> being a significant issue for most developers a long time ago - the first C
> standard is 30 years old - older than many (most?) of the people writing C
> code.

Minix would be the counter argument there: There is a lot of legacy code
in Minix. While Minix 3 isn't a spring chicken anymore, there is a lot
of legacy from Minix 2 around, which harks from a time when this was
very much an issue. I've dabbled with Minix quite a bit in my youth (fond
memories there), and there was a generous portion of K&R C floating around in
there.

Not that I would advocate Minix to be the golden standard for C coding,
nor do I think that it's particularly on-topic here. While the "Operating
System, Design and Implementation" books are still somewhat relevant, they
were never intended as a textbook on *programming*.

--
Martijn van Buul - pi...@dohd.org

[James Kuyper]

Cases like that one are why I qualified my statement with the words
"significant" and "most".

[Richard]

[Please do not mail me a copy of your followup]

G G <gdo...@gmail.com> spake the secret code
<4f9d8f15-cbe5-4208...@googlegroups.com> thusly:

>#define _PROTOTYPE(function, params) function params
>
>how does this work?

Lamely. :-)

Seriously, this looks like someone is using a macro to avoid the
syntax of the language. Just use the ordinary syntax.

I suppose they might have done this because they had scripts parsing a
file and wanted to make it easier for a script to extra meta
information from the declarations.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

gaz...@shell.xmission.com (Kenny McCormack) spake the secret code
<qfqdb8$fpt$2...@news.xmission.com> thusly:

>In article <f9a9ebfd-3e26-4756...@googlegroups.com>,
>James Kuyper <james...@alumni.caltech.edu> wrote:
>...
>>impossibility. Even in C code, the ability to compile with pre-standard
>>compilers ceased being a significant issue for most developers a long
>>time ago - the first C standard is 30 years old - older than many
>>(most?) of the people writing C code.
>
>I seriously doubt that. Aren't more C programmers old farts like us?

It depends on the application market segment. While it was routine to
write everything in C/C++ from the 80s and into the 90s, other
languages have arrived on the scene that have found their niche. Java
is dominant in enterprise level applications (with exceptions such as
financial trading) where people hate MS, C# is dominant in MS
enterprise applications or for Windows desktop applications (with
exceptions such as 3D and gaming), Ruby and Python are popular in Web
CRUD applications, etc.

>Most recruiters these days consider C++ "legacy". C is essentially in the
>same category as Cobol.

Most recruiters don't know their ass from a hole in the ground. C/C++
is dominant in the embedded space and not much manages to displace it
except for CPU specific assembly language and even there, most people
only use assembly for small sections of the overall system.

[James Kuyper]

On 7/10/19 12:46 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> G G <gdo...@gmail.com> spake the secret code
> <4f9d8f15-cbe5-4208...@googlegroups.com> thusly:
>
>> #define _PROTOTYPE(function, params) function params
>>
>> how does this work?
>
> Lamely. :-)
>
> Seriously, this looks like someone is using a macro to avoid the
> syntax of the language. Just use the ordinary syntax.

They're not using that macro to avoid the syntax of the language,
they're using it to deal with the changing syntax of the language. Just
using the "ordinary syntax" was not an option - these macros were
intended to be useful even with compilers that didn't recognize that
syntax. The relevant lines are:

#ifdef _ANSI
/* Keep everything for ANSI prototypes. */

#define _PROTOTYPE(function, params)
function params

...
#else
/* Throw away the parameters for K&R prototypes. */
#define _PROTOTYPE(function, params) function()
...
#endif

When _ANSI is #defined, _PROTOTYPE(function, params) produces a modern
prototyped declaration for the function. When _ANSI isn't #defined, it
produces a K&R style function declaration. My ellipses cover other
macros intended to simplify writing code that would work with with
either C89 or K&R C compilers.

Such macros were quite popular during the first decade or so after the
C89 was approved.

[Vir Campestris]

We're mostly C++, with a smattering of C, especially in 3rd party
libraries. And while I may be an old fart there are several
20-somethings full time, plus a couple of interns for the summer from
the local uni.

Andy

[Ian Collins]

Same (in all aspects!) here. C and C++ are very much alive in the
embedded space. We have 60+ on our C++ team and down the road there's
another company with a similar sized C team.

--
Ian.

[Queequeg]

Ian Collins <ian-...@hotmail.com> wrote:

> Same (in all aspects!) here. C and C++ are very much alive in the
> embedded space.

True. Fortunately, because I always wanted to work in embedded field...
and that's what I'm doing.

But, unfortunately, we still, in 2019, have to use C++03 (because of
platform, SDK and infrastructure limitations). Working full time I
have no means to really learn and practice modern C++ (even C++11).

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

[Real Troll]

On 06/07/2019 17:03, Szyk Cech wrote:
> W dniu 06.07.2019 o 17:05, Kenny McCormack pisze:
>> Most recruiters these days consider C++ "legacy". C is essentially
>> in the
>> same category as Cobol.
>
> Nope! Operating systems are wirten in pure C.
>

Used to be the case but these days Microsoft is re-writing its Windows 10
code in C#. There are somethings they need to write in C/C++ but c# is
taking hold on UI stuff.