POV-Ray : Newsgroups : povray.off-topic : Smart little programming tricks, where to find ? Server Time
11 Oct 2024 01:24:08 EDT (-0400)
  Smart little programming tricks, where to find ? (Message 22 to 31 of 51)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: stbenge
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 12:12:02
Message: <47e14962$1@news.povray.org>
Warp wrote:
> stbenge <stb### [at] hotmailcom> wrote:
>> What's wrong with C++?
> 
>   Some people don't like the fact that memory management requires great care.

I don't find it too difficult to delete every "new". Of course, I 
haven't coded anything too huge... yet.

Sam


Post a reply to this message

From: Warp
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 12:34:11
Message: <47e14e92@news.povray.org>
stbenge <stb### [at] hotmailcom> wrote:
> I don't find it too difficult to delete every "new".

  You would be surprised.

  There's a potential memory leak here:

void foo()
{
    char* s = new char[100];
    bar();
    delete[] s;
}

  There's a potential memory leak here:

class A
{
    char* s;

 public:
    A(): s(new char[100]) {}
    ~A() { delete[] s; }
};

  Naturally both of these leaks can be fixed by using cleaner code:

void foo()
{
    std::string s(100, ' ');
    bar();
}

class A
{
    std::string s;

 public:
    A(): s(100, ' ') {}
};

  No 'new' -> no leaks.

-- 
                                                          - Warp


Post a reply to this message

From: Vincent Le Chevalier
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 13:00:04
Message: <47e154a4$1@news.povray.org>
Warp a écrit :
> stbenge <stb### [at] hotmailcom> wrote:
>> I don't find it too difficult to delete every "new".
> 
>   You would be surprised.
>   No 'new' -> no leaks.
> 
Hey, but there are 'new's in the standard lib :-)

I think it would be more informative to give fixes that do not rely on 
the standard library... After all the 'new' operator exists for a 
reason, you don't always want to use the standard lib, and knowing what 
to do in these cases is useful.

No I won't do it as I'm not even sure I know where the leak is in the 
first case :-)

-- 
Vincent


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 13:01:41
Message: <47e15505$1@news.povray.org>
Warp escribió:
> stbenge <stb### [at] hotmailcom> wrote:
>> I don't find it too difficult to delete every "new".
> 
>   You would be surprised.
> 
>   There's a potential memory leak here:
> 
> void foo()
> {
>     char* s = new char[100];
>     bar();
>     delete[] s;
> }

If bar throws an exception, s won't be deleted. It can be avoided by 
using a smart pointer.

>   There's a potential memory leak here:
> 
> class A
> {
>     char* s;
> 
>  public:
>     A(): s(new char[100]) {}
>     ~A() { delete[] s; }
> };

Erm... No idea :) I know it could cause a double-free if you copy the 
object, since it doesn't have an explicit copy constructor and the 
default one doesn't do what we want in this case; but I don't know what 
could cause a leak.

>   Naturally both of these leaks can be fixed by using cleaner code:
> 
> void foo()
> {
>     std::string s(100, ' ');
>     bar();
> }
> 
> class A
> {
>     std::string s;
> 
>  public:
>     A(): s(100, ' ') {}
> };

Of course a string is better for this particular case :) Also avoids 
many possible buffer overflows (thought not all; operator[] is unchecked).


Post a reply to this message

From: Warp
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 16:02:56
Message: <47e17f80@news.povray.org>
Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> I think it would be more informative to give fixes that do not rely on 
> the standard library... After all the 'new' operator exists for a 
> reason, you don't always want to use the standard lib, and knowing what 
> to do in these cases is useful.

  If the standard library cannot be used, then it becomes a bit complicated.

> No I won't do it as I'm not even sure I know where the leak is in the 
> first case :-)

  If bar() throws an exception you have a memory leak.

-- 
                                                          - Warp


Post a reply to this message

From: Warp
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 16:04:51
Message: <47e17ff3@news.povray.org>
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Erm... No idea :) I know it could cause a double-free if you copy the 
> object, since it doesn't have an explicit copy constructor and the 
> default one doesn't do what we want in this case; but I don't know what 
> could cause a leak.

  Ok, not a leak per se, but accessing freed memory. (Although that would
require more member functions than I added there...)

-- 
                                                          - Warp


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 17:15:59
Message: <47e1909f$1@news.povray.org>
Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Erm... No idea :) I know it could cause a double-free if you copy the 
>> object, since it doesn't have an explicit copy constructor and the 
>> default one doesn't do what we want in this case; but I don't know what 
>> could cause a leak.
> 
>   Ok, not a leak per se, but accessing freed memory. (Although that would
> require more member functions than I added there...)
> 

Ahh, then I can say I did figure out both.


Post a reply to this message

From: Warp
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 17:36:56
Message: <47e19586@news.povray.org>
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Ahh, then I can say I did figure out both.

  Ok, if you want a harder puzzle, here's a curious quirk about C++ (not
related to memory leaks, though):

//------------------------------------------------------------------------
#include <map>

struct A { int i; };

struct Comp
{ bool operator()(const A& a1, const A& a2) const { return a1.i < a2.i; }
};

int main()
{
    std::map<A, int, Comp> theMap(Comp());
    A a = { 1 };
    theMap[a] = 5;
}
//------------------------------------------------------------------------

a) This doesn't compile. Without using a compiler, can you tell where
   is the problem and what is the exact reason why it doesn't compile?

b) If you can't see it, try it with a compiler. I bet you still can't see
   the problem... :P

c) In the erroneous line, can you tell me exactly what that line means?

d) What is the easiest way (smallest amount of extra code) to make it
   compile and work as expected?

-- 
                                                          - Warp


Post a reply to this message

From: Vincent Le Chevalier
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 18:08:32
Message: <47e19cf0@news.povray.org>
Warp a écrit :
>   Ok, if you want a harder puzzle, here's a curious quirk about C++ (not
> related to memory leaks, though):
> 
> a) This doesn't compile. Without using a compiler, can you tell where
>    is the problem and what is the exact reason why it doesn't compile?
> 
> b) If you can't see it, try it with a compiler. I bet you still can't see
>    the problem... :P
> 
> c) In the erroneous line, can you tell me exactly what that line means?
> 
> d) What is the easiest way (smallest amount of extra code) to make it
>    compile and work as expected?
> 

Well I have no real idea of what goes wrong but I have a proposition for 
d) :-) Down below...

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Replacing
     std::map<A, int, Comp> theMap(Comp());
with
     Comp c; std::map<A, int, Comp> theMap(c);
seems to do the trick as far as I figure. I don't like those anonymous 
objects anyhow ;-)

A trouble with references or some such ? That prevents the full 
instanciation of the map template ?

-- 
Vincent


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: Smart little programming tricks, where to find ?
Date: 19 Mar 2008 18:24:48
Message: <47e1a0c0$1@news.povray.org>
Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Ahh, then I can say I did figure out both.
> 
>   Ok, if you want a harder puzzle, here's a curious quirk about C++ (not
> related to memory leaks, though):
> 
> //------------------------------------------------------------------------
> #include <map>
> 
> struct A { int i; };
> 
> struct Comp
> { bool operator()(const A& a1, const A& a2) const { return a1.i < a2.i; }
> };
> 
> int main()
> {
>     std::map<A, int, Comp> theMap(Comp());
>     A a = { 1 };
>     theMap[a] = 5;
> }

Hrm, I never used map myself. I think I'll go search documentation on 
what the template parameters are.

> a) This doesn't compile. Without using a compiler, can you tell where
>    is the problem and what is the exact reason why it doesn't compile?
 >
> b) If you can't see it, try it with a compiler. I bet you still can't see
>    the problem... :P
> 
> c) In the erroneous line, can you tell me exactly what that line means?
> 
> d) What is the easiest way (smallest amount of extra code) to make it
>    compile and work as expected?

Oh I think I know. I took a while without noticing anything wrong, but 
now I remember having read about it in C++ FAQ Lite. theMap(Comp()) 
*declares a function* instead of instantiating an object. Good to know 
all the time I wast^H^H^H^H spent reading that website was actually useful.

Okay, *after* remembering that and writing that paragraph, I went and 
searched for what I remembered having read. Maybe that counts as 
cheating... I wouldn't have searched if I had read question D before, so 
I could try figuring out the solution myself :)

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

The solution is:
std::map<A, int, Comp> theMap = Comp();


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.