Warp wrote:
> Mike Raiford <mra### [at] hotmailcom> wrote:
>> I'd venture to say C# also has an astounding amount of libraries (at 
>> least, on the Windows platform ...) the base library for .NET is pretty 
>> extensive, though not without limitations, but those can easily be 
>> worked around. I don't know whether the base libraries for Mono are as 
>> plentiful, as I only have very limited experience with Mono.
> 
>> The drawback? It's not viewed as a high performance language.
> 
>   And rather Windows-only.

Isn't that the whole point of the Mono project?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

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

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

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

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

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

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

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

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

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