I pressed reply! Sorry it got pasted under you! That buffer is simply a char[16] buffer.

#if (defined(__unix__) || defined(unix)) && !defined(USG) #include #endif #include #include #if defined(_WIN32) || defined(__CYGWIN__) #include #elif defined MACOSX #include #include #elif defined __FreeBSD__ # if __FreeBSD_version >= 500000 # include # else # error FreeBSD versions prior to 500000 does not support uuid(3) # endif #else #include #endif ///Above are my includes, below is the calls abstracted #if defined(_WIN32) || defined(__CYGWIN__) GUID randomGuid; // create random GUID randomGuid = GUID_NULL; ::CoCreateGuid(&randomGuid); if (randomGuid == GUID_NULL) { fprintf(stderr,"Couldn't create a random GUID\n"); return; } memcpy(m_bufuid, &randomGuid, 16); #elif defined __FreeBSD__ uuid_t uid; // uuid_t is a struct uuid_create(&uid, NULL); memcpy(m_bufuid, &uid, 16); #else uuid_t uid; // uuid_t is defined as unsigned char[16] uuid_generate(uid); memcpy(m_bufuid, uid, 16); #endif std::string tmp; char cuid[100]; // Uid::GetUid temporary sprintf(cuid,"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", m_bufuid[0],m_bufuid[1],m_bufuid[2],m_bufuid[3], m_bufuid[4],m_bufuid[5],m_bufuid[6],m_bufuid[7], m_bufuid[8],m_bufuid[9],m_bufuid[10],m_bufuid[11], m_bufuid[12],m_bufuid[13],m_bufuid[14],m_bufuid[15]); tmp = cuid; Done. -- modified at 8:48 Wednesday 31st October, 2007

Thank you, this suggestion has proved quite fruitful! Ken

SQLite is designed for use with databases sized in kilobytes or megabytes not gigabytes. Therefore, it is unacceptable.

Thanks, I needed some sanity here. What type of profiler do you use? I've been playing with a few intel products, but the cost sours me to them.

I'm already synchronizing write and read operations. By this I mean that I keep track of what is currently being done to the file. Basically, the writer never goes backwards, so whatever has been written is fair game in regards to reading. The only random access is reading. A database for this application isn't acceptable. The question remains though. What approach is the best? Have a single reader per file handling many requests. (ie. setg to the offset) or having several fstream objects created that read independently, in a shared mode. I didn't mean that the OS, in this case Windows, prevents corruption when modifying files. I should of been more clear in my statement. I meant to say: My initial thought is that having multiple 'reader' objects is perfectly acceptable and not a performance hit. In addition, in a raid situation would it not make more sense to create multiple file streams to the same file due to the very nature of multiple disk heads? I'm not all that aware of where there is any performance to gain based on implementation. I can only assume that if I issue two reads to the same file, via two streams, that the raid controller (in my case raid 5) would out perform a setg operation. Maybe not with 2 reads, but maybe 100s of reads per second. Does this make sense?

I am currently involved a project that requires that I have random access to multiple files on disk. I have a single 'file writer' object that handles writes, but I am unsure about how to proceed with reads. The question is: If I want to be able to service multiple 'reads' at the same time to a single file should I have a single object (an fstream) that is synchronized (using a lock) or multiple fstream objects that are independent. I want to take advantage of my raid hardware as well as multiple processors throughout the application. My initial thought is that having multiple 'reader' objects leaves synchronization up to the OS, and that using some type of locking mechanism (such as a criticalsection/mutex) could slow performance. Any help here is much appreciated. On a side note: If I'm just writing buffers of data (or 1 byte aligned structures) does it make more sense to just use stdio functions?