Re: [boost] Boost public interface macro names

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-07 13:49:25

----- Original Message -----
From: "Beman Dawes" <beman_at_[hidden]>

>  >There's a reason we stick to ALL_UPPERCASE and prefix with BOOST_ for
> macro
>  >names: to avoid name conflicts by adhering to a common convention. If we
>  >make the prescription in our coding guidelines but fail to follow that
>  >prescription in our public interface macros, we are not only undermining
>  >the convention but, IMO, arrogantly flaunting our ability to do so.
>
> I'm trying to discover if it makes sense to have two conventions, one for
> implementation artifact macros, and another for public interface macros.

It's a sensible question.

> I don't see that as arrogant, just trying to find a better way.

I didn't mean to say that it was arrogant to ask, or investigate. I am just
trying to say that choosing to make a public interface macro that uses
all_lower_case will make a statement. I think the statement is an arrogant
one.

> Both the standard and boost already use two conventions for other names;
> template parameters start with an uppercase letter, other ordinary names
> don't.
>
> Maybe I'm the only one who finds it really jarring to see
> BOOST_STATIC_ASSERT as a function name in the middle of mainline code, and
> would like to find a better convention.

Uh, but it's not a function name. If it were, would we be discussing this?
Also, doesn't this fall in line with the classical arguments for names like
reinterpret_cast<> (i.e. that they're /supposed/ to be jarring)?

> Perhaps I should just work on a core proposal for a new language
> feature.  All of the macro uses we are talking about are needed to get
> __FILE__ and __LINE__.  How about two new special symbols:
>
> namespace boost {
>    static_assert( bool exp, const char * file=__FILE_AT_USE,
>                   int line=__LINE_AT_USE );
> }
>
> The compiler is required to replace these with the appropriate value at
the
> point of a call to static_assert(), rather than at point of declaration.

I like that proposal!

-Dave