Slicing problem

I'd like also to mention that I am wondering if there is a potential way
around it by doing something like

Base& operator=(const Derived& D)
{
data = 0;
return *this;
}
Base(const Base& B)
{
data = 0;
};

So that the Derived class has no way of "screwing" up the data. Ofcourse
this makes the "casting" useless because one can't access D's members and
also assumes that one knows about D in the first place but it seems like a
potential solution in some specific cases?

Lets suppose that in = I can access D, then and from my previous msg about
data having to be < 2 I could do something like

Base& operator=(const Derived& D)
{
if (D.data) > 1
{
// Maybe throw an exception or try to "fix-up"
return NULL;
}

// Derived is "compatible " with Base so "assign"
data = D.new_data;
return *this;
}

Just wondering. Just seems that maybe in some cases there is a way to
convert that won't cause "slicing" problems.

Also, am I right in assuming that the only problems that are involved is of
the Base classes data members that are inherited in Derived? Because Derived
can potentially screw with them in a way that Base didn't intend them to be?
(But ofcourse Base didn't know this)

If so then it seems that since Base knows how it will use its data it could
write

Base& operator=(const Any_Derived_Obj ect_of_Base& D)
{
// Check for a valid compatable conversion of D to B
...

// If all elements can be "converted" then assign them
....
return *this;
}

Ofcourse I don't think C++ has a way to do this since you should have to
overload for all possible Derived classes... I don't think templates would
work?

Anyways.

Thanks,
Jon

* Jon Slaughter:

[essentially, "what's the problem with slicing?"]

Let's first define slicing. It's what you get when you do

baseClassObject = derivedClassObj ect;

where only the BaseClass part of derivedClassObj ect is copied.

Unintentional slicing is a problem, but mostly for novices. E.g., a novice
programmer may not understand that

std::vector<Bas eClass> v;
DerivedClass o;

v.push_back( o );

performs a slicing operation.

Consequently, the novice, especially if coming from a reference-based language
such as Java and C#, may get apparently inexplicable behavior.

From a formal point of view slicing is not in general type safe. For an
example, consider a botched base class design:

class Base
{
private:
int myLength;
char myBuffer[256];
protected:
char* buffer() { return myBuffer; }
char const* buffer() const { return myBuffer; }
virtual int safeIndex( int i ) const
{ if( i >= myLength ) throw GeorgeBush; return i; }
public:
Base(): myLength( 0 ) {}
virtual void add( char ch ) { myBuffer[myLength++] = ch; }
virtual void at( int i ) const { return myBuffer[safeIndex(i)]; }
};

There's so much wrong here I don't care to enumerate it all, but anyways, our
hero the Derived class designer wants to add a conversion to std::string, and,
not having access to 'myLength' in Base, s/he decides to maintain an
independent length indicator in class Derived -- but, since s/he came from
the same university that miseducated the Base class designer, s/he thinks it
would be _inefficient_ to call the base class 'add', and so ends up with:

class Derived: public Base
{
private:
int myBufferLength;
protected:
virtual int safeIndex( int i ) const
{ if( i >= myBufferLength ) throw GeorgeBush; return i; }
public:
Derived(): myBufferLength( 0 ) {}
virtual void add( char ch ) { buffer()[myBufferLength+ +] = ch; }
virtual std::string asString() const
{ return std::string( myBuffer, myBuffer + myBufferLength ); }
};

Oh goody!

Now a Derived object works fine as long as it's treated as a Derived object,
even when it's accessed via a Base pointer or reference. However,
Base::myLength is _never_ updated from its original zero value. So, if you
slice a Derived to a Base, then you get an apparently entirely different
"value". And with some classes that may even break basic assumptions, the
class invariant. Which is where type safety enters the picture.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Mon, 19 Sep 2005 19:34:24 -0500, "Jon Slaughter"
<Jo***********@ Hotmail.com> wrote in comp.lang.c++:

I'm having a little trouble understanding what the slicing problem is.

In B.S.'s C++ PL3rdEd he says

"Becayse the Employee copy functions do not know anything about Managers,
only the Employee part of Manager is copied. "....

and gives the code above as

....
Employee e = m;
e = ml
You have a problem with terminology which may reflect a misconception,
the first instance coming up in the next line.
I fail to see how this is a problem as we are "casting" m into e and ^^^^^^^

You are not "casting" anything. A cast in C++ is performed only by
one of the cast operators, either the C style cast or one of the newer
type of classes. You cannot cast aggregate (arrays, classes, structs)
at all. You can only cast built-in scalar types (integer types,
floating point types, and pointers).

A cast is an explicit conversion. What is happening in your snippet
above is an automatic conversion caused by assignment. There is no
cast involved.

This is basically no different than the following:

double d = 3.14159;
int i = d;

There is no cast involved, but an automatic conversion of the value of
the double to an int. The result is well-defined as long as the whole
number part of the double is within the range of an int.

This assignment truncates, that is it "slices" off the fractional part
of the double. It is lost and gone forever, as far as 'i' is
concerned. There is no way to tell what the fractional part of the
double was just from looking at 'i'.

i = 3.0; // yields 3
i = 3.4; // yields 3
i = 3.9; // yields 3

So 'i' is part of 'd' with the other part "sliced" off and discarded.
obviously Employee shouldn't copy anything of m into e because that is not
already in e itself(where would it go?)?

I was thinking that "slicing" refered to an object being "sliced" in half by
not being copyied all the way so it would be seem that if we did something
like
Yes, part of 'm' has been sliced off and thrown away because it would
not fit into 'e'. If you assign 'e' back to another 'm', you don't
recover the part that was sliced off.
Manager m = e;

then we would have "sliced" m in half by only assigning those elements of m
that are also of e?
The slice comes off the value assigned, not the object it is assigned
to. 'm' has not been sliced at all, it is all there, although some of
its members are not initialized. And 'e' has not bee sliced, because
all of it is there.
This seems strange to me though.

By analogy if a derived object is larger than its base and we are casting
from a derived object into its base then we are "slicing" off the parts of
the derived object that don't fit into the base? But isn't that the whole
point? Else we wouldn't do the code to do the slice in the first place?
As already pointed out in another reply, slicing is almost always a
mistake on the part of the programmer. It is assigning objects rather
than using pointers.
Maybe I'm making it into a problem when its not? It just mentions that it
can be a source of suprices and errors but I don't see how unless someone
isn't really thinking about what is happening.

If I do something like:

Derived D;
Base B = D;

then potentially I see how that Derived could change a value that I normally
except Base wouldn't not expect to see.

struct Base
{
int data;
Base(int i) : data(i) {};
};
struct Derived : public Base
{
int new_data;
Derived(int i) : Base(i+1), new_data(4) {};
};

void main()
{
Derived D(1);
Base B = D;

return;
}

then, lets suppose that Base's data is never suppose to be > 1...

but B has B.data = 2 after the assignment and hence hence there is an error.

Is that the basic idea?

As for the fact that one might allow an inherited member in a derived
class take on values that are not allowed in the base class, that
could be a problem, if you actually wanted to use slicing on purpose.
But that is rarely the case.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

I suggest you really loose your attitude and also stop spreading
mis-information. You say my whole problem is based on a misconception of a
cast yet you obviously seem to have a misconception of your own. I suggest
you read C++ 3rd Ed page 407-408. Your ego seems to be a little bloated.

First off it doesn't matter what term I use if as long as the concept behind
it is adequate... in this case it is, specially since I used "casting" and
not casting. Secondly I suppose you should go call B.S. up and tell him he
as a misconception too because in his book he defines casting almost exactly
as I have used it. Third, It doesn't matter if its an implied cast or if
its an explict cast, its still a cast. A cast is a conversion from one type
to another... its that simple.

You wouldn't look so stupid if you didn't have such an ego.

Jon
"Jack Klein" <ja*******@spam cop.net> wrote in message
news:2f******** *************** *********@4ax.c om...

On Mon, 19 Sep 2005 19:34:24 -0500, "Jon Slaughter"
<Jo***********@ Hotmail.com> wrote in comp.lang.c++:

I'm having a little trouble understanding what the slicing problem is.

In B.S.'s C++ PL3rdEd he says

"Becayse the Employee copy functions do not know anything about Managers,
only the Employee part of Manager is copied. "....

and gives the code above as

....
Employee e = m;
e = ml

You have a problem with terminology which may reflect a misconception,
the first instance coming up in the next line.

I fail to see how this is a problem as we are "casting" m into e and

^^^^^^^

You are not "casting" anything. A cast in C++ is performed only by
one of the cast operators, either the C style cast or one of the newer
type of classes. You cannot cast aggregate (arrays, classes, structs)
at all. You can only cast built-in scalar types (integer types,
floating point types, and pointers).

A cast is an explicit conversion. What is happening in your snippet
above is an automatic conversion caused by assignment. There is no
cast involved.

This is basically no different than the following:

double d = 3.14159;
int i = d;

There is no cast involved, but an automatic conversion of the value of
the double to an int. The result is well-defined as long as the whole
number part of the double is within the range of an int.

This assignment truncates, that is it "slices" off the fractional part
of the double. It is lost and gone forever, as far as 'i' is
concerned. There is no way to tell what the fractional part of the
double was just from looking at 'i'.

i = 3.0; // yields 3
i = 3.4; // yields 3
i = 3.9; // yields 3

So 'i' is part of 'd' with the other part "sliced" off and discarded.

obviously Employee shouldn't copy anything of m into e because that is
not
already in e itself(where would it go?)?

I was thinking that "slicing" refered to an object being "sliced" in half
by
not being copyied all the way so it would be seem that if we did
something
like

Yes, part of 'm' has been sliced off and thrown away because it would
not fit into 'e'. If you assign 'e' back to another 'm', you don't
recover the part that was sliced off.

Manager m = e;

then we would have "sliced" m in half by only assigning those elements of
m
that are also of e?

The slice comes off the value assigned, not the object it is assigned
to. 'm' has not been sliced at all, it is all there, although some of
its members are not initialized. And 'e' has not bee sliced, because
all of it is there.

This seems strange to me though.

By analogy if a derived object is larger than its base and we are casting
from a derived object into its base then we are "slicing" off the parts
of
the derived object that don't fit into the base? But isn't that the
whole
point? Else we wouldn't do the code to do the slice in the first place?

As already pointed out in another reply, slicing is almost always a
mistake on the part of the programmer. It is assigning objects rather
than using pointers.

Maybe I'm making it into a problem when its not? It just mentions that
it
can be a source of suprices and errors but I don't see how unless someone
isn't really thinking about what is happening.

If I do something like:

Derived D;
Base B = D;

then potentially I see how that Derived could change a value that I
normally
except Base wouldn't not expect to see.

struct Base
{
int data;
Base(int i) : data(i) {};
};
struct Derived : public Base
{
int new_data;
Derived(int i) : Base(i+1), new_data(4) {};
};

void main()
{
Derived D(1);
Base B = D;

return;
}

then, lets suppose that Base's data is never suppose to be > 1...

but B has B.data = 2 after the assignment and hence hence there is an
error.

Is that the basic idea?

As for the fact that one might allow an inherited member in a derived
class take on values that are not allowed in the base class, that
could be a problem, if you actually wanted to use slicing on purpose.
But that is rarely the case.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

"Alf P. Steinbach" <al***@start.no > wrote in message
news:43******** ********@news.i ndividual.net.. .

* Jon Slaughter:

[essentially, "what's the problem with slicing?"]
Let's first define slicing. It's what you get when you do

baseClassObject = derivedClassObj ect;

where only the BaseClass part of derivedClassObj ect is copied.

Unintentional slicing is a problem, but mostly for novices. E.g., a
novice
programmer may not understand that

std::vector<Bas eClass> v;
DerivedClass o;

v.push_back( o );

performs a slicing operation.

Consequently, the novice, especially if coming from a reference-based
language
such as Java and C#, may get apparently inexplicable behavior.

From a formal point of view slicing is not in general type safe. For an
example, consider a botched base class design:

class Base
{
private:
int myLength;
char myBuffer[256];
protected:
char* buffer() { return myBuffer; }
char const* buffer() const { return myBuffer; }
virtual int safeIndex( int i ) const
{ if( i >= myLength ) throw GeorgeBush; return i; }
public:
Base(): myLength( 0 ) {}
virtual void add( char ch ) { myBuffer[myLength++] = ch; }
virtual void at( int i ) const { return myBuffer[safeIndex(i)]; }
};

There's so much wrong here I don't care to enumerate it all, but anyways,
our
hero the Derived class designer wants to add a conversion to std::string,
and,
not having access to 'myLength' in Base, s/he decides to maintain an
independent length indicator in class Derived -- but, since s/he came
from
the same university that miseducated the Base class designer, s/he thinks
it
would be _inefficient_ to call the base class 'add', and so ends up with:

class Derived: public Base
{
private:
int myBufferLength;
protected:
virtual int safeIndex( int i ) const
{ if( i >= myBufferLength ) throw GeorgeBush; return i; }
public:
Derived(): myBufferLength( 0 ) {}
virtual void add( char ch ) { buffer()[myBufferLength+ +] = ch; }
virtual std::string asString() const
{ return std::string( myBuffer, myBuffer + myBufferLength ); }
};

Oh goody!

Now a Derived object works fine as long as it's treated as a Derived
object,
even when it's accessed via a Base pointer or reference. However,
Base::myLength is _never_ updated from its original zero value. So, if
you
slice a Derived to a Base, then you get an apparently entirely different
"value". And with some classes that may even break basic assumptions, the
class invariant. Which is where type safety enters the picture.

Ok, I think I get the gist of it. Its more of a programming logic error than
anything? The coder not realizing what ill-effects the casting will cause
and its not a problem otherwise.

A similar situation would be casting a double into a float where the
programmer has not thought about this cast causing problems but in some
situations it might... class casting just seems more complicated because its
not a simple data type and requires more though?

Thanks,

Jon

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Thu, 22 Sep 2005 16:00:59 -0500, "Jon Slaughter"
<Jo***********@ Hotmail.com> wrote:

I suggest you really loose your attitude and also stop spreading
mis-information. You say my whole problem is based on a misconception of a
cast yet you obviously seem to have a misconception of your own. I suggest
you read C++ 3rd Ed page 407-408. Your ego seems to be a little bloated.
We'll leave it open who should change their attitude. I don't think it
is Jack, because his reply was very much to the point, and factually
correct.
First off it doesn't matter what term I use if as long as the concept behind
it is adequate... in this case it is, specially since I used "casting" and
not casting. Secondly I suppose you should go call B.S. up and tell him he
as a misconception too because in his book he defines casting almost exactly
as I have used it. Third, It doesn't matter if its an implied cast or if
its an explict cast, its still a cast. A cast is a conversion from one type
to another... its that simple.
The C++ standard is a little more up-to-date than B.S. "TC++PL". He
has worked together with the standards committee from day 1, though,
so you should always refer to the C++ standard if something in his
book is not completely clear.

Casting is not a conversion. Casting means you are telling the
compiler "trust me, I know what I am doing" because otherwise you
would probably get a compiler error.

C++ has static_cast, dynamic_cast, const_cast, and reinterpret_cas t.
Each one does something different. Then there are C-style casts which
are most similar to reinterpret_cas t, but also different
(reinterpret_ca st only works between pointers and other pointers, or
pointers and built-in types such as integers). These are all what are
called "explicit casts". You need to know exactly what they do and how
they differ. Any modern C++ text book will show the details.

Assigning an object of one type to an object of another type WITHOUT
using any of the above mechanisms is what is called an "implicit
conversion" -- there is no such thing as an implicit cast; neither is
there an explicit conversion, only explicit casts. There are certain
limitations on what can be converted implicitly; chapter 13.3.3.1 of
the C++ standard will enlighten you.
You wouldn't look so stupid if you didn't have such an ego.
Ever looked in the mirror lately?

Jon
"Jack Klein" <ja*******@spam cop.net> wrote in message
news:2f******* *************** **********@4ax. com...

On Mon, 19 Sep 2005 19:34:24 -0500, "Jon Slaughter"
<Jo***********@ Hotmail.com> wrote in comp.lang.c++:

I'm having a little trouble understanding what the slicing problem is.

In B.S.'s C++ PL3rdEd he says

"Becayse the Employee copy functions do not know anything about Managers,
only the Employee part of Manager is copied. "....

and gives the code above as

....
Employee e = m;
e = ml

You have a problem with terminology which may reflect a misconception,
the first instance coming up in the next line.

I fail to see how this is a problem as we are "casting" m into e and

^^^^^^^

You are not "casting" anything. A cast in C++ is performed only by
one of the cast operators, either the C style cast or one of the newer
type of classes. You cannot cast aggregate (arrays, classes, structs)
at all. You can only cast built-in scalar types (integer types,
floating point types, and pointers).

A cast is an explicit conversion. What is happening in your snippet
above is an automatic conversion caused by assignment. There is no
cast involved.

This is basically no different than the following:

double d = 3.14159;
int i = d;

There is no cast involved, but an automatic conversion of the value of
the double to an int. The result is well-defined as long as the whole
number part of the double is within the range of an int.

This assignment truncates, that is it "slices" off the fractional part
of the double. It is lost and gone forever, as far as 'i' is
concerned. There is no way to tell what the fractional part of the
double was just from looking at 'i'.

i = 3.0; // yields 3
i = 3.4; // yields 3
i = 3.9; // yields 3

So 'i' is part of 'd' with the other part "sliced" off and discarded.

obviously Employee shouldn't copy anything of m into e because that is
not
already in e itself(where would it go?)?

I was thinking that "slicing" refered to an object being "sliced" in half
by
not being copyied all the way so it would be seem that if we did
something
like

Yes, part of 'm' has been sliced off and thrown away because it would
not fit into 'e'. If you assign 'e' back to another 'm', you don't
recover the part that was sliced off.

Manager m = e;

then we would have "sliced" m in half by only assigning those elements of
m
that are also of e?

The slice comes off the value assigned, not the object it is assigned
to. 'm' has not been sliced at all, it is all there, although some of
its members are not initialized. And 'e' has not bee sliced, because
all of it is there.

This seems strange to me though.

By analogy if a derived object is larger than its base and we are casting
from a derived object into its base then we are "slicing" off the parts
of
the derived object that don't fit into the base? But isn't that the
whole
point? Else we wouldn't do the code to do the slice in the first place?

As already pointed out in another reply, slicing is almost always a
mistake on the part of the programmer. It is assigning objects rather
than using pointers.

Maybe I'm making it into a problem when its not? It just mentions that
it
can be a source of suprices and errors but I don't see how unless someone
isn't really thinking about what is happening.

If I do something like:

Derived D;
Base B = D;

then potentially I see how that Derived could change a value that I
normally
except Base wouldn't not expect to see.

struct Base
{
int data;
Base(int i) : data(i) {};
};
struct Derived : public Base
{
int new_data;
Derived(int i) : Base(i+1), new_data(4) {};
};

void main()
{
Derived D(1);
Base B = D;

return;
}

then, lets suppose that Base's data is never suppose to be > 1...

but B has B.data = 2 after the assignment and hence hence there is an
error.

Is that the basic idea?

As for the fact that one might allow an inherited member in a derived
class take on values that are not allowed in the base class, that
could be a problem, if you actually wanted to use slicing on purpose.
But that is rarely the case.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

--
Bob Hairgrove
No**********@Ho me.com

"Bob Hairgrove" <in*****@bigfoo t.com> wrote in message
news:n3******** *************** *********@4ax.c om...

On Thu, 22 Sep 2005 16:00:59 -0500, "Jon Slaughter"
<Jo***********@ Hotmail.com> wrote:

I suggest you really loose your attitude and also stop spreading
mis-information. You say my whole problem is based on a misconception of
a
cast yet you obviously seem to have a misconception of your own. I
suggest
you read C++ 3rd Ed page 407-408. Your ego seems to be a little bloated.
We'll leave it open who should change their attitude. I don't think it
is Jack, because his reply was very much to the point, and factually
correct.

Not really. I'd believe B.S. over Jack any day.

First off it doesn't matter what term I use if as long as the concept
behind
it is adequate... in this case it is, specially since I used "casting" and
not casting. Secondly I suppose you should go call B.S. up and tell him
he
as a misconception too because in his book he defines casting almost
exactly
as I have used it. Third, It doesn't matter if its an implied cast or if
its an explict cast, its still a cast. A cast is a conversion from one
type
to another... its that simple.

The C++ standard is a little more up-to-date than B.S. "TC++PL". He
has worked together with the standards committee from day 1, though,
so you should always refer to the C++ standard if something in his
book is not completely clear.

Um, B.S. wrote C++ and so, as I said, I trust him much more. The point is
not that I AM 100% right and you should get that through your head. THAT IS
WHY I USED QUOTES. But to act like my whole misunderstandin g stems from the
fact that I used "cast" instead of conversion is a bunch of BS.

You know, he could have just said "Its more proper to say conversion than to
say casting" or something like that and not is "tirade"(no tice the quotes)
that my whole problem is simply because I used the wrong word... which is
complete BS... Doesn't matter if I call an apple a fucking_asshole as long
as anyone who I say it to can understand what I mean in the context...
ofcourse they can correct me but theres a right way to do it and a wrong
way.

Casting is not a conversion. Casting means you are telling the
compiler "trust me, I know what I am doing" because otherwise you
would probably get a compiler error.

Sure it is, um.. what is a conversion then??
C++ has static_cast, dynamic_cast, const_cast, and reinterpret_cas t.
Each one does something different. Then there are C-style casts which
are most similar to reinterpret_cas t, but also different
(reinterpret_ca st only works between pointers and other pointers, or
pointers and built-in types such as integers). These are all what are
called "explicit casts". You need to know exactly what they do and how
they differ. Any modern C++ text book will show the details.

Yes, as also an implicit and explicit cast(BUT THEY ARE CASTS NONE THE
LESS!). So B.S.'s book isn't modern?
Assigning an object of one type to an object of another type WITHOUT
using any of the above mechanisms is what is called an "implicit
conversion" -- there is no such thing as an implicit cast; neither is
there an explicit conversion, only explicit casts. There are certain
limitations on what can be converted implicitly; chapter 13.3.3.1 of
the C++ standard will enlighten you.

omg! You act like the difference between casting and converting is the same
as the difference between the Sun and the Moon. Tell my why there isn't
such a thing as an implicit cast? double d = 3.2; int i = d; your saying
that there is an implicit conversion but that is not an implicit cast...
sounds to me like you are just making up something to support jack...
Doesn't matter what you call it, the difference has nothing to do with my
original problem....

Theres a difference between syntax and semantics and you should know that if
you know programming. One can have the wrong syntax but right semantics.
Such as dobule d = 3.2; The fucking semantics there is the exact same as
double d = 3.2; (BECAUSE it is implied to be double do with a syntax
error... it is not ambiguous unless dobule has some semantical meaning.. and
it doesn't).... surely you guys learned all about that stuff in your formal
languages class at grad school? Or maybe you forgot?

The problem is, is not that I was right because I'm not saying that... but
what I'm saying is that what was wrong was not the issue(or not the main
issue... and not even close).... and to assume it is and then to farther
make it an issue of ego is, as I say many times, pure BS.
My misconception had nothing to do with using casting instead of converting,
and actually I doubt there would ever be much confusion by using one for the
other, but that the slicing problem is a logical problem and not a language
problem... simply by changing the word casting into converting in my OP
would not have changed that issue.

Basicaly, Jack saw an oppurtunity to show his ego and he did... just as you
are(but not so much, atleast you try to have some restraint unlike our
friend Jack).

You wouldn't look so stupid if you didn't have such an ego.

Ever looked in the mirror lately?

Um...

You do realize that what I did and what he did was two different things? I
do not help someone and at the same time put them down and try to make them
look/feel stupid so I can feel smarter... this is exactly what he, as many
in this group do. That is uncalled for and when it happens they deserve to
be called on it. Even if I make a blatent stupid mistake I shouldn't be
berated for it or made to feel stupid AND specially when the poster doing it
makes a fucking illogical mistake about it.

Its the same shit when you argue with someone and then they revert to the
"... and your grammar sucks" type of argument. I have every right to defend
myself and not for me but for others that have to put up with that crap.
All to often I see people in this NG replying like this for no reason(well,
no good reason).

As I have said many times, You don't have to help... no one has a gun to
your head saying you have to hit the reply button. I only do it to put
people like this in there place(atleast the best I can) to others don't have
to deal with this crap.

You don't have to agree or like it but if you don't see a difference then
your just as bad as him. THERES A HUGE DIFFERENCE BETWEEN BEING AN ASSHOLE
AND BEING AN ASSHOLE TO AN ASSHOLE.
BTW, if you notice in Alf's post there is no bullshit like in Jacks. Alf
could have corrected me on the fine details of the difference between
casting and converting if he wanted to but he didn't... either because he
didn't see the difference as being an issue, because he doesn't know, or
because he knows that it has nothing to do with the problem. Jack, OTOH,
decides to correct me, which is fine and dandy, but as I said, he doesn't
have a right to through in his attitude with it.

People "trying to help" others in this NG do not have the right, as far as
we have any rights in this NG, to act like this. I will never act like this
if I was replying to someone that needed help.. unless ofcourse they were
being completely stupid then maybe(such as a troll)... but normally I would
just not reply. I suggest that if you, Jack, or anyone else that is having a
bad day or has to show there ego then should just not reply. ITS THAT
SIMPLE. Then we can stick to the real problems of what this NG is for and
not our personal and emotional ones.

Jon

Jon Slaughter top-posted:

I suggest you really loose your attitude and also stop spreading
mis-information. You say my whole problem is based on a
misconception of a cast yet you obviously seem to have a
misconception of your own. I suggest you read C++ 3rd Ed page
407-408.
This newsgroup is for discussing ISO Standard C++. The words of the
Standard have more importance than the words of some other document.

If I didn't know the meaning of the word "deer", would you refer
me to a modern dictionary, or to Shakespeare?

Section 5.4 of the Standard defines "cast" as "explicit type
conversion".
First off it doesn't matter what term I use if as long as the
concept behind it is adequate...
Obviously it's not adequate, otherwise this discussion would never
have got started. Further, by your definition,

char *ptr = 0;
or
long two = 1 + 1;

is a cast. This doesn't seem like a very useful definition to me.
Third, It doesn't matter if its an implied cast or if its an
explict cast, its still a cast.
You're 100% wrong. It might not matter to you if you call a lemon
an orange, but it matters when other people are tring to understand
you.
A cast is a conversion from one type to another... its that simple.
You're making a basic logic error: although all casts are conversions,
not all conversions are casts. Here's another example of the same
error:

"A cat is an animal... its [sic] that simple. It doesn't matter
if its a small furry animal, or a slimy underwater animal,
its still a cat."
You wouldn't look so stupid if you didn't have such an ego.

You would have a bit more credibility if you started following
the etiquette of this NG, in particular, not top-posting.

>You're 100% wrong. It might not matter to you if you call a lemon

an orange, but it matters when other people are tring to understand
you.

Yadda yadda yadda.. so he haven't *talked* about the concepts too much
apparently and called *type* conversion casting, big deal move on
already.. how many here honestly, when things get downright *rough*
haven't resorted to whipping open a copy of the Standard document?
Thought so.