Showing posts with label Boost. Show all posts
Showing posts with label Boost. Show all posts

Friday, January 2, 2009

Working with other libraries, part 3: use consistent conventions for member types

Ever get confused by the names of member variables/types/functions of C++ class templates?

Boost.Format's basic_format class template defines five public and two private member types, using a mix of four different naming conventions!

[an extract from boost/format/format_class.hpp]

// in namespace boost
template <class Ch, class Tr, class Alloc>
class basic_format
{
private:
  typedef typename io::CompatTraits<Tr>::compatible_type compat_traits;
  typedef io::detail::stream_format_state<Ch, Tr> stream_format_state;
  
public:
  typedef Ch CharT;
  typedef std::basic_string<Ch, Tr, Alloc> string_type;
  typedef typename string_type::size_type size_type;
  typedef io::detail::format_item<Ch, Tr, Alloc> format_item_t;
  typedef io::basic_altstringbuf<Ch, Tr, Alloc> internal_streambuf_t;

In Extended STL, volume 1: Collections and Iterators I recommend the use of the following naming convention for member types:
  1. For public member types that share names with standard components that have the same logical purpose, follow the standard convention and use the standard name. An example would be iterator.
  2. For public member types that are not covered by clause 1, use the _type suffix. An example would be char_type.
  3. For private member types, use the _type_ suffix. An example would be compat_traits_type_.
and
  1. For public API (non-member) types use the _t suffix. An example would be pan_char_t.
  2. For non-public/implementation API (non-member) types use the _t_ suffix. An example would be b64ErrorString_t_.


I've been using this for many years without a blip. I can read my code, even some years later, and understand what's a type and what isn't and also, importantly, which types are for consumption in the outside world and which are internal to the component. Q.E.D.

Monday, December 29, 2008

FastFormat now performance tested against Loki

As of 0.2.1 beta 6, FastFormat's performance test programs now also compare against Andrei Alexandrescu's Loki library's SafeFormat component. The results clearly demonstrate FastFormat's performance superiority over this library, as they do over C++'s standard IOStreams and Boost.Format.

Given the fact that FastFormat is more robust and more flexible than these other libraries, and is highly expressive, I think it's fair to now claim that it is the pre-eminent formatting library for C++. All that remains is to provide the planned width+alignment+fill functionality, and it'll be effectively complete.

I'll be looking for input/assistance in the new year for packaging and porting. If anyone wants to volunteer, you'll be most welcome.

Wednesday, September 10, 2008

FastFormat is FAST: It's official!

I just posted some performance stats on the FastFormat website. I'll just give you the summary here:
  • The Format API is faster than IOStreams by between ~140-730%, faster than MFC's CString::Format() by between ~300-400%, and faster than Boost.Format by between ~470-1600%! The only formatting API that gives it a run for some architecture/compiler/configurations is sprintf(), which is not type-safe, at between ~40-380%. (FastFormat's Format API is 100% type-safe.)
  • The simpler Write API is faster than IOStreams by between ~270-1350%, faster than MFC's CString::Format() by around ~420%, and faster than Boost.Format by between ~630-1800%! Again, the only formatting API that gives it a run for some architecture/compiler/configurations is sprintf(), at between ~65-390%. (FastFormat's Write API is 100% type-safe.)