• Adi (14/14) Nov 26 2009 Hi,
• Matthew Wilson (12/24) Nov 26 2009 2. means that it would have to go from Immutable RAII to Mutable RAII (s...
• Adi Shavit (36/78) Nov 28 2009 Hi Matt,
• Adi Shavit (6/103) Nov 28 2009 Sorry, the last line should be:
• Adi Shavit (5/47) Nov 28 2009 BTW, having the (helpful) swap() method already makes this a "non-pure" ...

Adi <adishavit_withoutthispart_+webnews gmail.com> writes:

Hi,

  I've been trying to use memory_mapped_file and saving it as a member.
However, the class does not have a default ctor, and I do not know the file
name until after construction.
I thought I'd be able to either:
1. Use an "empty" member, and when I have the name use a local variable to open
the file and then swap.

or

2. If memory_mapped_file had an "open" method, open the file directly when I
have the name.

With the current interface I cannot do neither of these.
The only option I see is to use a pointer and allocate memory_mapped_file  on
the heap, which kind of beats the whole point of RAII...

Any suggestions?

Also, on a more general note, I want to load some small WAV files to memory for
later fast immediate playback. I was wondering if memory_mapped_file will give
me the same speed as just reading the whole raw file to memory and playing it
from there.
Does anyone have any experience with this?


Thanks,
Adi

"Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:

"Adi" <adishavit_withoutthispart_+webnews gmail.com> wrote in message
news:helem0$25vn$1 digitalmars.com...
 Hi,

   I've been trying to use memory_mapped_file and saving it as a member.
 However, the class does not have a default ctor, and I do not know the file
name until after construction.
 I thought I'd be able to either:


 1. Use an "empty" member, and when I have the name use a local variable to
open the file and then swap.

 or

 2. If memory_mapped_file had an "open" method, open the file directly when I
have the name.

 With the current interface I cannot do neither of these.
 The only option I see is to use a pointer and allocate memory_mapped_file  on
the heap, which kind of beats the whole point of

RAII...
 Any suggestions?

2. means that it would have to go from Immutable RAII to Mutable RAII (see IC++
for refs), which means more complex implementation
for the component. (Aside: I know you know this, Adi, my friend. Am just
stating for benefit of anyone else reading this.

However, 1. seems an eminently reasonable way of having mutability without
fundamentally changing to Mutable RAII (although it does
mean that it would be Mutable RAII "on the inside").

Let me have a thunk about it. It'd help if you could post a bit of contextual
code to help the old grey matter. ;-)


 Also, on a more general note, I want to load some small WAV files to memory
for later fast immediate playback. I was wondering if

memory_mapped_file will give me the same speed as just reading the whole raw
file to memory and playing it from there.
 Does anyone have any experience with this?

No direct experience, but I cannot imagine you'll notice much of a performance
difference either way. If anything, I would guess
that, when playing the entire file, you might get slightly better performance
with the mapped version.

HTH

Matt

Adi Shavit <adishavit_thisdoesnotbelonghere_ gmail.com> writes:

Hi Matt,

  Thanks for the quick reply.
I guess it does mean Mutable RAII. 

I actually got it to work using a dummy file (that must exist).
Here is the sample code (also attached):

#include <string>
#include <winstl/filesystem/memory_mapped_file.hpp>
#include <mmsystem.h>

// Note: you have to link with winmm.lib

void main()
{
   // What I can do today is (using the SND_MEMORY flag) :
   winstl::memory_mapped_file myWAVFile("beep.wav");
   ::PlaySound((LPCSTR)myWAVFile.memory(), 0, SND_MEMORY | SND_SYNC);

   // This is essentially identical to doing this (note using the SND_FILENAME
flag):
   ::PlaySound("beep.wav", 0, SND_FILENAME | SND_SYNC);
   // this is unfortunate since the file needs to be read from the HDD for
every call.


   // I'd like to hold the file in memory 
   // To do this, I want to do it this way:

   
   // 1. this would be my member
   // ...
   
   // winstl::memory_mapped_file myWAVFile_;                // !!! I can't do
this now. No empty ctor!!
   winstl::memory_mapped_file myWAVFile_("dummy_file.txt"); // !!!  I must use
a dummy file!


   // 2. somewhere else in an initialization/configuration part I would do this:
   std::string myWAVFileName = "beep.wav"; // I know this at this stage
   winstl::memory_mapped_file tmp(myWAVFileName.c_str());
   // if we got here all is well...
   tmp.swap(myWAVFile_);


   // 3. then... every time I want to play the file I do this:
   ::PlaySound((LPCSTR)myWAVFile.memory(), 0, SND_MEMORY | SND_SYNC);
}


Thanks,
Adi


Matthew Wilson Wrote:

 
 "Adi" <adishavit_withoutthispart_+webnews gmail.com> wrote in message
news:helem0$25vn$1 digitalmars.com...
 Hi,

   I've been trying to use memory_mapped_file and saving it as a member.
 However, the class does not have a default ctor, and I do not know the file
name until after construction.
 I thought I'd be able to either:

 
 
 1. Use an "empty" member, and when I have the name use a local variable to
open the file and then swap.

 or

 2. If memory_mapped_file had an "open" method, open the file directly when I
have the name.

 With the current interface I cannot do neither of these.
 The only option I see is to use a pointer and allocate memory_mapped_file  on
the heap, which kind of beats the whole point of

 RAII...
 Any suggestions?

 
 2. means that it would have to go from Immutable RAII to Mutable RAII (see
IC++ for refs), which means more complex implementation
 for the component. (Aside: I know you know this, Adi, my friend. Am just
stating for benefit of anyone else reading this.
 
 However, 1. seems an eminently reasonable way of having mutability without
fundamentally changing to Mutable RAII (although it does
 mean that it would be Mutable RAII "on the inside").
 
 Let me have a thunk about it. It'd help if you could post a bit of contextual
code to help the old grey matter. ;-)
 
 
 Also, on a more general note, I want to load some small WAV files to memory
for later fast immediate playback. I was wondering if

 memory_mapped_file will give me the same speed as just reading the whole raw
file to memory and playing it from there.
 Does anyone have any experience with this?

 
 No direct experience, but I cannot imagine you'll notice much of a performance
difference either way. If anything, I would guess
 that, when playing the entire file, you might get slightly better performance
with the mapped version.
 
 HTH
 
 Matt
 
 

Adi Shavit <adishavit_thisdoesnotbelonghere_ gmail.com> writes:

Sorry, the last line should be:

   // 3. then... every time I want to play the file I do this:
   ::PlaySound((LPCSTR)myWAVFile_.memory(), 0, SND_MEMORY | SND_SYNC);

Trying to attach the file again...

Adi

Adi Shavit Wrote:

 Hi Matt,
 
   Thanks for the quick reply.
 I guess it does mean Mutable RAII. 
 
 I actually got it to work using a dummy file (that must exist).
 Here is the sample code (also attached):
 
 #include <string>
 #include <winstl/filesystem/memory_mapped_file.hpp>
 #include <mmsystem.h>
 
 // Note: you have to link with winmm.lib
 
 void main()
 {
    // What I can do today is (using the SND_MEMORY flag) :
    winstl::memory_mapped_file myWAVFile("beep.wav");
    ::PlaySound((LPCSTR)myWAVFile.memory(), 0, SND_MEMORY | SND_SYNC);
 
    // This is essentially identical to doing this (note using the SND_FILENAME
flag):
    ::PlaySound("beep.wav", 0, SND_FILENAME | SND_SYNC);
    // this is unfortunate since the file needs to be read from the HDD for
every call.
 
 
    // I'd like to hold the file in memory 
    // To do this, I want to do it this way:
 
    
    // 1. this would be my member
    // ...
    
    // winstl::memory_mapped_file myWAVFile_;                // !!! I can't do
this now. No empty ctor!!
    winstl::memory_mapped_file myWAVFile_("dummy_file.txt"); // !!!  I must use
a dummy file!
 
 
    // 2. somewhere else in an initialization/configuration part I would do
this:
    std::string myWAVFileName = "beep.wav"; // I know this at this stage
    winstl::memory_mapped_file tmp(myWAVFileName.c_str());
    // if we got here all is well...
    tmp.swap(myWAVFile_);
 
 
    // 3. then... every time I want to play the file I do this:
    ::PlaySound((LPCSTR)myWAVFile.memory(), 0, SND_MEMORY | SND_SYNC);
 }
 
 
 Thanks,
 Adi
 
 
 Matthew Wilson Wrote:
 
 
 "Adi" <adishavit_withoutthispart_+webnews gmail.com> wrote in message
news:helem0$25vn$1 digitalmars.com...
 Hi,

   I've been trying to use memory_mapped_file and saving it as a member.
 However, the class does not have a default ctor, and I do not know the file
name until after construction.
 I thought I'd be able to either:

 
 
 1. Use an "empty" member, and when I have the name use a local variable to
open the file and then swap.

 or

 2. If memory_mapped_file had an "open" method, open the file directly when I
have the name.

 With the current interface I cannot do neither of these.
 The only option I see is to use a pointer and allocate memory_mapped_file  on
the heap, which kind of beats the whole point of

 RAII...
 Any suggestions?

 
 2. means that it would have to go from Immutable RAII to Mutable RAII (see
IC++ for refs), which means more complex implementation
 for the component. (Aside: I know you know this, Adi, my friend. Am just
stating for benefit of anyone else reading this.
 
 However, 1. seems an eminently reasonable way of having mutability without
fundamentally changing to Mutable RAII (although it does
 mean that it would be Mutable RAII "on the inside").
 
 Let me have a thunk about it. It'd help if you could post a bit of contextual
code to help the old grey matter. ;-)
 
 
 Also, on a more general note, I want to load some small WAV files to memory
for later fast immediate playback. I was wondering if

 memory_mapped_file will give me the same speed as just reading the whole raw
file to memory and playing it from there.
 Does anyone have any experience with this?

 
 No direct experience, but I cannot imagine you'll notice much of a performance
difference either way. If anything, I would guess
 that, when playing the entire file, you might get slightly better performance
with the mapped version.
 
 HTH
 
 Matt
 
 

 

Adi Shavit <adishavit_withoutthispart_ gmail.com> writes:

BTW, having the (helpful) swap() method already makes this a "non-pure"
immutable RAII, doesn't it?

Also, RAII does not stand for Resource Allocation is Construction, so having an
initialization() method, does not, per-se in my view, contradict the spirit of
RAII (nor of immutable RAII)

Thanks,
Adi 


Matthew Wilson Wrote:

 
 "Adi" <adishavit_withoutthispart_+webnews gmail.com> wrote in message
news:helem0$25vn$1 digitalmars.com...
 Hi,

   I've been trying to use memory_mapped_file and saving it as a member.
 However, the class does not have a default ctor, and I do not know the file
name until after construction.
 I thought I'd be able to either:

 
 
 1. Use an "empty" member, and when I have the name use a local variable to
open the file and then swap.

 or

 2. If memory_mapped_file had an "open" method, open the file directly when I
have the name.

 With the current interface I cannot do neither of these.
 The only option I see is to use a pointer and allocate memory_mapped_file  on
the heap, which kind of beats the whole point of

 RAII...
 Any suggestions?

 
 2. means that it would have to go from Immutable RAII to Mutable RAII (see
IC++ for refs), which means more complex implementation
 for the component. (Aside: I know you know this, Adi, my friend. Am just
stating for benefit of anyone else reading this.
 
 However, 1. seems an eminently reasonable way of having mutability without
fundamentally changing to Mutable RAII (although it does
 mean that it would be Mutable RAII "on the inside").
 
 Let me have a thunk about it. It'd help if you could post a bit of contextual
code to help the old grey matter. ;-)
 
 
 Also, on a more general note, I want to load some small WAV files to memory
for later fast immediate playback. I was wondering if

 memory_mapped_file will give me the same speed as just reading the whole raw
file to memory and playing it from there.
 Does anyone have any experience with this?

 
 No direct experience, but I cannot imagine you'll notice much of a performance
difference either way. If anything, I would guess
 that, when playing the entire file, you might get slightly better performance
with the mapped version.
 
 HTH
 
 Matt