code portability

[Eigenvector]

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?

[jmcgill]

en******@yahoo.com wrote:

Having said that, the reigning culture in comp.lang.c
is to remind contributors about what's considered
topical, and especially what isn't.

I find that extremely annoying in this case.

You might want
to read for a while before deciding

I've been part of this forum since at least 1992.
I think I have it figured out by now.

[Ian Collins]

en******@yahoo.com wrote:

Having said that, the reigning culture in comp.lang.c
is to remind contributors about what's considered
topical, and especially what isn't.

I don't see you jumping on anyone who advocates the development strategy
of using a debugger to work out why something doesn't work. If I were
to dare to suggest they write some tests, I'm sure you'd pile in and
accuse me of proselytising.

Topicality is in the eye of the beholder.

--
Ian Collins.

[Frederick Gotham]

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

[Frederick Gotham]

Ian Collins posted:

Unfortunately that's the real world we professional programmers inhabit,
although I've never had to, or in recent years required my staff to
"dumb down" programming. I'm not sure from where or on what basis you
make that observation.

Over on comp.lang.c++, many regular participants condemned the following
code, saying it was cryptic:

for(size_t i = len - 1; i != -1; --i)

I understand it perfectly, and don't want to be dragged down with those who
fail to understand.

--

Frederick Gotham

[Frederick Gotham]

Keith Thompson posted:

What I don't understand is how this quest leads you to declare things
backwards, using "int unsigned" rather than the far more common
"unsigned int". (Note that even in English grammar, "unsigned int"
makes more sense; "unsigned" is an adjective, and "int" is a noun --
not that that's a decisive argument.)

English is quite strange in that regard. I think most languages put their
words in order of descending importance. Irish for example:

window = fuinneog

small = beag

small window = fuinneog bheag

I think it makes sense to receive information in order of descending
importance. I like to know the type first and foremost, which is why I
prefer:

int const i = 5;

over:

const int i = 5;

It doesn't make much of a difference with small, simple, definitions, but
it certainly does work nice with long unwiedly ones.

You've invented a set of rules for how you order keywords, taking
advantage of the fact that the compiler doesn't care. The result is
difficult to read for 99% of C programmers. It's not impossible to
read, just annoyingly difficult, and for no benefit that I can see.

I wouldn't have thought people would be so puzzled by the simple ordering
of words.

--

Frederick Gotham

[Frederick Gotham]

Flash Gordon posted:

The reality is that when more than one person works on a project it is
far easier to read if everyone uses the same coding style and in the
real world the majority of complex pieces of software are worked on by
multiple people.

I think this argument is exagerated. I can read any style, so long as it's
valid C. I'll admit, that at first, there were some things which puzzled
me, things like:

sizeof obj

instead of:

sizeof(obj)

Or:

int const *p;

instead of:

const int *p;

But is that not part of learning C? Some people put their function blocks
like so:

int Func()
{

}

while others put them like so:

int Func() {

}

It might be a little puzzling the first time you encounter it, and you
might even find it disgusting, but if you look at it objectively, you can
still read the code.

If you were to supply me with a source file which contained several
different styles, I wouldn't have a problem reading it.

--

Frederick Gotham

[Frederick Gotham]

en8t8si posted:

First, you have to get up to their level, then you can start improving
things.

Perhaps you'd like to post some of your own code, and I'll point out the
flaws?

I suspect most potential responders believe your comments wouldn't
have enough value to be worth the effort of posting.

With suspicion like that, you should write a murder mystery book.

--

Frederick Gotham

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

Flash Gordon posted:

>The reality is that when more than one person works on a project it is
far easier to read if everyone uses the same coding style and in the
real world the majority of complex pieces of software are worked on by
multiple people.

I think this argument is exagerated. I can read any style, so long as it's
valid C. I'll admit, that at first, there were some things which puzzled
me, things like:

sizeof obj

instead of:

sizeof(obj)

Or:

int const *p;

instead of:

const int *p;

But is that not part of learning C? Some people put their function blocks
like so:

int Func()
{

}

while others put them like so:

int Func() {

}

It might be a little puzzling the first time you encounter it, and you
might even find it disgusting, but if you look at it objectively, you can
still read the code.

If you were to supply me with a source file which contained several
different styles, I wouldn't have a problem reading it.

The thing you obstinately fail to recognise is this : WHY change
anything? Do you read books where the font keeps changing?

Yes, we can all *read* and understand mixed styles, but we dont like to
keep changing our focus.

There is no argument : standards on projects exist for a good
reason. And your self discovered style will not be welcomed on any
established code base. This is a simpe fact of life.

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

Keith Thompson posted:

>What I don't understand is how this quest leads you to declare things
backwards, using "int unsigned" rather than the far more common
"unsigned int". (Note that even in English grammar, "unsigned int"
makes more sense; "unsigned" is an adjective, and "int" is a noun --
not that that's a decisive argument.)

English is quite strange in that regard. I think most languages put their
words in order of descending importance. Irish for example:

window = fuinneog

small = beag

small window = fuinneog bheag

I think it makes sense to receive information in order of descending
importance. I like to know the type first and foremost, which is why I
prefer:

Are you trolling? Gaelic is not an internationally recognised language
of choice for documents or code bases.

And what you think has no relevance in the real world : MOST european
based languages are adjective noun order.

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

Ian Collins posted:

>Unfortunately that's the real world we professional programmers inhabit,
although I've never had to, or in recent years required my staff to
"dumb down" programming. I'm not sure from where or on what basis you
make that observation.

Over on comp.lang.c++, many regular participants condemned the following
code, saying it was cryptic:

for(size_t i = len - 1; i != -1; --i)

I understand it perfectly, and don't want to be dragged down with those who
fail to understand.

Its not cryptic : it just plain sucks and may well be inefficient too.

[Philip Potter]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:19*******************@news.indigo.ie...

Keith Thompson posted:

What I don't understand is how this quest leads you to declare things
backwards, using "int unsigned" rather than the far more common
"unsigned int". (Note that even in English grammar, "unsigned int"
makes more sense; "unsigned" is an adjective, and "int" is a noun --
not that that's a decisive argument.)

English is quite strange in that regard. I think most languages put their
words in order of descending importance. Irish for example:

window = fuinneog

small = beag

small window = fuinneog bheag

I think it makes sense to receive information in order of descending
importance. I like to know the type first and foremost, which is why I
prefer:

int const i = 5;

over:

const int i = 5;

It doesn't make much of a difference with small, simple, definitions, but
it certainly does work nice with long unwiedly ones.

And who defines importance? You, as a C++ programmer, should know that
sometimes type doesn't even matter. (That's why templates were created.)
Sometimes I'm much more interested in the fact that a variable is const than
the fact that it is an int. *Every* piece of information in the declaration
becomes important at some point.

Sticking to a common coding style between multiple programmers on the same
project makes looking for the piece of information you want *right now* much
easier. It's far more important to stick to a common coding style than to
invent a new one which you think is better but which nobody else is used to.

Since you are a lone programmer, agreement on your common coding style
becomes much easier and you can use whatever coding style you like. :)

You've invented a set of rules for how you order keywords, taking
advantage of the fact that the compiler doesn't care. The result is
difficult to read for 99% of C programmers. It's not impossible to
read, just annoyingly difficult, and for no benefit that I can see.

I wouldn't have thought people would be so puzzled by the simple ordering
of words.

I can see exactly why you and Keith keep disagreeing in this respect. You
are saying that the code has exactly the same information as before, so any
programmer worth his salt would be able to work out what the declaration
meant, whatever the word order. And you're right. It certainly is still just
as possible to get the same information.

However, the same programmer, when presented with a word order he is not
familiar with, will take longer to read it, and will have to think more, and
(quite possibly) will be frustrated by this fact. The code is not
unreadable; but it *is* less readable.

--

Philip Potter

[Frederick Gotham]

Richard posted:

> for(size_t i = len - 1; i != -1; --i)

Its not cryptic : it just plain sucks and may well be inefficient too.

Care to express why you think it "plain sucks", and why it may be well be
inefficient too?

--

Frederick Gotham

[Frederick Gotham]

Philip Potter posted:

>I wouldn't have thought people would be so puzzled by the simple
ordering of words.

I can see exactly why you and Keith keep disagreeing in this respect.
You are saying that the code has exactly the same information as before,
so any programmer worth his salt would be able to work out what the
declaration meant, whatever the word order.

Precisely.

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() {}

And you're right. It certainly is still just as possible to get the same
information.

However, the same programmer, when presented with a word order he is not
familiar with, will take longer to read it, and will have to think more,
and (quite possibly) will be frustrated by this fact. The code is not
unreadable; but it *is* less readable.

I don't quite agree. The only time I need to pay attention to word order in a
C definition is whether a "const" is placed before or after an asterisk:

int const *p;
int *const p;

Other than that, I just scan the words and take meaning from them.

--

Frederick Gotham

[Frederick Gotham]

Philip Potter posted:

>It doesn't make much of a difference with small, simple, definitions,
but it certainly does work nice with long unwiedly ones.

And who defines importance? You, as a C++ programmer, should know that
sometimes type doesn't even matter. (That's why templates were created.)

Not quite, I still want to see the types:

template<class RetType, class ArgType>
RetType const inline *Func(ArgType arg)
{

}

--

Frederick Gotham

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

Frederick Gotham <fg*******@SPAM.comwrites:

The people who are arguing that "other people should be able to read your
code" are the very people who have difficulty reading other people's code.
Big deal: I write "char unsigned" instead of "unsigned char"... is it
really that bewildering?

It takes a small amount of time to figure it out the first time you
see it, and some more time to figure out why it's being written that
way. If I see "char unsigned" in some random piece of code, I'm not
just going to wonder why it's written that way, I'm also going to
wonder whether it's correct. I know the language allows either order,
but I'm going to have to allow for the possibility that the author
doesn't know what he's doing. I know that "unsigned char" and "char
unsigned" mean the same thing, but how do I know that the author knows
that?

Don't you think that you're being just a _little_ extreme? At the very
least you have to admit that Frederick's order is legal, correct,
logical, internally consistent (which cannot be said of most code out
there, which throws consts around /ad libitum/), and if applied
throughout his code base, pretty clearly intentional. It might not be
your preferred order of specifiers, but for heavens' sake, if you're
going to spend a whole our getting used to it, you're dyslexic.

Richard

[Richard Bos]

Ian Collins <ia******@hotmail.comwrote:

Frederick Gotham wrote:

I am predominantly a C++ programmer, however I can program in C.

My own code does not suffer from any restrictions which a company may
impose, and so I strive to write quality, fully-portable, Standard-
compliant, efficient code.

Commendable objectives.

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.

Dunno about you, but if we're bandying manglement terms about, I prefer
to employificate Programmer Driven Development.

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.

Richard

[Frederick Gotham]

Richard Bos posted:

>It takes a small amount of time to figure it out the first time you
see it, and some more time to figure out why it's being written that
way. If I see "char unsigned" in some random piece of code, I'm not
just going to wonder why it's written that way, I'm also going to
wonder whether it's correct. I know the language allows either order,
but I'm going to have to allow for the possibility that the author
doesn't know what he's doing. I know that "unsigned char" and "char
unsigned" mean the same thing, but how do I know that the author knows
that?

Don't you think that you're being just a _little_ extreme? At the very
least you have to admit that Frederick's order is legal, correct,
logical, internally consistent (which cannot be said of most code out
there, which throws consts around /ad libitum/), and if applied
throughout his code base, pretty clearly intentional. It might not be
your preferred order of specifiers, but for heavens' sake, if you're
going to spend a whole our getting used to it, you're dyslexic.

If the word order in definitions/declarations was purely at the programmer's
discretion, then perhaps it would be beneficial to view them as if you're
dyslexic! I only pay attention to whether a const is placed before or after
an asterisk... it's a free-for-all after that.

--

Frederick Gotham

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

Richard posted:

>> for(size_t i = len - 1; i != -1; --i)

>Its not cryptic : it just plain sucks and may well be inefficient too.

Care to express why you think it "plain sucks", and why it may be well be
inefficient too?

Sure : I'm just expressing my individuality and unsupported opinion as
you like to do :-; And it was explained to you on c++ forum.

It is much more common, and often faster, to a zero check as the
limiting condition. Maybe the compiler will do it for you. I dont know.

while(count--)
arr[count]=val;

But this is religious stuff.

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

Philip Potter posted:

>>I wouldn't have thought people would be so puzzled by the simple
ordering of words.

I can see exactly why you and Keith keep disagreeing in this respect.
You are saying that the code has exactly the same information as before,
so any programmer worth his salt would be able to work out what the
declaration meant, whatever the word order.

Precisely.

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() {}

>And you're right. It certainly is still just as possible to get the same
information.

However, the same programmer, when presented with a word order he is not
familiar with, will take longer to read it, and will have to think more,
and (quite possibly) will be frustrated by this fact. The code is not
unreadable; but it *is* less readable.

I don't quite agree. The only time I need to pay attention to word order in a
C definition is whether a "const" is placed before or after an asterisk:

int const *p;
int *const p;

Other than that, I just scan the words and take meaning from them.

Would you be able to read the code as well if someone stripped out all
the whitespace?

[Phlip]

Richard Heathfield wrote:

Phlip in c.p has made himself a right PITN by going on and on and on about
TDD. Please don't make the same mistake. The clc group is about the C
language, not about development strategies.

This is a new low for you, Richard - invoking my name to flame someone else.

Maybe TDD is spreading, if anyone besides me deigns to bring it up...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Frederick Gotham]

Richard posted:

Frederick Gotham <fg*******@SPAM.comwrites:

>Richard posted:

>>> for(size_t i = len - 1; i != -1; --i)

>>Its not cryptic : it just plain sucks and may well be inefficient too.

Care to express why you think it "plain sucks", and why it may be well

be

>inefficient too?

Sure : I'm just expressing my individuality and unsupported opinion as
you like to do :-; And it was explained to you on c++ forum.

There's a difference between an "explanation", and "this his how I do it --
any other way is wrong".

It is much more common, and often faster, to a zero check as the
limiting condition. Maybe the compiler will do it for you. I dont know.

while(count--)
arr[count]=val;

But if a loop is more complex, it's nice to shape it as a "for" loop with
four straight-forward compartments:

1) The stuff done before the loop begins.
2) The condition which is tested.
3) The loop body which is executed.
4) The stuff done after each iteration.

--

Frederick Gotham

[Frederick Gotham]

Richard posted:

Would you be able to read the code as well if someone stripped out all
the whitespace?

Yes, although I'd appreciate if you'd leave the new-line characters in.

I've seen plenty of programmers who write the likes of the following
(including an ex-lecturer of mine:)

int i=width*2+4/height*3/2;

I've no problem reading it, even though I'd prefer something like:

int i = width*2 + 4/height * 3/2;

--

Frederick Gotham

[Phlip]

Ian Collins wrote:

ena8t8si wrote:

>Having said that, the reigning culture in comp.lang.c
is to remind contributors about what's considered
topical, and especially what isn't.

I don't see you jumping on anyone who advocates the development strategy
of using a debugger to work out why something doesn't work. If I were
to dare to suggest they write some tests, I'm sure you'd pile in and
accuse me of proselytising.

Topicality is in the eye of the beholder.

Enforcing topicality helps a newsgroup grow a crew of regulars, without
boring them with endless questions like, "How do I click on the VC++ Class
Wizard?"

A crew of regulars may then shepherd discussions that link the newsgroup's
topic to issues of interest to all programmers. The difference is the
discussion participants know the difference between topical and marginal
items.

In this system, nobody scores points by saying "your post is off-topic
because it mentioned C and also Brand X". Such grumpiness does not reflect
well on the accusers.

And a newsgroup can only grow when its senior members bring good general
advice.

(BTW my creds here are K&R C since the 1980s, folks...)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Richard]

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.

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

Richard posted:

>Frederick Gotham <fg*******@SPAM.comwrites:

>>Richard posted:

for(size_t i = len - 1; i != -1; --i)

Its not cryptic : it just plain sucks and may well be inefficient too.
Care to express why you think it "plain sucks", and why it may be well

be

>>inefficient too?

Sure : I'm just expressing my individuality and unsupported opinion as
you like to do :-; And it was explained to you on c++ forum.

There's a difference between an "explanation", and "this his how I do it --
any other way is wrong".

>It is much more common, and often faster, to a zero check as the
limiting condition. Maybe the compiler will do it for you. I dont know.

while(count--)
arr[count]=val;

But if a loop is more complex, it's nice to shape it as a "for" loop with
four straight-forward compartments:

1) The stuff done before the loop begins.
2) The condition which is tested.
3) The loop body which is executed.
4) The stuff done after each iteration.

It was an example of the range. I know how a for loop works.

[Richard]

"Phlip" <ph******@yahoo.comwrites:

Ian Collins wrote:

>ena8t8si wrote:

>>Having said that, the reigning culture in comp.lang.c
is to remind contributors about what's considered
topical, and especially what isn't.

I don't see you jumping on anyone who advocates the development strategy
of using a debugger to work out why something doesn't work. If I were
to dare to suggest they write some tests, I'm sure you'd pile in and
accuse me of proselytising.

Topicality is in the eye of the beholder.

Enforcing topicality helps a newsgroup grow a crew of regulars, without
boring them with endless questions like, "How do I click on the VC++ Class
Wizard?"

But like the post you criticised, this is OT. Take it to alt.pedant or
somesuch.

Alteratively, carry on since its a *developing thread* and others not
interested can kill the thread. Easy eh?

Too many chiefs too few indians 'round these parts.

[Philip Potter]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:hy*******************@news.indigo.ie...

Philip Potter posted:

I can see exactly why you and Keith keep disagreeing in this respect.
You are saying that the code has exactly the same information as before,
so any programmer worth his salt would be able to work out what the
declaration meant, whatever the word order.

Precisely.

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. The return type is "const int *
const" or "int const * const" and yet these terms have been scattered
throughout the declaration. The function itself is declared "static inline"
or "inline static". Why mix these things up? Don't you think it makes more
sense to write:

<function-modifiers<return typeFunc();

than anything else? Any other ordering will intermingle keywords specifying
return type with keywords that have nothing to do with return type.

And you're right. It certainly is still just as possible to get the same
information.

However, the same programmer, when presented with a word order he is not
familiar with, will take longer to read it, and will have to think more,
and (quite possibly) will be frustrated by this fact. The code is not
unreadable; but it *is* less readable.

I don't quite agree. The only time I need to pay attention to word order

in a >

C definition is whether a "const" is placed before or after an asterisk:

int const *p;
int *const p;

Other than that, I just scan the words and take meaning from them.

Again, good for you. But I want my code to be portable to picky programmers.

--

Philip Potter

[Al Balmer]

On Wed, 09 Aug 2006 17:19:35 +0200, Richard <rg****@gmail.comwrote:

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

A new buzzword? I call it a thread that's become off-topic, and should
be ended or moved to an appropriate venue.

--
Al Balmer
Sun City, AZ

[Richard Heathfield]

Phlip said:

Richard Heathfield wrote:

>Phlip in c.p has made himself a right PITN by going on and on and on
about TDD. Please don't make the same mistake. The clc group is about the
C language, not about development strategies.

This is a new low for you, Richard - invoking my name to flame someone
else.

I wasn't flaming him. I was asking him not to dump loads of TDD evangelism
on us. Since you're here, perhaps I could ask you the same. Thanks.

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

[Richard]

Al Balmer <al******@att.netwrites:

On Wed, 09 Aug 2006 17:19:35 +0200, Richard <rg****@gmail.comwrote:

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

A new buzzword? I call it a thread that's become off-topic, and should
be ended or moved to an appropriate venue.

What a surprise.

[Al Balmer]

On Wed, 09 Aug 2006 07:22:32 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:

>Flash Gordon said:

>Frederick Gotham wrote:

<snip>

>>Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business.

Many of us here earn our living writing software.

Many of us here use third-party libraries written in C. That does not mean
that third-party libraries are topical in clc.

No one is actually discussing business. What does happen is that in
the course of discussion, people draw from their real-world experience
for purposes of exposition. If programming style is topical, surely
programming style in the context of the real world is topical. You
can't discuss the merits of a style without giving reasons for it. For
most of us professionals, the reasons relate to real-world
considerations such as maintainability and working with other
programmers. For Frederick, the reasons appear to be that he enjoys
flouting convention, and likes to make up stuff as he goes along.
That's OK, he's a hobbyist, and need only please himself. However, he
should make an effort to understand that professional programmers have
other goals and other criteria, and not too surprisingly, those goals
and criteria relate to their jobs.

--
Al Balmer
Sun City, AZ

[Richard Heathfield]

Al Balmer said:

On Wed, 09 Aug 2006 07:22:32 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:

>>Flash Gordon said:

>>Frederick Gotham wrote:

<snip>

Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business.

Many of us here earn our living writing software.

Many of us here use third-party libraries written in C. That does not mean
that third-party libraries are topical in clc.

No one is actually discussing business. What does happen is that in
the course of discussion, people draw from their real-world experience
for purposes of exposition. If programming style is topical, surely
programming style in the context of the real world is topical. You
can't discuss the merits of a style without giving reasons for it.

All true.

For
most of us professionals, the reasons relate to real-world
considerations such as maintainability and working with other
programmers. For Frederick, the reasons appear to be that he enjoys
flouting convention, and likes to make up stuff as he goes along.
That's OK, he's a hobbyist, and need only please himself.

Again, all true.

However, he
should make an effort to understand that professional programmers have
other goals and other criteria, and not too surprisingly, those goals
and criteria relate to their jobs.

But why should he make the effort? It's not as if he's asking us to read his
code. It's not as if he's asking for help. It's not as if he's ever going
to /work/ as a programmer. So why shouldn't he code as he likes? Just so
long, of course, that he doesn't ever expect to work as a programmer, or
get help from us with his code, or get us to read his code.

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

[Richard]

Richard Heathfield <in*****@invalid.invalidwrites:

Al Balmer said:

>On Wed, 09 Aug 2006 07:22:32 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:

>>>Flash Gordon said:

Frederick Gotham wrote:

<snip>

Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business.

Many of us here earn our living writing software.

Many of us here use third-party libraries written in C. That does not mean
that third-party libraries are topical in clc.

No one is actually discussing business. What does happen is that in
the course of discussion, people draw from their real-world experience
for purposes of exposition. If programming style is topical, surely
programming style in the context of the real world is topical. You
can't discuss the merits of a style without giving reasons for it.

All true.

>For
most of us professionals, the reasons relate to real-world
considerations such as maintainability and working with other
programmers. For Frederick, the reasons appear to be that he enjoys
flouting convention, and likes to make up stuff as he goes along.
That's OK, he's a hobbyist, and need only please himself.

Again, all true.

>However, he
should make an effort to understand that professional programmers have
other goals and other criteria, and not too surprisingly, those goals
and criteria relate to their jobs.

But why should he make the effort? It's not as if he's asking us to read his
code. It's not as if he's asking for help. It's not as if he's ever going
to /work/ as a programmer. So why shouldn't he code as he likes? Just so
long, of course, that he doesn't ever expect to work as a programmer, or
get help from us with his code, or get us to read his code.

But the point is, he is doing exactly that.

And he is arguing the toss that a programmer should be able to do as
they like if *they* understand it. More topical to general programming
of course, but C is especially good at becoming confusing as it is
without someone "rewriting" the general rules. As for arguing that he
could & should reqrite the coding standards on a large project, well,
for those of us here who have worked in the real world, we know it to be
laughably ludicrous.

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

--

[Phlip]

Richard wrote:

But like the post you criticised, this is OT. Take it to alt.pedant or
somesuch.

Topicality is always on topic.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Frederick Gotham]

Philip Potter posted:

Why mix these things up? Don't you think it
makes more sense to write:

<function-modifiers<return typeFunc();

No, I prefer:

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

"name" might include pointer-ness, or function-ness, or array-ness. Something
like:

long unsigned const volatile static inline (*Func(void))[6]
{
long unsigned volatile static arr[6] = {1,2,4,8,16,32};

return &arr;
}

int main(void)
{
long unsigned const volatile (*const p)[6] = Func();
}

--

Frederick Gotham

[Michael Wojcik]

In article <87************@mail.com>, Richard <rg****@gmail.comwrites:

"Philip Potter" <ph***********@xilinx.comwrites:

<we******@gmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

*something in which the content was lost in a swathe of personal attacks*

Calm down. You do not make your points any clearer by insulting others and
ignoring their arguments. While I think that *what* you were saying has some
validity [1], the way you said it was completely OTT.

He wasnt overly rude : just somewhat miffed, as a lot of posters get,
when dealing with the typically overtly imperious tone taken by a
certain poster.

You think *Keith* was "imperious", compared to Paul? You may have the
oddest sense of prose style I have ever encountered, and I used to
teach literature at university.

--
Michael Wojcik mi************@microfocus.com

[Harald van Dijk]

Frederick Gotham wrote:

Philip Potter posted:

>Why mix these things up? Don't you think it
makes more sense to write:

<function-modifiers<return typeFunc();

No, I prefer:

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

While that's valid, please keep in mind that the ability to put
static/extern/inline in the middle of a declaration is marked
an "obsolescent" feature.

[Al Balmer]

On Wed, 09 Aug 2006 16:37:46 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:

>However, he
should make an effort to understand that professional programmers have
other goals and other criteria, and not too surprisingly, those goals
and criteria relate to their jobs.

But why should he make the effort?

For whatever reason he's making the effort to post here :-)

>It's not as if he's asking us to read his
code. It's not as if he's asking for help. It's not as if he's ever going
to /work/ as a programmer. So why shouldn't he code as he likes? Just so
long, of course, that he doesn't ever expect to work as a programmer, or
get help from us with his code, or get us to read his code.

--
Al Balmer
Sun City, AZ

[Frederick Gotham]

Harald van =?UTF-8?B?RMSzaw==?= posted:

>No, I prefer:

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

While that's valid, please keep in mind that the ability to put
static/extern/inline in the middle of a declaration is marked
an "obsolescent" feature.

I wasn't aware of that. Which Standard says that you can't put them in
whatever order you like?

So where must they be put, and in what order?

--

Frederick Gotham

[Harald van Dijk]

Frederick Gotham wrote:

Harald van =?UTF-8?B?RMSzaw==?= posted:

>>No, I prefer:

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

While that's valid, please keep in mind that the ability to put
static/extern/inline in the middle of a declaration is marked
an "obsolescent" feature.

I wasn't aware of that. Which Standard says that you can't put them in
whatever order you like?

So where must they be put, and in what order?

No standard says that. Obsolescent means it may be considered for removal in
a future standard, and is discouraged, but is currently still supported.
What n1124 says is:

Introduction p2:

Certain features are obsolescent, which means that they may be considered
for withdrawal in future revisions of this International Standard. They are
retained because of their widespread use, but their use in new
implementations (for implementation features) or new programs (for language
[6.11] or library features [7.26]) is discouraged.

6.11.5 Storage-class speci�ers
The placement of a storage-class speci�er other than at the beginning of the
declaration speci�ers in a declaration is an obsolescent feature.

I was overly broad, though, sorry: inline is not a storage-class specifier.
It's a function specifier, and there does not seem to be a similar note for
function specifiers.

[Keith Thompson]

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.

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

[Flash Gordon]

Frederick Gotham wrote:

Richard Bos posted:

>>It takes a small amount of time to figure it out the first time you
see it, and some more time to figure out why it's being written that
way. If I see "char unsigned" in some random piece of code, I'm not
just going to wonder why it's written that way, I'm also going to
wonder whether it's correct. I know the language allows either order,
but I'm going to have to allow for the possibility that the author
doesn't know what he's doing. I know that "unsigned char" and "char
unsigned" mean the same thing, but how do I know that the author knows
that?

Don't you think that you're being just a _little_ extreme? At the very
least you have to admit that Frederick's order is legal, correct,
logical, internally consistent (which cannot be said of most code out
there, which throws consts around /ad libitum/), and if applied
throughout his code base, pretty clearly intentional. It might not be
your preferred order of specifiers, but for heavens' sake, if you're
going to spend a whole our getting used to it, you're dyslexic.

If the word order in definitions/declarations was purely at the programmer's
discretion, then perhaps it would be beneficial to view them as if you're
dyslexic! I only pay attention to whether a const is placed before or after
an asterisk... it's a free-for-all after that.

I know for a fact there is at least one dyslexic programmer on this
group, and the person I am thinking of finds is easier if a consistent
style is used, and easiest if the consistent style is the one he deals
with most of the time.
--
Flash Gordon
Dyslexic Programmer with a certificate to prove it.
At least the compiler ensures I spell variable names consistently wrong.

[Flash Gordon]

Frederick Gotham wrote:

Flash Gordon posted:

>The reality is that when more than one person works on a project it is
far easier to read if everyone uses the same coding style and in the
real world the majority of complex pieces of software are worked on by
multiple people.

I think this argument is exagerated. I can read any style, so long as it's
valid C. I'll admit, that at first, there were some things which puzzled
me, things like:

sizeof obj

instead of:

sizeof(obj)

Never gave me a problem.

Or:

int const *p;

instead of:

const int *p;

Neither of these has puzzled me either. However, I have to slow down for
the one I'm not used to and if I'm scanning back up to check some aspect
of the type of p then instead of scanning and immediately picking out
the aspect I want to know I'll have to stop and read it.

But is that not part of learning C? Some people put their function blocks
like so:

int Func()
{

}

while others put them like so:

int Func() {

}

It might be a little puzzling the first time you encounter it, and you
might even find it disgusting, but if you look at it objectively, you can
still read the code.

Yes, but for the style you do not generally use it slows you down. If
you see
int Func() {
int i;

You may well have to pause a moment to confirm that there is nothing in
the parenthesis and so i is a local variable rather than a parameter.

If you were to supply me with a source file which contained several
different styles, I wouldn't have a problem reading it.

I would still be able to read it, I know because I have had to, but it
slows most people down. It especially slows people down when they are
scanning just to check something.

Some of us can be asked to review a few thousand lines of C code.
Anything that slows you down on this in a busy day is undesirable.

For your own code seen by no one else do whatever you please. I'm just
explaining why when more than one person is involved it is advisable to
stick to a consistent style, and where there is a commonly accepted
style it is generally easiest to stick to it.

I'm not going to continue responding to this since it is a style issue
and you never get everyone agreeing (I've accepted Pascal coding styles
I did not like because it was the standard for the project). Although
the fact that most people posting an opinion seem to think your coding
style is less readable might give you a hint.
--
Flash Gordon
Still sigless on this computer

[Keith Thompson]

mw*****@newsguy.com (Michael Wojcik) writes:

In article <87************@mail.com>, Richard <rg****@gmail.comwrites:

>"Philip Potter" <ph***********@xilinx.comwrites:

<we******@gmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...
*something in which the content was lost in a swathe of personal attacks*

Calm down. You do not make your points any clearer by insulting
others and ignoring their arguments. While I think that *what*
you were saying has some validity [1], the way you said it was
completely OTT.

He wasnt overly rude : just somewhat miffed, as a lot of posters get,
when dealing with the typically overtly imperious tone taken by a
certain poster.

You think *Keith* was "imperious", compared to Paul? You may have the
oddest sense of prose style I have ever encountered, and I used to
teach literature at university.

It's not quite clear to me who Richard was saying wasn't "overly
rude", and who he was saying takes a "typically overtly imperious
tone". Richard, would you care to clarify?

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

[Ian Collins]

Richard Bos wrote:

Ian Collins <ia******@hotmail.comwrote:

>>Frederick Gotham wrote:

>>>I am predominantly a C++ programmer, however I can program in C.

My own code does not suffer from any restrictions which a company may
impose, and so I strive to write quality, fully-portable, Standard-
compliant, efficient code.

Commendable objectives.

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.

Dunno about you, but if we're bandying manglement terms about, I prefer
to employificate Programmer Driven Development.

I'm not.

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?

--
Ian Collins.

[Ian Collins]

Frederick Gotham wrote:

Flash Gordon posted:

>>The reality is that when more than one person works on a project it is
far easier to read if everyone uses the same coding style and in the
real world the majority of complex pieces of software are worked on by
multiple people.

I think this argument is exagerated.

No it isn't. You say that you don't work in a team, so you don't have
any basis for that statement.

Look at any large opensource project and you will find a coding
standard, with will be enforced with the same rigour as topicality on
this group!

The same applies for each of the many commercial applications I have
worked on.

--
Ian Collins.

[Frederick Gotham]

Keith Thompson posted:

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.

No, I'd consider it more akin to:

a big, yellow, smooth, painted wall

instead of:

a smooth, yellow, painted, big wall

There are times when the order doesn't change the meaning.

--

Frederick Gotham

[Ian Collins]

Phlip wrote:

Ian Collins wrote:

>>ena8t8si wrote:

>>>Having said that, the reigning culture in comp.lang.c
is to remind contributors about what's considered
topical, and especially what isn't.

I don't see you jumping on anyone who advocates the development strategy
of using a debugger to work out why something doesn't work. If I were
to dare to suggest they write some tests, I'm sure you'd pile in and
accuse me of proselytising.

Topicality is in the eye of the beholder.

Enforcing topicality helps a newsgroup grow a crew of regulars, without
boring them with endless questions like, "How do I click on the VC++ Class
Wizard?"

I don't dispute that, what I do object to is some one using topicality
as a cover for a personal agenda.

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.

--
Ian Collins.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Keith Thompson posted:

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

No, I'd consider it more akin to:

a big, yellow, smooth, painted wall

instead of:

a smooth, yellow, painted, big wall

There are times when the order doesn't change the meaning.

No, it doesn't change the meaning -- and in this case, it doesn't
matter because there's no conventional ordering for those words.

In C, there is a conventional ordering, though it's not imposed by the
rules of the language.

I have tried several times to explain why your chosen style merely
makes your code more difficult for others to understand.

I posted a C example where I sorted the keywords alphabetically. That
example is, for most of us, no more or less difficult to read than
your style with the "most important" keywords first. Anything other
than the conventional ordering used in most actual C code, and in the
examples in the standard, is more difficult to read, and with no
benefit for anyone other than you.

If you promise not to post any such code here, I won't complain about
it again. If you do post such code, don't expect anyone to spend the
extra time required to figure it out.

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

[Frederick Gotham]

Keith Thompson posted:

>No, I'd consider it more akin to:

a big, yellow, smooth, painted wall

instead of:

a smooth, yellow, painted, big wall

There are times when the order doesn't change the meaning.

No, it doesn't change the meaning -- and in this case, it doesn't
matter because there's no conventional ordering for those words.

In C, there is a conventional ordering, though it's not imposed by the
rules of the language.

This newsgroup is for the discussion of the C language as described by the
Standard(s).

I don't think either of the Standards indicate that one should write:

int const *p;

rather than:

const int *p;

If it wanted to impose such a restriction, it would.

If you promise not to post any such code here, I won't complain about
it again. If you do post such code, don't expect anyone to spend the
extra time required to figure it out.

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?

What puzzles me more than anything is that you even pay attention to the
ordering of the words. The only time it comes into play is whether "const"
and "volatile" and "restrict" appear before or after an asterisk. The rest
of the time, it's irrelevant.

--

Frederick Gotham