Boost logo

Boost :

From: Reid Sweatman (borderland_at_[hidden])
Date: 2000-07-31 11:24:05


> So, I'll go to the wall fighting BOOST_POSTULATE(), tolerate something
> clumsy like BOOST_COMPILE_TIME_ASSERT() or (better)
> BOOST_STATIC_ASSERT(),
> but prefer something pithy and just-informative-enough, like
> BOOST_PROVEN()
> or BOOST_CHECKED().

If you want to go that route, why not just BOOST_AXIOM? (Apologies in
advance to those who've already rejected "axiom" for whatever reason. From
my slightly earlier post, I am, a Priori, a fence-sitter on that issue <g>.
But since this thread verges on being a code Jihad, why not just interject
the divine outright, and use BOOST_FIRST_PRINCIPLE, or
BOOST_RATIONES_SEMINALES (ah, the advantages of a Classical education <g>).
No, but seriously, folks, BOOST_AXIOM works for me, although, as Dave points
out, it doesn't capture the compile-time nature of the assert, and
BOOST_COMPILE_TIME_AXIOM is just as bad as BOOST_COMPILE_TIME_ASSERT. I
thought of suggesting BOOST_COMPILER_ASSERT, but then, it's the user code,
not the compiler that's asserting, so the semiotics are wrong (BTW, I use
"semiotics" merely because "semantics" is already overloaded in this
context).

One question: why does this assert have to include the prefix BOOST_?
Merely for consistency with other library usage? If it's in the Boost
namespace, couldn't this merely be assumed? Or, for that matter, why
require such a lengthy prefix throughout the library? Why not abbreviate it
to something like BST_? I know that goes against the already-stated goal of
spelling things out explicitly, but it's really getting close to the unique
length limit on identifier names some compilers have, while making the
leading six characters axiomatically non-unique. I've hit that one myself
in the past designing my own library modules, and finally ended up with a
self-imposed rule that I never use a module prefix longer than three
characters (which allows somewhat longer names in my case, since I write in
Hungarian notation, and only use underscores when necessary for
disambiguation).

Sorry if I'm treading over well-trodden acreage, so no flames, please. I
mean well, and probably like the rest of you, I've been hammering at the
problem of a good convention of succinct, communicative names for years now.
My conversion to Hungarian was solely due to McConnell's "Code Complete,"
and I effectively have my own sub-lingo of it, based on some valid
criticisms of Hungarian I've been exposed to. I don't know about the rest
of you, but my own comprehension of code is *very* much affected by naming
and formatting; so much so that when handed someone else's code to read, my
first act is to run it through a reformatter. If I make changes, I reformat
it back the way it was handed to me before returning it. Especially I find
that one thing that drops my comprehension of code drastically is identifier
length. The STL is already beastly in that regard, so I try to keep any
identifier within my control as mercifully short as possible. I have to
admit, BOOST_COMPILE_TIME_ASSERT is getting pretty close to the edge for me.

I only go to such lengths explaining this because I'm probably a lot closer
to the average *user* of Boost than the Big Brains who are hashing out the
deep issues in the library (although as Yosemite Sam said, "I'm a'thinkin'.
And my head hurts. <g>). Anyway I'm only suggesting that I'm an example of
the working programmer you're supposedly writing Boost++ for. If I have a
hard time understanding it, I may be in some sense representative.

My 0.02 Drachmas in debased currency of the later Byzantines (apropos, no?)
void * m_pReidSweatman;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk