[boost] MetaComm Regression results for gcc/icc on linux
Hi, I am trying to find regression test results for gcc-3.3 on linux and Intel 7.1 on Linux. Are the meta-intel-7.1 results at http://www.meta-comm.com/engineering for windows or linux? Does anyone have regression results for gcc/intel on linux? By the way, these results are really useful, thanks for all the effort. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] "Mutable typedefs" - changing the type associated with an identifier
Hello all,
Recently, I had the following problem in some library code I maintain.
I provide users with a macro which generates fairly complex typedefs:
#define MAKE_TYPEDEF(Ident, etc) typedef complicated Identifier;
Users use the macro to define a bunch of different types, all with
identifiers of the user's choosing. Elsewhere, I need an mpl::list of the
types generated by the macro. Right now, users have to supply me with
this mpl::list. This opens the possibility for the list to get out of
sync with the MAKE_TYPEDEF()s if the user forgets to update the list when
adding a new MAKE_TYPEDEF() invocation.
I wanted to eliminate this possible source of bugs, by somehow
automatically generaring the mpl::list as a side effect of using the
MAKE_TYPEDEF macro. I want each macro invocation of MAKE_TYPEDEF to
mpl::push_front<> the type it declares onto the front of a typelist.
#define MAKE_TYPEDEF() ...\
typedef mpl::push_front< previous_list, Ident>::type new_list;
The problem is the naming of the identifiers previous_list and
new_list. Because of ODR, each invocation of MAKE_TYPEDEF needs to give a
unique identifier to new_list, and yet somehow figure out what name was
used for previous_list. The easy solution is to have the user provide
unique names and chain the list of MAKE_TYPEDEFs together. But, this is
just as error prone as having the user simply provide the mpl::list
directly.
I wanted a solution which is completely transparent to the user. Thus, I
cooked up the following, which I am calling "mutable typedef".
The solution abuses the __LINE__ macro to generate unique identifier
names. A template specialization is created to mark the line number
used in the identifier. Then, when I wish to determine the name of
the identifier, a second template tests each line number going
upward from the current line until it finds the line number marked by the
specialization. Using this trick, I can create the effect of a
typedef which can be redefined, without violating ODR. Each use of the
typedef finds the nearest preceeding definition.
The code demostrating the trick appears below. The same trick can be used
to redefine integral constants as well, but I omit that code for brevity.
The main disadvantages of the approach are that it is not extremely robust
(doesn't work if line numbers change, i.e. when including files; or if
multiple mutable typedefs appear on one line), and that it requires a
large number of template instantiations if the nearest definition of the
mutable typedef is far away.
My questions for the Boost community are:
1) Is there an easier way to accomplish what is outlined in my use case
above, using preprocessor tricks or something similar?
2) Is there a way to enhance the mutable typedef trick to avoid the
large number of template instantiations?
3) Are there others interested in using this or seeing it submitted to
Boost?
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
=== Example code begines here. Tested with gcc 3.3 ===
#include
#include
//Create the base templates for a line marker for Identifier and declare
//the struct used to search for the nearest previous occurence of the
//marker
#define DECLARE_LAST_LINE_MARKER(Identifier) \
template \
struct BOOST_PP_CAT(last_line_marker_,Identifier) \
: public BOOST_PP_CAT(last_line_marker_,Identifier) {}; \
template \
struct BOOST_PP_CAT(find_last_line_,Identifier) \
: public BOOST_PP_CAT(last_line_marker_,Identifier)< StartAtLine > {} /**/
//Mark the current line
#define LAST_LINE_MARKER(Identifier) \
template<> struct BOOST_PP_CAT(last_line_marker_,Identifier)<__LINE__> \
{ static const int value = __LINE__; } /**/
//Find the line number where the mark was last set
#define FIND_LAST_LINE_MARKER(Identifier) \
BOOST_PP_CAT(find_last_line_,Identifier)<__LINE__ - 1>::value /**/
//Declare the base template for a mutable typedef.
#define DECLARE_MUTABLE_TYPEDEF(Identifier) \
template< int UniqueId > \
struct BOOST_PP_CAT(mutable_typedef_,Identifier); \
DECLARE_LAST_LINE_MARKER(Identifier) /**/
//Set the type of mutable typedef Identifier to Type.
#define SET_MUTABLE_TYPEDEF(Identifier, Type) \
template<> \
struct BOOST_PP_CAT(mutable_typedef_,Identifier)<__LINE__> \
{ typedef Type type; }; \
LAST_LINE_MARKER(Identifier) /**/
//Returns the type of the mutable typedef. Can be used anywhere a type-id is legal.
#define GET_MUTABLE_TYP
[boost] [MPL] for_each broken with empty list<>'s
Hi,
for_each seems to be unable to deal with empty lists, or lists that
are built by push_front on an empty list. However, vectors work
fine. Here is code which demonstrates the problem. Replacing list with
vector makes the code compile.
#include
#include
#include
#include
#include
#include
#include
typedef mpl::list<> empty;
typedef mpl::list single;
typedef mpl::push_front::type two;
typedef mpl::push_front::type push_on_empty;
BOOST_STATIC_ASSERT(mpl::size::value == 0); //OK
BOOST_STATIC_ASSERT(mpl::size::value == 1); //OK
BOOST_STATIC_ASSERT(mpl::size::value == 2); //OK
BOOST_STATIC_ASSERT(mpl::size::value == 1); //OK
struct type_printer
{
type_printer(std::ostream& s) : f_stream(&s) {}
template< typename U > void operator()(U &)
{
*f_stream << typeid(U).name() << '\n';
}
private:
std::ostream* f_stream;
};
int main() {
mpl::for_each< empty >( type_printer(std::cout) ); //won't compile
mpl::for_each< single >( type_printer(std::cout) ); //OK
mpl::for_each< two >( type_printer(std::cout) ); //OK
mpl::for_each< push_on_empty >( type_printer(std::cout) ); //won't compile
}
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
On Thu, 26 Jun 2003, Paul A. Bristow wrote: > > // (C) Jane Programmer, 2003 > // See www.boost.org/license for license terms and conditions > // See www.boost.org/libs/janes-lib for documentation > > Looks fine to me, though I prefer "Copyright" to (C) > > Paul I have been told by previous employers' lawyers that the word "Copyright" is in fact required. A claim of copyright must include the word "Copyright" or the copyright symbol (a circled C), and the year of the copyright. In the US, a capital C in parenthesis does not carry the legal meaning of the word copyright or the copyright symbol. Since ASCII doesn't offer a copyright symbol, we must include the word copyright. However, the same lawyers suggested including both "Copyright" and "(C)", as other countries may not accept the word Copyright, but might accept the (C). In any event, this is a really short and easy question for the lawyers. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] partial<> proposal
Hi all,
On Tue, 25 Feb 2003, Fernando Cacciola wrote:
>
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > template void * operator new(size_t n, optional & t);
> >
>
> Anyway, there are still problems with this: operator new is called _before_
> the T is constructed, so there won't be a way, AFAICT, to properly set the
> initialized flag ('cause if T ctor throws, placement new won't be aware of
> it)
>
Additionally, I think writing into the object in operator new before the
object is constructed leads to undefined behavior, or, at least, not the
behavior you want. I tried something similar once, where operator new
filled in a data member of the object being created, and the constructors
for the object left that data member unitialized. However, it turned out
that Intel C++ 7.0 zeroed out the entire object via memset() before
invoking my constructor, wiping out the data stored by operator new. I
could find nothing in the standard that prohibited icc from doing this.
The fix is to move the data member either before or after the object, and
have operator new allocate extra memory. Perhaps you could put the
initialized flag before the optional<>, and have operator new initialize
this bool to false. If optional<>'s constructor knows that there is a
bool located immediately before the optional in memory, it can calculate
the address of it and access it, even though it lives outside the actual
optional<> object.
I don't understand all the issues here, so I am not sure if this helps at
all. Also, there are alignment issues that need to be dealt with, to
assure that both the bool and the optional are properly aligned, but
I'm sure these can be handled.
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preliminary submission: command line & config file library
Hi all, I have not followed this discussion closely, but I did want to add on one point: On Thu, 16 Jan 2003, Vladimir Prus wrote: > > > > BTW what if I want ? as a part of my parameter name? > > Do you need this really? > > > For example: > > > > my_program /roll trace file? = "yes" > > > > CLA is basic facility that is used by many people with different habits. You > > could not afford to incur too many restrictions. > > I think that *existing* habits shold be supported. However, the library should > encourage some "standard" command line style. Contrived command line style is > only an inconvenience to user. As an example: what does "-r" option to CVS > does? (It has 2 unrelated meanings, and about 4 syntax variations) Some programs might support a command line like this: my_program ? To print out help information (ie same as my_program --help). Therefore, allowing ? as a command line argument is an important use case. I am not sure whether or not Vladimir's proposal would support a question mark by itself. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost License Issues
Hi, Just as a note to those scanning files for copyright messages, I was once informed by lawyers at one of my former employers that the string "(C)" (that is, a capital C in parenthesis) has no legal standing - only the word "copyright" or the copyright symbol (not available in ASCII) legally imply a claim of copyright. Whether this is correct or not, I would suggest that Boost err on the side of caution. If we are going to scan files for copyright strings, we might as well require that they spell out the word "copyright". Thoughts? -Tom Wenisch Computer Architecture Lab Carnegie Mellon University On Sun, 24 Nov 2002, Beman Dawes wrote: > At 12:36 PM 11/19/2002, Rene Rivera wrote: > > >I think you did a limited search... only in the headers. There are many > >more files without (C). For example most "Jamfile"s don't have one. > > > >Could you post how you did the search... perhaps this is something for > >Beman > >to add to the list of checks for releases. > > Thanks, Rene. > > It's on my list to add to the scans. > > --Beman > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
