code portability

[Phlip]

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.

 

[Dik T. Winter]

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

 

[Frederick Gotham]

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.

 

[Eigenvector]

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

 

[Richard Heathfield]

Dik T. Winter said:

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

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

 

[Philip Potter]

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]

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.

 

[Richard Bos]

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

 

[Richard Bos]

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

 

[Richard Bos]

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

 

[Philip Potter]

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

 

[Frederick Gotham]

Eigenvector posted:

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]

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<NumT> const &stls)

 

[Chris Dollin]

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

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.

 

[Frederick Gotham]

Philip Potter posted:

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]

Chris Dollin posted:

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.

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.

 

[Chris Dollin]

Chris Dollin posted:


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.

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

 

[Frederick Gotham]

Chris Dollin posted:

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.

 

[Philip Potter]

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<NumT> const &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