rationale.qbk 2.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051
  1. [/
  2. / Copyright (c) 2008 Eric Niebler
  3. /
  4. / Distributed under the Boost Software License, Version 1.0. (See accompanying
  5. / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
  6. /]
  7. [section:rationale Appendix C: Rationale]
  8. [/==================================================]
  9. [section:static_initialization Static Initialization]
  10. [/==================================================]
  11. Proto expression types are PODs (Plain Old Data), and do not have constructors. They are brace-initialized, as follows:
  12. terminal<int>::type const _i = {1};
  13. The reason is so that expression objects like `_i` above can be ['statically
  14. initialized]. Why is static initialization important? The terminals of many embedded
  15. domain-specific languages are likely to be global const objects, like `_1` and
  16. `_2` from the Boost Lambda Library. Were these object to require run-time
  17. initialization, it might be possible to use these objects before they are
  18. initialized. That would be bad. Statically initialized objects cannot be misused
  19. that way.
  20. [endsect]
  21. [/=========================================================]
  22. [section:preprocessor Why Not Reuse MPL, Fusion, et cetera?]
  23. [/=========================================================]
  24. Anyone who has peeked at Proto's source code has probably wondered, "Why all the
  25. dirty preprocessor gunk? Couldn't this have been all implemented cleanly on top of
  26. libraries like MPL and Fusion?" The answer is that Proto could have been
  27. implemented this way, and in fact was at one point. The problem is that template
  28. metaprogramming (TMP) makes for longer compile times. As a foundation upon which
  29. other TMP-heavy libraries will be built, Proto itself should be as lightweight as
  30. possible. That is achieved by prefering preprocessor metaprogramming to template
  31. metaprogramming. Expanding a macro is far more efficient than instantiating a
  32. template. In some cases, the "clean" version takes 10x longer to compile than the
  33. "dirty" version.
  34. The "clean and slow" version of Proto can still be found at
  35. http://svn.boost.org/svn/boost/branches/proto/v3. Anyone who is interested can
  36. download it and verify that it is, in fact, unusably slow to compile. Note that
  37. this branch's development was abandoned, and it does not conform exactly with
  38. Proto's current interface.
  39. [endsect]
  40. [endsect]