I know that on some compilers, if there is no explicit return statement, then it will just return the last value that was calculated. I wasn't sure if it was standard or not.
I know that on some compilers, if there is no explicit return statement, then it will just return the last value that was calculated. I wasn't sure if it was standard or not.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
Hi guys,
please please, i beg you, do not post your tips and tricks here and instead, post it on my website,
my collection of tips and tricks
please... thanks
http://www.angrysoft.com/
Get SMS Counter and Call Counter for Nokia 7650/3650
http://www.angrysoft.com/tipsandtricks.php
Please contribute some tips and tricks that you know of.
Not to my knowledge. In assembly it's just easier, so some compilers defaulted to that. Since the value is in the register already, that's one less step in preparing the stack for a function call.Originally posted by XSquared
I know that on some compilers, if there is no explicit return statement, then it will just return the last value that was calculated. I wasn't sure if it was standard or not.
OK. Edited my code to add a return statement.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
Nah, it's better to post them here - where everyone can benefit. There's really no incentive to go to your website, anyway.Originally posted by mickey
Hi guys,
please please, i beg you, do not post your tips and tricks here and instead, post it on my website,
my collection of tips and tricks
please... thanks
You could just copy and paste the "tips and tricks", no?
I can explain this one for you. Delete acts instantly. That memory is no longer assigned to your program, and could change at any time. But you still have a pointer to it, because you haven't changed the pointer's value (you should always change it to NULL after you delete to avoid this problem). Delete just means that the memory isn't assigned to your program anymore - it doesn't clear the contents of the RAM there. So, you're couting the data in that location of the RAM, but it doesn't belong to your program and won't *necessarily* be what you think it will be. It's the same reason that you should initialize your pointers to NULL and your variables to some value before you use them...there's junk data there until then.Originally posted by prophet
Last thing I've noticed and I already made a post about this is the following problem on BCC and g++. Don't know what other compilers are affected but I know VC++ does it correctly (ironic).
I was under the impression that delete works pretty much instantaneously and that is what the benefits of using dyanamic arrays were for, to save memory. If it didn't work instantaneously then it would more than likely return the memory at the END of the program which would mean that it takes up memory as much as static arrays. Obviously I could be wrong about this but, that was the impression I got from reading about it. Also I'm getting too used to Java's garbage collecting feature in the compiler which handles that stuff for you =)Code:void main() { int *arr = new int[10]; arr[5] = 3; cout << "Before: " << arr[5] << endl;//prints out 3 delete[] arr; //deletes the array from memory cout << "After: " << arr[5] << endl; //prints out 3
Away.
is that right? wow, but it's still there, just ready to be overwritten eh?Originally posted by blackrat364
Delete just means that the memory isn't assigned to your program anymore - it doesn't clear the contents of the RAM there.
anyway, i am still hoping that you guys could transfer your tips and tricks to my page:
http://www.angrysoft.com/tipsandtricks.php
http://www.angrysoft.com/
Get SMS Counter and Call Counter for Nokia 7650/3650
http://www.angrysoft.com/tipsandtricks.php
Please contribute some tips and tricks that you know of.
yeah, try this... well, actually, don't, but you can if you want.
You'll get some junk value there, or a crash, or something to tell you you're doing something incorrectly.Code:int a; cout<<a;
just gives you a lot of junk....Code:int *a; a=new int[23423];
You've just given yourself a pointer to...who knows what. There will be data there, though. It might be yours. It might not be. But you could definitely output it...Code:int *a=/*some arbitrary memory address hard coded*/
Here's the lesson boys and girls, and a great tip for all:
Initialize your pointers to null, and reset them to null after you delete
Away.
alright guys,
i might as well be the one to transfer the tips and tricks on this forum if you guys don't want to.
http://www.angrysoft.com/
Get SMS Counter and Call Counter for Nokia 7650/3650
http://www.angrysoft.com/tipsandtricks.php
Please contribute some tips and tricks that you know of.
Actually, I believe the lesson he was referring to was:Originally posted by vVv
> Here's the lesson boys and girls, and a great tip for all:
Mere misinformation, such as the assumption that you can accidently access other processes' address spaces, is definitely not a lesson.
>>Initialize your pointers to null, and reset them to null after you delete
He even put it in bold. And that colon after the word "all" was also a good clue.
Yeah, you sure might as well be "the one." Don't be sad, though. As long as you get those nifty tricks, you should be fine.Originally posted by mickey
alright guys,
i might as well be the one to transfer the tips and tricks on this forum if you guys don't want to.
That's more like it, ``vVv."Originally posted by vVv
> Actually, I believe the lesson he was referring to was:
I know very well what he was referring to, it's just my wording that might have been misleading. How about:
Mere misinformation, such as the assumption that you can accidently access other processes' address spaces, is definitely not an argument to make a ``lesson'' any more credible.
It's still butchered, but you get what I mean (hopefully).
Well...actually...ok, I'll stop.
Anyway, it wasn't just your wording, you actually quoted:
> Here's the lesson boys and girls, and a great tip for all:
In any case, take care, kid.