468,490 Members | 2,553 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,490 developers. It's quick & easy.

code portability

My question is more generic, but it involves what I consider ANSI standard C
and portability.

I happen to be a system admin for multiple platforms and as such a lot of
the applications that my users request are a part of the OpenSource
community. Many if not most of those applications strongly require the
presence of the GNU compiling suite to work properly. My assumption is that
this is due to the author/s creating the applications with the GNU suite.
Many of the tools requested/required are GNU replacements for make,
configure, the loader, and lastly the C compiler itself. Where I'm going
with this is, has the OpenSource community as a whole committed itself to at
the very least encouraging its contributing members to conform to ANSI
standards of programming?

My concern is that as an admin I am sometimes compelled to port these
applications to multiple platforms running the same OS and as the user
community becomes more and more insistent on OpenSource applications will
gotcha's appear due to lack of portability in coding? I fully realize that
independent developers may or may not conform to standards, but again is it
at least encouraged?

11.32 of the FAQ seemed to at least outline the crux of what I am asking.
If I loaded up my home machine to the gills will all open source compiler
applications (gcc, imake, autoconfig, etc....) would my applications that I
compile and link and load conform?
Aug 1 '06
239 8108
Ian Collins wrote:
This year I have mentioned TDD in two threads here, both times he or she
has piled in with a personal attack. The first time on a thread that
was weeks old, no way that could be considered topicality guidance.
It gets worse when someone attacks you over a topic known to attract
negative attention. The you get a lot of empty 'me-too's.

However, I thought you knew better than to engage Frederick
Premature-Optimization Gotham. His game is forcing you to admit your code
must obey business constraints, so he can brag that he is free to play with
only one aspect of engineering, while neglecting others.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Aug 9 '06 #201
Phlip posted:
However, I thought you knew better than to engage Frederick
Premature-Optimization Gotham.

Amusing.

His game is forcing you to admit your code must obey business
constraints, so he can brag that he is free to play with only one aspect
of engineering, while neglecting others.

Such as business?

My code is fully-portable, Standard-compliant and efficient -- that's all I
need.

--

Frederick Gotham
Aug 9 '06 #202
In article <87************@mail.comRichard <rg****@gmail.comwrites:
....
And what you think has no relevance in the real world : MOST european
based languages are adjective noun order.
*Germanic* european based languages. (I do not know about the Slavic
languages.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Aug 9 '06 #203

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:C0*******************@news.indigo.ie...
Eigenvector posted:
>Man I don't know where you work, but every single programmer I manage on
my system codes by the methods outlined by the customer - NOT what they
feel is appropriate. If the customer wants his int variables to be
named using some arcane mathematical formula then so be it, if they want
the int variables to be a,b,c,d,e,f,... then so be it. The coding
standard is determined by the project and the customer, never the coder
- at least in my realm.


More of a topic for comp.lang.c.business.

I don't work as a programmer -- I have no customer and no boss.

--

Frederick Gotham
So then I question your devotion to your style and your confidence in its
effectiveness. If you have never worked in the industry nor have had to
satisfy a customer or their requirements I don't see how you can make
judgements on your style vs. what the undoubted experts here in this forum
promote.

Personally if I do something one way in a non-professional environment, but
a bunch of people take me aside and provide example after example of why my
method is not really in line with normal practices - I take their
suggestions to heart. You don't appear to be doing that to my untrained
eyes.

Do as you wish, I just don't care having said my peace. I agree to not
agree with you.
Aug 10 '06 #204
Dik T. Winter said:
In article <87************@mail.comRichard <rg****@gmail.comwrites:
...
And what you think has no relevance in the real world : MOST european
based languages are adjective noun order.

*Germanic* european based languages. (I do not know about the Slavic
languages.)
In Polish, which is of course a Slavic language, it varies (just as it does
in English proper!).

For example: in "otwartym terenie" - "open terrain" - the adjective comes
first, and this is commonplace. But "dzien otwarty" - "open day" - places
the adjective after the noun.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 10 '06 #205
Keith Thompson <ks***@mib.orgwrote:
Frederick Gotham <fg*******@SPAM.comwrites:
I wouldn't have thought people would be so puzzled by the simple ordering
of words.

I be by have ordering people puzzled simple so the thought would
wouldn't of words.
Oh, now you're just being dense for the sake of it. Get a grip, ok?

Richard
Aug 10 '06 #206
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:vy*******************@news.indigo.ie...
No, I prefer:

<type<type specifiers<const<volatile<static/extern<inline>
<name>

const and volatile *are* type specifiers, afaicr.
"name" might include pointer-ness, or function-ness, or array-ness.
Something

It also has to include any pointer-ness of the type as well as of the
function. If you return a const char * from a static function, you'd end up
writing:

char const static *func(args)

because there's no way to pull the * left of the "static". You have split
the type up, so that you have to read the whole declaration to realise the
function returns a "const char *" and not just a "const char".

I'm not saying you shouldn't do it, nor that it's poor style or any weasel
words like that. I'm just saying it confuses me, and it'll probably confuse
others too.

Why have you chosen this style? Please tell me any benefits it could offer.

--

Philip Potter

Aug 10 '06 #207
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:FH*******************@news.indigo.ie...
If they need the extra time to figure it out, then they probably can't
help
me anyway. If you're expecting someone to say:

a big, yellow, smooth, painted wall

and instead, they say:

a smooth, yellow, painted, big wall

, then will you be confused, and will it take you longer to decipher the
sentence?
False comparison. In the above case, each specifier of "wall" is of an
equivalent type - an adjective. In declarations, there are some specifiers
which describe the function, and some which describe its return value.
Mixing them together doesn't confuse the compiler, but it serves no purpose
towards making it any clearer for people.

--

Philip Potter

Aug 10 '06 #208
"Phlip" <ph******@yahoo.comwrote:
Ian Collins wrote:
This year I have mentioned TDD in two threads here, both times he or she
has piled in with a personal attack. The first time on a thread that
was weeks old, no way that could be considered topicality guidance.

It gets worse when someone attacks you over a topic known to attract
negative attention. The you get a lot of empty 'me-too's.
That's as may be, but it's still not as bad as when someone comes in to
fight his personal feuds and advocacy battles where they're completely
off-topic. So please don't.

Richard
Aug 10 '06 #209
Ian Collins <ia******@hotmail.comwrote:
Richard Bos wrote:
Last year it was Pattern Driven Development. The year before that Rapid
Development. Now Test Driven Development is apparently the buzzword of
the day. Bah. My tests test my program development; they do not drive
it. _I_ do that.

So someone else drives you tests?
No. I do that, too. The good thing about not advocating some fashionable
cure-all method is that you can use Brain Driven Development with pure
ISO C, which is the topic of this newsgroup.

Richard
Aug 10 '06 #210
"Philip Potter" <ph***********@xilinx.comwrote:
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:hy*******************@news.indigo.ie...
Consider an internal linkage, inline function which returns a const pointer
to a const int. Each of the following are easily readable to me:

inline static const int * const Func1(void) {}

static inline int const* const Func2() {}

const static int inline *const Func3(void) {}

int const inline static* const Func4() {}

Good for you if you can read it. I have no objection to Func1 or Func2,
except that Func2 is poor-style C89 (it doesn't specify arguments).

Func3 and Func4 are less readable to me.
And yet, you will encounter all of them, and worse, in the wild. You may
not like them, but you'll have to be able to work with them.

Richard
Aug 10 '06 #211
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:44***************@news.xs4all.nl...
const static int inline *const Func3(void) {}
>
int const inline static* const Func4() {}
<snip>

Func3 and Func4 are less readable to me.

And yet, you will encounter all of them, and worse, in the wild. You may
not like them, but you'll have to be able to work with them.
Yes, I agree. What's your point? Func3 and Func4 are still less readable.
Note that I didn't say *unreadable*.

--
Philip Potter

Aug 10 '06 #212
Eigenvector posted:
>More of a topic for comp.lang.c.business.

I don't work as a programmer -- I have no customer and no boss.

So then I question your devotion to your style and your confidence in
its effectiveness.

So I can't cook well if I don't work as a chef?

If you have never worked in the industry nor have
had to satisfy a customer or their requirements I don't see how you can
make judgements on your style vs. what the undoubted experts here in
this forum promote.

I cook my own food to satisfy myself.

I write my own code to satisfy myself.

Personally if I do something one way in a non-professional environment,
but a bunch of people take me aside and provide example after example of
why my method is not really in line with normal practices - I take their
suggestions to heart. You don't appear to be doing that to my untrained
eyes.

That's because I have a fully-functional brain, and don't need to be told
that:

static int Func(void) {...

is better than:

int static Func(void) {...

--

Frederick Gotham
Aug 10 '06 #213
Philip Potter posted:
It also has to include any pointer-ness of the type as well as of the
function. If you return a const char * from a static function, you'd end
up writing:

char const static *func(args)

because there's no way to pull the * left of the "static". You have
split the type up, so that you have to read the whole declaration to
realise the function returns a "const char *" and not just a "const
char".

Yes -- I consider the asterisk to be a part of the name; this is reflected
by:

int *p, q, *r;

/* p is a pointer */

/* q is an int */

/* r is a pointer */
int (*k)[5];

/* k is a pointer */

I'm not saying you shouldn't do it, nor that it's poor style or any
weasel words like that. I'm just saying it confuses me, and it'll
probably confuse others too.

Why have you chosen this style? Please tell me any benefits it could
offer.

I started it when I had to deal with very long function definitions in C++,
for example:

export template<class NumT, class StrT>
typename Assum<NumT,StrT>::CharT const
static inline
*Assum<NumT,StrT>::TextProcess(Letters<NumTconst &stls)

--

Frederick Gotham
Aug 10 '06 #214
Frederick Gotham wrote:
Eigenvector posted:
>>More of a topic for comp.lang.c.business.

I don't work as a programmer -- I have no customer and no boss.

So then I question your devotion to your style and your confidence in
its effectiveness.

So I can't cook well if I don't work as a chef?
You won't get so much feedback as to the success of your recipes
if you cook only for yourself.
>If you have never worked in the industry nor have
had to satisfy a customer or their requirements I don't see how you can
make judgements on your style vs. what the undoubted experts here in
this forum promote.

I cook my own food to satisfy myself.

I write my own code to satisfy myself.
Then why are you wasting time trying to convince people that they
should like /your/ food? If you're coding for yourself, code for
yourself - our preferences shouldn't matter to you.

You're in the position of trying to convince eaters that it's not
/logical/ for them to dislike broccoli or parmesan or deep-fried
honeybees [1].
That's because I have a fully-functional brain,
No-one has a fully functional brain; brains have mutable (and
mutated) state.

[1] Bleagh.

--
Chris "fixpoint operator" Dollin
"Who do you serve, and who do you trust?" /Crusade/

Aug 10 '06 #215
Philip Potter posted:
>If you're expecting someone to say:

a big, yellow, smooth, painted wall

and instead, they say:

a smooth, yellow, painted, big wall

, then will you be confused, and will it take you longer to decipher
the sentence?

False comparison. In the above case, each specifier of "wall" is of an
equivalent type - an adjective. In declarations, there are some
specifiers which describe the function, and some which describe its
return value. Mixing them together doesn't confuse the compiler, but it
serves no purpose towards making it any clearer for people.

These are concepts in your own mind, not in the C language.

A function is defined just like a variable, except that you have
parentheses after the name which contain a list of arguments.

Here's a few things which a variable can be:

unsigned
volatile
static

Just like my "smoot, yellow, painted, big wall", I don't care what order
they're put in:

static unsigned volatile i = 5;

Moving on to functions, we just make parentheses a part of the name:

enum { SystemMemAddress = 0xFFF776 };

int const volatile static (*Func(void))[5]
{
return (int const volatile (*)[5])SystemMemAddress;
}

int main()
{
int const volatile *const p = *Func();
}

--

Frederick Gotham
Aug 10 '06 #216
Chris Dollin posted:
>So I can't cook well if I don't work as a chef?

You won't get so much feedback as to the success of your recipes
if you cook only for yourself.

Yes, but I have my own sense of judgement.

It either tastes good or it doesn't.

It either runs fast and without crashing, or it doesn't.

>>If you have never worked in the industry nor have
had to satisfy a customer or their requirements I don't see how you can
make judgements on your style vs. what the undoubted experts here in
this forum promote.

I cook my own food to satisfy myself.

I write my own code to satisfy myself.

Then why are you wasting time trying to convince people that they
should like /your/ food? If you're coding for yourself, code for
yourself - our preferences shouldn't matter to you.

I'm not trying to convice people to start writing:

int const static *Func(void);

But rather to explain to them that it's a perfectly acceptable variant.

--

Frederick Gotham
Aug 10 '06 #217
Frederick Gotham wrote:
Chris Dollin posted:
>>So I can't cook well if I don't work as a chef?

You won't get so much feedback as to the success of your recipes
if you cook only for yourself.

Yes, but I have my own sense of judgement.

It either tastes good or it doesn't.
/To you/.
It either runs fast and without crashing, or it doesn't.
It's either maintainable or it isn't.
>>>If you have never worked in the industry nor have
had to satisfy a customer or their requirements I don't see how you can
make judgements on your style vs. what the undoubted experts here in
this forum promote.

I cook my own food to satisfy myself.

I write my own code to satisfy myself.

Then why are you wasting time trying to convince people that they
should like /your/ food? If you're coding for yourself, code for
yourself - our preferences shouldn't matter to you.

I'm not trying to convice people to start writing:

int const static *Func(void);
Just as well.
But rather to explain to them that it's a perfectly acceptable variant.
But it /isn't/. And the proof is, it's not being accepted. You keep
saying that it's perfectly acceptable, look, the grammar allows it
and you /can/ read it, see! and it's just like trying to convince me
that broccoli or liver tastes /nice/, ugh spit.

You're saying that you-all could get used to something different. We-all
are saying "what's the return on investment?". Since there isn't one,
I'm surprised you're surprised that people aren't interested in making
the effort.

"The grammar allows it" isn't enough. The grammar [including the lexis]
allows `int djh908gf( void *ewjh8455534 );` too, and `int *a, b;`,
and unrestrained use of `goto`, and redundant `auto`s and irrelevant
`register`s and pointless casts. The point about a widely-used ordering
for the formally order-irrelevant parts of a declaration means that
we don't have to /care/.

--
Chris "seeker" Dollin
Meaning precedes definition.

Aug 10 '06 #218
Chris Dollin posted:
>It either runs fast and without crashing, or it doesn't.

It's either maintainable or it isn't.

My code is maintainable. Most of it is self-explanatory, and in other places
it's commented.

But it /isn't/. And the proof is, it's not being accepted.

By whom? You?

I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.

--

Frederick Gotham
Aug 10 '06 #219
Frederick Gotham <fg*******@SPAM.comwrites:
Chris Dollin posted:
>>It either runs fast and without crashing, or it doesn't.

It's either maintainable or it isn't.


My code is maintainable. Most of it is self-explanatory, and in other places
it's commented.

>But it /isn't/. And the proof is, it's not being accepted.


By whom? You?

I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.
The is order word important fool you.

Convinced am I troll you are. Noone could be so ridiculously naive to
believe that the ordering doesnt affect people ability to read and
maintain your code.
Aug 10 '06 #220
Richard wrote:
Convinced am I troll you are. Noone could be so ridiculously naive to
believe that the ordering doesnt affect people ability to read and
maintain your code.
I am much smarter than you, so you obviously can't read my code. This is
your problem, not my codes'!

;-)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Aug 10 '06 #221
Richard wrote:
Convinced am I troll you are.

You left out the indefinite article: "a".

Noone could be so ridiculously naive to believe that the ordering doesnt
affect people ability to read and maintain your code.

Naive... or realistic? If people are taking any meaning from the word order,
then they're wrong to do so.

If I write:

int const *p;

, then does it mean that I'm lonely?

And if I write:

cont int *p;

, the does it mean that I'm excited?

--

Frederick Gotham
Aug 10 '06 #222
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Bu*******************@news.indigo.ie...
Philip Potter posted:
Yes -- I consider the asterisk to be a part of the name; this is reflected
by:

int *p, q, *r;

int (*k)[5];
I consider the asterisk to be part of the type. This is reflected by pointer
typecasts. (I admit that this view is not any more or less valid than
yours.)

I also wouldn't write

int *p, q, *r;

not because I find it difficult to read, but I'm afraid somebody else might.
(But this is very much IMHO, and you can do what you like.)
I started it when I had to deal with very long function definitions in
C++,
for example:

export template<class NumT, class StrT>
typename Assum<NumT,StrT>::CharT const
static inline
*Assum<NumT,StrT>::TextProcess(Letters<NumTconst &stls)
I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls)

What is clear to you is not necessarily clear to others. Especially when
others have been used to a particular style for a long time.

Philip

Aug 10 '06 #223
Philip Potter posted:
I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls)

Yes but things get fuzzy when I return a pointer to an array:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT (*
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls))[5]

--

Frederick Gotham
Aug 10 '06 #224
Frederick Gotham wrote:
Chris Dollin posted:
>>It either runs fast and without crashing, or it doesn't.

It's either maintainable or it isn't.

My code is maintainable.
By /you/ to /your/ standards - just like /fast/, it's a
particular taste. So long as you're feeding yourself,
that's OK.
>But it /isn't/. And the proof is, it's not being accepted.

By whom? You?
By the people in the discussion who you are failing to convince.
I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.
See? You're doing it /again/. You're saying that because the
word order doesn't matter /to the formal language processor/,
it doesn't matter. It matters to the /people/ involved.
(This is as true of English as it is of C declarations,
incidentally.) You should just realise that and acquiesce to it.

--
Chris "seeker" Dollin
"No-one here is exactly what he appears." G'kar, /Babylon 5/

Aug 10 '06 #225
On Thu, 10 Aug 2006 15:03:14 +0100, Chris Dollin <ch**********@hp.com>
wrote:
>"The grammar allows it" isn't enough. The grammar [including the lexis]
allows `int djh908gf( void *ewjh8455534 );` too, and `int *a, b;`,
and unrestrained use of `goto`, and redundant `auto`s and irrelevant
`register`s and pointless casts. The point about a widely-used ordering
for the formally order-irrelevant parts of a declaration means that
we don't have to /care/.
One point that no one has brought up is that reading code in quantity
is like reading English. One does not read one word at a time and
think about what the combination of words means. We recognize phrases
and even multi-line conventional idioms. When those conventional
phrases are scrambled, we have to go back to word at a time reading
and interpreting, at least momentarily. This not only slows the scan,
but interrupts the flow of thinking and absorbing the meaning of the
code.

In practice, over many years, conventions have appeared which make
this process possible. There are variations, but few, and they are
well known. Although I have a preferred brace style, I can switch
gears to one of the other conventional styles easily, so long as
there's consistency (the reason that maintenance programmers try to
maintain the style of the code they're changing.) OTOH, if you decided
that all opening braces should be in column 80 and all closing braces
should be indented from the previous statement, that's not one of the
conventions we're used to, and most of us would slow *way* down while
reading it, even though the compiler wouldn't mind a bit.

(Incidentally, although Frederick may be an expert cook, I suspect
he'd have some surprises in store if he took on the job of a real
chef.)

--
Al Balmer
Sun City, AZ
Aug 10 '06 #226
On Thu, 10 Aug 2006 04:57:47 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
>Dik T. Winter said:
>In article <87************@mail.comRichard <rg****@gmail.comwrites:
...
> And what you think has no relevance in the real world : MOST european
based languages are adjective noun order.

*Germanic* european based languages. (I do not know about the Slavic
languages.)

In Polish, which is of course a Slavic language, it varies (just as it does
in English proper!).

For example: in "otwartym terenie" - "open terrain" - the adjective comes
first, and this is commonplace. But "dzien otwarty" - "open day" - places
the adjective after the noun.
But, to the point, the usage is conventional and normally doesn't
change, right? In English, we allow "poetic license" but normally
conventions are followed, even if not all conventions are consistent
with each other.

--
Al Balmer
Sun City, AZ
Aug 10 '06 #227
On Thu, 10 Aug 2006 13:26:57 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:
>Yes -- I consider the asterisk to be a part of the name;
But, of course, it isn't.
>this is reflected
by:

int *p, q, *r;
Heh. You don't code for a living, but I had a long-term client who
insisted that the asterisk was part of the type and required

int* p;
int q;
int* r;

This, of course, would limit your choices of where to put other
modifiers.

I though it was silly, but it's not that unusual, and can be
considered one of the standard styles. I made my opinion known (about
this and even sillier things in their style guide), but it was
opinion, not religion, and they paid well.

--
Al Balmer
Sun City, AZ
Aug 10 '06 #228
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:kP*******************@news.indigo.ie...
Naive... or realistic? If people are taking any meaning from the word
order,
then they're wrong to do so.
It. Takes. People. Longer. To. Understand. Unfamiliar. Things.

--

Philip Potter

Aug 10 '06 #229
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Ch*******************@news.indigo.ie...
Philip Potter posted:
I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls)

Yes but things get fuzzy when I return a pointer to an array:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT (*
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls))[5]
And again, your style doesn't make it any clearer.

--

Philip

Aug 10 '06 #230
Philip Potter posted:
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Ch*******************@news.indigo.ie...
>Philip Potter posted:
I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls)

Yes but things get fuzzy when I return a pointer to an array:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT (*
Assum<NumT,StrT>::TextProcess(const Letters<NumT&stls))[5]

And again, your style doesn't make it any clearer.
I would write it as:

export template<class NumT,class StrT>
typename Assum<NumT,StrT>::CharT const
static inline
(*Assum<NumT,StrT>::TextProcess(Letters<NumTconst &stls))[5]
And I do find it clearer. Anyhow, I think this conversations has gone on
long enough.

--

Frederick Gotham
Aug 10 '06 #231
Al Balmer said:
On Thu, 10 Aug 2006 04:57:47 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
>>Dik T. Winter said:
>>In article <87************@mail.comRichard <rg****@gmail.comwrites:
...
And what you think has no relevance in the real world : MOST european
based languages are adjective noun order.

*Germanic* european based languages. (I do not know about the Slavic
languages.)

In Polish, which is of course a Slavic language, it varies (just as it
does in English proper!).

For example: in "otwartym terenie" - "open terrain" - the adjective comes
first, and this is commonplace. But "dzien otwarty" - "open day" - places
the adjective after the noun.

But, to the point, the usage is conventional and normally doesn't
change, right?
Um, quite so. Polish is astonishingly regular for a natural language. And
whilst there may be exceptions to this rule that I don't know about, it
appears to have 100% regular spelling, too. For example, two of my Polish
friends rejoice in the name "Joanna", and each pronounces /both/ of the 'n'
letters - "Yo-a-nuh-na".
In English, we allow "poetic license" but normally
conventions are followed, even if not all conventions are consistent
with each other.
Yes. When a good writer breaks those conventions, he or she does so for a
good reason. For example, there's a book by Joseph Conrad that starts
something like this:

"And the wind blew. And the sea roared."

He doesn't mess around with merely starting a sentence with a conjunction -
he starts the entire /book/ with a conjunction! The effect, however, is
startling, and deliberately so.

I think there's a C newsgroup around here somewhere. Does anyone know where
it's got to?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 10 '06 #232
Frederick Gotham <fg*******@SPAM.comwrites:
Philip Potter posted:
>>If you're expecting someone to say:

a big, yellow, smooth, painted wall

and instead, they say:

a smooth, yellow, painted, big wall

, then will you be confused, and will it take you longer to decipher
the sentence?

False comparison. In the above case, each specifier of "wall" is of an
equivalent type - an adjective. In declarations, there are some
specifiers which describe the function, and some which describe its
return value. Mixing them together doesn't confuse the compiler, but it
serves no purpose towards making it any clearer for people.

These are concepts in your own mind, not in the C language.
They're also concepts in the minds of most C programmers, based on the
way most C code is actually written. The same is true of indentation.
The compiler doesn't care how or whether you indent your code, but
anyone reading it does.
A function is defined just like a variable, except that you have
parentheses after the name which contain a list of arguments.

Here's a few things which a variable can be:

unsigned
volatile
static

Just like my "smoot, yellow, painted, big wall", I don't care what order
they're put in:
If you don't care, why not just do it the way everyone else does it?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Aug 10 '06 #233
Frederick Gotham <fg*******@SPAM.comwrites:
Chris Dollin posted:
>>It either runs fast and without crashing, or it doesn't.

It's either maintainable or it isn't.

My code is maintainable. Most of it is self-explanatory, and in other places
it's commented.
>But it /isn't/. And the proof is, it's not being accepted.

By whom? You?
By anybody in this discussion other than you. Or hadn't you noticed?
I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.
Word order, in some cases, doesn't matter to the compiler. This has
been acknowledged *repeatedly* in this thread.

Arbitrary variations in word order, even if they don't matter to the
compiler, can make code more difficult to read for most people. Al
Balmer posted an excellent analysis of this phenomenon:

| One point that no one has brought up is that reading code in quantity
| is like reading English. One does not read one word at a time and
| think about what the combination of words means. We recognize phrases
| and even multi-line conventional idioms. When those conventional
| phrases are scrambled, we have to go back to word at a time reading
| and interpreting, at least momentarily. This not only slows the scan,
| but interrupts the flow of thinking and absorbing the meaning of the
| code.

It is your stubborn refusal to acknowledge this point that has made
this thread as long as it is.

If you want to use some unconventional style in your own code, code
that you never share with anyone else, nobody is going to complain.
If you insist on sharing your ideas with others, as you're doing here,
people are going to explain to you why it's a bad idea, as you've seen
here.

Nobody is going to acquiesce to your style. You should acquiesce to
that.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Aug 10 '06 #234

Richard wrote:
en******@yahoo.com writes:
Ian Collins wrote:
>
It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.
Kindly take your TDD proselytizing to a newsgroup where
it's topical.

Its called a developing thread.
The point is that threads not related to standard C
should develop somewhere else.

Aug 10 '06 #235

Philip Potter wrote:
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:vy*******************@news.indigo.ie...
No, I prefer:

<type<type specifiers<const<volatile<static/extern<inline>
<name>

const and volatile *are* type specifiers, afaicr.
Type qualifiers.

Aug 10 '06 #236

Frederick Gotham wrote:
>
I'm not trying to convice people to start writing:

int const static *Func(void);

But rather to explain to them that it's a perfectly acceptable variant.
It is perfectly acceptable to you. For
lots of other people, it isn't. Do you
get it now?

Aug 10 '06 #237
Keith Thompson <ks***@mib.orgwrote:
Frederick Gotham <fg*******@SPAM.comwrites:
Chris Dollin posted:
>It either runs fast and without crashing, or it doesn't.

It's either maintainable or it isn't.
My code is maintainable. Most of it is self-explanatory, and in other places
it's commented.
But it /isn't/. And the proof is, it's not being accepted.
By whom? You?

By anybody in this discussion other than you. Or hadn't you noticed?
Dunno about you, but I'd not noticed that, no.

Richard
Aug 11 '06 #238
"Philip Potter" <ph***********@xilinx.comwrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:44***************@news.xs4all.nl...
const static int inline *const Func3(void) {}

int const inline static* const Func4() {}
<snip>
>
Func3 and Func4 are less readable to me.
And yet, you will encounter all of them, and worse, in the wild. You may
not like them, but you'll have to be able to work with them.

Yes, I agree. What's your point? Func3 and Func4 are still less readable.
Wrong. You had it right last time: they're less readable _to you_. To
someone else, who wrote those lines, they're presumably more readable.

And my point? My point was that you're going to encounter a whole lot
worse than Frederick's unusual, but at least consistent style, so if you
get fazed by that kind of word order, you need more experience.

Richard
Aug 11 '06 #239
Keith Thompson <ks***@mib.orgwrote:
Frederick Gotham <fg*******@SPAM.comwrites:
Here's a few things which a variable can be:

unsigned
volatile
static

Just like my "smoot, yellow, painted, big wall", I don't care what order
they're put in:

If you don't care, why not just do it the way everyone else does it?
Who is this mythical "everyone" you keep harping on about? The
"everyone" who always uses the same style as "everyone" else? The one,
golden, omnipotent, omnipresent, sacrosanct C style?

If you read code that does not come from your own shop, you _are_ going
to encounter different styles of coding. Many of them are a lot less
consistent than Frederick's. And contrary to the assertions made in this
thread, it is not unfamiliarity which makes code hard to read - not for
longer than five minutes - it is inconsistency. I can easily read any
reasonably laid-out code, even if it's different from mine. The problems
start when a coder starts mixing styles at random.

Richard
Aug 11 '06 #240

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.