deque: the memmory is increased 
Author Message
 deque: the memmory is increased

Hello everyone!

I have in my multithreaded program a global deque.
All the time I add (by push_back function) elements and removes them (by
pop_front function).
And here is a problem:
    With time, the program's usage memory is increased permanently (I see it
in the WIN Task Manager), in spite of the fact that my deque has no more
than 100
elements.

How can I free unused memory? Does deque free unused memory by itself?

Thank u



Fri, 09 Dec 2005 01:27:32 GMT  
 deque: the memmory is increased


Quote:
>Hello everyone!

>I have in my multithreaded program a global deque.
>All the time I add (by push_back function) elements and removes them (by
>pop_front function).
>And here is a problem:
>    With time, the program's usage memory is increased permanently (I see it
>in the WIN Task Manager), in spite of the fact that my deque has no more
>than 100
>elements.

It shouldn't. What is the type of your elements? Are you sure you
don't leak memory in your copy constuctor or destructor? Are you
protecting accesses to the deque properly with a mutex/critical
section?

Quote:
>How can I free unused memory? Does deque free unused memory by itself?

Yes, it does. Post some code showing how you use the deque, and we may
be able to help.

It is possible that you are the victim of some kind of caching memory
allocator that is failing to reuse the parts of the deque that it has
finished with. What standard library are you using? What compiler?

In any case, if you want maximum performance you need to write a
circular buffer class (with a similar interface to deque) and use that
instead. The Metroworks standard library has one as an extension, or
you may be able to find a ready made one elsewhere.

Tom



Fri, 09 Dec 2005 20:50:57 GMT  
 deque: the memmory is increased
Hello again!
This is my simple code. Here I have two problems.
The first is that my memory is increased permanently and the second that
condition
"pi != Request.end() "  doesn't work always :(   (I don't understand why?)

typedef struct RequestTAG
{
    HGLOBAL   hMemoryForMessage;

Quote:
}RequestTYP;

typedef    std::deque <RequestTYP> RequestArrayTYP;
RequestArrayTYP  Request;    /* Global deque */

/*  adding into deque  */

RequestTYP NewReq;
NewReq=  HGLOBAL hMemory = GlobalAlloc (GPTR,256);
Request.push_front(NewClient);

/*  deleting  from deque  */
RequestArrayTYP::iterator pi;
RequestArrayTYP::iterator pi_temp;

for(pi=Request.begin(); pi != Request.end()  ; ++pi)
{
    if("some condition")
    {
        GlobalFree(pi->hMemoryForMessage);
        pi_temp=pi;
        pi= Request.erase(pi_temp);
    }

Quote:
}

Thank u in advance


Sun, 11 Dec 2005 19:43:25 GMT  
 deque: the memmory is increased


Quote:
>Hello again!
>This is my simple code. Here I have two problems.
>The first is that my memory is increased permanently and the second that
>condition
>"pi != Request.end() "  doesn't work always :(   (I don't understand why?)

>typedef struct RequestTAG
>{
>    HGLOBAL   hMemoryForMessage;
>}RequestTYP;

The above is a "C-ism". In C++ you just do:

struct RequestTYP
{
    HGLOBAL   hMemoryForMessage;

Quote:
};
>typedef    std::deque <RequestTYP> RequestArrayTYP;
>RequestArrayTYP  Request;    /* Global deque */

>/*  adding into deque  */

>RequestTYP NewReq;
>NewReq=  HGLOBAL hMemory = GlobalAlloc (GPTR,256);

I assume you meant
NewReq.hMemoryForMessage = GlobalAlloc (GPTR,256);
?

By why not just use new/delete?

Quote:
>Request.push_front(NewClient);

push_back is likely to be slightly more efficient, so if the way you
do it doesn't matter, go for push_back.

Quote:

>/*  deleting  from deque  */
>RequestArrayTYP::iterator pi;
>RequestArrayTYP::iterator pi_temp;

>for(pi=Request.begin(); pi != Request.end()  ; ++pi)
>{
>    if("some condition")
>    {
>        GlobalFree(pi->hMemoryForMessage);
>        pi_temp=pi;
>        pi= Request.erase(pi_temp);

The above assigns pi to the iterator after the one you are erasing.
Then ++pi increments the iterator again, missing out an element.

Quote:
>    }

The loop should be:

for(pi=Request.begin(); pi != Request.end();/*no inc*/)
{
    if("some condition")
    {
        GlobalFree(pi->hMemoryForMessage);
        pi= Request.erase(pi);
    }
    else
    {
        ++pi;
    }

Quote:
}

However, note that the above is incredibly inefficient, turning what
should be an O(n) algorithm into O(n^2).

Better would be to have RequestTYP be a proper object, using a
reference count and automatic deallocation of the memory on
destruction, and then you can use remove_if.
As it is, this is likely to be much faster:

struct ConditionFunctor
{
        bool operator()(RequestTYP const& t) const
        {      
                return "some condition";
        }

Quote:
};

struct RequestTYPDeleter
{
        bool operator()(RequestTYP& t) const
        {
                GlobalFree(t.hMemoryForMessage);        
        }

Quote:
};

//move the elements you want to remove to the end
pi = std::partition(Request.begin(), Request.end(), ConditionFunctor);
//free the memory for them (better handled by reference counting and
destructor?)
for_each(pi, Request.end(), RequestTYPDeleter());
//remove the dead elements from the deque
Request.erase(pi, Request.end());

Tom



Sun, 11 Dec 2005 20:01:34 GMT  
 deque: the memmory is increased


Quote:
> The loop should be:

> for(pi=Request.begin(); pi != Request.end();/*no inc*/)
> {
>     if("some condition")
>     {
>         GlobalFree(pi->hMemoryForMessage);
>         pi= Request.erase(pi);
>     }
>     else
>     {
>         ++pi;
>     }
> }

Well known "erase_if from sequence" idiom.

Quote:

> However, note that the above is incredibly inefficient, turning what
> should be an O(n) algorithm into O(n^2).

There is no O(N*N) in the above loop. Calling it "incredibly
inefficient" is, well, incredibly unbelievable. Sequence::erase()
returns an iterator to the element immediately following the one that
was erased. If it returned Sequence::begin() you would be right, but
this is not the case.

Quote:

> Better would be to have RequestTYP be a proper object, using a
> reference count and automatic deallocation of the memory on

That's what I would do too.

Quote:
> destruction, and then you can use remove_if.

Wrapping the container into a class with proper interface would be my
first choice.

Quote:
> As it is, this is likely to be much faster:

I don't think so.

Quote:

> struct ConditionFunctor
> {
>    bool operator()(RequestTYP const& t) const
>    {      
>            return "some condition";
>    }
> };

> struct RequestTYPDeleter
> {
>    bool operator()(RequestTYP& t) const
>    {
>            GlobalFree(t.hMemoryForMessage);        
>    }
> };

> //move the elements you want to remove to the end
> pi = std::partition(Request.begin(), Request.end(), ConditionFunctor);

O(N) complexity.

http://www.sgi.com/tech/stl/partition.html
"Complexity: Linear. Exactly last - first applications of pred, and at
most (last - first)/2 swaps."

There are no swaps in the loop version. In addition, std::partition()
is not stable. This could be a problem. std::stable_partition() is
stable, but it will attempt to allocate temporary buffer. This could
be another problem.

Quote:
> //free the memory for them (better handled by reference counting and
> destructor?)
> for_each(pi, Request.end(), RequestTYPDeleter());

Another O(N) complexity.

Quote:
> //remove the dead elements from the deque
> Request.erase(pi, Request.end());

Yet another O(N) complexity.

Both versions are O(N), but the algorithm version definitely has a
bigger constant factor than loop version. The loop version is also
much easier to grasp IMO.

Todor



Sun, 11 Dec 2005 21:16:13 GMT  
 deque: the memmory is increased

Quote:


> > The loop should be:

> > for(pi=Request.begin(); pi != Request.end();/*no inc*/)
> > {
> >     if("some condition")
> >     {
> >         GlobalFree(pi->hMemoryForMessage);
> >         pi= Request.erase(pi);
> >     }
> >     else
> >     {
> >         ++pi;
> >     }
> > }

> > However, note that the above is incredibly inefficient, turning what
> > should be an O(n) algorithm into O(n^2).

> There is no O(N*N) in the above loop.

Is too. erase from the middle of the deque is O(N) operation. There are
potentially O(N) such operations in the loop (in the worst case, every
other element satisfies the condition). The total is O(N^2).
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Sun, 11 Dec 2005 21:49:45 GMT  
 deque: the memmory is increased


Quote:


>> The loop should be:

>> for(pi=Request.begin(); pi != Request.end();/*no inc*/)
>> {
>>     if("some condition")
>>     {
>>         GlobalFree(pi->hMemoryForMessage);
>>         pi= Request.erase(pi);
>>     }
>>     else
>>     {
>>         ++pi;
>>     }
>> }

>Well known "erase_if from sequence" idiom.

Well known? It is only efficient for node based containers, like list,
set and map, and for set and map you need:

cont.erase(pi++);
rather than
pi = cont.erase(pi);

However, to call it well known implies that you see a lot of
inefficient code around. Such code makes me sad, as a mathematician by
training, but I see lots of it around, mostly from Java programmers
(anti Java troll not intended, observation only).

Quote:

>> However, note that the above is incredibly inefficient, turning what
>> should be an O(n) algorithm into O(n^2).

>There is no O(N*N) in the above loop. Calling it "incredibly
>inefficient" is, well, incredibly unbelievable. Sequence::erase()
>returns an iterator to the element immediately following the one that
>was erased. If it returned Sequence::begin() you would be right, but
>this is not the case.

You seem to be missing the fact that erasing from the middle of a
deque is O(n). All elements after (or possibly before?) the erased
element have to be shifted back one.

Quote:
>http://www.sgi.com/tech/stl/partition.html
>"Complexity: Linear. Exactly last - first applications of pred, and at
>most (last - first)/2 swaps."

>There are no swaps in the loop version. In addition, std::partition()
>is not stable. This could be a problem. std::stable_partition() is
>stable, but it will attempt to allocate temporary buffer. This could
>be another problem.

Yup, stable_partition may be required, which will slow things down a
touch.

Tom



Mon, 12 Dec 2005 00:03:10 GMT  
 deque: the memmory is increased

Quote:
> > However, note that the above is incredibly inefficient, turning what
> > should be an O(n) algorithm into O(n^2).

> There is no O(N*N) in the above loop.

Nonsense. erase of any arbitrary element in a deque involves in most
implementations the move of up to N/2 elements to close the gap. If the
element is nearer the front of the deque, the elements preceding will be
moved up, if the element is nearer the back of  the deque, the elements
succeeding will be moved down. With N elements to process I make that O(N *
N / 2).

Quote:
> Calling it "incredibly inefficient" is, well, incredibly unbelievable.

Tom is correct. There are some experimental versions of deque which may do
better but AFAIK, they are still O(N * N).

It is a shame that there is not

deque.erase_if()

for it could be O(N), erasing elements and reordering the deque in 1 pass.
Why bother moving elements that will be deleted next iteration?

Stephen Howe



Mon, 12 Dec 2005 01:36:09 GMT  
 deque: the memmory is increased

Quote:
> It is a shame that there is not

> deque.erase_if()

> for it could be O(N), erasing elements and reordering the deque in 1
pass.
> Why bother moving elements that will be deleted next iteration?

That's what remove-erase idiom is all about. You first call remove() to
move all "bad" elements to the end, then erase() to erase all of them in
one go.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Mon, 12 Dec 2005 02:15:01 GMT  
 deque: the memmory is increased

Quote:
> That's what remove-erase idiom is all about. You first call remove() to
> move all "bad" elements to the end, then erase() to erase all of them in
> one go.

Good point Igor. I forgot about that.

Stephen Howe



Mon, 12 Dec 2005 07:33:07 GMT  
 deque: the memmory is increased


Quote:
> You seem to be missing the fact that erasing from the middle of a
> deque is O(n). All elements after (or possibly before?) the erased
> element have to be shifted back one.

Yes, I've missed that. Thanks to everybody who pointed out my mistake.
It should have been obvious, but would require from me to stop and
think before replying. Must be the heat. Now, before I go and hide in
some place well stocked with beer let me try to contribute something
meaningful to this thread.

Quote:
> Well known? It is only efficient for node based containers, like list,
> set and map, and for set and map you need:

> cont.erase(pi++);
> rather than
> pi = cont.erase(pi);

OK. But I still maintain that std::[stable_]partition() followed by
[possible] std::for_each() and Container::erase() is not the best
approach for random access containers. One just have to write the
correct O(N) loop.
Starting from this post from John Potter in comp.lang.c++.moderated
(http://groups.google.com/groups?selm=Pine.A32.3.96.1010913162238.1632...)

// Worker for node-based containers
template<class Container, class Predicate, class Op>
void erase_if_worker
 ( Container& c
 , typename Container::iterator first
 , typename Container::iterator last
 , Predicate pred
 , Op op
 , std::forward_iterator_tag)
{
 while(first != last)
 {
  if(pred(*first))
  {
   op(*first);
   c.erase(first++);
  }
  else
  {
   ++first;
  }
 }

Quote:
}

// Worker for random access containers.
template<class Container, class Predicate, class Op>
void erase_if_worker
 ( Container& c
 , typename Container::iterator first
 , typename Container::iterator last
 , Predicate pred
 , Op op
 , std::random_access_iterator_tag)

{
 while(first != last && !pred(*first))
  ++first;
 if(first != last)
 {
  op(*first);
  typename Container::iterator next(first);
  for(++first; first != last; ++first)
  {
   if(pred(*first))
    op(*first);
   else
    *next++ = *first;
  }
  c.erase(next, last);
 }

Quote:
}

// Dispatch to worker through iterator category
template<class Container, class Predicate, class Op>
void erase_if_loop
 ( Container& c
 , typename Container::iterator first
 , typename Container::iterator last
 , Predicate pred
 , Op op)
{
#if _MSC_VER <= 1300
 // std::iterator_traits<> does not work in VC6/VC7
 erase_if_worker
  ( c
  , first
  , last
  , pred
  , op
  , std::_Iter_cat(first));
#else
 erase_if_worker
  ( c
  , first
  , last
  , pred
  , op
  , std::iterator_traits<typename          
     Container::iterator>::iterator_category());
#endif

Quote:
}

For comparision:

template<class Container, class Pred, class Op>
void erase_if_algo(Container& c, Pred pred, Op op)
{
 typename Container::iterator i =  
  std::stable_partition(c.begin(), c.end(), pred);
 std::for_each(c.begin(), i, op);
 c.erase(c.begin(), i);

Quote:
}

Throwing in a simple class with metered copy ctor and copy assign:

struct Item
{
 static size_t s_ctors;
 static size_t s_assigns;

 int m_value;
 ...

Quote:
};

and a predicate:

template<int N>
struct Predicate
{
 bool operator()(Item const& i) const
 {
  return i.m_value % N == 0;
 }

Quote:
};

Combining this into a test program gives results that show that
erase_if_loop() is cheaper in both number of operation on Item and
execution time, which should be expected.

Quote:
> Yup, stable_partition may be required, which will slow things down a
> touch.

Changing std::partition() to std::stable_partition() changes the
difference from tens of percents to hundreds of percents. Again this
should be expected.

Quote:
> However, to call it well known implies that you see a lot of
> inefficient code around. Such code makes me sad, as a mathematician by
> training, but I see lots of it around, mostly from Java programmers
> (anti Java troll not intended, observation only).

For the record: I've never wrote a single line of Java. Though I must
admit I've done a lot of VB in last few years. That might explain it.
Or may be not. Whatever.

Todor



Mon, 12 Dec 2005 23:38:45 GMT  
 deque: the memmory is increased

Quote:
> OK. But I still maintain that std::[stable_]partition() followed by
> [possible] std::for_each() and Container::erase() is not the best
> approach for random access containers. One just have to write the
> correct O(N) loop.

You are comparing apples and oranges. Your hand-written loop preserves
only "good" elements and trashes "bad" ones. However, partition()
carefully preserves both "good" and "bad" elements, even though the
latter would be ultimately erased.

Instead of using partition, use remove_if under a well-known
remove-erase idiom:

c.erase(remove_if(c.begin(), c.end(), pred), c.end());

remove_if works in exactly the same way as your loops.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Tue, 13 Dec 2005 00:01:20 GMT  
 deque: the memmory is increased


Quote:
>OK. But I still maintain that std::[stable_]partition() followed by
>[possible] std::for_each() and Container::erase() is not the best
>approach for random access containers.

No, definitely not, but it is the best approach if you stick to
standard algorithms, and it does at least match the asymptotic
behaviour of any other algorithm (O(n)).

 One just have to write the

Quote:
>correct O(N) loop.
>Starting from this post from John Potter in comp.lang.c++.moderated
>(http://groups.google.com/groups?selm=Pine.A32.3.96.1010913162238.1632...)

Yup, there's been lots of talk of adding container algorithms in
addition to the iterator ones, since there are many algorithms that
are sub-optimal efficient if you limit yourself to range based
algorithms only.

[SNIP adaption of John Potter's code, obviously a more efficient
solution, but requiring additional non-standard algorithms]

Quote:
>For comparision:

>template<class Container, class Pred, class Op>
>void erase_if_algo(Container& c, Pred pred, Op op)
>{
> typename Container::iterator i =  
>  std::stable_partition(c.begin(), c.end(), pred);
> std::for_each(c.begin(), i, op);
> c.erase(c.begin(), i);
>}

That isn't quite the algorithm I was suggesting, but this:

template<class Container, class Pred, class Op>
void erase_if_algo(Container& c, Pred pred, Op op)
{
 typename Container::iterator i =  
  std::stable_partition(c.begin(), c.end(), std::not1(pred));
 std::for_each(i, c.end(), op);
 c.erase(i, c.end());

Quote:
}

It will obviously be a lot better for vector, although not necessarily
all that much better for deque. In addition, for the problem in
question, only the order of the first half of the partition is
important, so an algorithm like partially_stable_partition would be
ok. I think that can be written O(n) with no temporary allocations.

Quote:
>Throwing in a simple class with metered copy ctor and copy assign:

>struct Item
>{
> static size_t s_ctors;
> static size_t s_assigns;

> int m_value;
> ...
>};

>and a predicate:

>template<int N>
>struct Predicate
>{
> bool operator()(Item const& i) const
> {
>  return i.m_value % N == 0;
> }
>};

>Combining this into a test program gives results that show that
>erase_if_loop() is cheaper in both number of operation on Item and
>execution time, which should be expected.

>> Yup, stable_partition may be required, which will slow things down a
>> touch.

>Changing std::partition() to std::stable_partition() changes the
>difference from tens of percents to hundreds of percents. Again this
>should be expected.

I think this is partly down to a poor stable_partition implementation.
To make the implementation easier in the face of exceptions, the
elements in the temporary buffer are probably being unnecessarily
default constructed, when they could be placement copy constructed as
and when required.

Quote:

>> However, to call it well known implies that you see a lot of
>> inefficient code around. Such code makes me sad, as a mathematician by
>> training, but I see lots of it around, mostly from Java programmers
>> (anti Java troll not intended, observation only).

>For the record: I've never wrote a single line of Java. Though I must
>admit I've done a lot of VB in last few years. That might explain it.
>Or may be not. Whatever.

I'm mostly programming Java these days. :(

Tom



Tue, 13 Dec 2005 21:56:07 GMT  
 deque: the memmory is increased
On Thu, 26 Jun 2003 12:01:20 -0400, "Igor Tandetnik"

Quote:

> You are comparing apples and oranges. Your hand-written loop preserves
> only "good" elements and trashes "bad" ones. However, partition()
> carefully preserves both "good" and "bad" elements, even though the
> latter would be ultimately erased.

Perhaps you forgot what the OP was about. Let me summarize:

Given CopyConstructible and Assignable type Type and
  typedef std::deque<Type> TypeContainer;
  struct Predicate {
    bool operator()(Type const& t) const;
  };
  struct Operation {
    void operator()(Type& t) const;
  };

write an algorithm Algo()
  // PreCondition: none
  // PostCondition:
  //  std::find_if(c.begin(), c.end(), pred) == c.end()
  // Effects:
  //  Invokes op on each element removed from c.
  void Algo(TypeContainer& c, Predicate pred, Operation op);

For example, in the OP's case:
  struct Type
  {
    HGLOBAL hMemoryForMessage;
  };

  bool Predicate::operator()(Type const& t) const
  {
    return "some condition";
  }

  void Operation::operator()(Type& t) const
  {
    ::GlobalFree(t.hMemoryForMessage);
  }

Quote:
> Instead of using partition, use remove_if under a well-known
> remove-erase idiom:

> c.erase(remove_if(c.begin(), c.end(), pred), c.end());

> remove_if works in exactly the same way as your loops.

Do you still think that remove_if works in exactly the same way?

Todor



Wed, 14 Dec 2005 19:15:45 GMT  
 deque: the memmory is increased


Quote:


> >OK. But I still maintain that std::[stable_]partition() followed by
> >[possible] std::for_each() and Container::erase() is not the best
> >approach for random access containers.

> No, definitely not, but it is the best approach if you stick to
> standard algorithms, and it does at least match the asymptotic
> behaviour of any other algorithm (O(n)).

If you take into account only the level of familiarity and LOC, then
yes, it could be the considered better. There could be other criteria,
though.

Quote:

>  One just have to write the
> >correct O(N) loop.
> >Starting from this post from John Potter in comp.lang.c++.moderated
> >(http://groups.google.com/groups?selm=Pine.A32.3.96.1010913162238.1632...)

> Yup, there's been lots of talk of adding container algorithms in
> addition to the iterator ones, since there are many algorithms that
> are sub-optimal efficient if you limit yourself to range based
> algorithms only.

From what I recall there wasn't much enthusiasm for adding container
algorithms in std lib. At least I haven't heard of such proposal.
Wasn't there a Boost project for such things?

Quote:
> >For comparision:

> >template<class Container, class Pred, class Op>
> >void erase_if_algo(Container& c, Pred pred, Op op)
> >{
> > typename Container::iterator i =  
> >  std::stable_partition(c.begin(), c.end(), pred);
> > std::for_each(c.begin(), i, op);
> > c.erase(c.begin(), i);
> >}

> That isn't quite the algorithm I was suggesting, but this:

> template<class Container, class Pred, class Op>
> void erase_if_algo(Container& c, Pred pred, Op op)
> {
>  typename Container::iterator i =  
>   std::stable_partition(c.begin(), c.end(), std::not1(pred));
>  std::for_each(i, c.end(), op);
>  c.erase(i, c.end());
> }

> It will obviously be a lot better for vector, although not necessarily
> all that much better for deque.

Agreed.

Quote:
> In addition, for the problem in
> question, only the order of the first half of the partition is
> important, so an algorithm like partially_stable_partition would be
> ok. I think that can be written O(n) with no temporary allocations.

I think of std::partition() as "symmetrical" algorithm - treating one
of the halfs differently seems like very "non-partition" thing to do.
remove_if() (remove_preserve_if?) might be better starting place for
naming such algorithm. As for writting it - if you have an idea can
you please describe it? This is something that I can add to my xstd
namespace along with things like copy_if.

Quote:
> >Changing std::partition() to std::stable_partition() changes the
> >difference from tens of percents to hundreds of percents. Again this
> >should be expected.

> I think this is partly down to a poor stable_partition implementation.
> To make the implementation easier in the face of exceptions, the
> elements in the temporary buffer are probably being unnecessarily
> default constructed, when they could be placement copy constructed as
> and when required.

I don't see the need of default construction. In Dinkumware
implemetation the temporary buffer is dumped down vector - initialy
empty with capacity fixed on construction, copy/assign with auto_ptr
flavor, no resize, push_back constructs in place.

Quote:

> >For the record: I've never wrote a single line of Java. Though I must
> >admit I've done a lot of VB in last few years. That might explain it.
> >Or may be not. Whatever.

> I'm mostly programming Java these days. :(

I'm back to C++ in the last few months. 3+ years old project, VC6/MFC
and no chance of upgrading, abysmal SCC (PVCS), very low level of
competence (without even getting into architecture/design issues -
containers of auto_ptr are not uncommon, numerous leaks. The folks
have found a "clever" way to get rid of automatic leak report:
TerminateProcess() from CMainFrame::OnClose()).

Leaving money aside for a moment, would you prefer working in such
conditions or with even moderately competent programmers, even if the
main language is Java, C# or VB?

I know what I prefer, but I cannot afford to leave money aside, except
for a moment :(

Todor



Wed, 14 Dec 2005 19:23:24 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. deque - I am being bitten

2. memmory accessing

3. Memmory protection

4. Unable to Unload DLL from memmory

5. Memmory mapped files

6. I am new to programming and am lost

7. Access Violation in list, vector, stack, deque... What am I doing wrong?!?!?!?!?!?

8. template-template params default values - std::deque

9. Deque routine

10. deque

11. Problem with my DEQUE program?

12. deque Data Structure

 

 
Powered by phpBB® Forum Software