Inquiry of standardization status of boost::format
Due to the limitation of gettext usage with standard iostream, there's a proposal to improve the case in glibmm's string implementation [1], whose goals resemble boost::format very much. There's a thought that if boost::format is going to be standardized, then it's better to adopt the boost syntax and ease switching to standard in the future. So is this happening? How's the status? [1] http://mail.gnome.org/archives/gtkmm-list/2007-August/msg00055.html
manphiz wrote:
Due to the limitation of gettext usage with standard iostream, there's a proposal to improve the case in glibmm's string implementation [1], whose goals resemble boost::format very much.
This stuff will all be much easier once we have variadic templates, i.e. you will be able to have a type-safe sprintf in C++. You can now get a version of gcc that supports them, and they should be in C++0x. So unless you have some very urgent reason to change immediately, I suggest that you wait for a bit. (I imagine that this means that the operator%-style Boost.Format will not progress towards the standard library, but I am not in any position to comment on that.) Regards, Phil.
Phil Endecott wrote:
This stuff will all be much easier once we have variadic templates, i.e. you will be able to have a type-safe sprintf in C++. You can now get a version of gcc that supports them, and they should be in C++0x. So unless you have some very urgent reason to change immediately, I suggest that you wait for a bit.
(I imagine that this means that the operator%-style Boost.Format will not progress towards the standard library, but I am not in any position to comment on that.)
Maybe the operator%-style can be obsolete (and I don't like it either) in favor of variadic templates magic, but plain sprintf still cannot be directly used to deal with std::string, is it? Is there any plan to let sprintf adapt std::string or vice versa? So something similar can be implemented for future migration to standard approach.
Regards,
Phil.
On Aug 15, 2007, at 3:19 AM, manphiz wrote:
Phil Endecott wrote:
This stuff will all be much easier once we have variadic templates, i.e. you will be able to have a type-safe sprintf in C++. You can now get a version of gcc that supports them, and they should be in C++0x. So unless you have some very urgent reason to change immediately, I suggest that you wait for a bit.
(I imagine that this means that the operator%-style Boost.Format will not progress towards the standard library, but I am not in any position to comment on that.)
Maybe the operator%-style can be obsolete (and I don't like it either) in favor of variadic templates magic, but plain sprintf still cannot be directly used to deal with std::string, is it?
Why not? Variadic templates make it possible to implement a sprintf- like interface that supports all data types (strings, user-defined types, etc.) and checks the format string against the actual argument types to provide better type safety. They give us a chance to revisit the Format interface to determine whether we can do better with new features; that might mean bringing back the old-but-familiar (s) printf interface with added functionality. - Doug
Douglas Gregor wrote:
On Aug 15, 2007, at 3:19 AM, manphiz wrote:
Phil Endecott wrote:
This stuff will all be much easier once we have variadic templates, i.e. you will be able to have a type-safe sprintf in C++. You can now get a version of gcc that supports them, and they should be in C++0x. So unless you have some very urgent reason to change immediately, I suggest that you wait for a bit.
(I imagine that this means that the operator%-style Boost.Format will not progress towards the standard library, but I am not in any position to comment on that.)
Maybe the operator%-style can be obsolete (and I don't like it either) in favor of variadic templates magic, but plain sprintf still cannot be directly used to deal with std::string, is it?
Why not? Variadic templates make it possible to implement a sprintf- like interface that supports all data types (strings, user-defined types, etc.) and checks the format string against the actual argument types to provide better type safety. They give us a chance to revisit the Format interface to determine whether we can do better with new features; that might mean bringing back the old-but-familiar (s) printf interface with added functionality.
Thanks for enlightening me on this! It seems templates may make printf-family something more ambitious. And following this lead, many plain C functions may also be excavated and refined with new power as well! I'm quite curious about where this is going. On the other hand, I'm also a little bit doubt about whether this is something that C++ will be interested in. C interfaces was introduced into C++ intact to maintain compatibility, and it is likely to remain that way. So what's going to happen? Is there any discussion in this realm?
- Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Aug 15, 2007, at 8:36 AM, manphiz wrote:
Thanks for enlightening me on this! It seems templates may make printf-family something more ambitious. And following this lead, many plain C functions may also be excavated and refined with new power as well! I'm quite curious about where this is going.
On the other hand, I'm also a little bit doubt about whether this is something that C++ will be interested in. C interfaces was introduced into C++ intact to maintain compatibility, and it is likely to remain that way.
The original idea with a variadic-templates printf() was that it could replace the C printf by providing a superset of the C printf behavior under the same interface. Basically, it means that existing uses of printf(), when compiled with the new variadic-templates--- based printf, would get run-time checking of the format specifier "for free." I don't know if that's particularly useful or not. At the time, it was more like a flagship "hey, look what variadic templates can do!" idea.
So what's going to happen? Is there any discussion in this realm?
I don't believe this is being discussed. It's too late for such a change to get into C++0x, so the right answer is probably to revisit Boost.Format to determine whether we can now do something better. - Doug
Doug Gregor wrote:
The original idea with a variadic-templates printf() was that it could replace the C printf by providing a superset of the C printf behavior under the same interface. Basically, it means that existing uses of printf(), when compiled with the new variadic-templates--- based printf, would get run-time checking of the format specifier "for free."
I don't know if that's particularly useful or not. At the time, it was more like a flagship "hey, look what variadic templates can do!" idea.
Now variadic-templates together with overloading may rescue variadic functions from lacking of type safety. There may be some other areas waiting to be exploited.
I don't believe this is being discussed. It's too late for such a change to get into C++0x, so the right answer is probably to revisit Boost.Format to determine whether we can now do something better.
It's a misfortune to miss the train to C++0x, but it'll be a grief if something immature gets into the standard. So let Boost.Format evolve :)
- Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Doug Gregor -
Douglas Gregor -
manphiz -
Phil Endecott