469,315 Members | 1,802 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,315 developers. It's quick & easy.

UNIX, C, Perl

Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C? Examples:
Network and internet access, access to UNIX interprocess controls and
communication, locale determination, EBCDIC/ASCII discrimination, etc.

Almost all of these are easy in Perl. Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these? Isn't
anyone working on this problem? or is it all being left for proprietary
systems?
Sep 2 '08
223 5903
Ben Bacarisse <be********@bsb.me.ukwrote:
This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.
It's an elephant, all right: it's strong, it's intelligent, and if you
want to handle it professionally you'd better know what you're doing.
But if you want to go into the jungle, there's nothing better, not even
a military-designed vehicle.

Richard
Sep 5 '08 #101
"Bartc" <bc@freeuk.comwrote:
"James Kuyper" <ja*********@verizon.netwrote in message
Can you see the difference between my re-write and what he actually said?
Do you understand that your statements apply only to my rewrite, and not
to the original? I only changed a few words, but the result is that it
converts a legitimate point of view (which I don't fully share) into a
statement that could only be made by an idiot.

It's not too hard to read between the lines of the original. Clearly he has
the skills to put across what he thinks without making any hard and fast
commitments.
It's also not hard to read between the lines of those clamouring for
wholesale changes to the Standard, and seeing there that they're
compensating for their small reproductive members and the lack of love
they got from their mothers. But that would be equally unwarranted as
your jumping to conclusions about Doug Gwyn.
Tact and diplomacy I think it's called.
No, it's called post-modernism. It works in literary criticism, but not
in computer science, where we're supposed to get things done instead of
just stating our opinions again and again.

Richard
Sep 5 '08 #102
jacob navia <ja***@nospam.comwrote:
la************@siemens.com wrote:
jacob navia <ja***@nospam.comwrote:
I need 10 thousand euros (15 000 US$) to buy the AFNOR
(French ISO organization) to present my proposal after
I got sponsored by some company.
That's not necessary -- committee meetings are open to the public.

If the public can afford the trip, obviously.

I proposed that they set up a web site or similar place
where we could propose things (since they do not bother
to read comp.std.c as I heard in that group in the last
discussion)
Whereas I propose that, since you get money from your C implementation
(however much or little - it really does not matter, it's a point of
principle, not centimes), you stop freeloading already and shell out for
the tools of your trade. It's easy to demand of others that they do your
will, but if you want to prosper by those demands, that's no longer
called arrogance, it's called slave-driving, and it's as illegal in
France as anywhere else. _You_ want this, _you_ use it for monetary
gain, _you_ stump up the ante. Nobody else.
No answer.
I wait without bating my breath.

Richard
Sep 5 '08 #103
Richard Bos wrote:
It's also not hard to read between the lines of those clamouring for
wholesale changes to the Standard, and seeing there that they're
compensating for their small reproductive members and the lack of love
they got from their mothers.
That was funny bos. Just keep the good work.

:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Sep 5 '08 #104
On Sep 4, 8:12*pm, Richard Heathfield <r...@see.sig.invalidwrote:

<snip>
... [C is] also a really-nice-to-have for reading technical docs, since
they are often illustrated with C fragments (cases in point:
Aho-Sethi-Ullman (the Dragon Book), Petzold (Programming Windows), Knuth
(TAOCP)).
TAOCP uses C?

<snip>

--
Nick Keighley
Sep 5 '08 #105
On Sep 4, 6:32*pm, Antoninus Twink <nos...@nospam.invalidwrote:
On *4 Sep 2008 at 17:14, jacob navia wrote:
Antoninus Twink wrote:
And before you know it, you've got a horrible mess...
If you do not know how to stop!

Sure... unfortunately the main historical example is Bjarne Stroustoup,
who definitely didn't know how to stop!
what about Alogol-68!
Personally I see nothing wrong with writing
C-with-the-odd-nice-C++-feature and compiling it with a C++ compiler.
definitly not Jacob's view

--
Nick Keighley

Sep 5 '08 #106
Nick Keighley said:
On Sep 4, 8:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:

<snip>
>... [C is] also a really-nice-to-have for reading technical docs, since
they are often illustrated with C fragments (cases in point:
Aho-Sethi-Ullman (the Dragon Book), Petzold (Programming Windows), Knuth
(TAOCP)).

TAOCP uses C?
Yes, albeit rarely. (That's how I got my cheque - by spotting a bug in C
code.)

--
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
Sep 5 '08 #107
On Fri, 2008-09-05 at 05:25 -0700, Nick Keighley wrote:
On Sep 4, 8:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:

<snip>
... [C is] also a really-nice-to-have for reading technical docs, since
they are often illustrated with C fragments (cases in point:
Aho-Sethi-Ullman (the Dragon Book), Petzold (Programming Windows), Knuth
(TAOCP)).

TAOCP uses C?

<snip>
I think he did once in the chapter introducing MIX, when explaining
why he chose to make up a language instead of using one. (IIRC, he
said something like "There's a good argument for using C, but..."
and proceeded to say something that sounded reasonable the last time
I read it.)

--
Andrew Poelstra <ap*******@wpsoftware.com>
To email me, change .net to .com in the above address.

Sep 5 '08 #108
On Sep 4, 8:47*pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
"Richard Heathfield" <r...@see.sig.invalidwrote in message news
Malcolm McLean said:
I trust you are now joining the campaign for 64 bit ints.
Why? They're legal already. In any case, one day they will be too small..

Think the campaign for real ale rather than the campaign to free the weed..

I don't think we will actually run out of integers with 64 bits. With 32
bits yes, you can't quite give one to everyone in the world. But 64 bits
aren't going to have that problem for a long time yet.
so why did IPv6 use 128 bits?

--
Nick Keighley
Sep 5 '08 #109
jacob navia <ja***@nospam.comwrote:
Richard Bos wrote:
It's also not hard to read between the lines of those clamouring for
wholesale changes to the Standard, and seeing there that they're
compensating for their small reproductive members and the lack of love
they got from their mothers.

That was funny bos. Just keep the good work.
My name, unlike yours, is spelled with an initial capital. Please have
the decency.

Richard
Sep 5 '08 #110
On Sep 4, 10:45 pm, jacob navia <ja...@nospam.comwrote:
Lassie wrote:
"jacob navia" <ja...@nospam.comschreef in bericht
news:g9**********@aioe.org...
Operator overloading is not an objective per se. It is a means of making
libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:
data[2]
to acces the third element of a list/array/other
I really would not implement operator[] for a linked list. operator[]
has the semantics of being a random access operator. A linked list is
not a data stucture one would use when random access is needed and
operator[] would have to loop to the correct index every time which is
suddenly invisible from the programmer.

Well, if you are using a list and you need the nth element you will
have to start at the start and go to the nth. That is because of the
data structure used.
And if you need the three elements 'n', 'n+1' and 'n+2', do you search
or each of them from the start of the list (what operator[] would have
to do), or do you only write a loop to the first one, and access the
other two by following a link from the element you currently have?
>
When you see that you are accessing random elements you change your
declaration to a flexible array and you have more efficient random
access. And you do not need to change the code.
And when you find that you only access successive elements, you drop
the library that foolishly uses operator[] to access elements in a
linked list.
You would have to change the code, but you get a several orders of
magnitude performance gain in return.
>
--
jacob navia
Bart v Ingen Schenau
Sep 5 '08 #111

"Bart van Ingen Schenau" <Ba********************@ict.nlwrote in message
news:aa**********************************@d45g2000 hsc.googlegroups.com...
On Sep 4, 10:45 pm, jacob navia <ja...@nospam.comwrote:
>Lassie wrote:
I really would not implement operator[] for a linked list. operator[]
>Well, if you are using a list and you need the nth element you will
have to start at the start and go to the nth. That is because of the
data structure used.

And if you need the three elements 'n', 'n+1' and 'n+2', do you search
or each of them from the start of the list (what operator[] would have
to do), or do you only write a loop to the first one, and access the
other two by following a link from the element you currently have?
And when you find that you only access successive elements, you drop
the library that foolishly uses operator[] to access elements in a
linked list.
I created a scripting language once with arrays implemented as a linked list
(actually, as a block of 8 elements).

This remembered the last visited element, so [] indexing was reasonably
quick provided the application acccessed the array more or less
sequentially.

For C which is used to array accesses taking a couple of machine
instructions, even doing this would be quite a performance hit. Memory
management would be far easier though.

But, if the alternative was to use a higher-level (interpreted) language for
the extra
flexibility, then C + linked-list arrays + []indexing could be viable.

--
Bartc

Sep 5 '08 #112
jacob navia <ja***@nospam.comwrote:
la************@siemens.com wrote:

That's not necessary -- committee meetings are open to the public.

If the public can afford the trip, obviously.
Obviously. Like I said, however, the committee does try to meet in
various locations to make it easier for people to attend, but we're
limited to locations where someone is willing to host us (which requires
a not insubstatial expense). As you can see from the committee's web
site, we've been pretty successful in the past:

<http://www.open-std.org/jtc1/sc22/wg14/www/meetings>
I proposed that they set up a web site or similar place
where we could propose things (since they do not bother
to read comp.std.c as I heard in that group in the last
discussion)

No answer.
That's because you proposed it in comp.std.c, which you already know
most committee members don't read! And the reason we don't do it is the
same as the reason most members don't read comp.std.c -- if we did, we
would be inundated with half-baked suggestions from dilettantes who
would expect us to spend time and effort seriously considering their
suggestions and providing detailed feedback on their merits and
demerits. We simply don't have the resources to do that. Insisting
that people expend a certain amount of time and money to actually attend
a meeting weeds out people who aren't serious and allows face-to-face
discussion which is far less rancorous and much more productive than
on-line discussions. It also increases the committee's resources to
help offset the increased work load.
Do you know where the next meeting is?
Next week in San Jose, CA, USA. The meeting schedule (as far as is
known) is posted on the above page. Meetings for next year have not
been finalized yet, but there are outstanding or pending invitations to
meet in Toronto, CA in April and Santa Cruz, CA, USA in October
(according to the minutes from the last meeting, which are also posted
on the web site).
--
Larry Jones

I don't NEED to compromise my principles, because they don't have
the slightest bearing on what happens to me anyway. -- Calvin
Sep 5 '08 #113
Richard Heathfield <rj*@see.sig.invalidwrites:
jacob navia said:
>Ben Bacarisse wrote:

<snip>
>>Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers.

I don't think you're in a position to insist, are you? Not even Microsoft
is in a position to insist on a change to the C language. In fact, not
even Dennis Ritchie is in that position.

It is sometimes difficult to remember that what one person sees as an
obvious improvement, another person sees as a hideous wart. Putting
oneself in another person's position is a useful and informative
intellectual exercise. Think up a change to C that you would really NOT
like to see in the language, and you should get the idea.

By the way, I'm not particularly against the idea of introducing operator
overloading into C (although many people probably are). But
politicking
I would sooner boil my nuts in a vat of sun flower oil than agree that
operator overloading in C is a good idea.
about it in comp.lang.c isn't going to get you anywhere. It's the ISO
people, not us, that you have to convince, and they are going to take a
lot of convincing after the drubbing they took over C99.
--
Sep 5 '08 #114

"Nick Keighley" <ni******************@hotmail.comwrote in message
>
>>I don't think we will actually run out of integers with 64 bits. With 32
bits yes, you can't quite give one to everyone in the world. But 64 bits
aren't going to have that problem for a long time yet.
>so why did IPv6 use 128 bits?
maybe it wasn't well designed. I can't imagine they had more than 2^64 bytes
of memory installed.
OTOH it might have been a signals processing device. These don't really use
integers in the normal C sense of the term. The integers are representations
of real valued signals, and highly specialised.
--
Nick Keighley

Sep 6 '08 #115
Richard wrote:
I would sooner boil my nuts in a vat of sun flower oil than agree that
operator overloading in C is a good idea.
Should I send you olive oil maybe?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Sep 6 '08 #116
On Sep 5, 1:45*pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On Sep 4, 8:47*pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
"Richard Heathfield" <r...@see.sig.invalidwrote in message news
Malcolm McLean said:
>I trust you are now joining the campaign for 64 bit ints.
Why? They're legal already. In any case, one day they will be too small.
Think the campaign for real ale rather than the campaign to free the weed.
I don't think we will actually run out of integers with 64 bits. With 32
bits yes, you can't quite give one to everyone in the world. But 64 bits
aren't going to have that problem for a long time yet.

so why did IPv6 use 128 bits?
That's as in TCP/IP the internet protocol. "old" IP (v4) used 32-bit
addresses (usually shown in dotted notation eg. 192.12.0.1). Because
the
address space is sparsely used they started to run out of addresses.
Telephone numbers suffer from the same problem. Hence London (UK) got
renumbered *twice* in recent years.

One fix for the IP address problem was a "new" IP standard, v6 (no-one
knows what happened to v5 :-) ). Initially 64 bits was proposed.
According
to their model this would allow everyone on the planet to have an IP
address.
But looking the then rate of technological progress it was realised
they should allow multiple IP addresses per person. This has now
happened;
my home isn't particualrly technology dense but I have several
ip addresses. Hence they went for 128 bits which is expected to last
for
quite a while. So there is already an application that finds 64 bits
inadequate without the need for 16 exa-bytes of memory.

--
Nick Keighley
Sep 6 '08 #117
Nick Keighley wrote:
On Sep 5, 1:45 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
>so why did IPv6 use 128 bits?
....
my home isn't particualrly technology dense but I have several
ip addresses. Hence they went for 128 bits which is expected to last
for
quite a while. So there is already an application that finds 64 bits
inadequate without the need for 16 exa-bytes of memory.
This is little to do with needing 128-bit integers. This application needs a
16-byte identifier for the same sorts of reasons that credit cards mostly
use 16-digit numbers.

And it's unlikely that IP addresses need ALU support for +, -, * and /
operations. Possibly logical operations but this can easily be achieved on a
64-bit CPU without having a 128-bit word length.

--
Bartc

Sep 6 '08 #118
Nick Keighley said:

<snip>
But looking the then rate of technological progress it was realised
they should allow multiple IP addresses per person. This has now
happened;
my home isn't particualrly technology dense but I have several
ip addresses. Hence they went for 128 bits which is expected to last
for
quite a while. So there is already an application that finds 64 bits
inadequate without the need for 16 exa-bytes of memory.
Furthermore, cryptographically-inclined programmers will happily take the
biggest ints you can give them, and then beg for still bigger ints.

--
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
Sep 6 '08 #119

"Nick Keighley" <ni******************@hotmail.comwrote in message
>Telephone numbers suffer from the same problem. Hence London (UK) got
renumbered *twice* in recent years.
I'm of the opinon that 3074457345 telephones ought to be enough for anyone,
if 64 bit integers were distributed fairly instead of being hogged by the
rich nations.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Sep 6 '08 #120
Ian Collins <ia******@hotmail.comwrites:
Richard Heathfield wrote:
>Ian Collins said:

<snip>
>>C has lost the
mindshare in hosted applications programming and there's little point in
trying to win it back.

Am I the only one who isn't particularly bothered about this? Let people
write applications in whatever language /they/ want, as long as they leave
me to write them in whatever language /I/ want. I choose C (often - not
always). If they want to use C# or F# or Eb or D minor, that's up to them
- who cares?
No me. I just use the most appropriate tool for the job.
The difference being that Heathfield often uses C when it might not be
the most appropriate tool for the job.

One must always think of maintainability and the workforce required to
perform that maintenance. The likes of RH will not always be in ones
employ.
Sep 6 '08 #121
Willem <wi****@stack.nlwrites:
jacob navia wrote:
) Richard Heathfield wrote:
)
) [snip]
)
) I asked you a question Heathfield, a question that you conveniently
) snipped away.
)
) I repeat it:
) How would *you* solve the above problem?

You're begging the question.
Richard never claimed (in this thread at least) that your
solution was bad in any way.

And here's the question *you* never answered.
The question that *is* relevant:

Why do you argue about changing C *here*, in this newsgroup ?

Because its called comp.lang.c and experienced "standard" C programmers
with an opinion reside here? Simple really. I am astonished you could
not draw that conclusion yourself.
Sep 6 '08 #122
ja*********@verizon.net writes:
jacob navia wrote:
>Willem wrote:
...
Why do you argue about changing C *here*, in this newsgroup ?

Because this group discusses the C language obviously.

I presented my ideas to the comp.std.c group, many times.

I discuss them there too.

While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.
All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".

Sep 6 '08 #123
In article <g9**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote in response to some chump:
....
>Why do you argue about changing C *here*, in this newsgroup ?


Because its called comp.lang.c and experienced "standard" C programmers
with an opinion reside here? Simple really. I am astonished you could
not draw that conclusion yourself.
It really is amazing. The problem is that this newsgroup is totally,
100%, hung-up on the idea of what C "is". As has been pointed out many
times, it is a dogmatic position not found in any other subspecies of
the computing profession. It is, of course, much more at home in a
religious context.

I know of no other comp.* newsgroup where this sort of obsession (*) exists.

(*) Obsession with things as they are and absolute paranoia about
discussing how things might be (i.e., what they could evolve into).

Sep 6 '08 #124
Richard wrote:
Willem <wi****@stack.nlwrites:
....
And here's the question *you* never answered.
The question that *is* relevant:

Why do you argue about changing C *here*, in this newsgroup ?


Because its called comp.lang.c and experienced "standard" C programmers
with an opinion reside here? Simple really. I am astonished you could
not draw that conclusion yourself.
If his arguments were intended to promote a discussion in which he
would hear differing opinions about his proposed changes to the
standard and take them into consideration when putting together his
presentation for the committee, that would make a certain amount of
sense. But we're talking about jacob navia; he's apparently incapable
of tolerating (or even reading clearly and correctly) opinions that
differ from his own. He also seems, based upon the examples we've
seen, to be incapable of putting together a proposal that's
sufficiently complete and detailed to be taken seriously by the
committee; and unwilling to take the steps needed to actually place
his proposal before them.

In any event, the original question was posed by Richard Heathfield:
... I'm just curious as to why you propose it here, since nobody here has any authority to change the language
definition (except Larry, perhaps, since he's actually a voting member of the ISO C Committee). It seems
rather pointless.
In reference to jacob's comment:
That is why I have been insisting that we adopt the operator overloading feature that would allow using the '['
and ']' notation for general containers.
The point of the matter is, "insisting" on it here won't do any good.
"insisting" on it in a discussion with committee members actually has
a chance of success, however slim that chance might be. The chances
would be better if he'd replace the word "insist" with something like
"suggest", which more accurately reflects his position in the scheme
of things. No one (except possibly the ISO secretariat) has the
authority to "insist" that the committee do anything other than what
the committee itself thinks is the best thing for it to do.

Sep 6 '08 #125
Richard wrote:
ja*********@verizon.net writes:
jacob navia wrote:
Willem wrote:
...
Why do you argue about changing C *here*, in this newsgroup ?


Because this group discusses the C language obviously.

I presented my ideas to the comp.std.c group, many times.

I discuss them there too.
While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.

All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".
But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification, and sufficiently important that they should be approved
immediately. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.

Granted, he won't get uncritical acceptance from the Committee,
either. However, at least from the committee he has some vanishingly
small chance of getting his ideas approved; something that this
newsgroup has no authority to do (and neither does comp.std.c).
Sep 6 '08 #126
ja*********@verizon.net writes:
Richard wrote:
>ja*********@verizon.net writes:
jacob navia wrote:
Willem wrote:
...
Why do you argue about changing C *here*, in this newsgroup ?
Because this group discusses the C language obviously.

I presented my ideas to the comp.std.c group, many times.

I discuss them there too.

While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.

All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".

But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification, and sufficiently important that they should be approved
immediately. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.

Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.
Sep 6 '08 #127
Richard<rg****@gmail.comwrites:
ja*********@verizon.net writes:
>Richard wrote:
>>ja*********@verizon.net writes:
<snip>
>While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal.
<snip>
>>All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".

But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification, and sufficiently important that they should be approved
immediately. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.

Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.
Odd, then, that your contribution to this mature debate was:

| I would sooner boil my nuts in a vat of sun flower oil than agree
| that operator overloading in C is a good idea.

to which Jacob simply suggested supplying an alternative oil. Why did
you not think Jacob would be receptive to a more technical critique at
the time?

--
Ben.
Sep 6 '08 #128
Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
>ja*********@verizon.net writes:
>>Richard wrote:
ja*********@verizon.net writes:
<snip>
>>While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal.
<snip>
>>>All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".

But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification, and sufficiently important that they should be approved
immediately. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.

Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.

Odd, then, that your contribution to this mature debate was:

| I would sooner boil my nuts in a vat of sun flower oil than agree
| that operator overloading in C is a good idea.

to which Jacob simply suggested supplying an alternative oil. Why did
you not think Jacob would be receptive to a more technical critique at
the time?
Its called a joke. We had discussed it before and I explained my
"practical" objections to operator overloading in any language. i
realise I am in a minority. I remember when I thought they were
"kewl". Then I had to maintain and extend poorly written code which
absolutely thrashed the use of them. It was horrific.
--
Sep 6 '08 #129
Ben Bacarisse said:

<snip>
Why did
you not think Jacob would be receptive to a more technical critique at
the time?
What makes you think Richard Riley is capable of a more technical critique?
From what I can recall of those articles of his that I read before
plonking him, he rarely posted anything even remotely to do with C, and on
the few occasions when he did he was typically wrong. He sticks to
bitching because bitching is all he knows how to do, and (unless he has
improved remarkably in recent times) he doesn't do that terribly well
either, poor chap. Perhaps we should organise a whip-round or something.

No, if you want a critique of operator overloading in C, you'll have to
look elsewhere. And unfortunately there's no point looking in my direction
for such a critique, because I kind of like the idea!

--
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
Sep 6 '08 #130
Richard wrote:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>ja*********@verizon.net writes:

Richard wrote:
ja*********@verizon.net writes:
<snip>
>>>>>While such a suggestion is on-topic in that group, it is still not the
>right place to make your proposal.
<snip>
>>>>All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".
But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification, and sufficiently important that they should be approved
immediately. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.
Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.
Odd, then, that your contribution to this mature debate was:

| I would sooner boil my nuts in a vat of sun flower oil than agree
| that operator overloading in C is a good idea.

to which Jacob simply suggested supplying an alternative oil. Why did
you not think Jacob would be receptive to a more technical critique at
the time?

Its called a joke. We had discussed it before and I explained my
"practical" objections to operator overloading in any language. i
realise I am in a minority. I remember when I thought they were
"kewl". Then I had to maintain and extend poorly written code which
absolutely thrashed the use of them. It was horrific.

*Anything* can be misused Richard, and operator overloading is no
exception.

The main application domain I see is the capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Sep 6 '08 #131
jacob navia said:

<snip>
The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);
100% agreed. (And this is *me* saying it!)

I'm trying to work out how it would work for strings. It would be great to
be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s = t + n
instead of sprintf(s, "%s%d", t, n) - but that's going to make for an
almighty clash with ordinary pointer arithmetic. Any ideas?

--
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
Sep 6 '08 #132
jacob navia <ja***@nospam.comwrites:
Richard wrote:
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>Richard<rg****@gmail.comwrites:

ja*********@verizon.net writes:

Richard wrote:
>ja*********@verizon.net writes:
<snip>
>>While such a suggestion is on-topic in that group, it is still not the
>>right place to make your proposal.
<snip>
>All may be true. But to discuss it here is easily the best thing to do
>since real programmers can dissect ideas "in the real world".
But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification, and sufficiently important that they should be approved
immediately. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.
Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.
Odd, then, that your contribution to this mature debate was:

| I would sooner boil my nuts in a vat of sun flower oil than agree
| that operator overloading in C is a good idea.

to which Jacob simply suggested supplying an alternative oil. Why did
you not think Jacob would be receptive to a more technical critique at
the time?

Its called a joke. We had discussed it before and I explained my
"practical" objections to operator overloading in any language. i
realise I am in a minority. I remember when I thought they were
"kewl". Then I had to maintain and extend poorly written code which
absolutely thrashed the use of them. It was horrific.


*Anything* can be misused Richard, and operator overloading is no
exception.

The main application domain I see is the capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);
It is. Its also easier to type

a=f(a,z) than

total=sumOfTwoCoordinates(y1,y2); /* totally made up example but try to
get the drift .. */

I know which makes more sense and is easier to read and debug. Yes, yes,
I know c.l.c regs don't debug because Kernighan once said its easier to
do it right the first time than to have to debug it later but, well,
we're not all Richard Heathfields or Chuck Falconers.
Sep 6 '08 #133
Richard Heathfield <rj*@see.sig.invalidwrites:
jacob navia said:

<snip>
>The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

100% agreed. (And this is *me* saying it!)
But little thought is put into the example here.

Yes, it is easier. Especially when below is an example of it fully
extrapolated to a function call.

But what is easier in this instance?

i=a+b;

or

struct cursorPos=moveCursorRelative(xdelta,ydelta);

Really, I have been there done that. I never found anything worse in
code than operator overloading. It *does* get mis used. You can not read
the code properly from a print out IMO. Nightmare. So, basically I am
still to be convinced.
>
I'm trying to work out how it would work for strings. It would be great to
be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s = t + n
instead of sprintf(s, "%s%d", t, n) - but that's going to make for an
almighty clash with ordinary pointer arithmetic. Any ideas?
And integer arithmetic and anything else that uses "+" when you are
reading the code .....
Sep 6 '08 #134

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:PN******************************@bt.com...
jacob navia said:

<snip>
>The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

100% agreed. (And this is *me* saying it!)

I'm trying to work out how it would work for strings. It would be great to
be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s = t + n
instead of sprintf(s, "%s%d", t, n) - but that's going to make for an
almighty clash with ordinary pointer arithmetic. Any ideas?
t + u is addition of two pointers, which has at present no meaning in C.

t + n adds an integer to a pointer, and would be a problem, but it's not
unreasonable to require a conversion, eg: t + str(n).

More difficult is how to deal with the implicit memory handling which needs
to be done:

a = b + c + d + e

You might be able to do free(a), but what about the intermediate strings?
The whole thing is very un-C-like.

--
Bartc

Sep 6 '08 #135
"Bartc" <bc@freeuk.comwrites:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:PN******************************@bt.com...
>jacob navia said:

<snip>
>>The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

100% agreed. (And this is *me* saying it!)

I'm trying to work out how it would work for strings. It would be great to
be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s = t + n
instead of sprintf(s, "%s%d", t, n) - but that's going to make for an
almighty clash with ordinary pointer arithmetic. Any ideas?

t + u is addition of two pointers, which has at present no meaning in C.

t + n adds an integer to a pointer, and would be a problem, but it's
not unreasonable to require a conversion, eg: t + str(n).

More difficult is how to deal with the implicit memory handling which
needs to be done:

a = b + c + d + e

You might be able to do free(a), but what about the intermediate
strings? The whole thing is very un-C-like.
Exactly. And it opens up entire "paradigm shifts" which would lead to a
mess. Keep C as C.
Sep 6 '08 #136
Richard Heathfield wrote:
jacob navia said:

<snip>
>The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

100% agreed. (And this is *me* saying it!)

I'm trying to work out how it would work for strings. It would be great to
be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s = t + n
instead of sprintf(s, "%s%d", t, n) - but that's going to make for an
almighty clash with ordinary pointer arithmetic. Any ideas?
1) I am not convinced that addition is the right operator for string
concatentation since if we use it for strings:
a+b != b+a
Normally we treat addition as commutative...

2) The problem with addition of pointer with integer is that this
operation is already defined and has a well defined meaning
in C. That is why lcc-win does NOT allow you to redefine it
to give it a new meaning. The reasons are many mainly:
(a) Existing code becomes ambiguous.
(b) It is impossible to address a character beyond the
start of a string...

Look Mr Heathfield, you know this by heart, and it is really not very
helpful to just play games and pose "clever" questions...

It would be *much* more helpful if you would help with the *real*
problems with this stuff...

(1) How do you overload the '[' ']' operators with multidimensional
arrays? This is not possible with C++. I think that a syntax like
(1) TYPE operator [][](TYPE table,int line,int column)
{ ... }
(2) TYPE operator [2](TYPE table,int line, column)
{ ... }

Or just the same notation as for the normal operator { ] with
more indices:
(3) TYPE operator [](TYPE table, int plane, int line, int column)

(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment

but I am not sure of this.

There are several open issues like those.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Sep 6 '08 #137
jacob navia <ja***@nospam.comwrites:
Richard Heathfield wrote:
>jacob navia said:

<snip>
>>The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

100% agreed. (And this is *me* saying it!)

I'm trying to work out how it would work for strings. It would be
great to be able to say s = t + u instead of sprintf(s, "%s%s", t,
u) and s = t + n instead of sprintf(s, "%s%d", t, n) - but that's
going to make for an almighty clash with ordinary pointer
arithmetic. Any ideas?

1) I am not convinced that addition is the right operator for string
concatentation since if we use it for strings:
a+b != b+a
Normally we treat addition as commutative...

2) The problem with addition of pointer with integer is that this
operation is already defined and has a well defined meaning
in C. That is why lcc-win does NOT allow you to redefine it
to give it a new meaning. The reasons are many mainly:
(a) Existing code becomes ambiguous.
(b) It is impossible to address a character beyond the
start of a string...

Look Mr Heathfield, you know this by heart, and it is really not very
helpful to just play games and pose "clever" questions...
Its what he does. And he likes to seed Google with names (although
wrong) too I see!
>
It would be *much* more helpful if you would help with the *real*
problems with this stuff...
No chance. He is playing "friend" to appear to the casual observer that
he doesn't in fact hate your guts. And it is quite clear to anyone who
reads this newsgroup that he does indeed hate your guts. Very
un-christian like but most god botherers I have known have had similar
tendencies.

Sep 6 '08 #138
Bartc said:
Richard Heathfield wrote:
<snip>
>>
I'm trying to work out how it would work for strings. It would be great
to be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s =
t + n instead of sprintf(s, "%s%d", t, n) - but that's going to make for
an almighty clash with ordinary pointer arithmetic. Any ideas?

t + u is addition of two pointers, which has at present no meaning in C.
Yeah, actually I thought a bit after hitting Send (always the way, ain't
it?), and it occurred to me that it /couldn't/ work for C strings, but it
could work for a new type, xstring or whatever.
t + n adds an integer to a pointer, and would be a problem, but it's not
unreasonable to require a conversion, eg: t + str(n).
But this would work:

xstring s, t;
t = "come in, number ";
s = t + 42;
s += "; your time is up.";

provided we didn't ever want to treat xstring as a pointer.
More difficult is how to deal with the implicit memory handling which
needs to be done:

a = b + c + d + e

You might be able to do free(a),
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.
but what about the intermediate strings?
You would handle those the same way you handle intermediate values in f = 1
+ 2 + 3 + 4 + 5 in current C.
The whole thing is very un-C-like.
Yes. It's beginning to look remarkably C++-like, though.

--
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
Sep 6 '08 #139
jacob navia said:
Richard Heathfield wrote:
<snip>
Look Mr Heathfield, you know this by heart, and it is really not very
helpful to just play games and pose "clever" questions...
It wasn't a clever question. It was in fact a dumb question (but an honest
one), and it had an obvious answer, and having spent a few minutes
thinking about it I've answered it myself elsethread, in what I hope is a
positive way.
It would be *much* more helpful if you would help with the *real*
problems with this stuff...

(1) How do you overload the '[' ']' operators with multidimensional
arrays?
I wouldn't. I would allow any user-defined type to overload the array
operator, but I would stop there.

<snip>
(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment
Those look fine to me.
>
but I am not sure of this.
Why not? What is your concern?
There are several open issues like those.
So bring them on.

--
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
Sep 6 '08 #140

"jacob navia" <ja***@nospam.comwrote in message
(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment
What a nightmare.

++obj will do something subtly different to obj++. I'd keep the C rules of
precedence and binding, and define that the operations are always identical
otherwise.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 6 '08 #141
Malcolm McLean said:
>
"jacob navia" <ja***@nospam.comwrote in message
>(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment
What a nightmare.

++obj will do something subtly different to obj++.
So what? It already does.

--
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
Sep 6 '08 #142
Malcolm McLean wrote:
>
"jacob navia" <ja***@nospam.comwrote in message
>(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment
What a nightmare.

++obj will do something subtly different to obj++.
Can you explain a bit?

Because with
int a = 23;

++a does something subtly different than a++.
I'd keep the C rules
of precedence and binding, and define that the operations are always
identical otherwise.
I do not see how precedence rules are changed sorry. Maybe can you explain?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Sep 6 '08 #143
On Sep 6, 12:15*pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.
It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.
but what about the intermediate strings?

You would handle those the same way you handle intermediate values in f = 1
+ 2 + 3 + 4 + 5 in current C.
The whole thing is very un-C-like.

Yes. It's beginning to look remarkably C++-like, though.
If by C++-like you mean modern, then yes :-)

Sebastian

Sep 6 '08 #144
s0****@gmail.com writes:
On Sep 6, 12:15*pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.
but what about the intermediate strings?

You would handle those the same way you handle intermediate values in f = 1
+ 2 + 3 + 4 + 5 in current C.
The whole thing is very un-C-like.

Yes. It's beginning to look remarkably C++-like, though.

If by C++-like you mean modern, then yes :-)

Sebastian
RH knew exactly which way the conversation would turn. It is foolish to
pretend the addition of overloaded operators in C will not turn C into a
"poor mans" C++.
Sep 6 '08 #145
s0****@gmail.com said:
On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.
I already use constructors and destructors in C, so I know what you mean,
but it isn't quite what /I/ meant. In C, I have to call constructors and
destructors explicitly, and I'm fine with that. But if ISO were to
introduce operator overloading into C, I think there would be a lot of
pressure to introduce automatically-invoked constructors and destructors,
because (so it seems to me) there would be much more cleanup to do than is
at present the case, and the cost of overlooking cleanup could become
arbitrarily high.
but what about the intermediate strings?

You would handle those the same way you handle intermediate values in f
= 1 + 2 + 3 + 4 + 5 in current C.
The whole thing is very un-C-like.

Yes. It's beginning to look remarkably C++-like, though.

If by C++-like you mean modern, then yes :-)
No, I don't mean that. C is just about as modern as C++ is. It's just
*different*. Adding operator overloading would make it slightly less
different, and adding constructors and destructors would make it slightly
less different still, but that wouldn't make it any more "modern".

--
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
Sep 6 '08 #146
Richard Heathfield wrote:
>(1) How do you overload the '[' ']' operators with multidimensional
arrays?

I wouldn't. I would allow any user-defined type to overload the array
operator, but I would stop there.
But why? I do not see any reason (besides C++ compatibility) to avoid
overloading n dimensional arrays.
<snip>
>(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment

Those look fine to me.
OK
>
> but I am not sure of this.

Why not? What is your concern?
>There are several open issues like those.

So bring them on.
I think it is important to distinguish between read
and write access to tables. I use

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

This is done to support read only data types, what is very hard in C++.

I will bring other issues later.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Sep 6 '08 #147
Richard Heathfield <rj*@see.sig.invalidwrites:
s0****@gmail.com said:
>On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.

I already use constructors and destructors in C, so I know what you mean,
but it isn't quite what /I/ meant. In C, I have to call constructors and
destructors explicitly, and I'm fine with that. But if ISO were to
introduce operator overloading into C, I think there would be a lot of
pressure to introduce automatically-invoked constructors and destructors,
because (so it seems to me) there would be much more cleanup to do than is
at present the case, and the cost of overlooking cleanup could become
arbitrarily high.
>but what about the intermediate strings?

You would handle those the same way you handle intermediate values in f
= 1 + 2 + 3 + 4 + 5 in current C.

The whole thing is very un-C-like.

Yes. It's beginning to look remarkably C++-like, though.

If by C++-like you mean modern, then yes :-)

No, I don't mean that. C is just about as modern as C++ is. It's just
*different*. Adding operator overloading would make it slightly less
different, and adding constructors and destructors would make it slightly
less different still, but that wouldn't make it any more "modern".
That last paragraph is complete and utter rubbish and I have no idea why
someone with your technical knowledge and skills would say such a
thing. Note that "modern" does not, in any way, indicate "improved" as
far as the end product goes but there is a LOT of modern OO thinking
that has gone into C++.

Sep 6 '08 #148
jacob navia said:
Richard Heathfield wrote:
>>(1) How do you overload the '[' ']' operators with multidimensional
arrays?

I wouldn't. I would allow any user-defined type to overload the array
operator, but I would stop there.

But why? I do not see any reason (besides C++ compatibility) to avoid
overloading n dimensional arrays.
If you really want to do it, I suppose one way would be to allow type
synonyms to have their operators overloaded too. So, for example, here is
a not-very-well-thought-out idea in a language only barely resembling C:

struct foo
{
int i;
int j;
};

int foo::operator[](int offset) { return offset==0 ? i : j; }

/* yes, I stole the s.r.o. from C++ - sorry about that, but it conveys the
idea better than any other way I could think of */

typedef struct foo bar[]; /* bar is a synonym for an array of foo
with an arbitrary number of members */

int bar::operator[](int offset) { whatever...

the idea being that any given type can only overload one level of array
operator, but you add the ability to "build up" array types, dimension by
dimension, using typedef, and you give these array types the ability to
overload /their/ array operator. That would give you as many dimensions as
you need.

The more I think about this, the more I think it belongs in
comp.programming, not comp.lang.c. Still, at least it /is/ a discussion
now, which is a good start.

--
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
Sep 6 '08 #149
On 2008-09-06, Malcolm McLean <re*******@btinternet.comwrote:
>
"jacob navia" <ja***@nospam.comwrote in message
>(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment
What a nightmare.

++obj will do something subtly different to obj++. I'd keep the C rules of
precedence and binding, and define that the operations are always identical
otherwise.
ITYM, only one ++ behavior should be defined, and when it is invoked as
++obj, the value returned will be that /after/ said behavior, and when
invoked as obj++, the original object should be returned.

I'm not sure 'precedence' and 'binding' are the correct terms for that.

--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net
Sep 6 '08 #150

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Mohsin | last post: by
reply views Thread by Danny Jensen | last post: by
1 post views Thread by Al Belden | last post: by
4 posts views Thread by mdshafi01 | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.