saga::file::read and saga::file::write etc.

Resending because of mailer problems... Hi all, While trying to implement the latest changes of the spec I have the following comments: 1. we added the option for a const correct buffer class to the spec, shouldn't the same be allowed for the iovec class (i.e. a const correct version of the iovec type) 2. I'ld suggest to change the saga::file::read and saga::file::write API functions as follows: saga::ssize_t read(saga::mutable_buffer, saga::ssize_t bytes = 0) saga::ssize_t write(saga::const_buffer, saga::ssize_t bytes = 0) The rationale behind this is that the buffer already contains a size, which by default could be used for the operation (if the 'bytes' parameter is zero). In C++ this would allow to simplify the code significantly. i.e. saga::file f(...); char cb[100]; f.read(buffer(cb)); // read 100 char's std::vector<double> v(20); f.read(buffer(v, 10)); // read 10 doubles Or std::vector<int> vi; // fill vi ... f.write(buffer(vi)); // write all elements of vi Etc. Regards Hartmut

Hi Hartmut, Quoting [Hartmut Kaiser] (Oct 09 2007):
Resending because of mailer problems...
Hi all,
While trying to implement the latest changes of the spec I have the following comments:
1. we added the option for a const correct buffer class to the spec, shouldn't the same be allowed for the iovec class (i.e. a const correct version of the iovec type)
Yep - I'll make sure that it holds for all classes which derive from buffer.
2. I'ld suggest to change the saga::file::read and saga::file::write API functions as follows:
saga::ssize_t read(saga::mutable_buffer, saga::ssize_t bytes = 0) saga::ssize_t write(saga::const_buffer, saga::ssize_t bytes = 0)
The rationale behind this is that the buffer already contains a size, which by default could be used for the operation (if the 'bytes' parameter is zero). In C++ this would allow to simplify the code significantly. i.e.
saga::file f(...);
char cb[100]; f.read(buffer(cb)); // read 100 char's
std::vector<double> v(20); f.read(buffer(v, 10)); // read 10 doubles
Or
std::vector<int> vi; // fill vi ... f.write(buffer(vi)); // write all elements of vi
Etc.
That is already added, although verbosely. In the detailed notes to read/write, you should find: - if len_in is smaller than 0, or not given, the buffer size is used for len_in. If that is also not available, a 'BadParameter' exception is thrown. I wanted to avoid the default of 'size = 0', because that would be, although unusual, a valid expression. -1 would be invalid. I'll add the -1 to the prototypes if thats ok with you - not sure why I left it out in the first place... And yes, that is how it should like in C++ I guess :-))
Regards Hartmut
Thanks, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

Ooops, Quoting [Andre Merzky] (Oct 09 2007):
2. I'ld suggest to change the saga::file::read and saga::file::write API functions as follows:
saga::ssize_t read(saga::mutable_buffer, saga::ssize_t bytes = 0) saga::ssize_t write(saga::const_buffer, saga::ssize_t bytes = 0)
The rationale behind this is that the buffer already contains a size, which by default could be used for the operation (if the 'bytes' parameter is zero). In C++ this would allow to simplify the code significantly. i.e.
[...]
That is already added, although verbosely. In the detailed notes to read/write, you should find:
- if len_in is smaller than 0, or not given, the buffer size is used for len_in. If that is also not available, a 'BadParameter' exception is thrown.
I wanted to avoid the default of 'size = 0', because that would be, although unusual, a valid expression. -1 would be invalid.
I'll add the -1 to the prototypes if thats ok with you - not sure why I left it out in the first place...
And yes, that is how it should like in C++ I guess :-))
Well, -1 won't work in C++ btw, as size has the (unsigned) type of size_t. So, either we stick to the version you proposed (which I am not totally convinced of ;-), or we introduce two signatures (read (buffer), read (buffer, size)) to discriminate the cases (not nice either...). Anyway, thats a binding issue. Cheers, Andre.
Regards Hartmut
Thanks, Andre.
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
participants (2)
-
Andre Merzky
-
Hartmut Kaiser