If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Pseudopointers

don't say I don't accept anything because I didn't say I don't accept something,
that is just what you say.

the code doesn't need to be changed since it's working in a 32-bit system or at least for me,
since it doesn't involve another datatype than INT, and is not the point of this topic at all.

so if you say that it won't work in x64 that is offtopic, because you just can make
some minnor changes and get that to work for you. so why you get offtopic saying
this won't work on x64?
what I wanted to point out is the use of typecasting in basic variables so they work
as pointer variables.

I made no assumption at all.
I understand that the 10 variables are not trusted to be stored contiguously,
but remember, I relied on an "implementation detail", so as you see there was no
assumption, but a pure fact. The fact is, it works for me indeed so I can show my point,
which has nothing to do with x32 or x64 systems, data storage, and so ...
If this code doesn't work for you, still you can get the point of the topic by
reading the source code. If you want more, you can make it work for you with just
some changes.

point: "typecasting in basic variables so they work as pointer variables".

why you keep telling other kind of things?

EDIT:

Originally Posted by Paul McKenzie

...
Look, I tell you what: Take this and post it on another board by filling in the number to add to &x so that "OK" gets printed, and come back here and give us a link to the discussion:

by saying this, you just shown me you have not the minimal idea of what is going on in my code, since you lack the static variables initialization value, and your pointer variable is not static either. so as you see you have failed big there.

Re: Pseudopointers

Originally Posted by eightyfive

You seem to know about compiler internals, memory mapping, etc so tell me why wouldn't the 10 variables be stored contiguously? because you're so sure they will be not. you was told of it? or is your mere assumption?

Since you're suggesting this the burden of proving its correctness falls upon you. You'll have to point out the relevant sections in the C++ standard. Stretching a language isn't wrong but you need to formally ensure it didn't break. Testing is not enougth.

And not everything that's allowed is good programming practice. It may lead to brittle and error-prone code. This is especially true with C++. It's a very potent language that must be handled with care. It's easy to shoot oneself in the foot. In fact Java came about as a direct response to this problem.

I'd say Pseudopointer offers an interesting combination of meaningless functionality with naive and ignorant implementation. It's definately a strong candidate for the C++ Hall of Infamy.

Re: Pseudopointers

Originally Posted by nuzzle

Since you're suggesting this the burden of proving its correctness falls upon you. You'll have to point out the relevant sections in the C++ standard. Stretching a language isn't wrong but you need to formally ensure it didn't break. Testing is not enougth.

And not everything that's allowed is good programming practice. It may lead to brittle and error-prone code. This is especially true with C++. It's a very potent language that must be handled with care. It's easy to shoot oneself in the foot. In fact Java came about as a direct response to this problem.

I'd say Pseudopointer offers an interesting combination of useless functionality with naive and ignorant implementation. It's definately a strong candidate for the C++ Hall of Infamy.

useless functionality? since this is just another way of doing things and it's working so probably you have no idea what's going on at all.
the implementation works for me, considering that the code is not even the point of all this, so your logic is flawed getting here with such conclusion, by mixing pseudopointers with one or other code. I would ask you "what the hell" has a code or an implementation, to do with the pseudopointers themselves? the code was just used to point out what is this all about. Just look at you how ignorant you have been, by not readn the entire thread.

Re: Pseudopointers

the code doesn't need to be changed since it's working in a 32-bit system or at least for me,
since it doesn't involve another datatype than INT, and is not the point of this topic at all.

Err... what is the point of this topic again? I had the impression that you were trying to introduce an idea that you conceded -- from the start -- was unnecessary ("Honestly, there's no reason at all to make something like this"), but for which you wanted comment. You got the comments, and since they weren't all gushing with praise for your idea, you're rejecting them?

Originally Posted by eightyfive

by saying this, you just shown me you have not the minimal idea of what is going on in my code, since you lack the static variables initialization value

Objects with static storage duration are zero initialised at startup. Personally, I think not being explicit was sloppy on Paul McKenzie's part, but the code is actually correct.

Re: Pseudopointers

laserlight, you know I said before this is all about typecasting,
I came with a test code that is working for me, and is good enough to show my point.
if the code does not work in x64 systems or if you want to use it for other datatypes, I just said them they better go to make the changes and get it to work , that's not my problem. It's not even the point of all this, it could be a code or another, who cares.

The point was to show people how to use typecasting on basic variables, so you use them like pointer variables. Maybe for beginners?
It's okay, I never said this was advanced. Is about showing another way to do things.

Re: Pseudopointers

I see. Well, that's okay I guess, since anyone stumbling across this thread will now know why they shouldn't do this, and you can continue doing what you want as long as no one else comes into contact with your brittle and poorly written code that works for you... for now.

Re: Pseudopointers

Correct, no one needs to be in contact with my code as long as they can get the idea of all this. Something that seemed hard for a lot of people till now. maybe because they never saw something like this. they are scared for life, and they like to use arrays as they stated before.

Re: Pseudopointers

Originally Posted by eightyfive

The point was to show people how to use typecasting on basic variables, so you use them like pointer variables. Maybe for beginners?

Most certainly not for beginners. Typecasting here is a round about way of doing things. A beginner struggling to understand pointers will not be helped by making things more complicated. Furthermore, except when given artificial constraints or maybe in some area that I am not aware of, if you can typecast to/from a pointer, you can just use a pointer.

Originally Posted by eightyfive

as long as they can get the idea of all this. Something that seemed hard for a lot of people till now. maybe because they never saw something like this

There is no point being condescending here: your idea is easy to understand for people who are familiar with pointers, and that probably means everyone who has posted in this thread. If they didn't understand it, they wouldn't have been able to so readily point out the flaws with it. If anything was hard to understand, it was your insistence on espousing this idea.

Re: Pseudopointers

Originally Posted by eightyfive

by saying this, you just shown me you have not the minimal idea of what is going on in my code, since you lack the static variables initialization value, and your pointer variable is not static either. so as you see you have failed big there.

Well, you've just shown everyone here by saying this that you are not aware of two things:

1) Static variables are zero-initialized by default. So placing "= 0" does absolutely nothing. Even if the static variable wasn't initialized, what difference would it make? The point is not what the variables are initialized to -- the point is to see if we can get from one variable to another by simply getting the address of variable x and can jump to another variable y.

2) It doesn't matter how the pointer "z" is declared, whether it is static, global, or local. All it does is store the address of &x + 1. We're trying to find some way to get to "y", given x. If you can show a foolproof way of doing this, then all hats off to you.

Re: Pseudopointers

Originally Posted by Paul McKenzie

Well, you've just shown everyone here by saying this that you are not aware of two things:

1) Static variables are zero-initialized by default. So placing "= 0" does absolutely nothing. Even if the static variable wasn't initialized, what difference would it make? The point is not what the variables are initialized to -- the point is to see if we can get from one variable to another by simply getting the address of variable x and can jump to another variable y.

2) It doesn't matter how the pointer "z" is declared, whether it is static, global, or local. All it does is store the address of &x + 1. We're trying to find some way to get to "y", given x. If you can show a foolproof way of doing this, then all hats off to you.

the only code that failed is yours. mine worked as you saw in the image, if that wouldn't be the case, then I didn't answer you to that kind of program you came with, that is irrelevant to all this in the first place.
It is funny you mention those 2 aspects, which you ignored before in your "program".
I think we are talking from different compilers and different systems, so don't try to make a point because it's useless, since my code is working and yours not (or maybe you need another image?).
The only thing you can say now, is try to make me move to x64 or to change my compiler XD.

EDIT:

let me show you how you come here with NO POINT once again:

As I told before, we're talking from different perspectives, and I just shown you that my code REALLY WORKS

Re: Pseudopointers

Re: Pseudopointers

Originally Posted by GCDEF

Sometimes buggy code gives the right answer. It's still buggy code.

...

To Paul, just to show you that I don't want to fight you, because I am very objective when I talk about programming issues, I show you another image that can make a point of why I was giving them an initialization value to them.

also, I would like to know why you came with that small program to here? just for me to make it work?.
and let me tell you, I don't pay much attention on the result message "OK" or "NOT OK", I want to see the
addresses of the variables so I see how they got stored.

Now, regarding the storage directive for the pointer variable called "z". you said it doesn't need to be "static", but check these 2 images and tell me what conclusion you have about this?

So Paul you are wrong telling that I was not aware of the 'static' storage directive, since my code relies on that. I shown that I am very aware. but what about you?

As you see, I was caring about variables being stored contiguously. that is something un-guaranteed, still it is a fact. And we all know this all has nothing to do with the "pseudopointers", but somehow we are here.

Re: Pseudopointers

As I told before, we're talking from different perspectives, and I just shown you that my code REALLY WORKS

There is a difference between a "single observed behaviour" and a "rule" or "a proof".

Now lets say I have a 6 sided die. I roll it and it comes up as 5.
I hereby declare and prove that when you roll a six sided die, it will always return a 5 and nothing else because that's the single behaviour I observed. It just doesn't work like that.

You wrote a piece of code.
You ran it and it had the behaviour you expected. great for you.
But that doesn't make it valid C++ or guaranteed to work in every situation on every compiler on every platform. What you are doing simply is not guaranteed by the C++ spec.
I can write a whole bunch of C++ code that will produce different results that will depend on what compiler and compiler options it's being compiled with. If you use invalid c++ constructs, you'll get unpredictable results.

Your code may very well stop working when you install a new version of the compiler. Or if you use different compiler settings.

as to the "why would a compiler do this?" question you asked. Simple. because the compiler may have some obscure reason to organize memory in the way it does. all you do is tell the compiler to create 10 variables, there is no absolute relation between them and the compiler is free to put them anywhere he wants. Under the right optimisation settings, there may be very good reasons to not have them all consecutive in memory.

Re: Pseudopointers

Originally Posted by eightyfive

Not like Paul that doesn't know what is 'static' used for,

After 20+ years of writing C++ apps, starting my own company that uses C++ based components, etc. I better know what "static" is used for. Also, I know you're new, but to let you know, it is against CodeGuru policy to insult other members. No one insulted you -- we are commenting on your code and the flaws in it. Everyone commenting to you here have been on this board for years and have contributed hundreds, if not thousands of posts.

As to your attempt -- you conveniently changed the code to have those static variables declared in the global scope. How does this take away from the fact that the very same code I posted and you attempted to fix for Visual C++ failed in gcc? That's all I did -- took the code you say "worked" and did not change a single line except to get rid of the <windows> include file, and then ran it in the on-line compiler.

But by constantly changing code, you now are moving the goalposts by making changes to work for a particular compiler. What if I get another compiler X, and your fixes now don't work for that brand of compiler? Are you going to try and fix it for that compiler also? And let's say your new fixes changes the way it worked for the first compiler? That's why I stated hats off to you if you can come up with one single piece of code, without making any changes, that is guaranteed by the ANSI/ISO standard to do what you say it will do on every single compiler, compiler version, compiler settings, etc. With a case like that, you don't even need to run it -- it should be obvious as to what the output must be on every single compiler, since the program must behave exactly the same way in accordance to ANSI/ISO.

I have answered scores of questions similar to what OReueben's posted to you above. If you go through my posts here, you will see detailed answers given to many of the C++ threads that are started here that sound word to word like OReubens. If you wanted a reason why compiler's do what they do, many compilers take advantage of whatever hardware they're running on. But one thing a compiler cannot do is have an application behave contrary to what is stated in the ANSI/ISO standard, otherwise the compiler is broken.

ANSI/ISO specifies behaviour of the application when it uses a particular construct. There are few, if any ANSI requirements for a compiler to internally implement the behaviour in a certain way. For example, virtual functions are usually implemented as a v-table, but nowhere does ANSI/ISO really say how virtual functions are to be implemented. What ANSI/ISO does say is how virtual functions are supposed to behave. Another example are iterators -- many compilers implement iterators to certain containers as pointers, while other compilers will implement the same iterator as a struct or class. So it would be illegal to assume that an iterator is a pointer, even if it "works" for compiler A. These are just two of hundreds of different cases where code may work on one compiler, and will fail on another due to attempting to code to implementation-details instead of what is guaranteed by the standard.

The code you posted is implementation-defined, or at worst, undefined behaviour. As OReubens pointed out, writing code that uses implementation-defined (or undefined) behaviour results in programs that may run differently depending on compiler, compiler version, compiler settings, etc.