code portability

[Al Balmer]

Flash Gordon said:


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.

 

[Richard Heathfield]

Al Balmer said:

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]

Al Balmer said:


All true.


Again, all true.


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]

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

Topicality is always on topic.

 

[Frederick Gotham]

Philip Potter posted:

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

<function-modifiers> <return type> Func();

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

 

[Michael Wojcik]

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

 

[Harald van =?UTF-8?B?RMSzaw==?=]

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

 

[Al Balmer]

But why should he make the effort?

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

 

[Frederick Gotham]

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

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?

 

[Harald van =?UTF-8?B?RMSzaw==?=]

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



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.

 

[Flash Gordon]

Richard Bos posted:


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]

Flash Gordon posted:



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.

 

[Keith Thompson]

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]

*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?

 

[Ian Collins]

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]

Flash Gordon posted:





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.

 

[Frederick Gotham]

Keith Thompson posted:

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.

 

[Ian Collins]

Ian Collins wrote:




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.

 

[Keith Thompson]

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.

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.

 

[Frederick Gotham]

Keith Thompson posted:

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.