code portability

[Philip Potter]

Keith Thompson posted:


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.

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.

 

[Frederick Gotham]

Richard posted:

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]

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

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]

Philip Potter posted:

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

}

 

[Richard Bos]

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]

Richard posted:




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 Bos]

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

 

[Richard]

Philip Potter posted:



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




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?

 

[Frederick Gotham]

Richard Bos posted:

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.

 

[Phlip]

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

 

[Frederick Gotham]

Richard posted:

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]

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;

 

[Phlip]

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

 

[Richard]

Richard posted:

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]

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

Its called a developing thread.

 

[Richard]

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]

Philip Potter posted:


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 type> Func();

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

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.

 

[Al Balmer]

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.

 

[Richard Heathfield]

Phlip said:

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]

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.