Hi, currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars). I'm wondering if two template functions would improve the maintenability of the code. template <typename T> T host_to_network(T v); template <typename T> T network_to_host(T v); template <> long host_to_network<long>(long v) {return htonl(v);} template <> long network_to_host<long>(long v) {return ntohl(v);} template <> short host_to_network<long>(short v) {return htons(v);} template <> short network_to_host<long>(short v) {return ntohs(v);} we will need to add specialization for all the other integer types, and we can also include char and unsigned char template <> char host_to_network<char>(char v) {return v;} template <> char network_to_host<char>(char v) {return v;} Do you think that these template functions should be included in boost? Best regards, Vicente
vicente.botet a écrit :
Hi,
currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars).
<snip> Why are they template ? Atfer all, the 3 overload is fully sufficent I think
----- Original Message ----- From: "Joel Falcou" <joel.falcou@u-psud.fr> To: <boost@lists.boost.org> Sent: Thursday, September 25, 2008 9:08 PM Subject: Re: [boost] hton/ntoh template functions vicente.botet a écrit :
Hi,
currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars).
<snip> Why are they template ? Atfer all, the 3 overload is fully sufficent I think
Oups! You are right.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 25 September 2008 16:50 pm, vicente.botet wrote:
vicente.botet a écrit :
Hi,
currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars).
<snip>
Why are they template ? Atfer all, the 3 overload is fully sufficent I think
Oups! You are right.
A template would make it harder to accidentally do an implicit conversion of an unsupported argument type before it is byte swapped. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI3OEu5vihyNWuA4URAj+0AJ0UXUuV5ckLjHjWmR10xhjJtI3l9wCgunUE DgWlO2gj211PY513tYMF+QQ= =WE/4 -----END PGP SIGNATURE-----
----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Friday, September 26, 2008 3:18 PM Subject: Re: [boost] hton/ntoh template functions -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 25 September 2008 16:50 pm, vicente.botet wrote:
vicente.botet a écrit :
Hi,
currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars).
<snip>
Why are they template ? Atfer all, the 3 overload is fully sufficent I think
Oups! You are right.
A template would make it harder to accidentally do an implicit conversion of an unsupported argument type before it is byte swapped. Hi, you are right, and I think that we don't need accidental implicit conversions. I have tested with and withou the template and there is a conclict without. Vicente@viboes1 ~ $ g++ test_endian_conversions.cpp -o test /cygdrive/c/DOCUME~1/Vicente/LOCALS~1/Temp/cc2WdPFL.o:test_endian_conversions.cp p:(.text+0x21f): undefined reference to `S host_to_network<S>(S)' /cygdrive/c/DOCUME~1/Vicente/LOCALS~1/Temp/cc2WdPFL.o:test_endian_conversions.cp p:(.text+0x22d): undefined reference to `S network_to_host<S>(S)' collect2: ld returned 1 exit status Thanks for pointing the difference. Vicente
On Thu, Sep 25, 2008 at 15:03, vicente.botet <vicente.botet@wanadoo.fr> wrote:
currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars).
Have you looked at the proposed Boost.Endian library? It's a very elegant way of handling things: http://lists.boost.org/Archives/boost/2008/05/137820.php That said, it's a different philosophy from in-place byte swapping, so it might not fit what you need.
----- Original Message ----- From: "Scott McMurray" <me22.ca+boost@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, September 25, 2008 9:30 PM Subject: Re: [boost] hton/ntoh template functions
On Thu, Sep 25, 2008 at 15:03, vicente.botet <vicente.botet@wanadoo.fr> wrote:
currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars).
Have you looked at the proposed Boost.Endian library? It's a very elegant way of handling things: http://lists.boost.org/Archives/boost/2008/05/137820.php
Yes, I do.
That said, it's a different philosophy from in-place byte swapping, so it might not fit what you need.
There is one factor, it could be very simple to transform a program using the htons htonl version to the polymorphic ones. Evidently this has no importance for new code. The transparency will make easier bad uses of these endian types in parts not related to I/O. IMO it will be better if the endian library provides in addition to the already provided types the corresponding opaque byte holder types that do not provide the integer arithmetics operators. This will force the separation between the application and the physical presentation. What do you think Beman? Vicente
participants (4)
-
Frank Mori Hess -
Joel Falcou -
Scott McMurray -
vicente.botet