[ceph.git] / ceph / src / boost / libs / proto / doc / rationale.qbk

[/
 / Copyright (c) 2008 Eric Niebler
 /
 / Distributed under the Boost Software License, Version 1.0. (See accompanying
 / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
 /]

[section:rationale Appendix C: Rationale]

[/==================================================]
[section:static_initialization Static Initialization]
[/==================================================]

Proto expression types are PODs (Plain Old Data), and do not have constructors. They are brace-initialized, as follows:

    terminal<int>::type const _i = {1};

The reason is so that expression objects like `_i` above can be ['statically 
initialized]. Why is static initialization important? The terminals of many embedded
domain-specific languages are likely to be global const objects, like `_1` and 
`_2` from the Boost Lambda Library. Were these object to require run-time 
initialization, it might be possible to use these objects before they are 
initialized. That would be bad. Statically initialized objects cannot be misused 
that way.

[endsect]

[/=========================================================]
[section:preprocessor Why Not Reuse MPL, Fusion, et cetera?]
[/=========================================================]

Anyone who has peeked at Proto's source code has probably wondered, "Why all the 
dirty preprocessor gunk? Couldn't this have been all implemented cleanly on top of 
libraries like MPL and Fusion?" The answer is that Proto could have been 
implemented this way, and in fact was at one point. The problem is that template 
metaprogramming (TMP) makes for longer compile times. As a foundation upon which 
other TMP-heavy libraries will be built, Proto itself should be as lightweight as 
possible. That is achieved by prefering preprocessor metaprogramming to template 
metaprogramming. Expanding a macro is far more efficient than instantiating a 
template. In some cases, the "clean" version takes 10x longer to compile than the 
"dirty" version.

The "clean and slow" version of Proto can still be found at 
http://svn.boost.org/svn/boost/branches/proto/v3. Anyone who is interested can 
download it and verify that it is, in fact, unusably slow to compile. Note that 
this branch's development was abandoned, and it does not conform exactly with 
Proto's current interface.

[endsect]

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