templatetypename T
void foo( T const )
{
}
int main()
{
boost::variantint,. v = 5;
// Here I want to pass const reference to integer value of variant to
function foo
// foo( getint( v ) ); - type T is incorrect
foo( ??? );
}
I don't see why
If the issue concerns you this much, you might propose something along the
lines of BOOST_NO_EXCEPTIONS.
That is, you might try: BOOST_NO_RTTI anyone?
- Eric
I did. As a user defined parameter. Terrie made a point that it should be
config parameter cause some embedded compiler indeed does
I think you misunderstand: What I'm arguing is that the usage case you
propose here is itself erroneous. This is *not* an issue of whether I can
implement the behavior. (In fact, I need to do additional work to prohibit
it.)
Let me know if you still disagree.
I disagree. Let say I want to
Vladimir Prus wrote:
Hi Maxim,
And here are the Intel VTune results (see the sources for details):
Creation Assignment
struct 13383 27358
boost::any 3846 331870
TailoredAny 9151 310717
TailoredAnyLoki::SmallObject 3855 110022
IOW, TailoredAny behaves much worse on creation in default
Gennadiy Rozental wrote:
So what I want is
typedef boost::variantint const,std::string const GlobalParameter;
GlobalParameter input_socket( 12345 ); // localhost::12345
GlobalParameter output_socket( MultiplexorSocket );
typedef boost::variantint, std::string GlobalParameter;
Lars Gullik Bjønnes wrote:
We find ourselves in want of a custom deallocator for scoped_ptr, but
no such thing seems to exist now.
Has this been thought of?
If yes, what was the reason for not supporting this?
If you want a shared_ptr-style runtime custom deallocator support, this is
not
I think scoped_ptr needs to remain as it is. If we need this
functionality a new scoped_deallocator may be the way to go.
On Thursday, Apr 3, 2003, at 11:04 Europe/London, Peter Dimov wrote:
Lars Gullik Bjønnes wrote:
We find ourselves in want of a custom deallocator for scoped_ptr, but
no such
Among the several changes I've planned to dynamic_bitset there's one
which affects semantics and that, therefore, I would like to discuss
with you a bit. Note however that the old semantics were never
specified in the docs, so this would break nothing but adventurous
usages of undocumented
Larry Evans wrote:
Wouldn't the following:
*thisiomanip::setw(m_indent.length *
m_indent.level)setfill(fill)fill;
*thissetfill(fill);
do essentially what indentor OutputFileType ::indent() does?
Thanks. I didn't think of that. I'll implement it into the code (with the
correction pointed
On Wednesday 02 April 2003 02:57 pm, Paul A. Bristow wrote:
Sadly (but perhaps not too surpringly) this does not seem to work for MSVC
7.0 with complex. (OK without)
Could you elaborate? What didn't work? Any ideas how to fix? I don't use
MSVC.
A full working example with at least a few
On Thursday, April 3, 2003, at 05:04 AM, Peter Dimov wrote:
So if someone has an opinion about this potential change to
scoped_ptr, now
is probably the right time to express it.
I've been experimenting with:
templateclass T, class D = detail::apply_delete
class move_ptr;
So far I like it. It
At 04:01 AM 4/2/2003, k.t. wrote:
And in translating, we found some incorrect expressions in boost
document. We want to report them for feedback, then is it no problem to
report them here? Is boost users mailing list better for it?
This list is probably the best place.
Thanks,
-- Beman
Neal D. Becker wrote:
Could you elaborate? What didn't work? Any ideas how to fix? I don't use
MSVC.
Looking at the code, I think the problem is this (although I have not yet
tried it):
templatetypename T
struct Stat_t std::complexT {
typedef typename std::complexT::value_type value_t;
};
On Thu, 03 Apr 2003 14:15:27 +0200, Gennaro Prota
[EMAIL PROTECTED] wrote:
Now, for the gurus: this is the current interface of reference:
class reference
{
friend class dynamic_bitsetBlock, Allocator;
// the one and only non-copy ctor
reference(dynamic_bitset bs_, size_type
I believe this conjecture is correct, but I am still eagerly awaiting 7.1 :-)
This is quite interesting (though it needs Industrial Strengthening of course),
and could usefully generate the higher moments and other statistical thingys
too.
And it makes me wonder if one could use a container like
Reece Dunn wrote:
Larry Evans wrote:
[snip]
There are two possible ways I see at simplifying your marg_ostream:
[1] Overload string operations only since you only really need to
intercept '\n' characters - this appears to be the simpler of the two
solutions (as there is no real need to overload
A couple of corrections to my previous post:
And even if, how could one use a reference considering
that all its constructors are private?
All non-copy constructors, actually. Client code can easily create a
reference object by copy:
dynamic_bitset::reference ref = b[0];
This brings
Gennadiy Rozental:
templatetypename T
void foo( T const )
{
}
int main()
{
boost::variantint,. v = 5;
// Here I want to pass const reference to integer value of variant
to
function foo
// foo( getint( v ) ); - type T is incorrect
foo(
Gennadiy Rozental wrote:
While I do agree O(1) is better than O(N), I would like to point out
that
it is usable only when the pseudo-variadic template interface is used
(i.e.,
variantT1, T2, ..., TN as opposed to variantTypes).
Why? And to be absolutely clear: what do you mean by it?
By
I'm new to boost. But should '#define BOOST_HAS_THREADS' be added to
boost_1_30_0/config/platform/win32.hpp?
Or is there a better way?
Thanks.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
overview.) This technique is necessary to provide a general guarantee
of strong exception-safety, which in turn is necessary to maintain
a never empty invariant for variant.
What is this invariant? And why is it that important.
The invariant is quite straightforward: any object of
21 matches
Mail list logo
