Thursday, April 12, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

bartc <bc@freeuk.com>: Apr 12 05:23PM +0100

On 12/04/2018 14:44, Mr Flibble wrote:
 
> Now I have to look to the left to work out what type 'd' is rather than
> seeing it straight away as 'int d'. Sorry but IMO your idea is more
> annoying not less.
 
OK, so you would outlaw the use of a comma in many situations because
you have to scan all the way to the left (or to the top) to find out the
context:
 
... a, b, c ....
 
might be:
 
- Part of a set of enum names
- Part of an argument list for a function or macro
- Part of a comma-expression
- Part of the initialisation data for an array or struct
- Part of a parameter list (with names) when a,b,c are types
- Part of a sequence of declared variable names
- Etc (no doubt C++ provides more possibilities)
 
Sorry, your objection doesn't stand up.
 
>> invented for each kind of pointer.)
 
> That is what I do: I use typedef A LOT to introduce sensibly named
> aliases for simple types.
 
(And that's what drives me round the bend trying to decipher other
people's code because you have to go and track down all these aliases.
And eventually you find it's just a 'short'. Why not just say so in the
first place?)
 
>> that start with "*".)
 
> My idea of using one declaration per line works NOW i.e. doesn't require
> a change to the core language.
 
It is just avoiding the problem in a way that is unsatisfactory.
 
--
bartc
David Brown <david.brown@hesbynett.no>: Apr 12 08:11PM +0200

On 12/04/18 15:20, Rick C. Hodgin wrote:
>> have questioned them.
 
> The people here are C++ developers who have never had this ability.
> To them it is hogwash.
 
People here have plenty of experience with a wide range of languages.
Spaces in identifiers is crazy - everyone who has done any programming
in any language can tell you that. The example you gave of a language
with spaces - a variant of SQL - does not have them as programming
identifiers, but table names. That's the same as a programming language
being able to work with file names with spaces - very different from
program identifiers. There are also a few languages that can have some
kinds of identifiers enclosed in brackets or quotations, allowing spaces
or other characters.
 
> those who, unlike yourself and others here, find value in it.
 
> You really like to argue, don't you? I don't. I'm done with
> this conversation. This is the way CAlive is, and that's that.
 
Find me /one/ person, other than you, who is willing to say that spaces
in normal program identifiers might be a useful feature that could work
well in a programming language, and I will know it is not just you.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 05:49PM +0100

On 12/04/2018 17:23, bartc wrote:
> - Part of a sequence of declared variable names
> - Etc (no doubt C++ provides more possibilities)
 
> Sorry, your objection doesn't stand up.
 
Your assertion is false.
 
> people's code because you have to go and track down all these aliases.
> And eventually you find it's just a 'short'. Why not just say so in the
> first place?)
 
Most of the time you don't care what the underlying type is which is the
whole point; what you do care about is what the variable MEANS: "short"
is meaningless.
 
 
>> My idea of using one declaration per line works NOW i.e. doesn't
>> require a change to the core language.
 
> It is just avoiding the problem in a way that is unsatisfactory.
 
Another false assertion.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
gazelle@shell.xmission.com (Kenny McCormack): Apr 12 06:30PM

In article <24400777-4a8e-45aa-b0fc-e02c8a9f1adc@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
...
>C#, and other languages, without changing or extending RDC, but
>simply creating a new database which describes how to compile
>those other languages.
 
I admire your ambition. I don't think you realize just how far you have to
go. But, there is good news. Some people think that by the year 2050, we
will have the ability to put ourselves into digital (cloud) form - such
that we will no longer need physical bodies. Essentially, we will be able
to live forever in a mental/digital sense, without regard to our physical
bodies.
 
If you make it that far (and these people are right), you might, just
maybe, have a chance of achieving all that you are planning.
 
In the meantime, my suggestion to you is to do something a lot easier and
manageable, like, oh, say, solving the Middle East problem. Or the
Russia/Syria problem. Or the problem of global warming.
 
These tasks are so easy by comparison.
 
--
Nov 4, 2008 - the day when everything went
from being Clinton's fault to being Obama's fault.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 11:40AM -0700

On Thursday, April 12, 2018 at 2:11:28 PM UTC-4, David Brown wrote:
> [snip]
 
When it's released, don't use it. Problem solved.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 11:42AM -0700

On Thursday, April 12, 2018 at 2:30:25 PM UTC-4, Kenny McCormack wrote:
> manageable, like, oh, say, solving the Middle East problem. Or the
> Russia/Syria problem. Or the problem of global warming.
 
> These tasks are so easy by comparison.
 
I have been working on this design for years, Kenny. And I hope at
some point to have other Christians come help me because they too,
of their own volition, want to honor God in this way.
 
You should read about my Village Freedom Project sometime:
 
http://www.visual-freepro.org/wiki/index.php/Village_Freedom_Project
 
It is a well thought out goal and purpose. It took me years. And
I have refined it slightly over time. I am now working on another
endeavor beyond Liberty Software Foundation, but it is not yet ready
for release.
 
My life's work is given unto the Lord, Kenny. I will ONLY succeed
if it is His will. If not, then I will still have given my life's
work over to the Lord.
 
--
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 09:08PM +0200

On 12.04.2018 20:11, David Brown wrote:
> [snip]
> Spaces in identifiers is crazy - everyone who has done any programming
> in any language can tell you that.
 
Windows Cmd (a.k.a. the Windows batch language)
 
 
[P:\temp]+
> set uh oh=kadabra
 
[P:\temp]+
> echo %uh oh%
kadabra
 
[P:\temp]+
> _
 
 
With the proliferation of special meanings of characters and just
rudimentary quoting abilities, I have found no way to /safely/ handle
paths in the Cmd language. There's always some way any particular code
that handles paths, can be screwed up by data in the paths. Yet this
language has been used for that, and other things, since ~1984 (or
whenever it was that DOS acquired support for directories), which I
think goes to show that our intuitive notions of what's crazy don't
necessarily correlate with what's workable...
 
Cheers!
 
- Alf
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 12 09:17PM +0100

David Brown <david.brown@hesbynett.no> writes:
<snip>
> People here have plenty of experience with a wide range of
> languages. Spaces in identifiers is crazy - everyone who has done any
> programming in any language can tell you that.
 
I'd want to distinguish between significant spaces and non-significant
spaces and I'm not sure which is being talked but here. Non-significant
spaces are not obviously evil. It's a little bit like allowing a digit
separator in numbers. (Note the "little" -- I don't want to make a
Federal case out of this.)
 
Having significant spaces in identifiers would be bonkers.
 
<snip>
> spaces in normal program identifiers might be a useful feature that
> could work well in a programming language, and I will know it is not
> just you.
 
It never bothered me in Algol 68. In fact, I quite liked it. You don't
need to write line_spacing or lineSpacing you write
 
paragraph height +:= (number of lines - 1) * line spacing;
 
If you are not used to it, it looks bizarre, and it definitely benefits
from consistent usage -- seeing linespacing two statements later would
drive me nuts. I found it tended to make me put extra spaces in other
places which was probably no bad thing either.
 
The trouble is that it solves no modern real-world problem. Algol 68
was designed to have a presentation form and a machine form (I am sure
that's not how it was phrased) and published algorithms with thin spaces
in complex identifiers are very readable. But typography has moved on
#iPad, #monospacedfontsarecool, #noonecaresaboutspacesatallanymore.
 
--
Ben.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 12 01:20PM -0700

On 4/12/2018 5:12 AM, David Brown wrote:
> project, your challenge. It will never be of use or interest to me, no
> matter how complete and successful it may be - I work on a different
> kind of programming.
 
Fwiw, if CAlive ends up fully supporting C11 Threads, well, I would use it.
 
[...]
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 01:35PM -0700

On Thursday, April 12, 2018 at 4:20:33 PM UTC-4, Chris M. Thomasson wrote:
> > kind of programming.
 
> Fwiw, if CAlive ends up fully supporting C11 Threads, well, I would
> use it.
 
CAlive has a thread model already. If it can be incorporated or
extended to be compatible with C11 Threads, then it could be included.
 
You can read more here:
 
in -- Creates a new thread
andin -- Creates an additional new thread
out -- Leave a thread
join -- Joins the current thread to one (or more) thread(s)
before continuing
timeout -- Callback for each join-attempted thread that did not
out before timeout
success -- Callback if threads joined successfully before the
timeout
 
Examples:
 
thread x, y, z;
 
in x {
// Code here for this thread
} andin y {
// Code here for this thread
} andin z {
// Code here for this thread
}
 
join x, y, z
timeout 200 fail_function()
success success_function();
 
// Code continues here only after all three threads are joined
 
And you can also use:
 
thread t = { /* code here */ };
t.start;
 
thread t = some_function();
t.start;
 
thread t;
// Assign later:
t = some_function();
t.start;
 
And to terminate:
 
self.out; // Used in the thread itself
t.out; // Explicitly end the indicated thread
 
-----
I have something similar for creating processes with various syntaxes
and options including baked-in interprocess message passing:
 
process p;
 
--
Rick C. Hodgin
"Öö Tiib" <ootiib@hot.ee>: Apr 12 02:27PM -0700

On Thursday, 12 April 2018 22:08:40 UTC+3, Alf P. Steinbach wrote:
> kadabra
 
> [P:\temp]+
> > _
 
C++:
 
unsigned long long int kadabra;
legalize+jeeves@mail.xmission.com (Richard): Apr 12 06:13PM

[Please do not mail me a copy of your followup]
 
Tim Rentsch <txr@alumni.caltech.edu> spake the secret code
>> compatibility with C, and because its possible for a pointer to be
>> null, [...]
 
>And because pointers are mutable.
 
...and nullptr'able.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Manfred <noname@invalid.add>: Apr 12 08:14PM +0200

On 4/10/2018 7:45 PM, Alf P. Steinbach wrote:
 
> That's right.
 
> Bjarne added references to support user-defined operators. Without
> references they would be really ugly and not like built-in operators.
 
In fact it achieved a somewhat broader goal:
At the time C++ was invented, some languages (notably C) used
call-by-value argument evaluation, other (e.g. FORTRAN) used
call-by-reference evaluation.
Both methods had, and have, their pros and cons. So that when Bjarne
added the possibility to do both in his language, he achieved some
feature-completeness with argument evaluation.
Now, since it is possible to use pointers in C to achieve
pass-by-reference functionality, from this point of view the difference
is more semantical than substantial, as Mr. Flibble noted.
 
Obviously this resulted in some useful peculiar properties of
references: notably, they are immutable, and they are guaranteed to
refer to an actual object (if you don't break he rules).
It also resulted in some unconventional peculiarities, stemming from the
fact that "a reference is not an object", as Bjarne says, so that their
own semantics is substantially different from that of any actual C++
object (including pointers).
I think this last bit is what may make them less attractive to some.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 12 06:52PM

On Tue, 2018-04-10, Alf P. Steinbach wrote:
> references they would be really ugly and not like built-in operators.
 
> I think that tidbit came from his "evolution" book, which I don't have,
> sorry. Googling will probably find references. Maybe.
 
Page 85: "References were introduced primarily to support operator
overloading." Then he goes on to mention Algol68 as an inspiration.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
bartc <bc@freeuk.com>: Apr 12 07:54PM +0100

On 12/04/2018 19:14, Manfred wrote:
> Now, since it is possible to use pointers in C to achieve
> pass-by-reference functionality, from this point of view the difference
> is more semantical than substantial, as Mr. Flibble noted.
 
I use what I call pass-by-reference, indicated by a '&', in one of my
own languages, and I'd be interested to know if it's anything like what
is being talked about here.
 
I'll give examples in C syntax as people are familiar with that. First
example:
 
void getdims(int width, int height) {width=10; height;}
int h=0, w=0;
getdims(h,w);
 
This function is not useful as written because it doesn't return
anything to the caller. It has to be written like this:
 
void getdims(int *width, int *height) {*width=10; *height;}
int h=0, w=0;
getdims(&h,&w);
 
Now it works, but it needs explicit address-of and dereference operators
in both caller and function. Both versions use pass-by-value.
 
My & feature would work like this:
 
void getdims(int &width, int &height) {width=10; height;}
int h=0, w=0;
getdims(h,w);
 
& is implicitly added to arguments, and * to any use of a & parameter
within the function body. getdims(0,0) would not work (&0 is illegal),
so null pointers are not possible, but code doesn't even know it's using
pointers.
 
So, is this anything like C++'s & parameters?
 
--
bartc
David Brown <david.brown@hesbynett.no>: Apr 12 09:28PM +0200

On 12/04/18 20:54, bartc wrote:
> in both caller and function. Both versions use pass-by-value.
 
> My & feature would work like this:
 
>   void getdims(int &width, int &height) {width=10; height;}
 
I am guessing you meant something like "{width = 10; height = 20;}" ?
 
> so null pointers are not possible, but code doesn't even know it's using
> pointers.
 
> So, is this anything like C++'s & parameters?
 
Yes, that is /exactly/ like C++ reference parameters.
Manfred <noname@invalid.add>: Apr 12 09:29PM +0200

On 4/12/2018 8:54 PM, bartc wrote:
 
>   void getdims(int &width, int &height) {width=10; height;}
>   int h=0, w=0;
>   getdims(h,w);
 
This looks exactly like what C++ does (although you probably inverted h,
w in the getdims call)
 
 
> & is implicitly added to arguments, and * to any use of a & parameter
> within the function body. getdims(0,0) would not work (&0 is illegal),
The implementation is different, but the semantics hold.
In C++ the following would be illegal:
 
void foo(int& x);
foo(0);
 
because 0 is not an lvalue, so it is not possible to take a reference on it.
But the following would be legal:
 
void foo(const int& x);
foo(0);
 
Which is just one example of how many devils get hidden in the details
of a tiny little &
 
> so null pointers are not possible, but code doesn't even know it's using
> pointers.
 
> So, is this anything like C++'s & parameters?
 
Basically yes.
bartc <bc@freeuk.com>: Apr 12 09:13PM +0100

On 12/04/2018 20:28, David Brown wrote:
 
>> My & feature would work like this:
 
>>    void getdims(int &width, int &height) {width=10; height;}
 
> I am guessing you meant something like "{width = 10; height = 20;}" ?
 
Yes; I wondered what happened to all my height=20's. I'm sure they were
there before I posted! (And how did you know it was 20?)
 
>> using pointers.
 
>> So, is this anything like C++'s & parameters?
 
> Yes, that is /exactly/ like C++ reference parameters.
 
OK. In this case it seems a remarkably simple feature to implement
(perhaps 20 or 30 extra lines in a compiler). Something C could do with
perhaps.
 
(And to answer the OP's question, & can be applied to any parameter
type, including one that happens to have * for a pointer. An extra
pointer level will be added behind the scenes, but you write code on the
basis of that visible * pointer.
 
Without &, you'd have to write functions like the middle of my examples.
Which also makes it easier to pass null or invalid pointers.)
 
--
bartc
Paavo Helde <myfirstname@osa.pri.ee>: Apr 12 11:16PM +0300

On 12.04.2018 21:54, bartc wrote:
 
 
> This function is not useful as written because it doesn't return
> anything to the caller. It has to be written like this:
 
> void getdims(int *width, int *height) {*width=10; *height;}
 
*height; is a NOP.
 
> int h=0, w=0;
> getdims(&h,&w);
 
Arguments in the wrong order. This actually suggests encapsulating these
numbers into a Dims struct where such mixups would be less probable.
 
> within the function body. getdims(0,0) would not work (&0 is illegal),
> so null pointers are not possible, but code doesn't even know it's using
> pointers.
 
Yes, this is exactly as references work in C++.
 
&0 would not be a null pointer, but a pointer to some zero constant
somewhere (hopefully not in the global table of constants ;-). Null
references are not possible because for that one should pass an object
which resides at address zero, but it is not possible to create such an
object, and trying to fake it by dereferencing a null pointer is illegal
anyway.
 
That said, using references for such hidden output is usually not a good
idea from the readability point. In C++ one could use something like
that instead (assuming we do not want to create a Dims struct or something)
 
std::pair<int,int> getdims() {
return std::make_pair(10, 10);
}
 
int h=0, w=0;
std::tie(w, h) = getdims();
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 01:27PM -0700

> governing references were designed to justify the assumption that a
> reference always refers to an actual object of the specified type,
> which makes it easier to write safe code.
 
Wouldn't it be more desirable to keep them as pointers and use a
keyword to indicate it can't be NULL? We already use things like
const. Couldn't we use nonull?
 
void CAbc::func(const nonull CXyz* p)
{
// We know p will be non-NULL, so it can be used
}
 
And wouldn't it be possible to auto-create reference instances of
the pointer content, so something like p& is available for use with
that syntax?
 
// Some sample code
p->member // Accesses as pointer
p&.member // Accesses as reference
 
I don't see a reason to have both with the nonull keyword, and the
ability to reference pointer content as a reference. And if we're
going to go that far, why not just make it so that if we have the
token name in scope, and we reference it using the . syntax, then
it automatically handles the translation for us:
 
p->member // Accesses as pointer
p.member // Accesses as reference
 
It would remove some of the hidden compiler injection code for
passed parameters, but I actually think that's desirable, because
it's unclear from this:
 
int i = 5;
otherfunc(i);
 
If i is passed by reference or value. If you removed the ability
to pass by reference, it would be required to be clear in source
code:
 
int i = 5;
otherfunc(&i);
 
There would be no ambiguity. The only thing you'd have to have
then is knowledge of otherfunc() and if it included the nonull
keyword or not, but that's really only important to otherfunc()
and the compiler validating parameters at compile-time.
 
--
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Apr 13 08:32AM +1200

On 04/13/2018 08:27 AM, Rick C. Hodgin wrote:
 
> Wouldn't it be more desirable to keep them as pointers and use a
> keyword to indicate it can't be NULL? We already use things like
> const. Couldn't we use nonull?
 
No, just more clutter and more importantly, it wouldn't help with used
defined operators.
 
--
Ian
jameskuyper@verizon.net: Apr 12 02:00PM -0700

On Thursday, April 12, 2018 at 4:27:49 PM UTC-4, Rick C. Hodgin wrote:
> > which makes it easier to write safe code.
 
> Wouldn't it be more desirable to keep them as pointers and use a
> keyword to indicate it can't be NULL?
 
No, because doing so would discard the main motivating feature for references: the simpler syntax for using them.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 05:15PM -0400


>> Wouldn't it be more desirable to keep them as pointers and use a
>> keyword to indicate it can't be NULL?
 
> No, because doing so would discard the main motivating feature for references: the simpler syntax for using them.
 
Did you read the rest of my post? When passing pointers like that,
auto-allow the reference syntax when a name is used in a reference
syntax that goes back to a pointer.
 
nonull CAbc* abc;
abc->member(); // As pointer
abc.member(); // As reference
 
nonull int* i;
*i = 5; // As pointer
i = 5; // As reference
 
Why even deal with the various syntaxes in the large code blocks?
Define them once at some place (in the class, as a parameter, or
a global or local, etc.), and then use them how you see fit.
 
So long as there isn't a name collision ... why not?
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 10:20PM +0100

On 12/04/2018 22:15, Rick C. Hodgin wrote:
 
 
>     nonull int* i;
>     *i = 5;           // As pointer
>     i = 5;            // As reference
 
And if you want to make the pointer address 5 rather than what it points
to 5?
 
Try thinking before posting.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 12 06:52PM +0100

On Thu, 12 Apr 2018 09:09:35 -0700
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
[snip]
> an ML functor mapping a module to a module. It isn't exactly the
> same, but I think it's close enough so that "functor" makes
> sense. The C++ usage is way out in left field.
 
I am not going to reply to all of your email which was considerably
discursive. I shall restrict myself to the bits I particularly disagree
with.
 
And it is a real stretch to say modules in ML are roughly analogous to
a category, and by analogy that ML functors are roughly analogous to
functors in category theory in a way which is violated by C++'s usage
of the term. ML functors are not necessarily morphisms. MLs basically
consist of two languages, one of which operates on modules and one on
values. Functors are what operate on modules.
 
And if a module is so analogous, then so is an object in C++. A functor
in C++ maps from an object to the return value of the functor. (The
object of which of the functor is a member is in effect the first or
only argument of the function represented by the functor.) On this
analogy, there is a close relationship between C++ functors and ML
functors. A ML module is just a collection ("struct") of types and
values. First class modules are objects on steroids.
 
In fact every function in C++ is a mapping from some kind of type to
another (assuming you take 'void' to be a unit type). That's what
functions do. They may of course have side effects also in most
languages, including in ML and C++. A functor in ML can have a side
effect, albeit that is unusual: it can construct its output module for
example by taking a value from stdin.
 
[snip]
 
> specification, a feature set, a template interface, template
> pre-requisites, a meta-template, template constraints, or any
> number of other terms, all of which are more apt than "concept".
 
I think you had better begin to take is seriously, because it is what
they are going to be called. A concept in C++ is a collection of
behaviours or traits comprising at its simplest descriptions such as
"Comparable" or "Movable". Concept is fine as a label for that, in my
opinion.
 
 
> Virtual functions provide what the general programming language
> community just calls polymorphism. (Subtype polymorphism is
> a special case of polymorphism.)
 
Since you appear to know something about functional languages
this statement is astonishing. Virtual functions are not what the
general programming language community calls polymorphism. They are
what Java, C# and some poorly informed C++ programmers call
polymorphism. In fact, by saying that "subtype polymorphism is a
_special case_ of polymorphism" (my emphasis), you are implicitly
agreeing with me and contradicting yourself. Virtual functions
implement subtype polymorphism in C++.
 
> Nothing in C++ provides parametric polymorphism. Nothing can,
> because the type space in C++ is not rich enough.
 
I didn't say function templates provide parametric polymorphism. I
said they perform the role of parametric polymorphism: they provide
type inference on the template arguments. It is as close as C++ gets
to it.
 
> "dynamic polymorphism" is a gratuitous introduction of a new term
> where none is needed, because there was already a perfectly good
> term in use with the desired meaning.
 
The word "dynamic" is well established in C++. We have had dynamic_cast
since 1998 for example in exactly the same context.
 
> polymorphic: what executes in the program can operate on more
> than one form of data. Build-time polymorphic code is not really
> polymorphic at all.
 
I completely disagree.
 
I also have the feeling that this discussion is becoming more or less
futile because arguing about semantics quickly becomes pointless. In
summary, your starting argument was that C++ chooses its terms more
poorly than other programming languages. I disagree.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)