-
March 22nd, 2013, 08:20 AM
#31
Re: Pseudopointers
Originally Posted by eightyfive
Not like Paul that doesn't know what is 'static' used for, or the other guy that just justify it telling: "it is buggy code".
Others had told you why it was buggy. There was no need for me to repeat what they had said. You seemed to be clinging to the notion that because it worked for you, it was good code. Anybody with a little experience with code like that will tell you what a pain it is to debug, as it appears to work on your computer, but crash or malfunction on your customer's. These days with so many different operating systems in use, so many different networking options and possible configurations, it's really crucial that you write compliant code, rather than relying on specific compiler, OS or hardware behavior, that works randomly rather than by design.
Good luck with that attitude. Personally, I don't think it will get you very far, and coming in as a novice and insulting senior posters such as Paul is beyond ridiculous. What was the point of this thread anyway?
-
March 22nd, 2013, 08:51 AM
#32
Re: Pseudopointers
buggy code?
if the code is "buggy", as you only said (speak for your own please), then why
you tell that to me? is not even my code, is Paul's code. he posted it for
a reason that still I don't understand, and has nothing to do with the topic.
you say "my compiler"? but I just shown you in front of your eyes a working example
using that online c++ compiler. what other compilers do you want me to try so you can
understand?
so I changed the code huh? and tell me does that matter at any point?
10 variables as locals or 10 variables as globals, it's the same d..n thing
as long as they are one next to another in memory.
serious, did you really see my pictures where I shown you the memory addresses
of the 'static' locals and the 'static' globals ?
your code doesn't work, I just arranged to fix it again and again. and made it work
in front of your eyes exposing the very reasons of why used 'static' on the variables and
why they are either local or global in each case. Even why the pointer had to be also 'static'.
(remember you said it hasn't need to be 'static' and was exposed that it needed to be).
so?
so..Paul, your argument is "you changed to globals", are you serious?
I was logging the memory addresses every time in every picture so you can see
the point of getting the one next to another, and considering that was not even
my code. remember that code was posted by you Paul (purpose?).
I don't like to insult people. just said he didn't understand why I used 'static',
see my pictures. really are you not going to comment on them?
seriously guys, I would like to talk with you, for example in a bar taking some beers,
but we can't for now, don't feel like insulted.
Remember this is a discussion, and I said before that I didn't want to fight.
the point? why you ask me about the point if anyway you're not going to respect it.
I posted a lot of images and none of you managed to comment a single line on them.
But just remaining on telling me things that really don't help in any way.
Last edited by eightyfive; March 22nd, 2013 at 08:56 AM.
-
March 22nd, 2013, 09:04 AM
#33
Re: Pseudopointers
Originally Posted by eightyfive
buggy code?
if the code is "buggy", as you only said (speak for your own please), then why
you tell that to me? is not even my code, is Paul's code. he posted it for
a reason that still I don't understand, and has nothing to do with the topic.
you say "my compiler"? but I just shown you in front of your eyes a working example
using that online c++ compiler. what other compilers do you want me to try so you can
understand?
I was talking about your code, and it's been explained why it's buggy a number of times. Which part are you unclear on? What more needs to be said so that you can understand? Undefined behavior is just that. It may work the way you want it to, but it's not guaranteed, and writing code based on implementation specific undefined behavior is a horrible practice, and not one you should be bragging about.
-
March 22nd, 2013, 09:14 AM
#34
Re: Pseudopointers
Originally Posted by GCDEF
I was talking about your code, and it's been explained why it's buggy a number of times. Which part are you unclear on? What more needs to be said so that you can understand? Undefined behavior is just that. It may work the way you want it to, but it's not guaranteed, and writing code based on implementation specific undefined behavior is a horrible practice, and not one you should be bragging about.
Alright, but why you tell me that again? I tell you the reason.
Because Paul came here with ANOTHER code and that brought again the discussion about the un-guaranteed behaviour. So if you are following the thread correctly you shouldn't be talking about the first code again, because that was already clear. We are now talking about the second code, which is Paul's.
So don't mix the first code with the second. We are now talking about the second code, and the following versions (fixes) of it. We shouldn't get back to the first post and comment again on the first code, because was already clear and that was like 3 pages ago.
Also, let me tell something. Since Paul posted his code, which doesn't work for him and for anybody, then I fixed it to work for me and for the ONLINE C++ COMPILER. but obviously, I had to make changes, so I really don't get why you tell me "you have changed it!"?
if I wouldn't have changed it then it wouldn't be working! because the code wasn't working in the first place. Is just about logic
EDIT:
don't escape from commenting my pictures
Last edited by eightyfive; March 22nd, 2013 at 09:17 AM.
-
March 22nd, 2013, 12:42 PM
#35
Re: Pseudopointers
Originally Posted by eightyfive
if I wouldn't have changed it then it wouldn't be working! because the code wasn't working in the first place. Is just about logic
Consider this code snippet:
Code:
int x = 0;
int y = x++ + x++;
The programmer wants the final result to be such that x == 2 and y == 4. He writes a program to test the code snippet, finds that x == 2 and y == 0. No good, so he changes the code snippet to:
Code:
int x = 0;
int y = ++x + ++x;
Compile test, and ta da! He gets the desired result and concludes that the code is working.
The problem is that the code is still not quite working. It looks like it works, but there is undefined behaviour. Change the surrounding code, change the optimisation level, change the compiler version, and well, the answer could be different. This same principle applies to what you are talking about. Your definition of "working" isn't.
Originally Posted by eightyfive
if the code is "buggy", as you only said (speak for your own please), then why
you tell that to me? is not even my code, is Paul's code. he posted it for
a reason that still I don't understand, and has nothing to do with the topic.
Paul's intention is to simplify the code based on your idea to demonstrate some of its flaws. This is a useful tool when demonstrating something, or when debugging overly complex code: find the smallest and simplest (compilable) program that demonstrates the problem.
Originally Posted by eightyfive
I posted a lot of images and none of you managed to comment a single line on them.
Your images show the results you obtained for a particular variant of the code you tested on a particular compiler/system. So, they do not prove anything. That is all there is to comment about them, really, and the point has been repeated in this thread.
Last edited by laserlight; March 22nd, 2013 at 12:55 PM.
-
March 22nd, 2013, 04:32 PM
#36
Re: Pseudopointers
Originally Posted by eightyfive
buggy code?
if the code is "buggy", as you only said (speak for your own please), then why
you tell that to me? is not even my code, is Paul's code. he posted it for
a reason that still I don't understand, and has nothing to do with the topic.
The goal of the code is to see if you can take two independent variables declared "next to each other", and guarantee that you can add an offset to get from variable A to variable B in a consistent manner that works for all compilers and is guaranteed by ANSI/ISO to work. Once you can establish that, then you extend the same concept to 3, 4, 5, or 20 variables.
Then the next question to you would be "why static"? What would be your reasoning? Why not local variables? Why not class member variables? Why did you choose "static"? Is it because they were the only storage types that worked for your small sample? If you had stated "I chose static because variables of static storage are xxxx", then we would probably disagree about "xxxx", but at least we would respect that you were looking for a sound reason.
you say "my compiler"? but I just shown you in front of your eyes a working example
using that online c++ compiler. what other compilers do you want me to try so you can
understand?
Being a C++ programmer for over 2 decades now, I can tell you I have seen code "in front of my eyes" that would crash and burn if compiled with another compiler and run, but happen to work for another compiler. Take this famous example from Visual C++ 5.0:
Code:
int main()
{
char *x = "abc123";
x[0] = 'a';
}
This code would "work" in many compilers, and still "works" for many compilers. But guess what? The code produces undefined behaviour. The above code appeared in a lot of C and C++ code written for early versions of Visual C++. Once that code was ported to later versions of Visual C++, and even ported to other compilers and operating systems, code like the above would crash immediately.
Let's say you had written code similar to the above that didn't crash. Then we tell you "the code produces undefined behaviour". You then show us using your compiler that the code is OK. We show you that running on another compiler the code crashes. We then state to you in the ANSI/ISO document concerning string-literals that writing to a string-literal is undefined behaviour. In other words, we've exhausted ourselves in showing you the code is not sound. That is the situation we find ourselves with the examples you're posting now.
As to compiler, we don't go by which compiler you're using. We are determining whether your code is faulty by referring to the ANSI/ISO standard document. Nowhere in that document is it stated that independent variables must be declared in contiguous memory, similar to an array. This is the technique that all good C++ programmers use -- anything that may work but looks iffy, a good C++ programmer refers to the ANSI standard document to see if what they're doing is guaranteed to work. Some even go to sites such as this or other C++ related sites and politely ask "is what I'm doing guaranteed by the standard to work?".
I just happen to show a simple program that uses your constructs and ideas, and found a compiler where the exact same code produced different results. Even if I didn't go to the online compiler site, the code is still considered causing undefined behaviour. How do we know this? Again -- ANSI/ISO specification, and not by running the code in any compiler.
Now if the ANSI/ISO standard did say that "variables declared in the same context in consecutive lines of code are guaranteed to be contiguous, similar to arrays ,where adding an offset will get you from one previously declared variable to another variable", then online compiler would be considered broken, and you would have a point, but that isn't the case.
The current 2011 ANSI/ISO standard document is expensive, so possibly there are drafts that are free. The 2003 standard was around 20 or 30 US dollars, which is the one that myself and others are using. The 2003 document is over 700 pages and defines everything that a version ANSI/ISO standard compiler must support and how it must behave.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; March 22nd, 2013 at 04:36 PM.
-
March 23rd, 2013, 01:00 AM
#37
Re: Pseudopointers
The funny thing of all this, is that you still are speaking the same
argument that is very obvious to anyone (FOR ME TOO), it's like you need to say it again
so you're going to believe it.
If I'd have need 10 integer vars then I'd have used a 10-member struct or just
an array. But to make my point on the implementation of the pseudopointers, I had
the brilliant idea of using 10 'static', whatever global or local, variables.
You needed 3 pages of a thread to get why I used 'static', I really thought this
was so obvious that I didn't need to say anything about it.
I did later by showing images, your sample code didn't work since it shows
"Not OK" by the screen. and you didn't init the variables and the pointer
wasn't correctly declared (I mean to get that contiguousness). So as obvious it is, your addresses were not
the one next to the other. So I changed to make it work for THAT compiler, but
you said you did want me not to make a modification on it, which has no sense.
I can't get to work a not-working code if I am not allowed to make modifications on it.
Or probably, you'd have needed to give me a working code instead, so that'd have had some sense to test it in other compiler.
I tell you again, that code I posted in the first place, is just to make a point
on the pseudopointers, I'd have probably used an array and would go to loop through
it using the same mode of iteration than in the first code.
and probably you all would be excited because I used an array and not 10 variables.
would it be a really a more complicated way to do things?
probably, but as far as it works and it is another demostrating way to do things,
should not be called anything else but "another way to go".
(I'm talking about pseudopointers now).
Now, regarding the 10 variables, declared as 'static', either local or global, I know
that is just tricky related to some compilers, maybe all, or maybe 2,
I probably had to use an array and not those 10 variables, since my point on the
pseudopointers could have been stated anyways.
But if I used an array, some of you would have told me: "why you did that in that way"
"It's way easier to use an index and loop through an array", so now you see why I used
those 10 vars.
I probably will modify the first code later so I won't be using those 10 variables again.
happy now?
Last edited by eightyfive; March 23rd, 2013 at 01:09 AM.
-
March 23rd, 2013, 05:01 AM
#38
Re: Pseudopointers
premising that I fail to see what this thread is about ( I suppose it's not just to show the trivial fact that one can cast pointer from/to integers, is it ? ), and that I fail to see why you fail to see that randomly "fixing" code does not fix anything at all,
there is another source of non-portability in your code example: note that the standard only guarantees that explicit conversions from integers to pointers and back preserve the original pointer value and nothing else. This means that arithmetic operations ( like increments ) on your "pseudopointers" are not guaranteed to work on all machines.
-
March 23rd, 2013, 05:27 AM
#39
Re: Pseudopointers
I'll make a stew of all exposed codes (buggy codes) XD.
Here's the Paul's code
Code:
#include <iostream>
int main()
{
static int x;
static int y;
int *z = &x + 1; // What is the magic number to add?
printf("%X\n",&x);
printf("%X\n",&y);
printf("%X\n",z);
system("pause");
if ( z==&y )
std::cout << " OK\n"; // how will we get here?
else
std::cout << "Not OK\n";
return 0;
}
For example, if you would like 2 integers to be stored
contiguously, then you can do something like this:
Code:
#include <iostream>
int main()
{
int array[2]={0};
int *z = &array[0] + 1; // What is the magic number to add?
if ( z==&array[1] )
std::cout << " OK\n"; // how will we get here?
else
std::cout << "Not OK\n";
return 0;
}
But getting back to the first code, it wasn't working,
so I went to make some changes and got it to work IN MY COMPILER.
if you give those 2 variables called x and y, an initialization
value then they got stored contiguously.
If you do not, then they're not.
Ok, let's say that now they are contiguously AT LEAST in my compiler,
now if I do this comparision it doesn't come with the expected result.
As you see z is a local pointer variable, that means is in the stack,
but it is just a pointer which holds a memory address.
so why if I do:
it wouldn't work?. don't they mean just 2 memory addresses?
if you like to see it in other look, then see this:
I added another pointer that points to the second variable.
and now
it doesn't work again..
I fixed it in my compiler by making the z pointer variable to be 'static'
Code:
#include <iostream>
int main()
{
static int x=0;
static int y=0;
static int *z = &x + 1; // What is the magic number to add?
printf("%X\n",&x);
printf("%X\n",&y);
printf("%X\n",z);
system("pause");
if ( z==&y )
std::cout << " OK\n"; // how will we get here?
else
std::cout << "Not OK\n";
return 0;
}
so this is working for me, but is not working in other compiler, for example
http://www.compileonline.com/compile_cpp_online.php
but if you want it to work in that online compiler you do:
Code:
#include <iostream>
static int x=0;
static int y=0;
int main()
{
static int *z = &x + 1; // What is the magic number to add?
printf("%X\n",&x);
printf("%X\n",&y);
printf("%X\n",z);
system("pause");
if ( z==&y )
std::cout << " OK\n"; // how will we get here?
else
std::cout << "Not OK\n";
return 0;
}
the other fix that I managed to do is this (Only if they are contiguously stored):
Code:
#include <iostream>
static int x=0;
static int y=0;
int main()
{
int *z = &x + 1; // What is the magic number to add?
printf("%X\n",&x);
printf("%X\n",&y);
printf("%X\n",z);
system("pause");
if ( (z-&y) ==0 )
std::cout << " OK\n"; // how will we get here?
else
std::cout << "Not OK\n";
return 0;
}
As you see, I implemented a substraction of 2 memory addresses,
I assume it won't be get out of the INT valid range, and assuming
the INT type and the memory addresses are of 32 bits.
If the 2 addresses are the same then it will give ZERO as result.
That just works, and the pointer doesn't need to be 'static'.
But all this is relying in the fact that if the 2 variables will be
stored contiguously in memory. That is not guaranteed by the C++ specifications.
and I understand that is not the case of making fixes for every compiler.
You just said: "it's buggy code" ,
if that is the case I will be not discussing anymore on this, instead I will change my first
code to use an array or maybe a struct. Because every compiler seems to handle storage
in its own way (at least for the contiguousness).
EDIT:
I added the new code in the first post, now there are 3 examples of implementation.
(The first example is considered with an undefined behaviour).
Last edited by eightyfive; March 23rd, 2013 at 05:53 AM.
-
March 23rd, 2013, 10:38 AM
#40
Re: Pseudopointers
I haven't been following this thread in depth, but if you have to change your code to work on a new compiler, it's buggy code. Not only that, you now have two points in your code to maintain, making your code harder to maintain. Furthermore, nearly everyone in this thread has said your idea isn't guaranteed to work by the standard, so why are you arguing? I don't have a copy of the standard, but I've been around these forums long enough to know that the people here aren't lying to you about these things.
-
March 23rd, 2013, 10:47 AM
#41
Re: Pseudopointers
Please stop feeding the troll.
-
March 23rd, 2013, 11:14 AM
#42
Re: Pseudopointers
Originally Posted by STLDude
Please stop feeding the troll.
That immediately struck me but I'm not so sure. Some people are genuinely ignorant.
If the OP wreacs havoch on his own doesn't matter but the problem is he seems to be employed. Hopefully the company wakes up and realizes they cannot pick just any fool for programming, especially not in C++. The best option probably is to promote the OP into documentation or if he refuses, transfer him to a Java group. Java is more resilient to stupid programmers.
In the long run it's better of course to hire well-educated professionals only. Unfortunately this seemingly obvious strategy has yet to convince upper management who otherwise wouldn't dream of letting the pizza delivery man perfom brain surgery on them. For some reason anyone who can spell BASIC is considered top programmer.
Last edited by nuzzle; March 23rd, 2013 at 11:33 AM.
-
March 23rd, 2013, 01:26 PM
#43
Re: Pseudopointers
Originally Posted by nuzzle
That immediately struck me but I'm not so sure. Some people are genuinely ignorant.
If the OP wreacs havoch on his own doesn't matter but the problem is he seems to be employed. Hopefully the company wakes up and realizes they cannot pick just any fool for programming, especially not in C++. The best option probably is to promote the OP into documentation or if he refuses, transfer him to a Java group. Java is more resilient to stupid programmers.
In the long run it's better of course to hire well-educated professionals only. Unfortunately this seemingly obvious strategy has yet to convince upper management who otherwise wouldn't dream of letting the pizza delivery man perfom brain surgery on them. For some reason anyone who can spell BASIC is considered top programmer.
that's your story, and you say I'm a fool because I found some compiler bugs?
is not my fault if those bugs are there, bugs that you didn't have idea of their existence,
that's why you can't say anything objective and just come here to tell your story.
-
March 23rd, 2013, 01:41 PM
#44
Re: Pseudopointers
Err... what compiler bug did you find? Remember, if there is undefined behaviour, then the compiler behaving in a way that you do not expect is not a bug with the compiler but a bug with your code. If there is implementation defined behaviour, then the compiler behaving in a way that you do not expect, but which is still within the bounds specified by the standard, is a not a bug with the compiler, but a bug with your code.
-
March 23rd, 2013, 02:58 PM
#45
Re: Pseudopointers
you don't even know what bugs are we talking about, if not you probably can point to the specific line in one of the different codes that were exposed here, so you can show us what specific bug you want to remark. but you don't even know what code are you talking about. you just repeat the same things the others said,
like a troll, also is a postcounter++.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|