Say I wrote

int** foo = NULL;
int nx = 22, ny = 17;

void matrixfunc(){
  foo = new int*[nx];

  for (int x = 0; x < nx; x++)
   foo[x] = new int[ny];
}


and called matrixfunc();, but before I could delete it

for (int x = 0; x < nx; x++)
  delete[] foo[x];

  delete[] foo;
  foo = NULL;

the code crashed. Do I have a memory leak?

Sam

Post a reply to this message

On Thu, 20 Mar 2008 00:52:55 +0100, stbenge <stb### [at] hotmailcom> wrote:

> Say I wrote
>
> int** foo = NULL;
> int nx = 22, ny = 17;
>
> void matrixfunc(){
>   foo = new int*[nx];
>
>   for (int x = 0; x < nx; x++)
>    foo[x] = new int[ny];
> }

Much better to use std::vector instead. Avoid raw pointers like the  

plague; it will save you many headaches.



> and called matrixfunc();, but before I could delete it
>
> for (int x = 0; x < nx; x++)
>   delete[] foo[x];
>
>   delete[] foo;
>   foo = NULL;
>
> the code crashed. Do I have a memory leak?

If by "crash" you mean unexpected program termination, then not really  

(not because of the crash anyway). Any modern desktop OS will reclaim th
e  

resources held by a program when said program terminates.



-- 

FE

Post a reply to this message

Warp wrote:
>   (OTOH, one could argue that understanding "0 < money" becomes easy when
> you use it a lot...)

Yes, it takes practice.

>   The form you suggest becomes a bit counter-productive when the expression
> is not a pure "between x and y", like for example:
> 
> if(10 < money*money && money*12 < 100)
> 
>   Now it becomes much harder to understand quickly what's going on.

If money squared is more than ten or money times twelve is less than a 
hundred.  Makes sense to me. :-)  But then, I'm used to it.

I've noticed since this came up that I'll even do things like
   if (i > 0^H^H^H^H^H0 < i) ....

>   In most cases the compiler will issue a warning anyways if you make
> the mistake. Never been a problem to me.

It depends on the language, and the compiler.  A lot of embedded 
compilers aren't too smart, and a lot of languages that adopted C syntax 
(PHP, Java, etc) aren't too smart about that too.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Invisible wrote:
>>> But alas, it's not purely functional,
>>
>> Yeah. I don't think you could get a real distributed language with 
>> everything being truly functional, could you?
> 
> Um... why?

Because it's nondeterministic? It's I/O driven? It's asynchronous?

I mean, to the extent that you think a tail-recursive function accepting 
asynchronous messages and sending asynchronous messages in return can be 
"functional," then it looks like Erlang is functional.

>> I mean, what's the functional equivalent of "the machine running the 
>> calculation just burst into flames"? :-)
> 
> Throwing an exception, as a guess. Like a division by zero error, but 
> less deterministic. (??!?!) ;-)

Who throws the exception? The machine running the calculation isn't in 
any shape to do so.

>> What's the functional equivalent of "we've just released a new version 
>> of this function"?
> 
> Now that's an interesting question...

Let me know when you figure it out. ;-)

>>> and the general style just seemed untidy and complicated. It's just 
>>> not my cup of tea...
>>
>> Yep. Altho the language itself seems pretty simple and straightforward, 
> 
> If by "simple and straight forward" you mean "assumes referential 
> transparency but doesn't actually enforce it or make any attempt to 
> check that it's there", then sure. Go knock yourself out. ;-)

Where do you think it doesn't assume referential transparency?

By "simple and straightforward" I meant in the sense that there are 
relatively few types and primitives and interactions between them. More 
like Tcl or C than Ada or C++.

> Gotta love documentation where you can't figure out what order to read 
> it in...

It's not unusual. It's how I learned most of the languages I know. But 
then, most of the languages I learned that way didn't have 1500+ pages 
of documentation for the libraries. :-)  A two-pass read of the library 
docs is going to take a while.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

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.

My understanding is that there are piles and piles of gotchas you have 
to learn about before you can make reliable programs, even if you stay 
within the definition of the language and don't start doing threads or 
dynamic code loading or things like that.

With C, for example, there are only a handful of gotchas you have to 
learn about. Stuff like "don't run off allocated memory", "don't fail to 
declare types of function arguments and returns", "make sure your 
definitions match your declarations", "put parens around your macros", etc.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> Replacing
>      std::map<A, int, Comp> theMap(Comp());
> with
>      Comp c; std::map<A, int, Comp> theMap(c);

  That's not the shortest possible solution.

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

  No.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> 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.

  But why? Doesn't "Comp()" create an object? How can you declare a function
with an object (instead of a type)?

  What kind of function? What does it return? Does it take parameters?
What is the type of those parameters?

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

  Alternatively you can do:

std::map<A, int, Comp> theMap((Comp()));

(which would be necessary if the map constructor took more than one such
parameter...)

-- 
                                                          - Warp

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Thu, 20 Mar 2008 00:52:55 +0100, stbenge <stb### [at] hotmailcom> wrote:
> > Say I wrote
> >
> > int** foo = NULL;
> > int nx = 22, ny = 17;
> >
> > void matrixfunc(){
> >   foo = new int*[nx];
> >
> >   for (int x = 0; x < nx; x++)
> >    foo[x] = new int[ny];
> > }

> Much better to use std::vector instead. Avoid raw pointers like the  
> plague; it will save you many headaches.

  Yeah. You can do that with a one-liner:

std::vector<std::vector<int> > foo(nx, std::vector<int>(ny));

  And you don't have to delete anything.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>>>> But alas, it's not purely functional,
>>>
>>> Yeah. I don't think you could get a real distributed language with 
>>> everything being truly functional, could you?
>>
>> Um... why?
> 
> Because it's nondeterministic? It's I/O driven? It's asynchronous?
> 
> I mean, to the extent that you think a tail-recursive function accepting 
> asynchronous messages and sending asynchronous messages in return can be 
> "functional," then it looks like Erlang is functional.

Haskell supports random number generators. And I/O. And asynchronous 
exceptions. It just cleanly seperates what *is* deterministic from what 
is *not*, that's all. ;-)

>>> I mean, what's the functional equivalent of "the machine running the 
>>> calculation just burst into flames"? :-)
>>
>> Throwing an exception, as a guess. Like a division by zero error, but 
>> less deterministic. (??!?!) ;-)
> 
> Who throws the exception? The machine running the calculation isn't in 
> any shape to do so.

I would presume the exception is just thrown to whoever is waiting for 
the answer?

>>> What's the functional equivalent of "we've just released a new 
>>> version of this function"?
>>
>> Now that's an interesting question...
> 
> Let me know when you figure it out. ;-)

To be honest, I'm not really seeing a clean way to handle this in *any* 
language, but I haven't thought about it for that long yet.

>> If by "simple and straight forward" you mean "assumes referential 
>> transparency but doesn't actually enforce it or make any attempt to 
>> check that it's there", then sure. Go knock yourself out. ;-)
> 
> Where do you think it doesn't assume referential transparency?

Please reparse my sentence. I said it *does* assume referential 
transparency yet does nothing to *enforce* or even *check* for it.

In other words, if you're not careful, you can easily cause the system 
to massively malfunction with a few incautiously chosen commands.

> By "simple and straightforward" I meant in the sense that there are 
> relatively few types and primitives and interactions between them. More 
> like Tcl or C than Ada or C++.

I consider Haskell to be quite simple in this respect too. Until you 
start digging things up out of the standard libraries, the language 
itself gives you lists, tuples, integers, reals, booleans, characters, 
and that's more or less it. And the language is nearly devoid of 
keywords. (Decide for yourself if that's good or bad.)

>> Gotta love documentation where you can't figure out what order to read 
>> it in...
> 
> It's not unusual. It's how I learned most of the languages I know. But 
> then, most of the languages I learned that way didn't have 1500+ pages 
> of documentation for the libraries. :-)  A two-pass read of the library 
> docs is going to take a while.

I'm looking at you, Oracle. Trying to figure out where to start reading 
to actually comprehend this stuff is *far* too hard!

It's not that Oracle is hard to understand - just that the [multiple] 
manuals explain it quite poorly.

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

Post a reply to this message

Warp wrote:

> 
>   The form you suggest becomes a bit counter-productive when the expression
> is not a pure "between x and y", like for example:
> 
> if(10 < money*money && money*12 < 100)
> 
>   Now it becomes much harder to understand quickly what's going on.
> 

Right, and I don't think I'd dare use that form for a set of comparisons 
like that. But for simple ranges, it makes sense.

> 
>   In most cases the compiler will issue a warning anyways if you make
> the mistake. Never been a problem to me.
> 

Until you're working on some project where someone has set the Warning 
level so low that there are no warnings. (I have run into that, and 
setting the warning level any higher scared me ... so many warnings...)

>> My favorite syntactical bug was the following:
> 
>> for(int i = 0; i < cItems; i++);
>> {
>>     ... Block of code ...
>> }
> 
>> It's subtle, and if your for loops are any more complex than the above 
>> trivial example, results in headaches. I spent an hour tracking 
>> something similar down in my early days.
> 
>   If the loop of the body uses 'i' (as is rather usual) you'll get a
> compiler error.
> 

Without opening the argument on MS compiler vs a truly ANSI compliant 
compiler, that is not the case with Visual C++. It happily compiles the 
code because i is still declared after the for loop.

(I dislike this sort of behavior, and IIRC, they fixed it in more recent 
versions, but have an option to keep it compatible with code written in 
older versions)

Post a reply to this message