By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,670 Members | 1,526 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,670 IT Pros & Developers. It's quick & easy.

problem with macros

P: n/a
Hello, I have the following structure -

typedef struct
{
double x, y, z;

}vector;

In certain places, I could avoid triplification of code by using an
array instead of x, y, z. For eg:

typedef struct
{
double coord[3];

} vector;

But this notation does not some people who are going to read my code
(physics people). They are used to x, y, z notation for vectors. Also
I use long expressions in some places and using coord[index] makes it
even more intricate. So I decided to use x, y, z notation but I wrote
some macros that could help me in reducing the triplification of code
that may happen at some places:

#define coord[0] x
#define coord[1] y
#define coord[2] z

I thought this will allow array indexing of the coordinates but
instead I got an error "coord redefined" . Why is that ?
Aug 1 '08
Share this Question
Share on Google+
80 Replies


P: n/a
On Aug 4, 9:36 am, Eric Sosman <Eric.Sos...@sun.comwrote:
jacob navia wrote:
They are not written in 'regulars C'
o no network

Right. It's the domain of other standards, not of a programming
language standard.
Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.
o no graphics

Right. It's the domain of other standards (and less formal quasi-
standards), not of a programming language standard.
Java supports graphics, Python supports graphics, others probably
support graphics.
o no GUI

You're repeating yourself.
GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.
o no directories

Right. It's the domain of other standards, not of a programming
language standard.
Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.

<snip>

So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."

Sebastian

Aug 4 '08 #51

P: n/a
Eric Sosman wrote:
jacob navia wrote:
>Eric Sosman wrote:
>>[...]
You're repeating yourself from many earlier threads. You've
told us more than once that C is a dead language,

You are lying, as always

Then I've been misled by my own memory -- and by that of Google,
which quotes you as writing:

"There isn't a single interesting software written in ISO C."
Sure I said that. And I go on saying that.

You haven't got any example of any important software in ISO C.
"All people with an interest in language development, software
development are gone."
I was speaking about THIS GROUP you liar. Not about C. But you
take quotes without context and there you go!
"C++ is the way, C is dead, go away."
I was saying that the attitudes of the regulars leads to that
You took out the quote of its context, as the other one
above. That is why you do not put the URLs to those
quotes.
"Why KEEP this OLD interfaces that have proven wrong over
decades? strncpy, gets, asctime, trigraphs, all that CRUFT?"
Yes, Why keep them?

[snip rest of misquotes]

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 4 '08 #52

P: n/a
s0****@gmail.com wrote:
On Aug 4, 9:36 am, Eric Sosman <Eric.Sos...@sun.comwrote:
>jacob navia wrote:
>>They are not written in 'regulars C'
o no network
Right. It's the domain of other standards, not of a programming
language standard.

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.
>>o no graphics
Right. It's the domain of other standards (and less formal quasi-
standards), not of a programming language standard.

Java supports graphics, Python supports graphics, others probably
support graphics.
>>o no GUI
You're repeating yourself.

GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.
>>o no directories
Right. It's the domain of other standards, not of a programming
language standard.

Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.

<snip>

So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."

Sebastian
Exactly. And those things ARE supported in C. Not in ISO C, but in most
implementations of the languages there are libraries that fill those
gaps.

The regulars however would like to strip the language of all
practical significance.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 4 '08 #53

P: n/a
s0****@gmail.com wrote:
On Aug 4, 9:36 am, Eric Sosman <Eric.Sos...@sun.comwrote:
>jacob navia wrote:
They are not written in 'regulars C'
o no network

Right. It's the domain of other standards, not of a programming
language standard.

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.
What you chose perhaps to overlook is that one of the real advantages of
ISO C is it's easy implementability (leaving aside for the moment the
tragedy of C99 which was perhaps more a result of implementor
pragmatism than any technical difficulty) on a very wide range of
systems from the PICs to supercomputers. Even hosted implementations of
C are much more widespread than nearly any other language. This is a
side effect of the Committee keeping the standardised features to those
with existing implementations and in common use.

There is no *need* to bring in networking within C, because one of the
most popular networking API, the Berkeley sockets (and it's WinSock
Windows imitation), is written in C and more easily accessible from C
than in those other languages that you mention (whose primitives in
most cases are implemented on top of the BSD API anyway.)

<snip>
Java supports graphics, Python supports graphics, others probably
support graphics.
Are you saying that graphics is impossible in C. Note that GTK+, X
Windows, and earlier versions of Windows GDI are all done in C. The
language Standard doesn't include graphics, but again, it can be easily
done with any of the many toolkits and APIs.
o no GUI

You're repeating yourself.

GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.
And you can use GTK+ from C. There is also the Win32 API and Xlib for
the adventerous.
o no directories

Right. It's the domain of other standards, not of a programming
language standard.

Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.
Personally, I wouldn't mind directory support being added to C1x, but in
any case I suspect that the POSIX directory APIs are available on all
the systems that the above languages are themselves available on.
<snip>

So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."
No. You yourself admit above that those things need not be all included
in a single all encompassing document. And you're perfectly right. All
those things have either formal or de facto standards already and all
are easily accessible from C. Indeed most of them are *implemented* in
C.

Aug 4 '08 #54

P: n/a
s0****@gmail.com writes:
On Aug 4, 9:36 am, Eric Sosman <Eric.Sos...@sun.comwrote:
>jacob navia wrote:
They are not written in 'regulars C'
o no network

Right. It's the domain of other standards, not of a programming
language standard.

Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.
This is drifting off-topic, but unless I am looking at the wrong
standard C# (to take one example) does not have networking. As one
would expect it is an extra library that provides it. C# plus .NET
would be better compared to C + POSIX. In that sense C has networking
exactly like C# has networking -- via another specified interface
*outside* the language.

The trouble with cross-language discussions in comp.lang.X is the lack
of experts about Y and Z who will corrects the myths that get posted
about the other languages. (I am not setting myself up as C# expert,
by the way, I just happen to have the document to hand.)

--
Ben.
Aug 4 '08 #55

P: n/a
jacob navia <ja***@nospam.comwrites:
Eric Sosman wrote:
[Eric Sosman quoting jacob navia:]
> "Why KEEP this OLD interfaces that have proven wrong over
decades? strncpy, gets, asctime, trigraphs, all that CRUFT?"

Yes, Why keep them?
[...]

If that's a serious question, I'll be glad to answer it for you.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 4 '08 #56

P: n/a
Eric Sosman <Er*********@sun.comwrites:
jacob navia wrote:
>They are not written in 'regulars C'
o no network

Right. It's the domain of other standards, not of a programming
language standard.
>o no graphics

Right. It's the domain of other standards (and less formal quasi-
standards), not of a programming language standard.
>o no GUI

You're repeating yourself.
>o no directories

Right. It's the domain of other standards, not of a programming
language standard.
>o no parallelism

Right. It's the domain of other standards, which some experts
consider premature: The state of the art, they say, is insufficiently
advanced to warrant standardization. In any event, it's not an
appropriate matter for a programming language standard. (And before
somebody hollers "Java," read the serious and sometimes virulent
criticisms that have been leveled at its attempts to parallelize.)
>o no threads

You're repeating yourself.
[snip]

Eric, I think you're overstating the case. The listed features aren't
part of the C language standard, and IMHO most or all of them don't
need to be. But there are plenty of *other* languages that provide
such things as built-in features. (Ada has built-in multitasking;
Perl has just about everything, though much of it is in the form of
libraries.)

I see no fundamental reason why threads, for example, *shouldn't* be
part of a language standard, depending on the intended scope of the
language. It just isn't part of the C language standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 4 '08 #57

P: n/a
jacob navia <ja***@nospam.comwrites:
[...]
Exactly. And those things ARE supported in C. Not in ISO C, but in most
implementations of the languages there are libraries that fill those
gaps.
Right.
The regulars however would like to strip the language of all
practical significance.
No, we would not.

After all the years you've been reading and posting to this
newsgroup, you still don't understand this simple point.

All this stuff (GUIs, networking, threads, directories, etc.) can be
done in C by the use of add-on libraries outside the ISO C standard.
That's great. The standard itself specifically permits extensions
provided in the form of additional library functions. One of
C's greatest strengths is its ability to support these kinds of
extensions, and to allow *non-portable* programming when it's needed.

There's nothing wrong with additional libraries. Without them,
C would not be nearly as useful as it actually is.

You see? We're in agreement. How did manage not to notice that?

And yes, I disagree with those who say that code that uses
non-standard extensions is "not C".

But *there are other newsgroups* in which the details of those
non-standard libraries can be discussed. This newsgroup, by the
consensus of most of the participants (remember, we had a survey
less than a year ago), is for discussion of the standard C language,
which is more than enough to keep us busy indefinitely. And if you
think that questions about how to declare main() or what's wrong
with ``i=i++'' are the only things within that scope, that's just
a failure of your imagination and powers of observation.

If you want to talk about features provided by POSIX, go to
comp.unix.programmer. If you want to talk about features provided
by lcc-win, go to comp.compilers.lcc. If you want to push for new
features in the C standard, go to comp.std.c. If you want to talk
about the C language itself, this is the right place.

If I point out that something is off-topic, I'm not trying to limit
the scope of C, just of this newsgroup. ISO C is a big subject,
and I want to have a place where I can discuss it.

And somehow you'll manage yet again to fail to understand this.
I'm almost curious to see how you do it this time.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 4 '08 #58

P: n/a
jacob navia wrote:
[...]
I was speaking about THIS GROUP you liar. [...]
<off-topic>

Jacob, you can disagree with me and I with you, and that's
all right. You can argue for your positions and against mine,
and that's all right, too. You can advance your opinions and
assail mine, even vehemently, and that's still all right.

But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.

Be ashamed. And stop it.

</off-topic>

--
Er*********@sun.com
Aug 4 '08 #59

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>which is more than enough to keep us busy indefinitely. And if you
think that questions about how to declare main() or what's wrong
with ``i=i++'' are the only things within that scope, that's just
a failure of your imagination and powers of observation.
You are outrageously misrepresenting Jacob's (and others, including
myself) position. We deman an apology. We all know what a heinous
crime it is in CLC-land to misrepresent what someone says (and we know
how seriously folks here take this!).

Jacob's and my position (and that of many others) is that the list below
represents the totality of CLC's usefulness (as CLC is at present):

1) How to declare main()
2) What's wrong with `i=i++'
3) Why you should not cast the return value of malloc()

You do us a grevious disservice by not including that last, all
important, element from the list.

Aug 4 '08 #60

P: n/a
Keith Thompson wrote:
Eric Sosman <Er*********@sun.comwrites:
>jacob navia wrote:
[ ... ]
>>o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads

Right. It's the domain of other standards, [ ... ]
[ ... ] In any event, it's not an appropriate matter for a
programming language standard.
[ ... ]
Eric, I think you're overstating the case. The listed features aren't
part of the C language standard, and IMHO most or all of them don't
need to be. [ ... ]
That's exactly what many people fail to understand. I admit that it *is*
tempting to wish that one language/framework had support for most of
the typical tasks (and as you note, many languages like Python, Java,
Perl and others do implement this philosophy), but Standard C isn't the
right choice.

C's future lies in areas where ease of implementation, and efficiency
matter. Burdening C with innumerable features will be catastrophic for
the language, since it will simply mean that such a Standard will be
ignored outright by just about every implementor, except perhaps jacob
(and even he, I doubt, will be able to implement such a "super" C,
given that he is yet to fully implement the current language). Why
would they want to re-implement things that either they or someone else
has already done, and why would WG14 want to standardise functionality
that is either already standardised or is not suitable for
standardisation? Besides where is WG14 going to get the resources to
accomplish such a task?
But there are plenty of *other* languages that provide
such things as built-in features. (Ada has built-in multitasking;
Perl has just about everything, though much of it is in the form of
libraries.)

I see no fundamental reason why threads, for example, *shouldn't* be
part of a language standard, depending on the intended scope of the
language. It just isn't part of the C language standard.
I admit that it's tempting to wish that one well known language/tool had
all that you could desire, but not all languages are (or should) going
to go down that path.

Aug 4 '08 #61

P: n/a
jacob navia said:

<snip>
They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually :-)
You have a short memory. Kaz already explained why it would be
counter-productive for ISO to add these features to the C language, less
than a month ago, in <20****************@gmail.com>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 4 '08 #62

P: n/a
On 4 Aug 2008 at 14:44, jacob navia wrote:
Eric Sosman wrote:
> You're repeating yourself from many earlier threads. You've
told us more than once that C is a dead language,

You are lying, as always
>that C's lack of
features (both those mentioned above and others you've promoted)
have rendered it obsolete,

same lie
>that nobody uses C any more, ...

same lie
This is the way with Sossman, he's a Jeckell-and-Hyde character.
Sometimes he's funny and good-natured and provides useful information
and interesting historical anecdotes; other times, he behaves just like
Heathfield.

Aug 4 '08 #63

P: n/a
On 4 Aug 2008 at 14:06, jacob navia wrote:
They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually :-)
The thing that always amuses me is that all the regulars drool over K&R2
and recommend it to newbies... presumably they all tear out Chapter 8 of
any copy they own, seeing as it's "non-portable, not standard, can't
discuss it" by their definitions. Oh, and it casts the return value of
malloc(), too - the most famous clc shibboleth.

Aug 4 '08 #64

P: n/a
On 4 Aug 2008 at 15:49, jacob navia wrote:
Eric Sosman wrote:
> "There isn't a single interesting software written in ISO C."

Sure I said that. And I go on saying that.

You haven't got any example of any important software in ISO C.
Come now, are you discounting CBFalconer's brilliant ggets function? :)

Aug 4 '08 #65

P: n/a
On 4 Aug 2008 at 17:19, Eric Sosman wrote:
But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.

Be ashamed. And stop it.
An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.

Aug 4 '08 #66

P: n/a
On 4 Aug 2008 at 17:08, Keith Thompson wrote:
This newsgroup, by the consensus of most of the participants
(remember, we had a survey less than a year ago), is for discussion of
the standard C language
This is misleading. You mean "most of the participants in the survey",
not "most of the participants in the newsgroup". The participants in the
survey were a self-selecting group of those who care deeply enough about
topicality to bother participating in a stupid and rigged survey about
it.

Truth is, clc is not moderated and has no charter. In those
circumstances what is discussed here is whatever is discussed here - de
facto.

Aug 4 '08 #67

P: n/a
On Aug 4, 11:09 am, santosh <santosh....@gmail.comwrote:
s0s...@gmail.com wrote:
On Aug 4, 9:36 am, Eric Sosman <Eric.Sos...@sun.comwrote:
jacob navia wrote:
They are not written in 'regulars C'
o no network
Right. It's the domain of other standards, not of a programming
language standard.
Java supports networking, Python supports networking, Perl supports
networking, Ruby supports networking, C# supports networking, many
others support networking.

What you chose perhaps to overlook is that one of the real advantages of
ISO C is it's easy implementability (leaving aside for the moment the
tragedy of C99 which was perhaps more a result of implementor
pragmatism than any technical difficulty) on a very wide range of
systems from the PICs to supercomputers. Even hosted implementations of
C are much more widespread than nearly any other language. This is a
side effect of the Committee keeping the standardised features to those
with existing implementations and in common use.

There is no *need* to bring in networking within C, because one of the
most popular networking API, the Berkeley sockets (and it's WinSock
Windows imitation), is written in C and more easily accessible from C
than in those other languages that you mention (whose primitives in
most cases are implemented on top of the BSD API anyway.)
That seems reasonable; I agree. I just don't think they're not the
"domain of a programming language standard," only because they're not
in C's standard. Although on the accessibility matter, I don't think
this is so. It's true that most popular OSs support their APIs in C,
and with C you get direct access to them (unlike in Python, for
example, where you get the functionality through a module that's
actually written in C). But if you're going to port to another OS, you
need to depend on a specific OS's API or develop a portable framework
for your app alone (unlike in the above mentioned languages, where
even though you get most of the functionality through a lower-level
and less accessible module, you get the same interface in every
supported OS). Anyway, I do think it's worth the advantages you
mentioned in the first paragraph.
<snip>
Java supports graphics, Python supports graphics, others probably
support graphics.

Are you saying that graphics is impossible in C. Note that GTK+, X
Windows, and earlier versions of Windows GDI are all done in C. The
language Standard doesn't include graphics, but again, it can be easily
done with any of the many toolkits and APIs.
o no GUI
You're repeating yourself.
GUIs are not the same as graphics, if that's what you meant. Anyway,
Java supports GUIs, Python supports GUIs, others probably support
GUIs.

And you can use GTK+ from C. There is also the Win32 API and Xlib for
the adventerous.
o no directories
Right. It's the domain of other standards, not of a programming
language standard.
Java supports directory operations, Python supports directory
operations, Perl supports directory operations, C# supports directory
operations, Ruby supports directory operations, many others support
directory operations.

Personally, I wouldn't mind directory support being added to C1x, but in
any case I suspect that the POSIX directory APIs are available on all
the systems that the above languages are themselves available on.
<snip>
So, you see, many people (perhaps most people) do think those things
should be part of a programming language's standard (I mean "standard"
in a general sense, not necessarily a document like C's standard), and
some of them have worked hard on them. They're just not what you think
should be "a programming language standard."

No. You yourself admit above that those things need not be all included
in a single all encompassing document. And you're perfectly right. All
those things have either formal or de facto standards already and all
are easily accessible from C. Indeed most of them are *implemented* in
C.
In essence I was just trying to point out that those things /can/ be
the domain of a programming language. But I agree that most of them
would be inconvenient or unnecessary to standarize in C, for the exact
reasons you pointed out.

Sebastian

Aug 4 '08 #68

P: n/a
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 4 Aug 2008 at 17:19, Eric Sosman wrote:
> But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.

Be ashamed. And stop it.

An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.
Funny how that works, isn't it? Double standards and all...

Aug 4 '08 #69

P: n/a
jacob navia wrote:
>
.... snip ...
>
They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually :-)
Now you are getting the idea. You can write conforming code to do
those things, but they don't exist in a purely standard C program.
I trust this means your posts will be closer to topical in future.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Aug 4 '08 #70

P: n/a
CBFalconer <cb********@yahoo.comwrites:
jacob navia wrote:
>>
... snip ...
>>
They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually :-)

Now you are getting the idea. You can write conforming code to do
those things, but they don't exist in a purely standard C program.
I trust this means your posts will be closer to topical in future.
That is of course total and utter nonsense.

The C standard does not define a function called ChuckIsASelfImportantBlowhard()
either but that doesn't mean I can't write one in standard C. My program
is still written in standard C.

You probably meant to say they do not exist in the C standard and not
that they dont exist in a purely standard C program.
Aug 4 '08 #71

P: n/a
On Mon, 04 Aug 2008 18:02:51 +0000, Antoninus Twink wrote:
On 4 Aug 2008 at 17:19, Eric Sosman wrote:
> But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.

Be ashamed. And stop it.

An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.
Twink you know nothing about Navia. Like you he wants to ruin this group.
He could care less about C, only his lccwin32. This IS NOT C. He refuses
to conform to the ISO Standard. He attacks people who report
conformance bugs. He is a paranoid liar. Navia has caused division in this
group. Navia is a disgrace to C programming.

Regards,
Coffee Pot
Aug 4 '08 #72

P: n/a
On Tue, 05 Aug 2008 00:36:00 +0200, Richard wrote:
CBFalconer <cb********@yahoo.comwrites:
>jacob navia wrote:
>>They are not written in 'regulars C'
o no network
o no graphics
o no GUI
o no directories
o no parallelism
o no threads
o no nothing actually :-)

Now you are getting the idea. You can write conforming code to do
those things, but they don't exist in a purely standard C program. I
trust this means your posts will be closer to topical in future.

That is of course total and utter nonsense.

The C standard does not define a function called
ChuckIsASelfImportantBlowhard() either but that doesn't mean I can't
write one in standard C.
Sure, it would be similar to
int f(void) { return 0; }
which of course can be included in and called from strictly conforming
programs. Now, can you write functions for anything jacob navia mentioned
in standard C, other than "nothing"?
Aug 4 '08 #73

P: n/a
In article <pa****************************@nospam.com>,
Coffee Pot <no****@nospam.comwrote:
>On Mon, 04 Aug 2008 18:02:51 +0000, Antoninus Twink wrote:
>On 4 Aug 2008 at 17:19, Eric Sosman wrote:
>> But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.

Be ashamed. And stop it.

An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.

Twink you know nothing about Navia. Like you he wants to ruin this group.
He could care less about C, only his lccwin32. This IS NOT C. He refuses
to conform to the ISO Standard. He attacks people who report
conformance bugs. He is a paranoid liar. Navia has caused division in this
group. Navia is a disgrace to C programming.

Regards,
Coffee Pot
Let's see now. Whose sock puppet do ya suppose Mr. Pot is?
Who among the regs has really gone to pot this time?

My money is on my hero Keith, but other possibilities exist.

Aug 5 '08 #74

P: n/a
On 4 Aug, 23:42, Coffee Pot <nos...@nospam.comwrote:
On Mon, 04 Aug 2008 18:02:51 +0000, Antoninus Twink wrote:
On *4 Aug 2008 at 17:19, Eric Sosman wrote:
* * *But when you accuse people of lying, as you've done twice
to me in this thread alone, that is not all right. *That is an
accusation of dishonesty and bad faith, and assault not on ideas
but on character.
* * *Be ashamed. *And stop it.
An interesting sensitivity for one who's systematically tried to destroy
the character and reputation of Jacob Navia over the past few years,
along with Heathfield, Mackintyre, "Old Wolf" and the rest of your cabal
of bullies, liars and cowards.

Twink you know nothing about Navia. Like you he wants to ruin this group.
I don't think this is true. I think Jacob Navia cares a lot about C.
But many people disagree with his opinions about the direction C
should go in the future. They also disagree about the suitable topics
that should be discussed on clc. I don't think Jacob has any *intent*
to damage or destroy clc.
He could care less about C, only his lccwin32.
untrue, I believe. But then we are trying to mind read.
This IS NOT C. He refuses to conform to the ISO Standard.
well he claims to be trying to conform to C99. he just
doesn't think "a few extra bits in the standard headers"
is really important. he's wrong but then many other
implementations have trodden this road.
He attacks people who report conformance bugs.
true
He is a paranoid liar.
probably paranoid, probably over-excitable, often mistaken

Navia has caused division in this group.
it takes 2 to tango

Navia is a disgrace to C programming.
bollocks
--
Nick Keighley

C++: "an octopus made by nailing extra legs onto a dog"
-- Steve Taylor, 1998
Aug 5 '08 #75

P: n/a
Nick Keighley wrote:
Coffee Pot wrote:
[what one would expect from a neophyte troll]
bollocks
And IMO, that should've been your only response, if you had to respond
at all.

Aug 5 '08 #76

P: n/a
santosh wrote:
Nick Keighley wrote:
>Coffee Pot wrote:

[what one would expect from a neophyte troll]
>bollocks

And IMO, that should've been your only response, if you had to
respond at all.
When you respond, you should mark the areas where you snip
material. I consider the unmarked snippage from Mr. Keighleys
response to be very reasonable.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Aug 5 '08 #77

P: n/a
On 4 Aug 2008 at 22:42, Coffee Pot wrote:
Twink you know nothing about Navia. Like you he wants to ruin this group.
He could care less about C, only his lccwin32. This IS NOT C. He refuses
to conform to the ISO Standard. He attacks people who report
conformance bugs. He is a paranoid liar. Navia has caused division in this
group. Navia is a disgrace to C programming.
OK, Heathfield, whatever you say.

Aug 5 '08 #78

P: n/a
Keith Thompson <ks***@mib.orgwrote:
>
For a structure all of whose members are of the same type, a compiler
is *allowed* to insert padding between the members, but I can think of
no good reason for it to do so (though it may well have a reason to
insert padding at the end).
Stricter than required alignment may allow more efficient access. I know
of at least one compiler that aligns all structure members to at least a
4 byte boundary.
--
Larry Jones

Wheeee. -- Calvin
Aug 13 '08 #79

P: n/a
la************@siemens.com writes:
Keith Thompson <ks***@mib.orgwrote:
>For a structure all of whose members are of the same type, a compiler
is *allowed* to insert padding between the members, but I can think of
no good reason for it to do so (though it may well have a reason to
insert padding at the end).

Stricter than required alignment may allow more efficient access. I know
of at least one compiler that aligns all structure members to at least a
4 byte boundary.
Even for members smaller than 4 bytes?

Of course it can't do the same thing for array elements, so this:
struct { char c0, c1, c2, c3; };
would have a different representation than char[4].

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 13 '08 #80

P: n/a
Keith Thompson <ks***@mib.orgwrote:
la************@siemens.com writes:
Stricter than required alignment may allow more efficient access. I know
of at least one compiler that aligns all structure members to at least a
4 byte boundary.

Even for members smaller than 4 bytes?
Yes, *particularly* members smaller than 4 bytes. (Larger members are
usually aligned to larger boundary.) It also aligns regular variables
the same way.
Of course it can't do the same thing for array elements, so this:
struct { char c0, c1, c2, c3; };
would have a different representation than char[4].
Exactly.
--
Larry Jones

Geez, I gotta have a REASON for everything? -- Calvin
Aug 14 '08 #81

80 Replies

This discussion thread is closed

Replies have been disabled for this discussion.