When beginning to think how some packing alorhytms for the project i am currently doing in my company, i decided to go with streams as the contained for the packed data.
why?
first, i knew some stream working from C#,
second, i knew the packed data would be then sent over the network. in C# you can then quite easily convert your stream to a network stream and just send THAT over the network. out of some reason i thought that there surely also is some network stream class in c++.
third, back when i learned programming in colleg we were doing streams and they told us we should use them. if i think about it now i think our professor had a certain crush on streams.
fourth, i needed something abstract, where i just could put more and more data into easily and in the end, get everything out again. streams seem to be made for that right?
ok, now let me tell you:
if i could choose again, i would avoid them like a christian avoids hell.
why?
not only me but also my colleages find streams-programming is very counter-intuitive to work with.
* completely understanding the concept of streams is not easy.
* streams are not easily worked with:
- you cannot just copy a stream.
- you cannot even easily insert data somewhere at the stream.
- if you do something wrong you get funny compilation errors that do not really tell you what you did wrong (create a method that takes a stream reference as an argument , forget the "&" and look at the error message)
-you cannot easily extract data out of the stream, being it the data itself or things like the size of the stream. some things may even be impossible....
-different types of streams seem to behave differently when you shift data into them: this one i just discovered and still need to figure out
but the worst part is:
* there are many parts where streams behave differently under windows and linux!
so cross platform development becomes difficult:
example: streambuf methods (used for things like positioning the read/write pointer in an associated stream) like in_avail() and pubseekof() and pubseekpos() will return you different positions/sizes under windows and linux.
i still do not know why nor what to do about that. they also behave differently on 64-bit machines:
the same program under ubuntu on a Pentium4 compared to some 64bit - server monster running some linux distribution have the "get pointer" of the readbuffer on a different positions, thus making your logic fail.
maybe i'll post some of the anomalies in more detail in the future.
bytes
why?
first, i knew some stream working from C#,
second, i knew the packed data would be then sent over the network. in C# you can then quite easily convert your stream to a network stream and just send THAT over the network. out of some reason i thought that there surely also is some network stream class in c++.
third, back when i learned programming in colleg we were doing streams and they told us we should use them. if i think about it now i think our professor had a certain crush on streams.
fourth, i needed something abstract, where i just could put more and more data into easily and in the end, get everything out again. streams seem to be made for that right?
ok, now let me tell you:
if i could choose again, i would avoid them like a christian avoids hell.
why?
not only me but also my colleages find streams-programming is very counter-intuitive to work with.
* completely understanding the concept of streams is not easy.
* streams are not easily worked with:
- you cannot just copy a stream.
- you cannot even easily insert data somewhere at the stream.
- if you do something wrong you get funny compilation errors that do not really tell you what you did wrong (create a method that takes a stream reference as an argument , forget the "&" and look at the error message)
-you cannot easily extract data out of the stream, being it the data itself or things like the size of the stream. some things may even be impossible....
-different types of streams seem to behave differently when you shift data into them: this one i just discovered and still need to figure out
but the worst part is:
* there are many parts where streams behave differently under windows and linux!
so cross platform development becomes difficult:
example: streambuf methods (used for things like positioning the read/write pointer in an associated stream) like in_avail() and pubseekof() and pubseekpos() will return you different positions/sizes under windows and linux.
i still do not know why nor what to do about that. they also behave differently on 64-bit machines:
the same program under ubuntu on a Pentium4 compared to some 64bit - server monster running some linux distribution have the "get pointer" of the readbuffer on a different positions, thus making your logic fail.
maybe i'll post some of the anomalies in more detail in the future.
bytes
Comments