Re: excuse me if this is a real noddy question ...

> The only "obvious" reason for that would be if you need the pointer
> *after* the for loop.

this is not the obvious reason to which I was alluding, but again, I could
quite simply be WRONG.

it is my belief that the following call does two things

MyObject *ptrObject = new MyObject();

1) heap space is found and allocated for an object of size __sizeof(MyObject)
2) the object is initialised at the location given by ptrObject

so, if I were to make this call inside a loop (of any kind), each time the
call is made, heap space is found and allocated, whereas should the decl be
made outside the loop, heap space is only allocated once, and the object is
only instantiated for each iteration.

Speed is not the issue here, but instead it is available resources. Am I
still barking up the wrong tree?

--
--

Of all words of tongue and pen, the saddest are: "It might have been"


"Helge Jensen" wrote:

> billr wrote:
>
> > traditionally, I would declare my pointer OUTSIDE of the for loop (for
> > obvious reasons),
>
> The only "obvious" reason for that would be if you need the pointer
> *after* the for loop.
>
> > but whilst reviewing code produced by several "seasoned"
> > developers, their C# code does the opposite, for example:
>
> "seasoned" programmers should avoid micro-optimization, especially
> things like moving declarations outside loops to gain speed. The
> compiler will remove the percieved overhead, even when not generating
> optimized code.
>
> A good way to make fast programs is:
>
> 1. use the right algorithms and data-structures
> 2. only "optimize" code if the profiler shows it is using much of the
> run-time.
>
> > what I want to know is, yes, we are using a managed heap, but that doesn't
> > necessarily make that last bit of code any more acceptable does it?
>
> The first bit of code is probably most "unacceptable", in both C, C++
> and C#.
>
> --
> Helge Jensen
> mailto:helge.jensen@xxxxxxx
> sip:helge.jensen@xxxxxxx
> -=> Sebastian cover-music: http://ungdomshus.nu <=-
>
.

Relevant Pages

  • Re: Code comments solicited
    ... A decrementing loop is reasonably well understood, ... pointer to an array of pointers to functions, ... pointer to a function that returns an array of int's, ... counter unless you have a specific reason to do otherwise, ...
    (comp.lang.cpp)
  • Re: object system...
    ... but you shall not reason contradictory. ... while Halt loop ... Any finite halting problem is decidable, ...
    (comp.object)
  • Re: Which Is Better?
    ... The reason they gave was from a DBA perpspective like it was ... MERGE really necessary here - do you do any inserts in that loop, ... statistics for both approaches and compare them to see what could ... Did you capture any other statistics aside from run time ...
    (comp.databases.oracle.misc)
  • Re: measuring clock cycles per second
    ... In fact, I am not trying to convince you, I'm trying to find a reason why you would think it's useless. ... Let's assume that a program only executes a single loop and this loop ... Even if the average execution time of #1 is exactly 1/4 of the sampling interval and the average execution time of #2 is exactly 3/4 of the sampling interval, then, provided the standard deviation of the respective probability distributions of times is nonzero, the total time taken by the loop will, in general, be unequal to the sampling interval, even if by a mere 1%. ... Rather than the poor resolution, I find the fact that measurement itself leads to changes in timing more difficult to work with, especially when -g is used (not sure about the reason). ...
    (comp.os.linux.development.apps)
  • Re: Need Thread Advice
    ... The event object concept seems more reasonable. ... The code is written so that when a button is clicked, I open a com port ... but the release code hung in the whileloop. ... reason for this is volatile typically does not have the correct memory ...
    (microsoft.public.vc.mfc)
Loading