From: Dave (dfisher_at_pophost.com)
Date: 2002-03-04 01:59:14
On Sun, 03 Mar 2002 12:48:52 -0000, sleeper75se wrote:
>Rather than storing a single byte, interleave one-second blocks of
>data. That way different channels can have different sample rates and
>different samples can have different data types (doubles, ints, bools
>whatever).
>
>If one channel has a 256 Hz rate and another 73 Hz, for instance, it
>comes down to reading or writing a blocks of 256 samples followed by
>a blocks of 73 samples. I'm sure you can write the method that does
>that in less than 20 lines.
That sounds like a workable solution, too. There could certainly be a storage
object responsible for handling the job (buffering the second's worth of data
for each channel, writing it to file, etc.).
>By the way, you guys know about STL, right?
I think you mean the use of the stream class and insertion/extractor operator
aspects of C++, rather than STL. STL refers to the Standard Template Library
that is used to create non-specific typed container classes (such as lists,
vectors, etc.).
>An example:
>
>string s = "Andreas";
>double len = 182;
>
>ofstream file;
>file.open("Myfile.txt")
>file << "My name is" << s << ", and I am " << len << " centimeters
>tall.\n";
>file.close();
I agree on the use of the stream class. And the put/get operators are the
correct OO way of treating string and data objects in C++. But some C habits
die hard, and sometimes the read/write and fprintf's come more easier than
C++'s file handling.
>... is much easier to read and debug than FILE* and fopen etc...
>which is not "C++" but rather "C".
I think that would depend on your background and what you are accustomed to
seeing. I still find it easier to "see" the logic of fopen's, fprintf's, etc.
than the stream class and "<<" and ">>" operators. But the latter make more
sense in C++ projects.
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST