David Abrahams wrote:
What we need is some concrete use cases of toolset inheritance.
Well, to begin with, it's possible to have some common.jam, with
toolset.flags common.compile DEFINES ;
then gcc.jam would say
tolset.inherit-flags common ;
to reuse the first flags declaration. Look
David Abrahams <[EMAIL PROTECTED]> writes:
| Terje Slettebø <[EMAIL PROTECTED]> writes:
|
| > Static constant members are lvalues. So, if you have a declaration such as
| >
| > void foo(int const&);
| >
| > and you pass it the result of a metaprogram
| >
| > foo(Pow3<7>::result);
| >
| > a compil
At 05:17 PM 1/8/2003, William E. Kempf wrote:
>> From: Rene Rivera <[EMAIL PROTECTED]>
>> I rather dislike the conditional compilation solution. It makes it
rather
>> harder to write portable code as it makes for doing conditional PP code
>> outside of the library. Would it not be preferable to t
At 03:03 PM 1/8/2003, William E. Kempf wrote:
>The sched_fifo, sched_rr, sched_other, scope_process, and scope_system
>values are implementation defined, and on POSIX correspond to SCHED_FIFO,
>SCHED_RR, SCHED_OTHER, PTHREAD_SCOPE_PROCESS and PTHREAD_SCOPE_SYSTEM
>respectively.
Do these values
[2003-01-08] William E. Kempf wrote:
>
>>
>> From: Rene Rivera <[EMAIL PROTECTED]>
>> Date: 2003/01/08 Wed PM 03:38:07 EST
>> To: Boost mailing list <[EMAIL PROTECTED]>
>> Subject: Re: [boost] Next revision of boost::thread
>>
>> [2003-01-08] William E. Kempf wrote:
>>
>> >I'd appreciate commen
William E. Kempf wrote:
* Are there concerns about using conditional compilation and optional portions of the library, as POSIX does? I believe this is the only way Boost.Threads and the C++ standard will be able to provide "portable" threading libraries that don't restrict implementation to a le
Dietmar Kuehl wrote:
Alberto Barbati wrote:
One can use a char traits class different from
std::char_traits, that defines a suitable state type.
This is not really viable due to 27.8.1.1 paragraph 4:
An instance of basic_filebuf behaves as described in lib.filebuf
provided traits::pos_ty
>
> From: Rene Rivera <[EMAIL PROTECTED]>
> Date: 2003/01/08 Wed PM 03:38:07 EST
> To: Boost mailing list <[EMAIL PROTECTED]>
> Subject: Re: [boost] Next revision of boost::thread
>
> [2003-01-08] William E. Kempf wrote:
>
> >I'd appreciate comments on the above design. Specifically I have the
>From: "David Abrahams" <[EMAIL PROTECTED]>
> "Paul Mensonides" <[EMAIL PROTECTED]> writes:
>
> >> [EMAIL PROTECTED] (Hartmut Kaiser) writes:
> >>
> >> >
> >> > // The following expands to
> >> > //
> >> > // typedef char (&sizeN_t)[N];
> >> > //
> >> > // for N = 1..BOOST_MAX_SIZETYPE_COUNT
> >
David Abrahams wrote:
> > // The following expands to
> > //
> > // typedef char (&sizeN_t)[N];
> > //
> > // for N = 1..BOOST_MAX_SIZETYPE_COUNT
> > #define SIZETYPE(z, n, nil) \
> > typedef char (&size ## n ## _t)[n]; \
> > /**/
>
> Careful; isn't the symbol "_t" reserved to the imple
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> >> Careful; isn't the symbol "_t" reserved to the implementation in this
> > context?
> >
> > I thought it was only if the underscore was followed by a capital
letter, as
> > in "_T".
>
> 17.4.3.1.2 Global names
> 1
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 08, 2003 12:14 PM
> Subject: Re: [boost] Re: Small thing: yes_type and no_type made public?
>
>
>> [EM
[2003-01-08] William E. Kempf wrote:
>I'd appreciate comments on the above design. Specifically I have these
questions:
>
>
>* Are there concerns about using conditional compilation and optional
portions of the
>library, as POSIX does? I believe this is the only way Boost.Threads and
the C++
>
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 12:14 PM
Subject: Re: [boost] Re: Small thing: yes_type and no_type made public?
> [EMAIL PROTECTED] (Hartmut Kaiser) writes:
>
> >
> > // The f
- Original Message -
From: "Dirk Gerrits" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 6:15 PM
Subject: [boost] Re: intrusive tagging allows omision of unneeded headers
> Thorsten Ottosen wrote:
> [snip]
> > class X
> > {
> > public:
[EMAIL PROTECTED] (Hartmut Kaiser) writes:
>
> // The following expands to
> //
> //typedef char (&sizeN_t)[N];
> //
> // for N = 1..BOOST_MAX_SIZETYPE_COUNT
> #define SIZETYPE(z, n, nil) \
> typedef char (&size ## n ## _t)[n]; \
> /**/
Careful; isn't the symbol "_t" reserved
From: "David B. Held" <[EMAIL PROTECTED]>
> "Joel de Guzman" <[EMAIL PROTECTED]> wrote in message
> 01c701c2b602$dde18750$06d117d2@kim">news:01c701c2b602$dde18750$06d117d2@kim...
> > [...]
> > Well, I meant the targetted audience, of course, the C++ newbies :-)
>
> That's because the C++ noobs pre
I've been working on the next release of Boost.Threads and would like to discuss the
current design for the thread class. Here's a quick (and rough) description of the
design. Note that much of this design is based on POSIX, for those familiar with it.
class thread_cancel
{
public:
thread_
Paul Mensonides wrote:
> > I think, that using the PP library will give us the possibility to
> > configure the maximum number of required sizetype typedefs. I've
> > attached a version of the yes_no_type.hpp, which does so by
> defining a
> > constant 'BOOST_MAX_SIZETYPE_COUNT' if this constant i
- Original Message -
From: "Hartmut Kaiser" <[EMAIL PROTECTED]>
> David B. Held wrote:
>
> > "Terje Slettebø" <[EMAIL PROTECTED]> wrote in message
> > 05ab01c2b695$2f125c70$cb6c6f50@pc">news:05ab01c2b695$2f125c70$cb6c6f50@pc...
> > > Sure, that would be fine. I'm not that familiar with
>
Dirk Gerrits wrote:
Vladimir Prus wrote:
David Abrahams wrote:
Vladimir Prus <[EMAIL PROTECTED]> writes:
I'd prefer the latter variant, so that non-broken platforms use more
natural
syntax. Another question is whether we could use only the second
version.
Theoretically, if you call the
David B. Held wrote:
> "Terje Slettebø" <[EMAIL PROTECTED]> wrote in message
> 05ab01c2b695$2f125c70$cb6c6f50@pc">news:05ab01c2b695$2f125c70$cb6c6f50@pc...
> > Sure, that would be fine. I'm not that familiar with
> Boost.PP, though,
> > so I think I leave it to someone else to write that
> version
Larry Evans wrote:
> Peter Dimov wrote:
> > From: "Larry Evans" <[EMAIL PROTECTED]>
[snip]
> I'm pretty sure there a reference to it in some of the compare docs
> or code in the files/shared_cyclic_ptr directory.
I thought I'd be more help. The reference is:
David L. Detlefs. "Garbage collectio
At 10:22 AM 1/8/2003, David Abrahams wrote:
>Greg Colvin <[EMAIL PROTECTED]> writes:
>
>> At 04:02 PM 1/7/2003, David Abrahams wrote:
>>>...
>>>
>>>I can barely think of a reasonable design where GC is a big design win
>>>;-)
>>
>> A Python interpreter?
>
>I obviously have a poor imagination ;-)
M
Greg Colvin <[EMAIL PROTECTED]> writes:
> At 04:02 PM 1/7/2003, David Abrahams wrote:
>>...
>>
>>I can barely think of a reasonable design where GC is a big design win
>>;-)
>
> A Python interpreter?
I obviously have a poor imagination ;-)
--
David Abrahams
[EMAIL PROT
Vladimir Prus wrote:
David Abrahams wrote:
Vladimir Prus <[EMAIL PROTECTED]> writes:
I'd prefer the latter variant, so that non-broken platforms use more
natural
syntax. Another question is whether we could use only the second
version.
Theoretically, if you call the second version on cons
Douglas Gregor <[EMAIL PROTECTED]> writes:
> On Tuesday 07 January 2003 06:08 pm, David Abrahams wrote:
>> This compiler bug was reported on the Python/C++-sig. Probably we
>> should stick a const_cast in addressof just for vc7?
>
> Would you mind doing it? I don't have access to VC7 to test any
Thorsten Ottosen wrote:
[snip]
class X
{
public:
class tag {};
typedef tag X_tag;
^
};
class bar
{
public:
class tag {};
typedef tag bar_tag;
^^^
};
Why these typedefs? Why would one write X::X_tag instead of X::tag for
example?
Gennaro Prota <[EMAIL PROTECTED]> writes:
> Still the second line would be an improvement where a standard
> is available. But I guess I could replace it with
>
>enum { bits_per_block = some_namespace::precision::value };
>
> which is completely portable. That was just to show you a possibl
Hi Ulrich,
I like the general idea of your bidi_ptr. I haven't really read your
implementation yet, but your description sounds promising.
I don't really like the name bidi_ptr though. Bidirectional is always
spelled out in the Standard library. But bidirectional_ptr is rather
long. How about
Vladimir Prus <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Vladimir Prus <[EMAIL PROTECTED]> writes:
>
>>>I'd prefer the latter variant, so that non-broken platforms use more natural
>>>syntax. Another question is whether we could use only the second version.
>>>Theoretically, if you cal
- Original Message -
From: "Paul Mensonides" <[EMAIL PROTECTED]>
> Actually, this seems to be a bug in Comeau C++:
>
> #include
> #include
>
> struct A {
> enum type { x, y };
> };
>
> template struct B { };
>
> template inline T operator+(T lhs, T rhs) {
> throw 0;
> }
>
>
David Abrahams wrote:
Vladimir Prus <[EMAIL PROTECTED]> writes:
I'd prefer the latter variant, so that non-broken platforms use more natural
syntax. Another question is whether we could use only the second version.
Theoretically, if you call the second version on const string, then InputT
shou
On Wed, 08 Jan 2003 01:40:45 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>
>> Hi everybody,
>>
>> the attached files contain a bunch of trivial stuff related to
>> integral types that I need in a lot of situations. Any interest for
>> inclusion into
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Pavol Droba wrote:
>
> > I have following two variants of the same function:
> >
> > // find_first sequence const version
> > template< typename InputT, typename SearchT >
> > inline iterator_range< typename InputT::const_iterator >
> >
Vladimir Prus <[EMAIL PROTECTED]> writes:
> Hi Pavol,
>
> Pavol Droba wrote:
>
>> I have following two variants of the same function:
>> // find_first sequence const version
>> template< typename InputT, typename SearchT >
>> inline iterator_range< typename InputT::const_iterator >
>>
On Wed, Jan 08, 2003 at 05:10:17PM +0300, Vladimir Prus wrote:
> Hi Pavol,
>
> Pavol Droba wrote:
>
> > I have following two variants of the same function:
> >
> > // find_first sequence const version
> > template< typename InputT, typename SearchT >
> > inline iterator_range< typena
[2003-01-08] Beman Dawes wrote:
>At 07:58 AM 1/8/2003, John Maddock wrote:
>
> >This is another call for volunteers to come forward to help run the boost
> >regression tests on more platforms, particularly needed are the
>commercial
> >Unix variants (Solaris, HP, SGI Irix etc), but also Free|Net|
At 07:58 AM 1/8/2003, John Maddock wrote:
>This is another call for volunteers to come forward to help run the boost
>regression tests on more platforms, particularly needed are the
commercial
>Unix variants (Solaris, HP, SGI Irix etc), but also Free|Net|OpenBSD and
>MacOS X.
>
>To help kick thin
bjam has a useful "subinclude" feature, but the regression test status
reporting programs were not able to track subincludes, so use of the
feature was discouraged.
Dave Abrahams has made improvements to tools/build/testing.jam so that more
subinclude path information is available to reporting
>From: "Thorsten Ottosen" <[EMAIL PROTECTED]>
> just want to show you something I discovered
> (maybe you already know) which allows template functions to be specialized
> for a class without including its header; it does require that classes are
> changed internally,
> but I assume it will make c
Hi Pavol,
Pavol Droba wrote:
I have following two variants of the same function:
// find_first sequence const version
template< typename InputT, typename SearchT >
inline iterator_range< typename InputT::const_iterator >
find_first( const InputT& Input, const SearchT& Search )
Hi boosters,
just want to show you something I discovered
(maybe you already know) which allows template functions to be specialized
for a class without including its header; it does require that classes are
changed internally,
but I assume it will make compilation mucho faster. (another problem i
Pavol Droba <[EMAIL PROTECTED]> writes:
>
> If I compile cygwin version of bjam, would it solve my problem?
Yes, provided you only use it for cygwin gcc builds
> I thought, that the problem is not in bjam, but in tools settings
No, the reason it's hard to fix in this version of Boost.Build is
#include
I was recently having a case where I was coupling two objects loosely. Both
needed to know about each other, but the connection was not static, they
sometimes where separated and reconnected somewhere else. For the curious, I
was connecting a propertylist-widget with a container of en
On Wed, Jan 08, 2003 at 11:52:18AM -, John Maddock wrote:
> > I have encoutered a problem when building under win2k with cygwin gcc 3.2.
> >
> > Boost.Build select an extension for binary files according to OS platform.
> > So for the Windows paltform it selects .lib for library files and .obj
>From: "John Maddock" <[EMAIL PROTECTED]>
> > I've tried to compile something which uses std::wstring on GCC 3.2
> (MinGW),
> > but I get the following error at link-time:
> >
> > undefined reference to `std::basic_string > std::char_traits, std::allocator >::basic_string()'
> >
> > Using std::str
Hi Boosters,
I'd like to hear your opinion about following issue:
I have following two variants of the same function:
// find_first sequence const version
template< typename InputT, typename SearchT >
inline iterator_range< typename InputT::const_iterator >
find_first( const Inpu
This is another call for volunteers to come forward to help run the boost
regression tests on more platforms, particularly needed are the commercial
Unix variants (Solaris, HP, SGI Irix etc), but also Free|Net|OpenBSD and
MacOS X.
To help kick things off, I've attached a short shell script that wi
> I have encoutered a problem when building under win2k with cygwin gcc 3.2.
>
> Boost.Build select an extension for binary files according to OS platform.
> So for the Windows paltform it selects .lib for library files and .obj for
object files.
>
> However cygwin is using unix-like .a for libs. W
> I believe it's -tused you're referring to, isn't it?
Yep.
> Maybe you're planning to build two tests?
I already am, see for example: libs/config/test/has_pthread_ma_st_fail.cpp
and libs/config/test/has_pthread_ma_st_pass.cpp
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/
> I've tried to compile something which uses std::wstring on GCC 3.2
(MinGW),
> but I get the following error at link-time:
>
> undefined reference to `std::basic_string std::char_traits, std::allocator >::basic_string()'
>
> Using std::string works fine. Doesn't GCC 3.2 support wide character
> st
52 matches
Mail list logo
