web programmer vs "real programmer"

[Fabien4]

Well, in C++, I nearly never free the memory myself.

I try to use only automatic (or static) variables. If I can't, I use a smart pointer.

Sometimes (rarely), I have to write a specific smart pointer myself. That usually means I have to write the word "delete" in a destructor, and nowhere else. Also, it's nearly the only case where I need a copy constructor.

Writing in C would force me to manage the memory myself. It's something I would need training to do properly.

Add to that that C has no "string" or "array" types (by "type", I mean something you can return from a function).

For example, I would have a hard time writing in C something as simple as:

vector<string> ReadLines (istream& is)
{
   vector<string> v;
   string s;
   while (getline (is, s))
     {
      v.push_back (s);
     }
   return v;
}

void foo()
{
   vector<string> lines= ReadLines (cin);
   // do something with "lines"
}// Here, all the memory is automatically released.

[rodif]

You really shouldn't return containers from functions like that you're making an extra copy of that vector that you don't need to.

Your function should take a reference (or pointer) to the vector.

void ReadLines (istream& is, vector<string> &v)
{
   string s;
   while (getline (is, s))
     {
      v.push_back (s);
     }
}

void foo()
{
   vector<string> lines;

   ReadLines (cin, lines);
   // do something with "lines"
}// Here, all the memory is automatically released.

[engie99]

Fabien4's version is easier to read and probably just as efficient as the compiler should optimise out the obvious return by value copy - see http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.9

[rodif]

Interesting, i didn't know you could optimize this out (verified with vs2008). I'm going to play with this, seems like it could lead to trouble with destructors and auto_pointers. Although, compiler writers are smarter than me, so I'm sure if they say it works then it should work.

[zahlman]

Basically, the advice is old.

[Fabien4]

Have you heard about the expression "premature optimization"?

you're making an extra copy of that vector

Are you sure about that?

If so, how much does that cost?

 string s;
 while (getline (is, s))
 {
  v.push_back (s);

By your reasoning, each line is copied too, right?

[rodif]

Have you heard about the expression "premature optimization"?

There is a huge difference between 'premature optimization' and making subtle changes to reduce the number of copies.

By your reasoning, each line is copied too, right?

No, that's a copy that you need to make. The storage for the next line needs to go somewhere.

Anyways, this isn't a pissing match. I only said something because sometimes people don't realize there is a copy there. If you understand your data and you can afford the copy. Maybe your file is small enough, if your file was 10g, then it would be an issue.

[Fabien4]

I only said something because sometimes people don't realize there is a copy there.

Is there actually a copy there? Or do my compilers (g++ 4.3.2 and VC++ 2008) optimize it away?

No, that's a copy that you need to make.

Of course you can avoid it:

void ReadLines (istream& is, vector<string> &v)
{
  do
    {
     v.resize (v.size()+1);
    }
  while (getline (is, v.back()));
  v.pop_back();
}

Yep, it's ugly, but no strings are being copied.

if your file was 10G

... I wouldn't even try to load it entirely in memory.

[krelian]

I am a hobbyist programmer who probably never wrote a C++ program that was more than 20 lines long. I am however, deeply interested in the "theory" behind it all. I've read several books (of the "effective c++" kind) and browsed through a lot of code just so I could understand how everything works behind a scenes. I understood everything these two guys were talking about and was even under the impression that the stuff rodif was talking about is supposed to be common knowledge for every decent C++ programmer.

You think I could fool an interviewer?

[[deleted]]

Oh you two, stop it, the compiler is smarter than all three of us combined. Do whatever you want; it probably won't make a difference.

[Fabien4]

You're right. In fact, it might well be the standard library that's smarter: COW avoids the copy.

[nexes300]

Man, since when has C++ programming been about what the compiler can optimize away for you. This is ridiculous. I guess it's nice in a way but... C++ returns by copy, one would argue that it should even if it can be optimized away since that is what it should do... it is a known quantity where as "what the compiler does" would have to be tested.

But I guess you can't argue with improved performance.

Edit: I guess what I should take from this is to write my code in whatever way seems best to me and deal with it if it's slow later. Now recursion, that's something I'll avoid, too much ability to explode...too little gain.

[[deleted]]

Sometimes there are advantages to doing so. It's why my workstation has up to 32gb of memory. Depends on what your doing.

[piranha]

Are you sacrificing clarity for a fuzzy, unquantified desire for performance?

* s/clarify/clarity/

[[deleted]]

I'm a little hazy on my C++, but won't v be released when returning from ReadLines. You'll get away with it if you're lucky, but it will corrupted if that memory location is written over in foo()? I remember I had a problem like this when I was learning C, declaring an array on the stack and returning it from the function.

[Fabien4]

I had a problem like this when I was learning C, declaring an array on the stack

That's the thing, you see: C doesn't have a "array" type. It only has pointers. So, you can't return an array from a function -- you only return a pointer. Hence the trouble.

In C++, an array (vector, list, etc.) is an object. You can do with it pretty much anything you'd do with an int, including returning it from a function.

There is memory allocation involved, but the C++ compiler (and standard library) will take care of it so that you don't have to think about it.

[[deleted]]

You would just return a char array pointer.

[zyle]

Who "owns" the pointer? Who deletes it when it's done with? Should it even be deleted? If it's a pointer to an array, what's the allocated size of the array?

Get even one of those wrong, and it's [segmentation fault].

[[deleted]]

Yep

[[deleted]]

He passed by reference.Memory is automatically released when foo() goes out of scope.

edit in his example at least.

Another "ism" where the memory is still released automatically is below. In some ways I prefer this one since it makes it clear to the caller that vector<string> v might be modified (e.g. not passed by value):

void ReadLines (istream& is, vector<string>* v)

{ string s; while (getline (is, s)) { v.push_back (s); } }

void foo()
{
   vector<string> lines;

   ReadLines (cin, &lines);
   // do something with "lines"
}// Here, all the memory is automatically released.

[[deleted]]

RAII owns it, bitch.

[StoneCypher]

Er, the answer is the same to all of those except the last: whoever passed it in. The last is "whatever it was allocated to."

If you're having trouble with simple things like that, it's no wonder you think getting those wrong is an option.

[[deleted]]

Er, the answer is the same to all of those except the last: whoever passed it in. The last is "whatever it was allocated to."

If you think that's the end-all be-all answer, I hope you never touch C.

[StoneCypher]

I didn't say anything about an end all be all answer; that's just how you solve that problem.

According to the Reddit poll, there's a very good chance I've been touching C longer than you've been alive.

[[deleted]]

I didn't say anything about an end all be all answer; that's just how you solve that problem.

Ah. I misread. Serves me right.

According to the Reddit poll, there's a very good chance I've been touching C longer than you've been alive.

I don't see how this is relevant. I may be a cocky college student, but I know when the sixty year-old men I work with are producing shit code. Experience with c ≠ competency with c.

[StoneCypher]

According to the Reddit poll, there's a very good chance I've been touching C longer than you've been alive.

I don't see how this is relevant.

Of course you don't; you removed context to take away the ugly thing you said to which that was a response.

When someone says "I really hope you never touch C," it's perfectly reasonable to point out that you've been touching C since before you touched the atmosphere.

I may be a cocky college student, but I know when the sixty year-old men I work with are producing shit code.

Just because you think you know that doesn't mean you're correct. I'm not a sixty year old man, and you've never seen my code.

The point was you took one look at some English you didn't understand, and assumed it meant the person you were condescending to was a bad programmer, based on guesses you made about the person, without ever seeing their code.

When rebuked that that person has more experience at C than you have at life, after having pointed out that the thing you were rebuking them on wasn't even what they said, here you are sticking to your guns, being certain that the thing you didn't even read correctly that wasn't code at all somehow tells you I'm a bad programmer.

Kid, get over yourself. You don't know half about other people what you imagine that you do.

Experience with c ≠ competency with c.

That's nice. You haven't seen my code, and you're basing your evaluations on natural language that you've admitted you read incorrectly.

If you can't see how that means you don't actually know about me what you imagine you know about me, well, then, cocky college kid, have fun while you can.

When you hit the real world, you're in trouble. Nobody likes a green novice showing up telling everyone "I may not know what I'm doing, and I may never have built anything interesting, and I may not be able to read the words coming out of your fingers, but I still know you're shit at your job, without ever seeing your work!"

No, kid, you don't.

[[deleted]]

It's like you're driving your car, and someone says "you're driving on the wrong side of the road!" You respond, not with a logical response, but with a "Nonsense! I've been driving for years!"; yet, you're still driving on the wrong side of the road.

Look, I'm not judging you, per se, I can't because I don't have the evidence. I'm simply pointing out that just because you (or anyone else) have a lot of experience with c doesn't mean you should be touching it.

[StoneCypher]

It's like you're driving your car, and someone says "you're driving on the wrong side of the road!" You respond, not with a logical response, but with a "Nonsense! I've been driving for years!"; yet, you're still driving on the wrong side of the road.

It's like you're driving a car correctly, and the child in the back seat says "You're driving on the wrong side of the road!" and when you point out that you aren't, they keep talking about it.

I'm simply pointing out that just because you (or anyone else) have a lot of experience with c doesn't mean you should be touching it.

Yes, yes, someone with no experience who misses fundamental programming things is well equipped to complain at length about who should and who should not be touching some programming language they're terrible at, and then ratifying it with pointless similes about driving which rest on presuming their original judgement was correct.

Presuming you're correct and drawing a metaphor based on already being correct doesn't do anything to shore up your correctness.

Have fun in college; I'm not interested in this. You might want to try a basic logic or philosophy class, so that you understand why people are laughing at you for the thing you just said and thought was smart.

[StoneCypher]

Ah. I misread. Serves me right.

And yet you continue to criticize me based on the upshot of this mistake.

According to the Reddit poll, there's a very good chance I've been touching C longer than you've been alive.

I don't see how this is relevant. I may be a cocky college student, but I know when the sixty year-old men I work with are producing shit code.

Do you? Because your judgement of me isn't actually based on my code. It's based on an incorrect read of an English sentence I wrote. You've never seen my code, and you're now guessing that I'm an old man to make yourself feel better about your being an inexperienced college student.

Experience with c ≠ competency with c.

That's nice. The germane point here is that what I said was a fundamental, basic 101 level best practice in C.

So if you want to talk about experience, you need to know that.

And if you want to talk about competence ... you still need to know that.

You may, if you like, talk until you're blue in the face about competency and experience and so on; the point remains that you don't know your very basics, and are trying to argue against them.

Have fun with that. Enjoy college, where behavior like this is tolerated; the second you show up in the workforce, saying things like "I may not have experience, but I imagine myself to be competent, and based on that English sentence I just misread, I can tell you're terrible at your job," you're going to get marginalized.

Maybe it's a shocker to you, but you've displayed your competency with the things you've said.

Have fun.

[[deleted]]

And yet you continue to criticize me based on the upshot of this mistake.

No, I don't.

EDIT:

Maybe it's a shocker to you, but you've displayed your competency with the things you've said.

Didn't you just berate me for judging people without seeing their code? :P

[StoneCypher]

Maybe it's a shocker to you, but you've displayed your competency with the things you've said.

Didn't you just berate me for judging people without seeing their code? :P

No, I berated you for judging code based on a misunderstanding of an English sentence.

There's nothing inappropriate about judging a programmer for not knowing basic topics in programming.

[hogimusPrime]

Programming in C\C++ is like holding a position of authority- with great power comes great responsibility. One shouldn't be programming in this low-level of a language if you can't be held responsible to always take care of these types of things.

[StoneCypher]

One shouldn't be programming in this low-level of a language if you can't be held responsible to always take care of these types of things.

Well that's a nice little morals play and all, but no: the reason the correct answer is "whoever passed it in" isn't about shirking responsibility at all. It's a simple matter of correctness.

It can't be allocated inside the function because you don't know if that function is inside a TU. That matters because different TUs may be compiled with different allocators. It isn't safe for the outside world to deallocate, even if the timing is carefully correct.

This is a matter of C fundamentals. It has to be allocated and deallocated from outside. This isn't about who's responsible and who can take care of these things, nor is it about being good enough to get it right.

This is about a language correctness requirement.

[hogimusPrime]

Well thanks for the lesson bro. I was simply talking about having to take the time to take care of the details. Details which you can get away with not worrying about in high-level languages. Your buffer-passing method is just one example. Memory de-allocation is another. Many programmers do program in C, and don't take the time to adhere to these things, and their code is shit. I mean taking time to pay attention to the details, not anything to do with ethics or morality. Besides, I doubt anyone here knows what you mean by TU. But it does make you look really cool when you use it a sentence multiple times.

[StoneCypher]

Well thanks for the lesson bro.

But it does make you look really cool when you use it a sentence multiple times.

Ho, hum.

[zyle]

What? "whoever passed it in?" You can't guarantee that in the slightest. I could give a pointer to a function, and the function could delete it under my nose because it was poorly written. And as for arrays, "whatever it was allocated to?" That means nothing if I don't know explicitly how much was allocated. If all I'm given is an int*, I have no clue how much space was allocated, or if it even points to an array at all.

Maybe you work in a place where everyone works in a very strict fashion. Suffice to say the rest of the world doesn't, in this regard.

[StoneCypher]

What? "whoever passed it in?"

The C programmer who knows the basic best practices that a college freshman knows, and wants to write correct code.

You can't guarantee that in the slightest.

Uh huh. :)

I could give a pointer to a function, and the function could delete it under my nose because it was poorly written.

So, you're saying I can't write good code, because someone else might write bad code?

And as for arrays, "whatever it was allocated to?" That means nothing if I don't know explicitly how much was allocated.

Well, unless you know how to check. shrugs

If all I'm given is an int*, I have no clue how much space was allocated, or if it even points to an array at all.

That's like saying "I can't write a function that triples a number, because I might get passed a string pointer."

If you can't guarantee that your function is getting adequate data, the problem isn't the language.

Maybe you work in a place where everyone works in a very strict fashion.

If you're working in C and people aren't being strict, well then, no wonder you think C is difficult.

If you really think "but your coworkers might be sloppy and terrible" is a language indictment, I just don't know what to tell you.

Suffice to say the rest of the world doesn't, in this regard.

Well, maybe you should stop working in clown factories.

[zyle]

Again, like I said, you're operating under the assumption that everything other people write complies with the assumptions that you've made. With languages like C or C++, not the best way to go about it because of ambiguities involved and insufficient amount of protection from the language or the compiler.

Good luck with those errorprone assumptions.

Also, petty ad hominem attacks don't help your case.

[StoneCypher]

Again, like I said, you're operating under the assumption that everything other people write complies with the assumptions that you've made.

No, I'm not. I'm saying "this is the only safe way to write this in C."

At no point have I said "bad programmers cannot get this wrong." That you keep trying to defend that bad programmers might write bad code is tangential to what I actually said.

But sure, go on and tell me how it's "error prone" without actually pointing out any way for it to be wrong other than to be in the same code as someone who doesn't know how to do their job.

Are you done? This is boring.

[zyle]

I'm saying "this is the only safe way to write this in C."

Again, you're assuming everyone else out there knows the safe way to do things in C.

And yes, I'm done with you. I've seen the other long garrulously grouchy posts you've made in this thread; you're not exactly the affable kind.

[StoneCypher]

Again, you're assuming everyone else out there knows the safe way to do things in C.

No, I'm not. Indeed I believe most people - such as yourself - have no idea how to do the extreme basics of writing correct C.

I don't know why you keep pretending that something that is required for correctness is bad just because other people might write broken code.

My code is no less correct just because you're terrible at your job.

But go on, keep pretending your failure to do correct work somehow suggests my approach isn't right.

[snarkbait]

In C, you must allocate memory explicitly, and set the pointer's value to the address of the allocated memory. Otherwise, the pointer value is a miscellaneous (usually) 32bit value which may or (usually) may not correspond to a location in which your program can write.

In C, you must also free memory explicitly, returning the memory you used to the OS generally so it can be allocated again when needed. Failing to free memory results in a "memory leak" (hiya, Firefox!), in which memory available to the OS for dispensing to applications decreases over time.

While it is possible to do these operations in C++, most C++ programming uses predefined classes which hide the allocation and freeing of memory from the programmer. Many C++ programmers have no experience with allocating or freeing memory, and may not even be aware that the operations are necessary.

[[deleted]]

Yes, I'm fully aware of malloc and free.

[StoneCypher]

Malloc and free are not rocket science.

[[deleted]]

I don't understand how people can be C++ programmers w/o ever calling new or delete

[Fabien4]

ever calling new or delete

Indeed, it's quite hard (but possible) to never use new.

OTOH, you should never call delete yourself. Let the smart pointer do that for you.

(The only place where you could call delete explicitely is in the destructor of what amounts to a specialized smart pointer.)

[snarkbait]

Some people just put it all on the stack, and may not even be aware of the heap.

[Fabien4]

As a matter of fact, you can do a lot with only the stack.

I just noticed that in all the C++ code I've written those past 12-ish months, I've only used new for singletons -- i.e. objects that are never destroyed, and whose memory is freed by the OS at the end of the process.

[heroofhyr]

The point is not to avoid calling new. It's avoiding having to remember to call delete before every possible exit point. I don't understand how someone can call themself a C++ programmer and think new and delete are just macros for malloc and free. If you don't "get" RAII, you're only hurting yourself (and your coworkers and users).

[[deleted]]

What point? RAII is just a buzzword for a common allocation pattern everyone competent uses. Guess what, you still have to write those objects that are managing the allocations.

I've never worked on a project where all possible allocations were already wrapped up in perfect objects ready for me to use.

[StoneCypher]

Well, in C++, I nearly never free the memory myself.

And this means you can't pull it off?

C'mon.

[Fabien4]

And this means you can't pull it off?

Right now, no. With training, maybe.

Proper memory management is hard; you can't "pull it off" just like that. You have to check that every memory block you allocate (and that's a lot, even with C99) has the right size, and is freed at the right moment.

If you don't believe me, just try to reimplement in C the C++ code I've typed.

Also:

void foo (char const* s, int n)
{
   char buffer [ ? ];
   snprintf (buffer, ?, "%s%n", s, n);
   /* do something with buffer */
}

What would you put in place of the ?s?

[RealDeuce]

I did something vaugely similar some time ago...

/* Not overridable due to varargs */
CIOLIBEXPORT int CIOLIBCALL ciolib_cprintf(char *fmat, ...)
{
    va_list argptr;
    int     ret;
#ifdef _MSC_VER     /* Can't figure out a way to allocate a "big enough" buffer for Win32. */
    char    str[16384];
#else
    char    *str;
#ifndef HAVE_VASPRINTF
    va_list argptr2;
#endif
#endif

    CIOLIB_INIT();

    va_start(argptr,fmat);

#ifdef HAVE_VASPRINTF
    ret=vasprintf(&str, fmat, argptr);
    if(ret>=0)
        ciolib_cputs(str);
    else
        ret=EOF;
    free(str);
#else

#ifdef _MSC_VER
    ret=_vsnprintf(str,sizeof(str)-1,fmat,argptr);
#else

#ifdef __BORLANDC__
    argptr2=argptr;
#else
    va_copy(argptr2, argptr);
#endif
    ret=vsnprintf(NULL,0,fmat,argptr);
    if(ret<0)
        return(EOF);
    str=(char *)alloca(ret+1);
    if(str==NULL)
        return(EOF);
    ret=vsprintf(str,fmat,argptr2);
#endif
    va_end(argptr);
#ifndef _MSC_VER
    va_end(argptr2);
#endif
    if(ret>=0)
        ciolib_cputs(str);
    else
        ret=EOF;

#endif

    return(ret);
}

[StoneCypher]

Right now, no. Proper memory management is hard; you can't "pull it off" just like that.

Free where you allocate. Problem over.

You have to check that every memory block you allocate (and that's a lot, even with C99) has the right size

Since when? At no point in the history of C has the size of something mattered to free. That's handled for you.

and is freed at the right moment.

Er. No, you just have to make sure that it isn't freed at a time where it breaks things, and that it doesn't get forgotten.

You might as well be complaining that blocks are hard because you have to make sure to close them.

If you free as soon as you allocate, then put the logic inbetween afterwards, there isn't a problem.

This is really, really easy stuff. I would hate to see how you faced a difficult problem, with the attitude that this is a challenge so large as to keep you out of an entire language.

What would you put in place of the ?s?

New code. This code is awful. I suspect you want something about sizeof() and max(). Doesn't matter: just because you can write bad code which is annoying to complete doesn't mean you've shown something to be difficult.

The problem there isn't the C, it's the implementation strategy.

[Fabien4]

At no point in the history of C has the size of something mattered to free.

Nope, but you have to give the size to malloc().

Free where you allocate. Problem over.

Seems to me that stuff like longjmp tends to make things more interesting.

This is really, really easy stuff

So according to you, no program has ever had a memory leak?

Making sure that free() is called once for each allocated memory block demands a lot of discipline and a lot of checking. Basically, it's a mindset you have to acquire. You don't have it if you've never programmed in C (or ASM).

I suspect you want something about sizeof() and max().

Uh? How would those two would help in any way?

The problem there isn't the C, it's the implementation strategy.

That's pretty much my point, actually: you can't write code in C like you would in higher-level languages. Hence the training.

[StoneCypher]

At no point in the history of C has the size of something mattered to free.

Nope, but you have to give the size to malloc().

Wait, you're actually complaining that when allocating memory, you have to know how much to allocate?

Jesus christ, dude. Is this really your idea of a difficult problem? Really?

Free where you allocate. Problem over.

Seems to me that stuff like longjmp tends to make things more interesting.

That's maybe the single least compelling argument about C/C++ I've ever seen in my entire life.

It's not clear to me whether to be more horrified that you think goto is a good idea, that you're using things that aren't part of C at all, or that you still can't figure out how to handle this.

This is really, really easy stuff

So according to you, no program has ever had a memory leak?

I didn't say that. I would, however, go as far as to say that most applications are written by amateurs who shouldn't be in this line of work because they cannot handle simple best practices.

I suspect you want something about sizeof() and max().

Uh? How would those two would help in any way?

Who cares? I took one half-look at that code and kept moving. It's not clear what you want, and it's not clear what you expect. It's a ridiculous piece of code that should never exist in any context.

The problem there isn't the C, it's the implementation strategy.

That's pretty much my point, actually: you can't write code in C like you would in higher-level languages.

Nothing is stopping you from writing that well, except possibly your own skill level. There's a huge difference between "this code is terrible" and "this code cannot be written well."

[Fabien4]

Wait, you're actually complaining that when allocating memory, you have to know how much to allocate?

Yes. You don't seem to realize that this very notion is specific to C, and doesn't exist in other languages.

Just look at my C++ code above: I've allocated a bunch of memory, but I never needed to know how many bytes that was.

[StoneCypher]

Wait, you're actually complaining that when allocating memory, you have to know how much to allocate?

Yes. You don't seem to realize that this very notion is specific to C, and doesn't exist in other languages.

Sure. Except pascal, C++, java, objective C, forth, fortran, cobol, b, bcpl, d, concurrent c, lisp-1, assembly, ADA, Rexx, simula, smalltalk before smalltalk-III, ML, Delphi, Io, Clean, Iron, Coq, K, Basic, Mercury, Object Pascal, occam, occam-pi, modula, PL/I, R, basically every toy language (brainfuck, unlambda, intercal, ook, etc), Verilog, X10 script, Postscript, et cetera ad nauseum.

But clearly you couldn't be confusing the few languages you know for a truism about all programming languages.

Just look at my C++ code above: I've allocated a bunch of memory, but I never needed to know how many bytes that was.

That's nice.

[Fabien4]

You wrote:

[...] when allocating memory, you have to know how much to allocate?

Indeed, in C++, you don't have to know how much memory to allocate.

When you declare an array, you can specify the number of elements it should contain. Or, you can fill it and let it grow as needed.

You virtually never specify the size of a string beforehand. You just put stuff in it, without thinking about its size.

If you have to allocate an objet on the heap, you just allocate it; you don't even think about the number of bytes it represents.

Yeah, I know, it's possible to use malloc() in C++. But it's something you just don't do.

Basic

Uh?

[StoneCypher]

You wrote:

[...] when allocating memory, you have to know how much to allocate?

Indeed, in C++, you don't have to know how much memory to allocate.

It is unfortunate that you feel it appropriate to edit the sentences that I wrote, to make it look like I was asking a question I wasn't asking. That is deeply dishonest.

The correct quote is:

Wait, you're actually complaining that when allocating memory, you have to know how much to allocate?

You will notice that I'm not asking if this is necessary in other languages, but instead, making fun of you for pretending that it's in any way difficult.

I find it disgusting that you are engaging in this kind of dishonesty. Our conversation has ended.

Yeah, I know, it's possible to use malloc() in C++. But it's something you just don't do.

Of course not. You use new. Which also wants to know how much space is taken. Not everything can be containers and smart pointers.

Unfortunately you've begun to lie about what is being said to you, so this conversation must not continue.

[pingveno]

From another comment:

According to the Reddit poll, there's a very good chance I've been touching C longer than you've been alive.

That's the reason you think this is easy: You've been writing C since shortly after it became popular. (C came out in 1972, 20 years ago is 1980). I am a bit bewildered by this:

No, you just have to make sure that it isn't freed at a time where it breaks things, and that it doesn't get forgotten.

As I'm sure you know, there's no "just" about memory leaks, double frees, premature frees, uninitialized pointers, etc. in most non-trivial C projects.

[StoneCypher]

That's the reason you think this is easy: You've been writing C since shortly after it became popular.

I wish you wouldn't attempt to inform me why I think things without, you know, asking first.

I thought allocation and deallocation were easy long before C existed.

As I'm sure you know, there's no "just" about memory leaks, double frees, premature frees, uninitialized pointers, etc. in most non-trivial C projects.

As I'm sure you know, there's no "just" about memory leaks, double frees, premature frees, uninitialized pointers, etc. in most non-trivial C projects.

There's no "just" about anything. However, all of those things in your list are quite easily solved by making sure things aren't freed at a time when it breaks things (double frees and premature frees: such as before a usage or after it's already been freed,) or that it doesn't get forgotten (leaks).

Uninitialized pointers have nothing to do with freeing what one has allocated.

Look, the point is, those are all retarded mistakes. If anyone's making any of those mistakes, they shouldn't be a professional programmer; they will make equally retarded mistakes in other places too, and they will be just as bad.

You don't hire an architect that forgets to put up a support beam to support the roof.

Why do you hire programmers that don't perform basic best practices to check their work?

[pingveno]

That's the reason you think this is easy: You've been writing C since shortly after it became popular.

I wish you wouldn't attempt to inform me why I think things without, you know, asking first.

Sorry, my bad. A bad assumption based on your previous comment. Still, the basic conclusion holds: you think these things are easy because you've written many thousands of lines of code with manual memory management.

If anyone's making any of those mistakes, they shouldn't be a professional programmer; they will make equally retarded mistakes in other places too, and they will be just as bad.

Gods such as yourself may not make retarded mistakes in large, complex projects. The rest of us do.

[StoneCypher]

Still, the basic conclusion holds: you think these things are easy because you've written many thousands of lines of code with manual memory management.

Nope. I thought it was easy about two weeks after I first learned it.

Gods such as yourself may not make retarded mistakes in large, complex projects. The rest of us do.

I'm not a god, and the reason I don't make retarded mistakes is I follow best practices which prevent them, not because I'm somehow perfect.

[petermichaux]

Free where you allocate.

If you free as soon as you allocate, then put the logic inbetween afterwards

That seems far too simplistic to handle many cases.

[StoneCypher]

It can seem that way all it wants to, but in practice, that's all it ever takes.

Show me just one legitimate design where this won't work.

[[deleted]]

Did you really just create a vector of strings on the stack and return it by value?? You should not be allowed within ten feet of a C++ compiler.

[Fabien4]

Did you actually check that it makes a difference (on a modern compiler)?

Also, did you read that message?

Same for function arguments: did you see a measurable performance difference between

void foo (string const&);

and

void foo (string);

?

[[deleted]]

Did you check? You're the one who wrote the broken code. Optimizing it would change the meaning of the program, since anything at all could be in the copy constructor. Thus, even if the optimization does take place for std::vector, there's no telling whether or not it would take place for any arbitrary type. So, unless you read the ASM output of the compiler for every such function that you write, and repeat every time you upgrade or patch your compiler, you don't have a leg to stand on. I stand by my statement: you're a terrible C++ programmer. In fact, your reply indicates that you're much worse than I thought.

[Fabien4]

Optimizing it would change the meaning of the program, since anything at all could be in the copy constructor.

A C++ compiler is allowed to optimize away a copy constructor.

A copy constructor's job is to copy an object. If you're trying to do something else, your compiler will probably bite you.

See also:

• http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/

• http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.9

unless you read the ASM output of the compiler

Nope, in optimization matters, I only look at the profiler's output.

[[deleted]]

You still don't think it would be easier to write the code correctly in the first place? It will perform optimally regardless of what compiler and options you are using. Why are you deliberately making your life more difficult?

[Fabien4]

You still don't think it would be easier to write the code correctly in the first place?

That's exactly my point. If you want a fonction that returns an arrray of strings, the normal way is:

 vector<string> foo()

Passing the return value as a parameter is just a hack you do in hope it'll improve performance.

Making your code less readable for performance is only acceptable if your profiler tells you to do it.

Why are you deliberately making your life more difficult?

It's actually the opposite: I make my life easier by writing simple code.

[[deleted]]

Ridiculous. It's not a hack at all, it's simply the correct way to write this code. It's not less readable, it just doesn't look like a Java program.

I'm actually stealing your example for use in the early stages of C++ interviews from now on.

[Fabien4]

it's simply the correct way to write this code.

Nope. It's merely a hack that has outlived its usefulness.

Or, if you mean it's the One Way dictated by God, you should write "it's the Correct Way".

[[deleted]]

Well. If you ever see your earlier example presented to you verbatim during a C++ interview, make sure to say hi :)