Re: deque best practices - C / C++ / MFC Discussion Boards

Re: Force flush of unwritten data to USB stick?

dontknowitall2-Mar-08 3:39

dontknowitall

2-Mar-08 3:39

I've done that before. IIRC, you have to delve into DeviceIoControl().

Re: Force flush of unwritten data to USB stick?

Dominik Reichl2-Mar-08 4:00

Dominik Reichl

2-Mar-08 4:00

Do you remember the control code you used?

I've only found IOCTL_STORAGE_EJECT_MEDIA and such things, but no code to only flush write buffers.

Thanks for your reply, best regards
Dominik

Too many passwords to remember? Try KeePass Password Safe!

Re: Force flush of unwritten data to USB stick?

dontknowitall2-Mar-08 9:00

dontknowitall

2-Mar-08 9:00

Look at "FSCTL_LOCK_VOLUME". MSDN Library has this to say about it:

"The system flushes all cached data to the volume before locking it. For example, any data held in a lazy-write cache is written to the volume."

Re: Force flush of unwritten data to USB stick?

Dominik Reichl2-Mar-08 9:57

Dominik Reichl

2-Mar-08 9:57

I'll try that, thanks a lot!!

Too many passwords to remember? Try KeePass Password Safe!

Re: Force flush of unwritten data to USB stick?

JudyL_MD3-Mar-08 2:13

JudyL_MD

3-Mar-08 2:13

FlushFileBuffers doesn't work for a USB file?

Judy

deque best practices

George_George1-Mar-08 23:18

George_George

1-Mar-08 23:18

Hello everyone,

This is what mentioned in the book The C++ Standard Library, section 6.3 Deques,

--------------------
In summary, you should prefer a deque if the following is true:

You don't refer to elements of the container.

It is important that the container frees memory when it is no longer used (however, the standard does not guarantee that this happens).
--------------------

My confusions,

1. What means "refer to elements of the container"? We should not do that? Why -- we always refer to elements in the container? When we use iterator of deque to acccess elements in deque container, we always refer to elements of container, right? What does the author mean?

2. I think whether deque container implementation actually free the memory when we do erase or pop or just mark it as freed to reserve for future use (e.g. insert or push) is up to implementation details, does this point to be a reason why we use deque? Confused.

thanks in advance,
George

Re: deque best practices

C^hris L^osinger2-Mar-08 5:15

C^hris L^osinger

2-Mar-08 5:15

i assume he means you should only pop elements off the front end of the queue to look at them, you don't iterate over the queue and look at items the way you would with a vector (or a list). you use a queue when you need access to the front end (for reading) and the back end (for writing), and you don't much care about what happens in the middle.

image processing toolkits | batch image processing

Re: deque best practices

George_George2-Mar-08 14:09

George_George

2-Mar-08 14:09

Thanks Chris Losinger!

How do you understand this "It is important that the container frees memory when it is no longer used (however, the standard does not guarantee that this happens)."?

regards,
George

Re: deque best practices

C^hris L^osinger2-Mar-08 14:12

C^hris L^osinger

2-Mar-08 14:12

nobody would use or publish a container that didn't release memory when it was no longer needed. so i wouldn't worry about it.

image processing toolkits | batch image processing

Re: deque best practices

George_George2-Mar-08 14:51

George_George

2-Mar-08 14:51

Hi Chris Losinger,

Please read the context,

--------------------
In summary, you should prefer a deque if the following is true:

It is important that the container frees memory when it is no longer used (however, the standard does not guarantee that this happens).
--------------------

I do not know why "container frees memory is a reason why we use deque". I think it is up to implementation whether to free the memory or delay the free for the reason of performance improvement when we do rease/pop.

I think the author does not mean memory leak. Any comments? I do not know why it becomes a reason...

regards,
George

Re: deque best practices

C^hris L^osinger2-Mar-08 15:02

C^hris L^osinger

2-Mar-08 15:02

i don't have an answer for this.

you use a dequeue when you needs its primary functionality (ex: pop_front, push_back) and don't need random access (like with a vector). the exact implementation and its memory allocation strategy is not worth worrying about in the vast majority of situations.

image processing toolkits | batch image processing

Re: deque best practices

George_George2-Mar-08 15:13

George_George

2-Mar-08 15:13

Thanks Chris Losinger,

Question answered.

regards,
George

typedef struct problem

gentleguy1-Mar-08 22:21

gentleguy

1-Mar-08 22:21

dear all

how to understand typedef and struct..

for example: typedef struct a
{
int c;
int b;
} ddd;

how to understand typedef and ddd here/ thanks a lot

sorry for such easy question.

Li Zhiyuan

Re: typedef struct problem

Gary R. Wheeler2-Mar-08 1:04

Gary R. Wheeler

2-Mar-08 1:04

The typedef keyword creates a new name for an existing type. Using your example,

typedef struct a {
  int c;
  int b;
} ddd;

you can use the following:

struct a a1;
ddd a2;

This can be very useful when the existing name for a type is complicated (for example, with templates in C++).

Software Zen: delete this;
Fold With Us![^]

Re: typedef struct problem

gentleguy2-Mar-08 15:52

gentleguy

2-Mar-08 15:52

thanks friend.

how to understand ddd here? what does it denote? thanks

Li Zhiyuan

Re: typedef struct problem

Gary R. Wheeler3-Mar-08 11:18

Gary R. Wheeler

3-Mar-08 11:18

ddd is simply another name for the original struct a type.

Let me create another example for you:

template <typename integer>
class Process {
public:
  Process(integer initial)
  : Initial(initial)
  { };
private:
  integer   Initial;
};
 
typedef Process<unsigned long> ProcessULong;

Now, rather than having to type "Process<unsigned long>" every time you want to declare a value of this type, you can simply use "ProcessULong", like this:

ProcessULong PUL1;

typedef's are simply a convenience. They don't create a new type. They simply make a new name for an existing type.

Software Zen: delete this;
Fold With Us![^]

size and iterator of deque

George_George1-Mar-08 20:43

George_George

1-Mar-08 20:43

Hello everyone,

I am studying the C++ Standard Library book. In 6.3 Deques, it is mentioned,

1.

Iterators must be smart pointers of a special type rather than ordinary pointers because they must jump between different blocks.

What means "smart pointers of a special type" here? I do not understand if smart pointers here means auto_ptr something.

2.

In systems that have size limitations for blocks of memory (for example, some PC systems), a deque might contain more elements because it uses more than one block of memory. Thus, max_size() might be larger for deques.

I do not quite understand why we need special care about "more elements, ... more than one block of memory". I have this confusion is because deque is implemented as chunks of memory internally, which is already more than one blocks of memory, it has nothing to do with size limitations. What does the author mean here?

Why "max_size() might be larger for deques"?

thanks in advance,
George

Re: size and iterator of deque

markkuk1-Mar-08 22:10

markkuk

1-Mar-08 22:10

1. "smart" means that the iterators must overload e.g. the ++ and -- operators to deal with non-contiguous memory blocks. That means a deque iterator must be a class type as opposed to a vector iterator which can be a plain pointer.

2. Did you miss the part that says: "Deques have the following differences compared with the abilities of vectors"? Vectors must be in contiguous memory, deques may have multiple separate blocks. If the size of a contiguous memory block is limited, deques may grow bigger than vectors.

Re: size and iterator of deque

George_George1-Mar-08 22:50

George_George

1-Mar-08 22:50

Thanks markkuk,

1.

markkuk wrote:
1. "smart" means that the iterators must overload e.g. the ++ and -- operators to deal with non-contiguous memory blocks. That means a deque iterator must be a class type as opposed to a vector iterator which can be a plain pointer.

Thanks. Your description is clear. So it does not mean auto_ptr, just mean the pointer is not a plain raw point to deal with contigious memory block. Right? Smile | :)

2.

"the ++ and -- operators to deal with non-contiguous memory blocks", I think for deque, it involves move between different internal chunks (which are not continuous in memory address), right?

3.

Is it a must vector must use continuous memory block? I think it is not a must and if not a must, then for vector, it should be also smart pointer?

regards,
George

random access iterator

George_George1-Mar-08 20:33

George_George

1-Mar-08 20:33

Hello everyone,

For random access iterator, operator[] is supported. Mentioned in Bjarne's book, Chapter 19 (Iterators and Allocators).

I have not used operator[] on random access iterator before and I have not found a good and simple sample either. Smile | :)

Could anyone show its usage with some pseudo code please?

thanks in advance,
George

Re: random access iterator

Stephen Hewitt2-Mar-08 12:44

Stephen Hewitt

2-Mar-08 12:44