Need clarity on structure alignment

[Phil Carmody]

GUI, threads, database, network... the std C portion looks relatively
miniscule.

I've written a GUI for handheld devices that had to be portable
across both 16-bit and 32-bit CPUs from unrelated architectures.
The way I achieved such 2-platform portability was to be as far
as I could tell 100% portable standard C.

Threads - that's trivial - as the threads don't even need to know
they're threads. The thing that _manages_ threads needs to be
non-portable, as it needs to dick around with things like stack
pointers etc. but that's minuscule compared to the sum total of
all the threads.

Database? Given that database code is some of the most long-running
code in the history of the universe, anyone who codes databases
non-portably should be taken outside and shot. Let's call that
almost entirely portable standard C too.

Network? Given that almost every important spec is defined in
terms of octets, and C guarantees the ability to manage octets,
again, it's trivial to program networking code portably. Unless
you meant PHY drivers, in which case you're utterly unable to
express what you mean, and are worth deriding simply for that
fact.

0/4.

I consider std C/C++ (moreso C++ than C) a platform-specific thing to be
"isolated" also, though. YMMV.

You gibber a lot, though.

Phil

 

[Keith Thompson]

Network? Given that almost every important spec is defined in
terms of octets, and C guarantees the ability to manage octets,
again, it's trivial to program networking code portably.

[...]

How does C guarantee the ability to manage octets? I suppose it would
be possible on a system with CHAR_BIT==9, but that would depend on
just what you're supposed to do with the octets. (You could store
each octet in a 9-bit byte, but presumably you'd have to convert them
to some external form in some system-specific manner.)

 

[Phil Carmody]

Network? Given that almost every important spec is defined in
terms of octets, and C guarantees the ability to manage octets,
again, it's trivial to program networking code portably.

[...]

How does C guarantee the ability to manage octets? I suppose it would
be possible on a system with CHAR_BIT==9, but that would depend on
just what you're supposed to do with the octets. (You could store
each octet in a 9-bit byte, but presumably you'd have to convert them
to some external form in some system-specific manner.)

It promises the ability to manage data larger than octets, and
the ability to mask data larger than octets to octets. Therefore
it promises the ability to manage octets. Did you ask the wrong
question?

I'm curious - do you think that GSM 03.38 is more or less easy to
manage portably in an environment with CHAR_BIT==8 than octets are
in an environment with CHAR_BIT==9?

If you think that physical drivers are networking, then I think
you need to look into the size of actual networking stacks some
time. Stacks which your company's competitors migrate between
24-bit and 32-bit CPU architectures just because it gives them
a warm fuzzy feeling.

Phil

 

[CBFalconer]

I left out the word 'significant' before the word 'software'. And
yes, I meant complete programs/systems of programs and not just
some fraction of a program.

I suggest you reconsider that. I meant the word 'most' above. The
parts that really require system customization are usually quite
small. Portability pays.

 

[Tony]

I've written a GUI for handheld devices that had to be portable
across both 16-bit and 32-bit CPUs from unrelated architectures.
The way I achieved such 2-platform portability was to be as far
as I could tell 100% portable standard C.

Threads - that's trivial - as the threads don't even need to know
they're threads. The thing that _manages_ threads needs to be
non-portable, as it needs to dick around with things like stack
pointers etc. but that's minuscule compared to the sum total of
all the threads.

Database? Given that database code is some of the most long-running
code in the history of the universe, anyone who codes databases
non-portably should be taken outside and shot. Let's call that
almost entirely portable standard C too.

Network? Given that almost every important spec is defined in
terms of octets, and C guarantees the ability to manage octets,
again, it's trivial to program networking code portably. Unless
you meant PHY drivers, in which case you're utterly unable to
express what you mean, and are worth deriding simply for that
fact.

0/4.

You missed my point. That those libraries aren't part of the C standard.
Only the standard libraries are.

You gibber a lot, though.

You sound defensive.

Tony

 

[Tony]

I suggest you reconsider that. I meant the word 'most' above. The
parts that really require system customization are usually quite
small. Portability pays.

If you need it. Portability has degrees. It's best to be pragmatic rather
than dogmatic about it.

Tony

 

[Tony]

Unless you tell it specifically how to do padding/alignment. Whether
#pragma
pack(1) will get you padding at the end of a struct or not is probably
iffy.
Personally, I try to write structs that align nicely naturally without
padding. I wouldn't use just one 8-bit integer in a struct on a 32-bit
machine: I'd use 4 consequetive ones making the struct a multiple of 4
bytes.

"For what purpose? That won't change the alignment of the structure,
nor cause other fields and objects to be misaligned."

Other members could be misaligned if I sprinkle 8-bit ints around while
having the compiler pack struct members on 1-byte boundaries.

Tony

 

[Phil Carmody]

GUI, threads, database, network... the std C portion looks relatively
miniscule.

[SNIP - how to write those 4 things portably in std C]

0/4.

You missed my point. That those libraries aren't

What libraries? Who mentioned libraries? They're just code. They
might be libraries, they might be entire applications. And as such,
apart from a few corner cases, such as interfacing with the harware
or perhaps OS/platform, they can be written portably in standards-
conforming C. And that makes them "std C". Even if they're not ...

part of the C standard.

You're not making a particularly strong point if that's your point.

Only the standard libraries are.

My god, it was your point. An almost entirely pointless point.
"Only the standard C libraries are the standard C libraries."
Golly gee - I feel enlightened now.

Keith hit the nail on the head, there's no point re-wording it,
I'll just repeat it verbatim:

But most programs, even large ones, can be written
*mostly* in standard C.

You've utterly failed to counter that claim, and simply appear to
be wiggling directionlessly now.

You sound defensive.

My best defense from your gibbering is a killfile, I'm starting to think.

Phil

 

[Tony]

GUI, threads, database, network... the std C portion looks relatively
miniscule.
[SNIP - how to write those 4 things portably in std C]

0/4.

You missed my point. That those libraries aren't

What libraries? Who mentioned libraries? They're just code. They
might be libraries, they might be entire applications. And as such,
apart from a few corner cases, such as interfacing with the harware
or perhaps OS/platform, they can be written portably in standards-
conforming C. And that makes them "std C". Even if they're not ...

part of the C standard.

You're not making a particularly strong point if that's your point.

Only the standard libraries are.

My god, it was your point. An almost entirely pointless point.
"Only the standard C libraries are the standard C libraries."
Golly gee - I feel enlightened now.

Keith hit the nail on the head, there's no point re-wording it,
I'll just repeat it verbatim:

But most programs, even large ones, can be written
*mostly* in standard C.

You've utterly failed to counter that claim, and simply appear to
be wiggling directionlessly now.

You sound defensive.

My best defense from your gibbering is a killfile, I'm starting to think.

Phil

Change "in std C" to "with std C" and recognize the dilemma. It's hardly
just the libraries, but I didn't/don't want to go round and round with the
language worshippers.

Tony

 

[Guest]

If you need it. Portability has degrees. It's best to be pragmatic rather
than dogmatic about it.

I have experience of a largeish application taht migrated from Unix
to
Windows. Most of the application didn't require modification.

It used sockets, ran as a service, walked directories and had a GUI.

 

[J. J. Farrell]

If you need it. Portability has degrees. It's best to be pragmatic rather
than dogmatic about it.

Of course, but what you may not of considered is that portability issues
often creep up behind and bite you. Again and again I've worked on
projects where there was "no possibility whatsoever" that it would ever
need to be ported to anything other than the single platform it was
targeted for; then a year later, there we are porting it to several
others. If you get in the habit of coding portably (but pragmatically as
you say) you can often save yourself a lot of effort in the long run.
It's usually quite possible to write significant parts of a project in
highly portable code and clearly isolate the non-portable parts with
little or no extra effort over doing it in a less easily ported way.
They key point is "little or no extra effort", once you've learned the
skills involved. If it costs next to nothing to do a thing portably
rather than non-portably, then even if doing so only pays off once in a
blue moon you've gained.

Pursuing portability to the extent of limiting functionality, or quality
of interface, or at the cost of a lot of extra work, is clearly a
different matter (unless it's an up-front requirement).

 

[CBFalconer]

I have experience of a largeish application taht migrated from
Unix to Windows. Most of the application didn't require
modification. It used sockets, ran as a service, walked
directories and had a GUI.

And there is nothing dogmatic about separating the portable parts
from the non-portable parts.

 

[Tony]

If you need it. Portability has degrees. It's best to be pragmatic rather
than dogmatic about it.

"I have experience of a largeish application taht migrated from Unix
to
Windows. Most of the application didn't require modification.

It used sockets, ran as a service, walked directories and had a GUI."

That's great. I hope to get my own framework to a similar level (probably
(assumption) with more independence from 3rd party code (including std C++
and the std libraries) though).

Tony

 

[Tony]

Of course, but what you may not of considered is that portability issues
often creep up behind and bite you.

Believe me, I've obsessed over the concepts for years.

Again and again I've worked on projects where there was "no possibility
whatsoever" that it would ever need to be ported to anything other than
the single platform it was targeted for; then a year later, there we are
porting it to several others.

I hear ya: where you're building something for someone else ("project
work"), it's wise to have more contingency.

If you get in the habit of coding portably (but pragmatically as
you say) you can often save yourself a lot of effort in the long run.

That's getting to sound a bit dogmatic.

It's
usually quite possible to write significant parts of a project in highly
portable code and clearly isolate the non-portable parts with little or no
extra effort over doing it in a less easily ported way. They key point is
"little or no extra effort", once you've learned the skills involved.

It's not a question of skill, it's one of judgement. YMMV.

If
it costs next to nothing to do a thing portably rather than non-portably,
then even if doing so only pays off once in a blue moon you've gained.

Which way you choose depends on what your long term goals are. The academic
view indeed is how you say (regurgitate) it.

Pursuing portability to the extent of limiting functionality, or quality
of interface, or at the cost of a lot of extra work, is clearly a
different matter (unless it's an up-front requirement).

Tony

 

[Kenny McCormack]

If you need it. Portability has degrees. It's best to be pragmatic rather
than dogmatic about it.

Not here. Here, dogmatic wins every time.

 

[Richard]

Not here. Here, dogmatic wins every time.

Used to win.

Chuck is still huffing and puffing and throwing out topic orders and
realising with horror that people with far less standard experience than
him that can produce far better C are starting to come forward and be
counted. Well, you sow what you reap so I can't say I'm particularly
sorry for the bully of a man that he appears to be in c.l.c. Possibly in
real life he is practical, approachable and reasonable. I hope so.

 

[Tony]

Not here. Here, dogmatic wins every time.

Another potential trade rag article: "The Politics of Programming Language
Newsgroups". (AKA, take everything with a grain of salt?).

Tony

 

[Kenny McCormack]

Another potential trade rag article: "The Politics of Programming Language
Newsgroups". (AKA, take everything with a grain of salt?).

Indeed. Sounds like an article waiting to be writen.

 

[J. J. Farrell]

Believe me, I've obsessed over the concepts for years.


I hear ya: where you're building something for someone else ("project
work"), it's wise to have more contingency.



That's getting to sound a bit dogmatic.

How so?

It's not a question of skill, it's one of judgement. YMMV.


Which way you choose depends on what your long term goals are. The academic
view indeed is how you say (regurgitate) it.

I don't know what you're trying to imply by your use of "academic" and
"regurgitate". I'm talking about normal practice in the real world of
developing commercial software for a salary.

 

[Tony]

How so?

Your passage seemed akin to pontification of which one finds a lot of in
language groups.

I don't know what you're trying to imply by your use of "academic" and
"regurgitate". I'm talking about normal practice in the real world of
developing commercial software for a salary.

The same as above: you're preaching to the choir.