new meme: evil CS grad

>>61235580

> requires specific knowledge of ascii

I get: it ascii has a lot of features. No need to dwell on it

>>61235580
Have fun with your memory leak

>>61235580
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?

>>61235993

they cancel out I guess

>>61235993
It's a pointer to a char, passed by reference.

File: spurdo.png (117KB, 1024x749px) Image search: [Google]

117KB, 1024x749px

>>61236018
>They cancel out

This is the state of /g/

>>61236064
>>61236095

"A pointer to a char passed by reference" is just a pointer to a char dumbfuck

>>61236155
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.

>>61236155
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:

https://stackoverflow.com/questions/373419/whats-the-difference-between-passing-by-reference-vs-passing-by-value

>>61236238
>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

>>61236266
are you asking why pointer to pointer or just pointer to char pointer?

>>61236155

*a fucking pointer to a fucking pointer to a fucking char

>>61236306
no, I mean a pointer that's automatically dereferenced (without any indication in the code other than the variable declaration)

>>61236430
This

>>61236481
No, a reference is similar to a pointer, but it does not need to be dereferenced manually.

>>61235895
Where's the memory leak? It would seem as though all dynamically allocated memory is returned, and thus the responsibility of the caller.

>>61235976
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.

>>61235993
Correct, it is a reference to char*. It is used to assign the value of the position pointer... Kind of ugly really.

>>61236481
Syntactic sugar.

>>61236565
are you dense? i know what a reference is. we're talking about "char*&" here which IS automatically dereferenced

File: 7c6.png (11KB, 211x246px) Image search: [Google]

11KB, 211x246px

>>61236155
>>61236238
>>61236430
>>61236548
Then just try passing 0 (or nullptr in C++) for char*& vs. char**.

You all dun goofed.

>>61236624
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.

>>61236810

What did he mean by this?

>>61236624
>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.

File: gondola.jpg (39KB, 640x360px) Image search: [Google]

39KB, 640x360px

>>61236826

    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;
    }

>>61237051

I did not say that **char was the same as a *&char

>>61236155
no, idiot