Prev: What's the lifetime of temporaries in lambdas?
Next: implicit conversion: ctor or cast?
From: David Barrett-Lennard on 25 Apr 2010 18:13
On Apr 24, 8:37 am, �� Tiib <oot...(a)hot.ee> wrote:
> On Apr 23, 4:29 pm, David Barrett-Lennard <davi...(a)iinet.net.au>
> wrote:
>
> > On Apr 23, 12:55 pm, �� Tiib <oot...(a)hot.ee> wrote:
>
> > > On 23 apr, 02:18, David Barrett-Lennard <davi...(a)iinet.net.au> wrote:
>
> > > > On Apr 22, 6:59 pm, �� Tiib <oot...(a)hot.ee> wrote:
> > > > > I avoid it. In large project such implicit conversions cause sometimes
> > > > > hard to discover bugs because they hide simple typos.
>
> > > > Implicit conversions can be classified as safe or dangerous depending
> > > > on whether there are surprises. I believe I gave a safe one that is
> > > > very unlikely to be the source of bugs. Indeed all things being
> > > > equal, more concise code tends to have fewer bugs. If you think
> > > > otherwise I would appreciate a realistic example.
>
> > > Ok. Imagine function parameter #3 of 6 is Rect, but you pass
> > > innocently Squares to it (from some array) in cycle of 1000 that is in
> > > cycle of 1000. Only profiler shows that there takes place million of
> > > Rect constructions and simple optimization can get rid of it. Bare eye
> > > does not see it in noteworthy project.
>
> > That's not a bug though.
>
> No. I did not say it is a bug. I said that i usually avoid it
> (implicit conversions). With modern editors helping to type and with
> 1920 pixels of vertical space it is not so wasteful to indicate every
> conversion explicitily. It comments very well what is going on.

It makes code harder to read. The caller should assume it is
efficient and always use a clean and simple syntax. As a general rule
efficiency should be a problem managed by the implementer of the
service, not the caller of the service. It also complicates
generically written algorithms.

> > You seem to be saying that a general purpose algorithm shouldn't be
> > implicitly available for special cases because it may be suboptimal.
> > I find that idea highly questionable, particularly when it is easy to
> > specialise the algorithm as and when profiling indicates that it is
> > appropriate to do so.
>
> I did mean that implicit conversion hides that conversion takes place.
> Conversion may cause bugs or suboptimal code, but avoiding it because
> of that is premature optimization. I simply indicate it explicitly and
> all. That saves time of possible reader who is likely looking for
> cause of bug or possibility of optimization one day (often myself).

I think in practise it will have the opposite effect. E.g. in a very
large program there are thousands of calls written as

area(Rect(s))

to get the area of square s, and then later when you specialise the
area function for squares you have to ensure you remove all those
explicit conversion to Rect which (depending on the compiler) may get
what you asked for and defeat optimisation! What about massive
amounts of code written by other programmers using your geometric
shapes library? How do they benefit from your efforts at
specialisations?


> > > > Pass by value is hardly a "defect" (at least in the code I presented).
>
> > > Depends. For me there are some things that i imagine as values and
> > > other things that i imagine as objects. Objects i pass rarely by value
> > > (and if i do then i comment there why). Values i pass rarely by
> > > reference (and again if so then i comment there why). What is optimal
> > > from performance standpoint may be different, but the idiom what i
> > > described is optimal on majority of cases. "Rect" felt like example of
> > > object class. Had it been "Duration" then it felt like example of
> > > value class.
>
> > I'm unsure what you mean by "object". You seem to imply that objects
> > are not values and yet it could be possible (albeit "rarely") to pass
> > an object by value. I don't know what that means.
>
> "object" as abstraction of discrete item. Noun.
> Object has interface to observe and to manipulate it. Verb. Command.
> Query.
> "value" as property or relation of object or helper in interface.
> Adjective. Adverb. Preposition. Quantity. Property.
> That is my silly view on imperative object oriented programming. I
> create army of objects, observe and command them. Let them to observe
> and command each other for me. Silly, because in real languages same
> words take different parts of speech depending on context, but i
> ignore it.

Saying an object is a noun says virtually nothing at all. To have a
decent conversation I suggest you should use standard terms like
symbol, value, type, variable, state machine, pointer, function,
relation. Indeed these are all nouns, and so are 'instances' of them.

I note that we don't even agree on what the word "value" means, which
is asking for confusion.


> > I tend to avoid the word "object" because it is a source of
> > confusion. I consider functions to support pass by value, or else
> > pass by reference to a variable or state machine. I consider pass by
> > const reference to mean passing a reference to a variable or state-
> > machine that must be considered immutable.
>
> I imagine it so that if i pass some discrete item ("object") by value
> then i clone that item behind scenes by language rules. So i feel need
> to indicate it that i did it. However when it is support information
> ("value") then it is better to copy it. Giving reference to original
> property attached to some discrete object feels wrong (so again i feel
> need to indicate it).
>
> You seems to look at things differently. I do not say that it is
> wrong. Only that it is weakly supported by language mechanics, that
> does not let you do some things that you want and might do other
> things that spoil the effect.

Can you be more specific with that claim?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: David Barrett-Lennard on 25 Apr 2010 18:29
On Apr 24, 8:15 am, Keith H Duggar <dug...(a)alum.mit.edu> wrote:
> On Apr 22, 9:09 am, David Barrett-Lennard <davi...(a)iinet.net.au>
> wrote:
>
> > On Apr 22, 3:35 am, Keith H Duggar <dug...(a)alum.mit.edu> wrote:
> > > And no
> > > matter what definition you choose, if it allowed this to be a
> > > "form of inheritance" I would argue that said definition is at
> > > total odds with any common sense meaning of "inheritance".
>
> > I was thinking of it as "inheritance" in the following sense: Let a
> > data type mean a set of abstract values plus operators on those values
> > (using operator in an algebraic sense). The "behaviour" of a datatype
> > is only externally visible through those operators. Relating this
> > back to C++ code, assuming all operators are expressed as free
> > functions without in-out parameters, an implicit conversion between
> > two datatypes means that all the operators of one are available to the
> > other - because of value substitutability. I think it is reasonable
> > to call that "inheritance" treating the word as simply meaning that
> > "stuff" associated with one "thing" is automatically available to
> > another "thing". Anyway that was the only point I wanted to make! I
> > just looked for synonyms of "inherit" at synonym.com and the only
> > alternatives it gave me are "get" and "acquire".
>
> > > What about all the numerous
> > > other types we made add in future, are we now talking about
> > > multiple inheritance?
>
> > In the sense of inheritance I described above, definitely!
>
> Then as they say "Houston we have a problem" ;-) That is because
> traditionally (and I personally haven't seen any exceptions to
> this so I would tentatively say "universally") the "inheritance"
> concept in both type theory and practical programming, is thought
> of if not /defined/ as a partial ordering. And in that case we
> have the antisymmetry law of partial order logic ie
>
> x <: y AND y <: x IMPLIES x = y

Informally let

value type = set of values + algebraic operators on those values

and T1 is a subtype of T2, written T1 <: T2 if

1) values of T1 is a subset of the values of T2; and
2) operators of T1 is a superset of the operators of T2.

The subtype relation is reflexive, antisymmetric, and transitive, so
it is a partial order. Note that T1 = T2 means T1,T2 have the same set
of values and have the same operators.

The definition of subtype is appropriate for defining implicit
conversions that avoid surprises. Condition 1 ensures that the
implicit conversion is infallible. Condition 2 ensures that the 'copy'
created by the implicit coercion can only be used in operators that
are already available to the original.

It is important to distinguish between a C++ class and the abstract
value-type it represents (if any). Indeed two distinct classes can
represent the same value-type. For example, simply copy and paste a
class definition and give the copy a different name.

Classes named Polar and Cartesian could be regarded as distinct
classes that together represent a single underlying value-type.
Implicit conversions in both directions help to ensure this is the
case, for then all operators defined on one are available to the
other. The only reason for the implementation to supply alternative
representations is for physical performance reasons. From a "logical"
point of view there is no need for it. Indeed one could consider the
alternative implementations and use of constructors as only hints to
the compiler.

One can distinguish between an instance of an encoding (i.e. a
variable in memory of a value-type like Square) and the abstract value
it is deemed to represent. This is analogous to a formal semantics on
a first order logic, where a type name 'Square' plays the role of a
function symbol, and interpretation of the symbol is a function that
maps the parameters of the underlying implementation of the variable
to an abstract square value. One can also draw a similar analogy when
considering the constructors of C++ classes that represent value
types, because they are like functions that select abstract values.

With the analogy to a formal semantics on a first order logic there is
nothing wrong with two different function symbols 'Polar' and
'Cartesian' that under interpretation represent different functions
that happen to have the same codomain. This distinction for C++ value
types only manifests itself in two ways. One is in how a variable in
memory is interpreted according to its type, and the other is in the
constructors of a class which are used to construct a variable in the
first place. One could consider the underlying type to have the union
over all the constructors, and these can be modelled as operators.


> where "<:" is "inherits from" So, if we take you view that it's
> reasonable for (since you allow coercions define "inheritance")
>
> Rect <: Square
> Square <: Rect
>
> then
>
> Square = Rect
>
> which is obviously false. So I just think it's very unwise from

Yes but it is obviously false that

Rect <: Square

It is a bad idea to provide implicit conversions just because two
types overlap in the values they can represent. As far as the
abstract type system is concerned implicit coercions must be
infallible.

Only some rectangle values are square values, so this conversion must
be explicit and regarded as fallible. In the context of particular
client code it may be provable that the conversion will succeed and so
an assertion should probably be used to verify the design. Otherwise
a run time test is required. E.g. call

bool IsSquare(Rect r) { return width(r) == height(r); }


> a communication perspective to call '"stuff" associated with one
> "thing" is automatically available to another "thing"' inheritance.
> Other phrases such as convertible, compatible, associated, etc come
> to mind. Perhaps there is a traditional word for it in algebraic
> type theory but I can't recall.
>
> > > Suppose I create a coercion from complex<int,int> to rectangle,
> > > does complex<int,int> now "inherit" from rectangle? What if we
> > > add a coercion from rectangle to complex<int,int>, does rectangle
> > > no circularly inherit from complex?
>
> > That's just weird so I'm not sure what your point is here.
>
> Geometric interpretation of complex is VERY common. And the
> interpretation of a vector defining a corner of a rectangle
> rooted at the origin is also VERY common. So I don't see why
> you call this "weird". But this is a nit anyhow.

Fair enough, but then the source code shouldn't care to draw a
distinction either, so why not use a single class for both?


> > A better
> > example for me would be classes named Polar and Cartesian and we would
> > like implicit conversions in both directions. I haven't studied the
> > rules of implicit conversions for C++ to know whether such a thing
> > works in practise, but in principle I can't see any problems with
> > alternative representations of abstract values.
>
> Sure you can define implicit conversion in both directions
> (for user defined types anyhow).
>
> > BTW the conversions between polar and cartesian representations
> > involve cos, sin, sqrt, atan2 which are inexact for rational numbers
> > (including floats). That could mean we have an example of the
> > following assertion breaking which I find extremely unappealing:
>
> > T1 x;
> > T2 y = x;
> > assert(x == y);
>
> > This can fail if coercions aren't invertible and y is coerced in order
> > to perform comparison using T1::operator==. On that basis I would
> > reject implicit conversions between polar and cartesian
> > representations.
>
> Meh, that's an implementation issue that can be solved in a
> variety of ways.

I can only imagine solving it with symbolic logic, and that would have
very specialised application.


> > I would hope that implicit conversions between datatypes satisfy
> > reasonable "laws" to make program correctness easy to reason about.
>
> > Unfortunately C++ doesn't give you a transitive closure of the
>
> Well, unfortunately or fortunately depending on your viewpoint,
> the standards committee decided that disallowing such transitive
> closure was a "reasonable law" to help ensure correctness. Maybe
> one of the members will comment. I vaguely recall this briefly
> discussed in either D&E or ARM but I can't be asked to track that
> reference down right now. (I need grep'able copies of my books LOL).

Yes, I would be very interested in knowing the justification.

We can define an equivalence relation on encodings according to the
different ways to represent the same value. By convention in C++ this
is associated with operator==(). Unfortunately this is typically
defined using a class member function, so with implicit conversions
only acting on the rhs it doesn't tend to be symmetric. In addition,
since implicit coercions aren't transitive it is all too easy for
operator==() to not be transitive as well.

E.g.

T1 x;
T2 y;
T3 z;
if (x == y && y == z)
{
assert(x == z); // Oops. May not compile!!!
}

So far this thread has only provided examples using unary functions.
Specialisations become more labour intensive with binary functions.
E.g. == could be written differently for the following signatures:

Quad == Quad
Quad == Rect
Quad == Square
Rect == Quad
Rect == Rect
Rect == Square
Square == Quad
Square == Rect
Square == Square

I think in large programs one would hope to avoid writing lots of
special cases. It helps to use free functions, transitively applied
coercions and decent compiler optimisation.


> > defined implicit conversions. Consider that we extend my previous
> > example with an additional type to represent an arbitrary
> > quadrilateral and we recognise that square value is-a rectangle value
> > is-a quadrilateral value.
>
> *sigh* you keep forcing the "is-a" thinking in. Do you really see
> is-a as a necessary concept? Even a particularly helpful one? Do
> you not see any value in my suggestion to drop that hierarchical
> thinking in favor of "flatter" relational thinking ie algebraic
> type theory?

I cannot answer that without knowing more about what you mean. For
example, what do you see as the underlying basis for using implicit
coercions in practise? Do you require implicit coercions to be
transitive? Do you require x==y to be true after performing
assignment x=y? Do you require f(x)==f(y) whenever x==y? Do you
require == to be an equivalence relation? What does it mean if x==y
is undefined? Do implicit coercions need to be infallible? Can they
give the copy access to operators not available on the original?

I know an ostream is not a value type, but what are your impressions
of this?

void foo(std::ostream& os1, std::ostream& os2)
{
if (os1 == os2)
{
// What does this mean?
}
}


> > > Not anywhere close in my mind. How would
> > > such "inheritance" thinking or terminology even be useful?
>
> > In the case of square value isa rectangle value, it is useful in the
> > sense that it is a reminder that one doesn't necessarily need to
> > implement operators on square that have already been written for
> > rectangles. If one forgets that then one may end up writing more code
> > than needed (and the C++ compiler won't complain of course).
>
> Is that it?? A useful reminder? Sorry, that seems quite a tiny
> (if any) benefit to force "is-a" on to every (perhaps any)
> analysis of syntax or concepts.

No, there is a miscommunication. I think 'is-a' has a more far
involved purpose (see below). I was only talking about the utility of
the word "inheritance" in the context of value-types.


> For example, it is far more useful to keep in mind that division
> is not closed over integers than it is to sing "an integer is-a
> rational" all day long. The first viewpoint emphasizes knowing
> the algebra, the second knowing some shoe-horned "hierarchy".

Those two viewpoints are somewhat orthogonal. The rationals can be
defined axiomatically or else as equivalence classes over pairs of
integers. Either way, that is not the same as pointing out that there
exists a unique mapping from the integers into the rationals such that
the operators on the integers map to restrictions of corresponding
operators on the rationals, and therefore that there is a subset of
the rationals that is isomorphic to the integers. Since the integers
are only unique up to isomorphism it is convenient to say this subset
of the rationals is the integers. That rather complicated idea is
what 'is-a' means.

Very significantly, the nonzero integers inherit rational valued
multiplicative inverses. Indeed I recall a discussion on a database
newsgroup a few years ago where someone claimed Chris Date's notion of
subtype = subset made no sense, for example because although the
integers are a subset of the reals, they don't inherit the axiom of
multiplicative inverses and therefore it was claimed that it cannot be
said that the integers are a subtype of the reals. However this
problem disappears if we say that the integers "inherit"
multiplicative inverses from the larger system. Although it may be
questionable for whether mathematicians find this notion of subtype
useful, it does appear useful in computer science because it relates
to where implicit conversions work and behave nicely.


> > > > Square inherits functions defined on rectangles but not
>
> > > No it doesn't "inherit" the functions. Instead you have created
> > > an algebra in which an implicit coercion makes syntax such as
>
> > > width(square)
>
> > > valid. Suppose I now declare and explicit function for square
>
> > > int area ( Square s ) { return side(s) * side(s) ; }
>
> > > would you now propose to say that I have "overridden the
> > > inherited (from rectangle) area function"? That doesn't make
> > > any bit of sense to me. "inheritance" has no place here.
>
> > I'm not sure why. I thought the "override" metaphor was quite a good
> > one. I would however say it's a very dangerous analogy because it
> > means something quite different to overrides of virtual methods in the
> > context of subclassing. However, on the other hand we are talking
>
> Yes, that was careless. I was using "override" in the type theory
> usage forgetting that it has a restricted meaning in C++.
>
> > about data types here and we know that subclassing is completely and
> > universally useless for data types so I would suggest that confusion
> > cannot occur for C++ programmers that properly understand datatypes.
>
> Eh, I would rather just avoid words like "inheritance" for this
> mechanism since it already has such a strong nearly universal
> connotation of ordering that does not apply here.

Perhaps, but I think OO programmers tend to emphasise state machines
instead of value types, even at the expense of layering. E.g. OODBMS
misused to make data (i.e. values) look like persistable state
machines, or an abstract syntax tree where nodes represent state
machines rather than values.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Öö Tiib on 26 Apr 2010 09:11
On Apr 26, 12:13 pm, David Barrett-Lennard <davi...(a)iinet.net.au>
wrote:

> On Apr 24, 8:37 am, �� Tiib <oot...(a)hot.ee> wrote:

> > No. I did not say it is a bug. I said that i usually avoid it
> > (implicit conversions). With modern editors helping to type and with
> > 1920 pixels of vertical space it is not so wasteful to indicate every
> > conversion explicitily. It comments very well what is going on.

> It makes code harder to read. The caller should assume it is
> efficient and always use a clean and simple syntax. As a general rule
> efficiency should be a problem managed by the implementer of the
> service, not the caller of the service. It also complicates
> generically written algorithms.

Hmm. For me implementor of the service did not provide interface to
calculate area of square. He instead expects callers to convert square
into rectangle and then calculate area of resulting rectangle. To ease
hiding it from callers he made conversion from square to rectangle
implicit. The case under hand (square to rectangle) is not a big deal.
It would be more clear what is likely wrong if your library did hide
that the callers convert even farther to reach even more general but
also more unsuitably costly algorithms.

area(Parallelogram(square));

or

area(Polygon(square));


> I think in practise it will have the opposite effect. E.g. in a very
> large program there are thousands of calls written as

> area(Rect(s))

> to get the area of square s, and then later when you specialise the
> area function for squares you have to ensure you remove all those
> explicit conversion to Rect which (depending on the compiler) may get
> what you asked for and defeat optimisation! What about massive
> amounts of code written by other programmers using your geometric
> shapes library? How do they benefit from your efforts at
> specialisations?

I do not understand. How adding special function for calculating area
of Square defeats optimization? Square has certainly simpler algorithm
for area calculation than rectangle. Like rectangle has simpler
algorithm for area calculation than parallelogram. Compiler tries its
best but the bigger the job of simplifying algorithms the more likely
it results with something suboptimal.

> > "object" as abstraction of discrete item. Noun.
> > Object has interface to observe and to manipulate it. Verb. Command.
> > Query.
> > "value" as property or relation of object or helper in interface.
> > Adjective. Adverb. Preposition. Quantity. Property.
> > That is my silly view on imperative object oriented programming. I
> > create army of objects, observe and command them. Let them to observe
> > and command each other for me. Silly, because in real languages same
> > words take different parts of speech depending on context, but i
> > ignore it.
>
> Saying an object is a noun says virtually nothing at all. To have a
> decent conversation I suggest you should use standard terms like
> symbol, value, type, variable, state machine, pointer, function,
> relation. Indeed these are all nouns, and so are 'instances' of them.

I said object is abstraction of discrete item. You did not read it?
"Noun" is reference to real life language part what people use to talk
about such things.

If my software deals with crayons, then crayon is an object-type and
not value-type. Color of crayon however is value that each crayon has.
The color of crayon may be variable, its value may change. Each crayon
however is discrete abstract item (despite its color changed). I may
have "class Color" and "class Crayon". Then i say that Color is value-
type-class and Crayon is object-type-class. Color instances i pass-by-
value and Crayon instances i pass-by-reference.

> I note that we don't even agree on what the word "value" means, which
> is asking for confusion.

When "pointer" is just another pointer in your code then it is not
object but mere part of programming language like noun, verb,
adjective, adverb etc are parts of natural language. Sure, "pointer"
is object when your software (for example compiler) deals with
programming language text and so handles pointers in it as objects.

Your software deals with rectangles, but you say your rectangle is a
value. For me it is yes confusing what are the object-types (if any)
there. So i am indeed in dark and possibly misinterpret what you do.

> > You seems to look at things differently. I do not say that it is
> > wrong. Only that it is weakly supported by language mechanics, that
> > does not let you do some things that you want and might do other
> > things that spoil the effect.

> Can you be more specific with that claim?

Lack of chains of implicit conversions we already discussed. C++ does
not let you to do it. For other example the instances of classes in C+
+ are inherently meant as variable not constant. The manipulations do
not let you to change the class to what instance belongs run time. It
is because when you manipulate some instance you do not get some new
instance but you get your old instance overwritten. So you can not
"s.enwiden(2)" (enwidening your Square s by 2 units) and morph s into
Rectangle as result. I am not saying that you indicated desire to do
it anywhere. It should feel natural when not imagining "s is Square
object" but as "s is variable that has value of type Square".

You may perhaps implement a library that even creates illusions of
described behavior, but C++ likely fights back with various side
effects and limitations.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: David Barrett-Lennard on 26 Apr 2010 23:00
On Apr 27, 8:11 am, �� Tiib <oot...(a)hot.ee> wrote:
> On Apr 26, 12:13 pm, David Barrett-Lennard <davi...(a)iinet.net.au>
> wrote:
>
> > On Apr 24, 8:37 am, �� Tiib <oot...(a)hot.ee> wrote:
> > > No. I did not say it is a bug. I said that i usually avoid it
> > > (implicit conversions). With modern editors helping to type and with
> > > 1920 pixels of vertical space it is not so wasteful to indicate every
> > > conversion explicitily. It comments very well what is going on.
> > It makes code harder to read. The caller should assume it is
> > efficient and always use a clean and simple syntax. As a general rule
> > efficiency should be a problem managed by the implementer of the
> > service, not the caller of the service. It also complicates
> > generically written algorithms.
>
> Hmm. For me implementer of the service did not provide interface to
> calculate area of square. He instead expects callers to convert square
> into rectangle and then calculate area of resulting rectangle. To ease

We are comparing two approaches depending on whether implicit
conversions are utilised. In the approach that allows implicit
conversions what you said above is inappropriate. The interface would
be documented as saying that all operators available on rectangle
values are also available for square values. Indeed an automated
documentation engine could indicate that the area function is directly
available for class Square. A caller doesn't care how it is
implemented as long as it is efficient enough for their application.
The implementer of the library can easily provide guarantees of high
performance, by providing specialisations where the compiler proves to
be inadequate.

The open/closed principle suggests an interface should avoid
unnecessary changes. You want the interface to reflect how the
implementation works, by putting explicit conversions into client
code!


> hiding it from callers he made conversion from square to rectangle
> implicit. The case under hand (square to rectangle) is not a big deal.
> It would be more clear what is likely wrong if your library did hide
> that the callers convert even farther to reach even more general but
> also more unsuitably costly algorithms.
>
> area(Parallelogram(square));
>
> or
>
> area(Polygon(square));

It is easy to provide specialisations of functions to address
performance concerns so what is your point?


> > I think in practise it will have the opposite effect. E.g. in a very
> > large program there are thousands of calls written as
> > area(Rect(s))
> > to get the area of square s, and then later when you specialise the
> > area function for squares you have to ensure you remove all those
> > explicit conversion to Rect which (depending on the compiler) may get
> > what you asked for and defeat optimisation! What about massive
> > amounts of code written by other programmers using your geometric
> > shapes library? How do they benefit from your efforts at
> > specialisations?
>
> I do not understand. How adding special function for calculating area
> of Square defeats optimization? Square has certainly simpler algorithm
> for area calculation than rectangle. Like rectangle has simpler

You missed the point I made. Suppose clients of V1.0 of the geometry
library are told to use

area(Rect(s))

to calculate the area of square s. Suppose clients of V2.0 of the
geometry library are told to now use

area(s)

because a specialisation has been written. Unfortunately clients are
much too busy and cannot afford to go through their million line
program and make all the changes. So rather than inherently taking
advantage of the specialisation their unnecessarily verbose code
explicitly tells the compiler to coerce a square value into rectangle
value before computing the area which is like a hint to the compiler
saying "please don't use specialisation".


> algorithm for area calculation than parallelogram. Compiler tries its
> best but the bigger the job of simplifying algorithms the more likely
> it results with something suboptimal.

Yes, that is why the implementer of the library needs to provide
specialisations where required.


> > > "object" as abstraction of discrete item. Noun.
> > > Object has interface to observe and to manipulate it. Verb. Command.
> > > Query.
> > > "value" as property or relation of object or helper in interface.
> > > Adjective. Adverb. Preposition. Quantity. Property.
> > > That is my silly view on imperative object oriented programming. I
> > > create army of objects, observe and command them. Let them to observe
> > > and command each other for me. Silly, because in real languages same
> > > words take different parts of speech depending on context, but i
> > > ignore it.
>
> > Saying an object is a noun says virtually nothing at all. To have a
> > decent conversation I suggest you should use standard terms like
> > symbol, value, type, variable, state machine, pointer, function,
> > relation. Indeed these are all nouns, and so are 'instances' of them.
>
> I said object is abstraction of discrete item. You did not read it?
> "Noun" is reference to real life language part what people use to talk
> about such things.

Ok, but that still means essentially nothing. The word abstraction
means different things to different people. Also, what is an 'item'?


> If my software deals with crayons, then crayon is an object-type and
> not value-type. Color of crayon however is value that each crayon has.
> The color of crayon may be variable, its value may change. Each crayon
> however is discrete abstract item (despite its color changed). I may
> have "class Color" and "class Crayon". Then i say that Color is value-
> type-class and Crayon is object-type-class. Color instances i pass-by-
> value and Crayon instances i pass-by-reference.

Are you saying the software deals with crayons but not with colours?
What precisely does "deal with" mean?


> > I note that we don't even agree on what the word "value" means, which
> > is asking for confusion.
>
> When "pointer" is just another pointer in your code then it is not
> object but mere part of programming language like noun, verb,
> adjective, adverb etc are parts of natural language. Sure, "pointer"
> is object when your software (for example compiler) deals with
> programming language text and so handles pointers in it as objects.
>
> Your software deals with rectangles, but you say your rectangle is a
> value. For me it is yes confusing what are the object-types (if any)
> there. So i am indeed in dark and possibly misinterpret what you do.

Actually I distinguish between rectangle values, rectangle variables,
a rectangle class and an abstract rectangle data type.

An integer like '5' is an example of a value. Values are abstract and
mathematically defined, external, immutable and don't exist in time
and space. Values represent equivalence classes. For example the
integers are only uniquely defined up to isomorphism.

I do not characterise values as being properties of things. Instead I
consider values to come from pure axiomatic mathematical systems.


> > > You seems to look at things differently. I do not say that it is
> > > wrong. Only that it is weakly supported by language mechanics, that
> > > does not let you do some things that you want and might do other
> > > things that spoil the effect.
> > Can you be more specific with that claim?
>
> Lack of chains of implicit conversions we already discussed. C++ does
> not let you to do it. For other example the instances of classes in C+
> + are inherently meant as variable not constant. The manipulations do

The only thing that might be "inherent" is that C++ programmers
normally say "class instance" when they mean "variable", and not when
they mean "value". However that is merely a custom for terminology
and has nothing to do with the crucial distinction between variable
and value that is actually important whether a C++ programmer realises
it or not.

Whilst on the topic of terminology, I consider your use of the word
"constant" to be improper. A constant is a *symbol* in a language
that under a formal semantics denotes a value. Don't say "constant"
when you mean "value".


> not let you to change the class to what instance belongs run time. It
> is because when you manipulate some instance you do not get some new
> instance but you get your old instance overwritten. So you can not
> "s.enwiden(2)" (enwidening your Square s by 2 units) and morph s into
> Rectangle as result. I am not saying that you indicated desire to do
> it anywhere. It should feel natural when not imagining "s is Square
> object" but as "s is variable that has value of type Square".

Variables have a type that constrains what values they can hold. That
is the reason why you can't call enwiden on a variable of type Square.

I have no problem with a method Rect::enwiden(), and see this as a
function available for rectangle variables but not for square
variables. It works nicely in C++ and it's consistent with the
support for implicit conversions of values. There can't be a method
Square::enwiden(), and there's no contradiction because Square doesn't
subclass Rect.


> You may perhaps implement a library that even creates illusions of
> described behavior, but C++ likely fights back with various side
> effects and limitations.

Yes, unfortunately but it's not insurmountable.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4
Prev: What's the lifetime of temporaries in lambdas?
Next: implicit conversion: ctor or cast?