A
Adrian Hawryluk
William said:
Get rid of functions, macros, types... Hey! We're back to Machine
Language!
BTW, who states what is and is not talked about here?
Adrian
Get rid of functions, macros, types... Hey! We're back to Machine
Language!
BTW, who states what is and is not talked about here?
Adrian
R
Richard Heathfield
Adrian Hawryluk said:
The topic of comp.lang.c is the computer programming language called C.
Legally, anyone here can talk about anything that doesn't breach their
ISP's T&Cs. Socially speaking, however, discussing anything /other/
than C will cost you a certain amount of 'capital', and that 'capital'
can take a long time to acquire (by patiently and correctly answering C
questions for a rather long time). Such things are not tracked formally
- everyone has their own feel for who is an on-topic kinda person and
who is not. Newbies, not surprisingly, often get this wrong.
Those who are not on-topic kinda people will[*] tend to fade away from
comp.lang.c, and find other newsgroups (e.g. comp.unix.programmer or
comp.os.ms-windows.programmer.win32 or the like) - and that's fine. And
of course there's nothing to stop people subscribing to more than one
group.
[*] Except for some of the trolls.
The topic of comp.lang.c is the computer programming language called C.
Legally, anyone here can talk about anything that doesn't breach their
ISP's T&Cs. Socially speaking, however, discussing anything /other/
than C will cost you a certain amount of 'capital', and that 'capital'
can take a long time to acquire (by patiently and correctly answering C
questions for a rather long time). Such things are not tracked formally
- everyone has their own feel for who is an on-topic kinda person and
who is not. Newbies, not surprisingly, often get this wrong.
Those who are not on-topic kinda people will[*] tend to fade away from
comp.lang.c, and find other newsgroups (e.g. comp.unix.programmer or
comp.os.ms-windows.programmer.win32 or the like) - and that's fine. And
of course there's nothing to stop people subscribing to more than one
group.
[*] Except for some of the trolls.
S
SM Ryan
# Back to my original silly metaphor, if something is a Chicken or a
# Rooster but not both you might define a union to express this. Then,
# defining a function that accepts the type indicator and the union, if
# at a later date your code grows to encompass Cornish Game Hens,
# Turkeys, and Roast Peking Duck, you do not need to change the
# interface.
Unions require you distribute code to deal with each
possible union element throughout the code. Sometimes
this okay to best, especially when the union is small
and does not evolve. In other cases, everytime you
extend a union you have to track down all cases
throughout the code.
Object-oriented techniques instead collect all the
code for each union element in one place and let
you extend the union without perturbing other union
elements (theoretically).
You can do object-oriented programming in C.
# > struct record
# > {
# > int type;
# > union
# > {
# > TYPE_A A;
# > TYPE_B B;
# > TYPE_C C;
# > }
# > data;
# > };
// Define the Object.
struct record {
T (*method1)(struct record *self,...);
T (*method2)(struct record *self,...);
T (*method3)(struct record *self,...);
...
}
#define method1(self,...) ((self)->method1)((void*)(self),...)
....
// Implement TYPE_A variant of object.
struct recordA {
T (*method1)(struct record *self,...);
T (*method2)(struct record *self,...);
T (*method3)(struct record *self,...);
...
TYPE_A A;
}
T Amethod1(struct record *self0,...) {
struct recordA *self = (struct recordA*)self0;
...
}
struct record *newA(...) {
struct recordA *a = malloc(sizeof(struct recordA);
a->method1 = Amethod1;
...
return (struct record*)a;
}
etc
# Rooster but not both you might define a union to express this. Then,
# defining a function that accepts the type indicator and the union, if
# at a later date your code grows to encompass Cornish Game Hens,
# Turkeys, and Roast Peking Duck, you do not need to change the
# interface.
Unions require you distribute code to deal with each
possible union element throughout the code. Sometimes
this okay to best, especially when the union is small
and does not evolve. In other cases, everytime you
extend a union you have to track down all cases
throughout the code.
Object-oriented techniques instead collect all the
code for each union element in one place and let
you extend the union without perturbing other union
elements (theoretically).
You can do object-oriented programming in C.
# > struct record
# > {
# > int type;
# > union
# > {
# > TYPE_A A;
# > TYPE_B B;
# > TYPE_C C;
# > }
# > data;
# > };
// Define the Object.
struct record {
T (*method1)(struct record *self,...);
T (*method2)(struct record *self,...);
T (*method3)(struct record *self,...);
...
}
#define method1(self,...) ((self)->method1)((void*)(self),...)
....
// Implement TYPE_A variant of object.
struct recordA {
T (*method1)(struct record *self,...);
T (*method2)(struct record *self,...);
T (*method3)(struct record *self,...);
...
TYPE_A A;
}
T Amethod1(struct record *self0,...) {
struct recordA *self = (struct recordA*)self0;
...
}
struct record *newA(...) {
struct recordA *a = malloc(sizeof(struct recordA);
a->method1 = Amethod1;
...
return (struct record*)a;
}
etc
W
William Ahern
On Sat, 10 Mar 2007 10:37:16 +0000, SM Ryan wrote:
If you have a type "attribute", then very often its a good idea to use an
enum, because almost as often you will (or should) have a switch
statement (or statements) to control code flow for some set of the types.
Compilers like GCC can be told to warn when a switch occurs on
an enumerated type, and all the enumerated values are not accounted for.
If you're an advocate of defensive programming--at least in some
circumstances--then it can prove quite useful.
(I qualify with the defensive programming bit because the GCC checks can be
quite naive, and don't seem to do any sort of inter-procedural flow
analysis; in which case, the warning(s) could potentially be more a
nuisance than useful feedback on program correctness, and so defensible
only on pragmatic grounds).
If you have a type "attribute", then very often its a good idea to use an
enum, because almost as often you will (or should) have a switch
statement (or statements) to control code flow for some set of the types.
Compilers like GCC can be told to warn when a switch occurs on
an enumerated type, and all the enumerated values are not accounted for.
If you're an advocate of defensive programming--at least in some
circumstances--then it can prove quite useful.
(I qualify with the defensive programming bit because the GCC checks can be
quite naive, and don't seem to do any sort of inter-procedural flow
analysis; in which case, the warning(s) could potentially be more a
nuisance than useful feedback on program correctness, and so defensible
only on pragmatic grounds).
A
Adrian Hawryluk
Richard said:
Thanks for the info.
However, I and it looks like a few others don't see it your way that
unions are not topical.
Adrian
--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================
R
Richard Heathfield
Adrian Hawryluk said:
Huh?!?!? Of course unions are topical! See, for example, 6.7.2.1.
There's even a 'union' keyword. Unions not topical? Never heard such
tosh.
Huh?!?!? Of course unions are topical! See, for example, 6.7.2.1.
There's even a 'union' keyword. Unions not topical? Never heard such
tosh.
K
Kenny McCormack
Adrian Hawryluk said:
Whoever said that?
What *I* said, which you may have misunderstood, was that there's no
*use* of unions that is topical here that can't just as easily be done
with a struct. What this means is that unions *could* be removed from the
standard with no loss of functionality *as far as this ng is concerned*
(not true, of couse, as far as the *real world* is concerned).
That's not to say, of course, that there is any chance that they will
(be removed).
R
Richard Bos
Adrian Hawryluk said:
_That_ problem is easily solved by not listening to Kenny McTrollmack.
Richard
R
Richard Heathfield
Kenny McCormack said:
Counter-example:
union U { double d; unsigned char ir[sizeof(double)]; };
union U u;
size_t i;
u.d = 3.14159;
for(i = 0; i < sizeof(double); i++)
{
printf("%02X", u.ir);
}
putchar('\n');
Counter-example:
union U { double d; unsigned char ir[sizeof(double)]; };
union U u;
size_t i;
u.d = 3.14159;
for(i = 0; i < sizeof(double); i++)
{
printf("%02X", u.ir);
}
putchar('\n');
K
Kenny McCormack
Richard Heathfield said:
When I feed the above trash to my C compiler, I get a bunch of error
messages (said in the spirit of this newsgroup).
Anyway, type-punning was specifically disallowed in this NG a few years
back. You need to keep up.
R
Richard Heathfield
Kenny McCormack said:
First, learn C. Then add your own furniture to the above code fragment,
to get a fully compilable program. It's not difficult.
Read the Standard more closely, and you will discover your error.
First, learn C. Then add your own furniture to the above code fragment,
to get a fully compilable program. It's not difficult.
Read the Standard more closely, and you will discover your error.
A
Adrian Hawryluk
My apologies, that was miss directed. It was Kenny that said:Richard said:
Sorry again,
Adrian
--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================
A
Adrian Hawryluk
Kenny said:
Thanks for clarifying.
Adrian
--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================
F
Flash Gordon
Adrian Hawryluk wrote, On 13/03/07 16:48:
Please cut down your signature, half a page is *far* too long. The
convention is up to 4 lines, although a bit longer might not be
commented on, but this is 14. Alternatively I'll just plonk you due to
the annoyance factor.
Please cut down your signature, half a page is *far* too long. The
convention is up to 4 lines, although a bit longer might not be
commented on, but this is 14. Alternatively I'll just plonk you due to
the annoyance factor.
K
Kenny McCormack
Flash Gordon said:
Which would be best for all concerned. I say, go for it! Keep that sig
intact!
Nobody wants to hear from Fleshy, anyway.
K
Keith Thompson
[snip]Adrian Hawryluk said:
Kenny is an admitted troll; he is best ignored.
Y
Yevgen Muntyan
Keith said:
Note that in this case he caught even Richard Heathfield (of course
Richard could not resist to be right one more time and use Kenny's
mistake about "using struct"). Funny thing is that Kenny's original
statement was true. I'd think this union thing is good food for
thought about on-topic vs off-topic.
Yevgen
Y
Yevgen Muntyan
Richard said:
struct S {int foo;}; /* need to use struct somewhere */
double d = 3.14159;
unsigned char ir[sizeof (double)];
memcpy (ir, &d, sizeof d);
....
Now Richard should probably say that it's not as easy, to remain
right.
Yevgen
K
Kenny McCormack
Keith Thompson said:
Keith is an admitted anal retentive freak; he is best read carefully for
maximal enjoyment.
K
Kenny McCormack
Yevgen Muntyan said:
Heathfield claims, as far as I can tell, that there is a "special
license" in the standard for type punning involving unsigned char.
He may be right about this; I can't be bothered to check because it
doesn't change my underlying point. I.e., even if type punning is
allowable in one obscure special case, it doesn't change the fact that
the standard disallows it in general and that, therefore, the primary
use of unions (*) in the real world is OT here.
(*) That couldn't just as easily be done with a struct.