G
Goran
First things first. You do understand now that casts you tried to pull
off are UB, right?
Goran.
First things first. You do understand now that casts you tried to pull
off are UB, right?
Goran.
G
Goran
OK, so, let's say that what you say is true... (proof by contradiction
follows...)
In my previous example... What does "a" in "const A* a = b" points to
then? Clearly, b is an array. So what does a points to? To an array of
A, an array of B, or what? Clearly, b is an array, code is legal, no
casting, no funny business...
Further, if a points to an array of A, why incrementing it gives
strange results? If it's an array of B, how can that even compile? (B
__is__ A, but A __is not__ B).
I know that you have no relevant answer to any of these questions, so
I'll give it to you: "a" points to __the first element of "b"__. It
points to no array, ever.
Goran.
P
Paul
First things first. You do understand now that casts you tried to pull
off are UB, right?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
What exactly is UB? Casting in general produces UB, or only when I cast?
Is it a case that you are not interested in discovering the true language
technicalities and that your sole intention is to prove that I am wrong
about something.
G
Goran
In your post here: http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
I claimed that first two casts were UB. You claimed that they were
not. I proved you that they were (read back, please).
Goran.
S
SG
I quoted you correctly. You said "an array is just a pointer". You
used this as subject to one of the threads that spawned over 200 other
posts.
An array is never a pointer. What you tried to say should have been
worded like this: One can use an array expression in contexts where a
pointer is required due to the array-to-pointer standard conversion.
That's about it. You're just being overly broad and imprecise, as
ever. If you want to avoid looking dumb, you should put a little more
effort into precise wording.
Also, it strikes me as odd that a presumably native English speaker
who claims to be smarter than everybody who disagrees with him in here
says "intensive purposes" when "intents and purposes" is what he
meant.
Oh, how could I forget the name calling. Yes, that's definitely
indicating cleverness.
SG
P
Paul
In your post here:
http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
I claimed that first two casts were UB. You claimed that they were
not. I proved you that they were (read back, please).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You haven't proved anything is UB, In C++ casting is not UB , its
conversion form one type to another. Initially you said casting the return
from new was UB but since I have stated the standards states the return from
new must be castable you have changed your tune to , "your cast is UB
because I say so". Your code with assets and comparisons does not prove that
a cast is UB it only proves you can write code that has bugs.
Are you saying that casting a pointer to an array is UB? , Who knows because
you are not being specific, you are simply stating my cast is UB because you
say so.
Is this UB in your mind then:
template <typename T, int S>
T* foo(){
return static_cast<T*>
perator new(S * sizeof(T)));}
int main() {
int (*p)[6] = foo<int[6], 6>();
}
..
P
Paul
SG said:
You do not define what I say , I do.
P
Peter Remmers
Am 31.03.2011 18:01, schrieb SG:
*facepalm*
I kept wondering what was so intensive about the purposes...
Peter
*facepalm*
I kept wondering what was so intensive about the purposes...
Peter
P
Paul
Well keep on wondering maybe one day you will understand.Peter Remmers said:
P
Peter Remmers
Am 31.03.2011 22:28, schrieb Paul:
I guess your repetitive misuse of that expression shows that you
literally "don't know what you're talking about", i.e. what the words
you fail to use actually mean.
I bet you're one of those who don't get there/their/they're right.
Your response only shows that you are unable to own up to your mistakes.
Peter
I guess your repetitive misuse of that expression shows that you
literally "don't know what you're talking about", i.e. what the words
you fail to use actually mean.
I bet you're one of those who don't get there/their/they're right.
Your response only shows that you are unable to own up to your mistakes.
Peter
P
Paul
It wasn't a mistake its a deliberate varaition, unlike your misunderstandingPeter Remmers said:
of C++.
D
Drew Lawson
Intent sieve porpoises?
The very idea is full of holes.
I
Ian Collins
A friend just posted this link on another group:
http://www.politicsforum.org/images/flame_warriors/flame_77.php
I though it apt here as well.
G
Goran
Yes I have. Read this again:
http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
Now... (proof by contradiction follows... Do you know what "proof by
contradiction" means, BTW? I hope so. If not, I hope you can google
it.)
So... See the code? See the line:
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
?
You claimed that one should be able to do it, in this post:
http://groups.google.com/group/comp.lang.c++/msg/310cebb655d59715
So, presuming that your cast is not UB, I made you a bit of code that
uses your cast and doesn't work correctly. I'll repeat offending part,
slightly modified, since you seem to have an issue with assert macro
(a macro is not a statement, which is something you don't seem to
understand well):
Base (*p2)[3] = (Base (*)[3])new Derived[2][3]; // Presumption: no UB
in cast.
const Base& b = p2[0][1];
if (b.i) std::cout << "This is not possible!";
I'll also show you the correct code:
Derived(*p2)[3] = new Derived[2][3];
const Base& b = p2[0][1];
if (b.i) std::cout << "This is not possible!";
Contradiction is: the only difference between these two snippets is
the the cast^^^. If there's no UB in the cast, why doesn't first
snippet work? Answer: cast is UB; by consequence, anything that
follows is wrong.
^^^ Bar the use of Base type. But since e.g. "Base (*p2)[3] = new
Derived[2][3];" doesn't even compile, that's immaterial.
Goran.
P
Paul
Yes I have. Read this again:
http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This is your code that is wrong not the cast. You cannot even explain what
is wrong with the cast in your opinion , its just wrong?
I provided the following code as an alternative which you snipped and
ignored. And you replaced it with your buggy shit code.
The following is the same C cast but in C++ style, is this also UB in your
mind?
template <typename T, int S>
T* foo(){
return static_cast<T*>
perator new(S * sizeof(T)));}
int main() {
int (*p)[6] = foo<int[6], 6>();
}
<Snip>
P
Paul
Yes I have. Read this again:
http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
Now... (proof by contradiction follows... Do you know what "proof by
contradiction" means, BTW? I hope so. If not, I hope you can google
it.)
So... See the code? See the line:
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
?
You claimed that one should be able to do it, in this post:
http://groups.google.com/group/comp.lang.c++/msg/310cebb655d59715
So, presuming that your cast is not UB, I made you a bit of code that
uses your cast and doesn't work correctly. I'll repeat offending part,
slightly modified, since you seem to have an issue with assert macro
(a macro is not a statement, which is something you don't seem to
understand well):
Base (*p2)[3] = (Base (*)[3])new Derived[2][3]; // Presumption: no UB
in cast.
const Base& b = p2[0][1];
if (b.i) std::cout << "This is not possible!";
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This is because you think that the pointer-type Base (*)[3], points to an
array of Base[3], but it doesn't it points to an array of Derived[3].
Its your code that is wrong because you derefernce p2 as if it were a Base,
but it points to a Derived.
p2 returns i*sizeof(Base[3]), this is not the same as
i*sizeof(Derived[3]).
The memory layout of the object array is as follows:
[[Base][Derived]] [[Base][Derived]] [[Base][Dervied]]
You are trying to index this array in chunks sizeof(Base[3]).
This example to shows that the pointer-type does not define the object it
points to.
p2 points to an array of Derived, not an array of Bases.
G
Goran
Problem line is
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
and __you__ wrote it first.
I changed Base in a way that shows that your code won't work. But I
did not change the offending part.
It looks like you think that "not UB" means "seems to work on my
code"?
My explanation is fine compared to your lack of understanding what
"proof by contradiction" means.
Not true. Nothing in what __I__ wrote is wrong. Errors are in what
__you__ have written, that I took over. My purpose was clear: to show
you __how__ and __why__ what you wrote fails. You really seem to think
that "not UB" means "seems to work on my code".
The following is the same C cast but in C++ style, is this also UB in your
mind?
template <typename T, int S>
T* foo(){
return static_cast<T*>
int main() {
int (*p)[6] = foo<int[6], 6>();
}
It does not matter whether cast is C or C++-style.
Yes, this is UB, and it's __much__ worse than your old examples. If
you try this on __any__ type that has a constructor, this is going to
fail __massively__. Just put e.g. this in your main:
std::string (*p)[6] = foo<string[6], 6>();
And watch this lunacy of yours fail.
You can legally use static_cast to go from void* to some other type,
that's OK, but that does not mean that code can't exhibit UB.
Goran.
G
Goran
Being polite when asking for help is somewhat better. You might want
to try e.g. this way:
"I don't understand compiler errors. I did ABC, compiler told me XYZ.
What should I do?"
Goran.
G
Goran
First off, p2 is not a Base, it's not even a pointer-to-a-Base, it's a
pointer to Base[3]. But that is irrelevant.
My code is perfectly fine. I can't possibly dereference p2 as if it
were Derived[3], because type of *p2 is Base[3], not Derived[3]. Why
did this happen? Because of __your__ cast, not because of anything in
__my__ code.
Oh. Well, I am glad that you managed to understand the explanation I
gave you earlier.
.... because __your__ cast was UB.
Goran.
P
Paul
Problem line is
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
and __you__ wrote it first.
I changed Base in a way that shows that your code won't work. But I
did not change the offending part.
It looks like you think that "not UB" means "seems to work on my
code"?
My explanation is fine compared to your lack of understanding what
"proof by contradiction" means.
Not true. Nothing in what __I__ wrote is wrong. Errors are in what
__you__ have written, that I took over. My purpose was clear: to show
you __how__ and __why__ what you wrote fails. You really seem to think
that "not UB" means "seems to work on my code".
The following is the same C cast but in C++ style, is this also UB in your
mind?
template <typename T, int S>
T* foo(){
return static_cast<T*>
int main() {
int (*p)[6] = foo<int[6], 6>();
}
It does not matter whether cast is C or C++-style.
Yes, this is UB, and it's __much__ worse than your old examples. If
you try this on __any__ type that has a constructor, this is going to
fail __massively__. Just put e.g. this in your main:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
It's your use of the code that produces undefined behaviour, this code is
identical to the code used in std::allocator.
Just because you can use this code in a way that produces UB does not mean
the code itself produces UB.
If you theory was correct every container in the std lib would produce UB
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
std::string (*p)[6] = foo<string[6], 6>();
And watch this lunacy of yours fail.
You can legally use static_cast to go from void* to some other type,
that's OK, but that does not mean that code can't exhibit UB.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
As I said above you can make almost any code produce UB if you use it
incorrectly. It's not the code I posted that produces UB , its your
incorrect useage of the code.
If you think the code I posted produces UB then just compare that code to
the constructor in std::allocator. As the code is identical you must also
think std::allocator produces UB.
You call it lunacy but its your usage that is lunacy not the code from the
std lib.