Slicing problem

[Jon Slaughter]

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


I fail to see how this is a problem as we are "casting" m into e and
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

Manager m = e;

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

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?

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?

Thanks,
Jon

 

[Jon Slaughter]

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_Object_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

 

[Alf P. Steinbach]

* Jon Slaughter:

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

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

baseClassObject = derivedClassObject;

where only the BaseClass part of derivedClassObject is copied.

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

std::vector<BaseClass> 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.

 

[Jack Klein]

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.

 

[Jon Slaughter]

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

 

[Jon Slaughter]

* Jon Slaughter:

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

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

baseClassObject = derivedClassObject;

where only the BaseClass part of derivedClassObject is copied.

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

std::vector<BaseClass> 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

 

[Bob Hairgrove]

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_cast.
Each one does something different. Then there are C-style casts which
are most similar to reinterpret_cast, but also different
(reinterpret_cast 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 Slaughter]

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.

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 misunderstanding 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"(notice 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_cast.
Each one does something different. Then there are C-style casts which
are most similar to reinterpret_cast, but also different
(reinterpret_cast 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).

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

 

[Old Wolf]

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.

 

[persenaama]

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.

 

[Karl Heinz Buchegger]

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.

You know what?
If I make a mistake and use a word in a way it can't be used and somebody
corrects me and goes into great detail to explain to me what is wrong with
my usage and why it can't be used in that context, I say: "Thank you"

Your milage obviously varies as you showed in some other threads.

 

[Bob Hairgrove]

Basicaly, Jack saw an oppurtunity to show his ego and he did.

I still fail to see anything in Jack's post which might have anything
to do with his ego. And I'll leave it at that.

*plonk*

 

[Jon Slaughter]

I still fail to see anything in Jack's post which might have anything
to do with his ego. And I'll leave it at that.

Well, You might be right to some degree but there is a tint of it somewhere
in there. Its along the same lines as when someone points out something in
the code as being wrong when it has absolutely nothing to do with the
problem and acting like that is the whole problem. Now, whether he
intentionaly does it or not is a different story. But to assume that the
other person you are trying to help is an idiot because they are asking for
help isn't being very nice. The whole point being that he is assuming my
whole problem is because I misused a word which is completely wrong. The
problem is that to many people in here are trying to find fault with the
persons response instead of trying to help them. Do you think it would be
appropriate for me to reply to someone asking for help by pointing out all
there spelling and grammar mistakes? Do those pertain to the original
problem?

I guess the problem is that I fail to understand that most of you guys spend
the majority of your life with computers instead of real people and don't
interpersonal communication skills. Sorry. But on the other hand, then, I
don't like to be talked to like a computer ;/ Sorry if I took offense by
that ;/

Jon

 

[Jon Slaughter]

Jon Slaughter top-posted:

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".


Obviously it's not adequate, otherwise this discussion would never
have got started. Further, by your definition,

Thats not true, as you should know. Lots of people just like attention(and
I'm not trying to be one of those people by starting this thread either, I
hope). As you have pointed out "cast" = "explicit type conversion"!!!!
there you go. So if I happen to use it as "cast" = "implicit type
conversion" and you jump all over me then thats your problem... not mine.
the point is that both uses deal with conversion and that my "misconception"
is not 100% over the use of a damn word like Jack wants me to believe.

Why was it so hard for him to point out that "Casting is stated as an
explicit converion and when it is implicit we just say conversion" or
something like that?

I can't believe that you guys fail to see that whether I used the word
"casting" or "conversion" they are related... maybe there is a synatical
difference but that doesn't mean that my whole understanding of somethign is
wrong. As I said before, its fine to point out the difference but to make
it into the issue when it is not is the problem.

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

is a cast. This doesn't seem like a very useful definition to me.




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.


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:

Yeah, but you fail to realize many things. First I put cast in quotes which
means that its not the exact same. jesus christ... second he could easily
have pointed out the difference, third, the problem is slicing had nothing
to do with my "misconception" of casting because the meaning of casting is a
proper sub category of conversion.

Even your logic above is wrong.

the meaning of casting is a subcategory of conversion, it is a derived
meaning of the meaning of conversion and hence has some resemblence of
conversion...

maybe NOT every conversion is a cast BUT SOME are! Your logical fallicy is
to think believe that no cast is a conversion and hence I am wrong is using
what I did.


AS I SAID BEFORE, IT HAS NOTHING TO DO WITH IF I USED THE PROPER WORD OR
NOT! If you would get that through your head.. the original problem doesn't
matter if I use cast or conversion.. If I replaced the original post with
the proper use of casting do you think it would have made the problem go
away? (well, I guess it would have made Jack go away but I still would have
the EXACT same problem).

"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.

OMG, here we go again... so my whole argument is wrong because I top-posted?
Theres a reason I top posted... I'll let you figure it out though.

 

[Jon Slaughter]

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.

Exactly. They act like its the end of the world or something because I
misused a word... because I'm not perfect... and instead of actually helping
me they will run around spending there time looking up definitions to prove
there point and claim that my whole problem stems from my lack of proper use
of the definitions.

Its amazing to me. This seems like a trend amoung programmers... Maybe all
that coffee makes there brain into an anus(heh, I mean, makes them anal).

I'm glad atleast someone understand what I'm trying to point out. Thanks.

Jon

 

[Jon Slaughter]

You know what?
If I make a mistake and use a word in a way it can't be used and somebody
corrects me and goes into great detail to explain to me what is wrong with
my usage and why it can't be used in that context, I say: "Thank you"

Yeah, I agree completely. But do you realize there is a right way and a
wrong way to do this? Specially if its no real fault of my own... I take
B.S. as an authority because he pretty much wrote C++ and so if he uses
casting similar to what I have used then I assume I am correct... and if not
then sure, I have no problem with someone pointed it out.

First off, though, its funny how some of these guys resort to the C++ ISO
standard as the bible and then make a huge issue out of things that do not
really pertain to the real problem.... fine to point out the little issues
but to make it THE issue is plain wrong.

Again, as I have said probably 10 times already, ITS HOW YOU DO IT!! If
someone, and that includes anyone, comes in here to ask for help they do not
deserve to have to deal with this crap(if there question is legit).

Point out the problem but don't act like your some gods gift to
comp.lang.c++. Don't try and act like you are above the person you are
trying to help just because you know more about that subject. I as a tutor
for about 5 years and I'm sure if I acted like that I would have been
slapped eventually, at the very least no one would ask for help from me.

Whole point of helping is to help.. if you don't like helping then don't.
If you get pissed off because someone uses a wrong word then don't help. If
you are so anal about that kinda stuff then don't help... if everyone was
perfect like "you" then they wouldn't be asking for help.



The problem I had, which I might have slightly blown out of proportions,
which I apologize if I did, is

"------------
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.
----------"

When I read this I feel as if he is showing his ego... this is very hard to
tell because, ofcourse, I don't know him and because its only computer
text... but if you read it, it seems as if he is saying that my use of
casting is completely wrong... but this isn't the case.

double d = 3.2;
int i = d;

and

double d = 3.2;
int i = (int)d;

are exactly the same code? hmm, one as an explicit cast and one as a
"implicit" conversion... to me, I know that the first on is "casting"
because the types are different, and if you want to call it "implicit
conversion" to be pedantic then go ahead. But that doesn't mean the concept
behind the two are different. Do you think the compiler really see's a
difference? It knows d and i are different and it has to do a
"conversion"... it inserts the "(int)" behind the scenes? So just because
there is one level of abstraction taking away doesn't mean there is a HUGE
difference that Jack wants me to think.. Technically they have defined it to
mean something very precise but that doesn't mean that if one uses it in an
imprecise way then everything is wrong.

Thats all I'm trying to get across. If you understand the above then you
understand that Jacks point that my own problem is about casting is a little
wrong... and the "You are not "casting" anything" is kinda crap... because
whether I called it casting or converting has nothing to do with the
original problem.

Your milage obviously varies as you showed in some other threads.

Well, I just don't like this kinda crap. My impression is that people like
Jack, Victor, and others seem to think they are better than the rest of us.
Hell, even if they are they have no right to act like it... because if they
do then I have every right to try my best to put them in there place.
Normally I would not do something like that because I don't want to take
things out of context and misinterpret them... but seeing how rampant people
with ego's are on this board I'd rather take that chance. Not for my own
benifit but for others. I could care less about Jacks response and intially
just ignored it for 3 days. I have ignored others before because of that
crap... but then see them do it to others.

I guess programmers aren't taught "If you don't have anything nice to say
don't say it at all"? Again, when you are communicating with people you
have to say things in a way that won't hurt there feelings, etc...
Specially when someone is wrong then you have to show them they are without
making them feel stupid. If you go out of your way to do that then you
deserve whatever you get... if you just imply it you do deserve some of it
too. Jack was a not as bad as most but he's still trying to show how smart
he is. Again though, I don't know Jack and so I could have been completely
wrong... but how you say things is very important and you should do your
best to say them so you don't offend people.

For example, if you were a hostage negotiater you would have to be very
careful not to piss of the bad guys... you try to correct them on there
grammar, for example, or make them feel stupid will just get you fired. I
have no problem with Jack if he wants to be an asshole, say, but if he does
then he deserves the consequences... and again and again and again, he
doesn't have to help if he has to add all that extra bs in it. Though,
ofcourse, maybe english isn't his first language and he has problems with
wording things so they are taking to be mean or arrogant or whatever. If
thats the case then he should learn.

Anyways, I'm not so pissed off at Jack for the way he said it rather than
what he said... basicaly trying to make the issue about some definition when
it pretty much nothing to do with it. Sure, point out my problem and
correct it as simply and quickly as possible then move onto the real problem
and assume that I'm not an idiot(because thats what he assumes, its implied
in the context of that paragraph I quoted).

Jon

 

[Old Wolf]

Why was it so hard for him to point out that "Casting is stated as an
explicit converion and when it is implicit we just say conversion"
or something like that?

Er, he did. In fact here are his exact words:

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

He then went on to explain (politely, IMHO) how slicing comes
about, giving an example with int and double, and then an
example with class types.

Yeah, but you fail to realize many things. First I put cast in
quotes which means that its not the exact same. jesus christ...

"I see"

second he could easily have pointed out the difference,

He did (see above)

Even your logic above is wrong.

the meaning of casting is a subcategory of conversion, it is a derived
meaning of the meaning of conversion and hence has some resemblence of
conversion...

maybe NOT every conversion is a cast BUT SOME are! Your logical fallicy
is to think believe that no cast is a conversion and hence I am wrong
is using what I did.

Huh? All casts are conversions. I've said this repeatedly, I don't see
how you get "no cast is a conversion" from it.

AS I SAID BEFORE, IT HAS NOTHING TO DO WITH IF I USED THE PROPER WORD
OR NOT! If you would get that through your head..

You seem to be still trying to defend your position that implicit
conversions are casts. You need to get through your head that
that is wrong; only explicit conversions are casts.

the original problem doesn't matter if I use cast or conversion..
If I replaced the original post with the proper use of casting do
you think it would have made the problem go away?

It would have made this sub-thread go away. I couldn't care less
about the original problem. I am posting to correct your
misconception about the meaning of the word "cast". Also I am
partly motivated by your abusive reply to Jack Klein, who initially
answered your question (and you seem to have difficulty accepting
when you make a mistake).

well, I guess it would have made Jack go away but I still would
have the EXACT same problem.

If you took in the information in Jack's message, instead of
flaming him, then you wouldn't have the problem any more.

OMG, here we go again... so my whole argument is wrong because
I top-posted?

Please read what people say instead of putting words in their
mouth (fingers?) and then flaming them for it. I said "bit more
credibility", not "whole argument is wrong".

Theres a reason I top posted... I'll let you figure it out though.

Laziness?

 

[Jon Slaughter]

hmm..

You still completely fail to realize that he was making a huge issue out of
nothing... as I have pointed out so many times. Read persenaama's post if
you can't understand mine.

Jon