new meme: evil CS grad
New meme: evil CS grad
Other urls found in this thread:
stackoverflow.com
twitter.com
> requires specific knowledge of ascii
I get: it ascii has a lot of features. No need to dwell on it
Have fun with your memory leak
Also:
>A fucking itoa function
>Using recursion
M8 that's not even tail recursion. The compiler won't optimize the stack frames out.
Wait. This is bait.
>char*&
someone smarter than me please explain me what that is
a reference to a pointer?
they cancel out I guess
It's a pointer to a char, passed by reference.
>They cancel out
This is the state of Sup Forums
"A pointer to a char passed by reference" is just a pointer to a char dumbfuck
It's equivalent to a char**, but it's always dereferenced when used. It's not equivalent, because the & operator returns something from outside the stack frame.
I don't know if this is bait, but here is a stackoverflow answer explaining the difference between passing by value and passing by reference:
>It's equivalent to a char**, but it's always dereferenced when used
why on earth would someone want to use something like this
that just begs for undiscoverable bugs
are you asking why pointer to pointer or just pointer to char pointer?
*a fucking pointer to a fucking pointer to a fucking char
no, I mean a pointer that's automatically dereferenced (without any indication in the code other than the variable declaration)
This
No, a reference is similar to a pointer, but it does not need to be dereferenced manually.
Where's the memory leak? It would seem as though all dynamically allocated memory is returned, and thus the responsibility of the caller.
That is correct, it won't optimize the stack frames out. However, there is an upper limit on the amount of stack frames used, so a stack overflow is unlikely. It is nonetheless more than necessary.
And yes, it is bait. Hence why it's called the "evil CS grad". It's describing code so bad that it could be considered malicious. Although I don't think this is necessarily malicious, just badly designed.
Correct, it is a reference to char*. It is used to assign the value of the position pointer... Kind of ugly really.
Syntactic sugar.
are you dense? i know what a reference is. we're talking about "char*&" here which IS automatically dereferenced
Then just try passing 0 (or nullptr in C++) for char*& vs. char**.
You all dun goofed.
You have to rely on the caller doing that though. A better option might be to return a string, with which you can then call .c_str(). This way, the memory is abstracted away.
What did he mean by this?
>It would seem as though all dynamically allocated memory is returned, and thus the responsibility of the caller.
Wow this went straight from evil CS grad to bad CS grad.
You don't do that. You did not do that back in x86 assembly (except for Microsoft's stdcall), and you still do not do that in current x86-64 assembly (caller cleans up stack). Similarly in higher level languages you have RAII and always clean up the on the same scope as you allocated.
An there is a reason: What if the caller uses a different C/C++ runtime compared to the C/C++ runtime that the translation unit this function resides in uses? Exactly: Both C runtimes will run side-by-side, and both runtimes will have their own heaps. Your C/C++ runtime will think this memory was not allocated when you try to delete that memory. Have fun with that.
Also, doing memory allocation by the caller and memory deallocation by the caller allows the caller to use their own allocator, and not the one from the respective C/C++ runtime of that translation unit.
You see: Don't do that.
void Test1(char ** c) {}
void Test2(char *& c) {}
int main(int argc, char * argv[])
{
// Fine and dandy
Test1(0);
// error: invalid initialization of non-const reference of type ‘char*&’ from an rvalue of type ‘char*’
Test2(0);
return 0;
}
I did not say that **char was the same as a *&char
no, idiot