Monday, March 21, 2016

Digest for comp.lang.c++@googlegroups.com - 21 updates in 5 topics

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 21 06:01PM +0100

On 21.03.2016 14:20, Zaphod Beeblebrox wrote:
> subset of ellipses. The other way doesn't work, because it's not the
> case that every Ellipse or most Ellipses has exactly one radius.
 
> Well, it's not that simple, IMO.
 
Zaphod is quoting out of context, and ignoring the context in his
simplistic argumentation.
 
That's typical trolling behavior and I think I recall the nick as a
well-known clc++ troll way back.
 
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 21 05:43PM

On 21/03/2016 03:02, Jerry Stuckle wrote:
 
>> Try again Victor: virtual inheritance is NOT appropriate here.
 
>> /Flibble
 
> Actually, Victor is correct. You are not.
 
No Victor is incorrect as there is no multiple inheritance going on
here; it follows that you are also incorrect and that I am actually correct.
 
/Flibble
Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 10:50AM -0700

On Monday, 21 March 2016 17:01:40 UTC, Alf P. Steinbach wrote:
 
[...]
> Zaphod is quoting out of context, and ignoring the context in his
> simplistic argumentation.
 
Huh?! What are you talking about? I am not quoting out of context at all. Are you sure you got what I wrote?
 
> That's typical trolling behavior and I think I recall the nick as a
> well-known clc++ troll way back.
 
Huh?! What?!?!??
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 21 06:52PM +0100

On 21.03.2016 18:43, Mr Flibble wrote:
>>>>> Properties
>>>>> - Color
>>>>> - Brush...
 
As I see it a/the reasonable interpretation of the original posting is
that there is no real diamond inheritance pattern. Victor's posting,
assuming diamond inheritance, appeared to be be made in haste, misled by
the very misleading figure. Such things happen. :/
 
Cheers!,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 21 05:53PM

On 21/03/2016 16:32, Zaphod Beeblebrox wrote:
 
>> It has nothing to do with the attributes; the derived class may or may not have
>> additional attributes or it may hide attributes in the base class.
 
> I am not talking about the class members. I used quotes around that noun. I am talking about 'the attribute of being an Employee'. You qualify a person as an "employee". This specializes a person and, at the same time, *extends* a person with the attribute of being an employee. So does a manager with regard to an employee. A person is a person. An employee is a person *AND* an employee. A manager is a person, *AND* an employee, *AND* a manager. Each sub-type extends the base type, though it gets more and more specialized.
 
As far as the OP is concerned a circle is-a ellipse with both radii
being the same; the circle class could hide some of ellipse base class
member functions (so only one radii can be set) but given it is-a
ellipse the circle class must override the radii set functions to ensure
that it remains a circle (setting one radii will set the other radii to
be the same) but it is doubtful that this behaviour satisfies the Liskov
Substitution Principle as an ellipse can have two different radii.
 
/Flibble
Wouter van Ooijen <wouter@voti.nl>: Mar 21 07:02PM +0100

Op 21-Mar-16 om 6:53 PM schreef Mr Flibble:
> be the same) but it is doubtful that this behaviour satisfies the Liskov
> Substitution Principle as an ellipse can have two different radii.
 
> /Flibble
 
Watch yourself Fibble, you are making sense and that worries me. Out of
sausages?
 
Actually modeling a circle this way as a specialized subtype of ellipse
totally violates Liskov, unless of course the ellipse makes no promises
about being able to represent all elipses.
 
Wouter
"Öö Tiib" <ootiib@hot.ee>: Mar 21 11:21AM -0700

On Monday, 21 March 2016 19:50:25 UTC+2, Zaphod Beeblebrox wrote:
> > Zaphod is quoting out of context, and ignoring the context in his
> > simplistic argumentation.
 
> Huh?! What are you talking about? I am not quoting out of context at all. Are you sure you got what I wrote?
 
Yes, what you did looked indeed as contextomy. You cut his sentence.
That skewed the meaning of it. Then you replied to something that he
did not write. Do not do that since it is "informal fallacy" or when
put more strongly then it is a form of lying.
Jens Kallup <jkallup@web.de>: Mar 21 07:51PM +0100

Hello,
 
Thanks to all here in the group thread.
Please don't worry about, that i dont message you.
I found relevant documentation over virtual and
abstract classes virtual methods, ctor's and d'tors.
 
Also thanks to the tip with the Design.
It was not my homework :-) I am a little bit out of
date - a lazy 37 years old non-profit programmer.
More like a Hobbit.
 
I don't want to initial a flamewar, sorry.
 
When you spoke over collections - do you mean
containers? vectors?
 
Should I use -std-c++11 ? 14?
Is Linux gcc 4.9 to old?
 
Ok, I stop here - Questions over Questions :-)
 
TIA
Jens
Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 03:12PM -0400

On 3/21/2016 12:24 PM, Zaphod Beeblebrox wrote:
 
> [...]
>> Nope, I'm talking about inheritance.
 
> Okay, you need to make things clear in your mind and stop arguing just for the sake of it. If you say "Inheritance is always a 'type of' relationship", you are saying that inheritance is always sub-typing, therefore is always sub-classing.
 
I'm not the one arguing here. It is YOU trying to tell me what I am
talking about.
 
And you are the one who said there is a difference between inheritance
and subclassing. I use the term Inheritance as it is used in OOAD and
in C++.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 03:18PM -0400

On 3/21/2016 12:32 PM, Zaphod Beeblebrox wrote:
 
> [...]
>> More specific by definition means further restrictions.
 
> "More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends.
 
Wrong again. For instance, a Square is a type of Rectangle. However,
it does limit the base class's behavior because drawing a Square
requires all four sides to be the same length. And a Rectangle will
have length and width, but a Square will only have size. The derived
class Square changes the behavior of the Rectangle class.
 
And the derived class can even overload functions such that the base
class function is no longer available nor is it invoked. For instance,
the Square class can overload Height and Width related get/set members
of the Rectangle class such that those functions are not used for a
Square class object.
 
>> It has nothing to do with the attributes; the derived class may or may not have
>> additional attributes or it may hide attributes in the base class.
 
> I am not talking about the class members. I used quotes around that noun. I am talking about 'the attribute of being an Employee'. You qualify a person as an "employee". This specializes a person and, at the same time, *extends* a person with the attribute of being an employee. So does a manager with regard to an employee. A person is a person. An employee is a person *AND* an employee. A manager is a person, *AND* an employee, *AND* a manager. Each sub-type extends the base type, though it gets more and more specialized.
 
Which is what I said in the first place, and you argued was not true.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 21 07:35PM

On 21/03/2016 19:18, Jerry Stuckle wrote:
> requires all four sides to be the same length. And a Rectangle will
> have length and width, but a Square will only have size. The derived
> class Square changes the behavior of the Rectangle class.
 
Shall we play spot the logical fallacy?
 
Read a book mate.
 
[snip]
 
/Flibble
Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 03:47PM -0400

On 3/21/2016 3:35 PM, Mr Flibble wrote:
>> have length and width, but a Square will only have size. The derived
>> class Square changes the behavior of the Rectangle class.
 
> Shall we play spot the logical fallacy?
 
No fallacy - excerpted from real code I've used over the years.
 
> Read a book mate.
 
> [snip]
 
> /Flibble
 
I would suggest you do so - but I know you can't read.
 
And I'm not your mate.
 
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 21 08:27PM

On 21/03/2016 19:47, Jerry Stuckle wrote:
 
>> [snip]
 
>> /Flibble
 
> I would suggest you do so - but I know you can't read.
 
I suggest you start your learning by reading about the Liskov
Substitution Principle.
 
/Flibble
Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 04:30PM -0400

On 3/21/2016 4:27 PM, Mr Flibble wrote:
 
> I suggest you start your learning by reading about the Liskov
> Substitution Principle.
 
> /Flibble
 
I suggest you start with a basic text on OOAD. Nothing I have said
violates Liskov.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 21 08:42PM

On 21/03/2016 20:30, Jerry Stuckle wrote:
 
>> /Flibble
 
> I suggest you start with a basic text on OOAD. Nothing I have said
> violates Liskov.
 
Yes it does.
 
Go read.
 
/Flibble
Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 11:06AM -0700

On Wednesday, 16 March 2016 19:48:09 UTC, Alf P. Steinbach wrote:
 
[...]
> it does not make sense
> in C++ to have a Rational base class and an Integer derived class,
 
So how come it is perfectly sensible for you to have an Ellipse (2 axes) as a base class, and a Circle (just its radius) as a derived class? Isn't the set of circles contained in the set of ellipses? Having an Integer derived from a Rational is perfectly sensible, as integers *ARE* rationals: 1/1, 2/1, 3/1, 4/1, 5/1, ... and subclassing means creating an "is-a" relationship.
 
Note that I do not necessarily agree that classes should be designed that way, as I said. Things in OO may be different than set theory. It's not that easy: should in OO a circle be derived from an ellipse, or vice versa? Should an integer be derived from a rational or vice versa? At least, though, the principle should be consistent.
Wouter van Ooijen <wouter@voti.nl>: Mar 21 07:15PM +0100

Op 21-Mar-16 om 7:06 PM schreef Zaphod Beeblebrox:
>> in C++ to have a Rational base class and an Integer derived class,
 
> So how come it is perfectly sensible for you to have an Ellipse (2 axes) as a base class, and a Circle (just its radius) as a derived class? Isn't the set of circles contained in the set of ellipses? Having an Integer derived from a Rational is perfectly sensible, as integers *ARE* rationals: 1/1, 2/1, 3/1, 4/1, 5/1, ... and subclassing means creating an "is-a" relationship.
 
> Note that I do not necessarily agree that classes should be designed that way, as I said. Things in OO may be different than set theory. It's not that easy: should in OO a circle be derived from an ellipse, or vice versa? Should an integer be derived from a rational or vice versa? At least, though, the principle should be consistent.
 
It is not the attributes but the contracts that determines the
inheritance hierargy.
 
If a rational can (according to its contract) store the value 1/2, then
you can't derive integer from rational.
 
If integer values are guranteed to be a whole number, then you can't
derive rational from integer.
 
Note that things get different for non-mutable classes.
 
Wouter
woodbrian77@gmail.com: Mar 21 09:57AM -0700

On Monday, March 21, 2016 at 11:10:31 AM UTC-5, Daniel wrote:
 
> > "Jesus often insisted that trees which do not bear good fruit
> > will be cut down (Matthew 7:19; Luke 13:6-9).
 
> Interesting. But couldn't the same be said about C++ Middleware Writer?
 
Noah may have been asked something similar. It hadn't
even rained prior to the flood and it took them over
100 years to build the ark.
 
Although the C++ Middleware Writer isn't a financial
success yet, it has been helpful in terms of learning
and keeping my skills fresh. I don't think anyone
would deny that it covers a number of interesting
topics -- on line services, serialization, messages, etc.
 
 
Brian
Ebenezer Enterprises - "Unless the L-rd builds the house,
they labor in vain that build it." Psalms 127:1
bitrex <bitrex@de.lete.earthlink.net>: Mar 21 12:38PM -0400


> Out of curiosity, what's the range and precision of x that you need to
> support (including things like NaNs, zeros and Infs), and what
> precision can you live with in the result?
 
The function is for a "truncated exponential" involving e^(-3x).
The precision is not terribly critical, as it's just going to be
used to control the amplitude of other functions (audio
synthesis.) So 1 LSB maybe? There will be linear interpolation
happening as well so it might be good to store the derivative as
well.
 
I'm mobile and don't have the code in front of me, IIRC the full
function is something like MAGIC_NUMŨ(1 - e^(-3x)).
 
Input will actually be floats, with a domain between 0 and 1.0 at
256 steps. The result will then be shifted and cast to a unit 16
full with fractional representaton and stored.
 
Thanks so much for your help.
 
--
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
bitrex <bitrex@de.lete.earthlink.net>: Mar 21 12:39PM -0400


> Out of curiosity, what's the range and precision of x that you need to
> support (including things like NaNs, zeros and Infs), and what
> precision can you live with in the result?
 
The function is for a "truncated exponential" involving e^(-3x).
The precision is not terribly critical, as it's just going to be
used to control the amplitude of other functions (audio
synthesis.) So 1 LSB maybe? There will be linear interpolation
happening as well so it might be good to store the derivative as
well.
 
I'm mobile and don't have the code in front of me, IIRC the full
function is something like MAGIC_NUMŨ(1 - e^(-3x)).
 
Input will actually be floats, with a domain between 0 and 1.0 at
256 steps. The result will then be shifted and cast to a unit 16
full with fractional representaton and stored.
 
Thanks so much for your help.
 
--
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
woodbrian77@gmail.com: Mar 21 08:10AM -0700

On Sunday, March 20, 2016 at 10:07:13 PM UTC-5, Öö Tiib wrote:
 
> I meant that fastest feed-back are IDE underlying things red or compiler
> errors about conflicts. The '::std' cooperates with potential ignorance,
> accidents and/or malice by avoiding such compiler errors.
 
 
I agree that detecting potential problems is helpful, but
I'd rather know that the software will work right for
users in their environment.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
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)