From: Rob Lori [EMAIL PROTECTED]
E. Gladyshev wrote:
--- Edward Diener [EMAIL PROTECTED] wrote:
As you have pointed out in the rest of your post, it
may prove more
worthwhile to work with the developers which already
exist for a free
cross-platform framework like wxWindows, in order to
From: Philip Miller [EMAIL PROTECTED]
Now, the reason for my posting. I am using MSVC 7.0 and am unable to
compile the date_time library tests. Compiling time_parsing.hpp gives
me an error in lexical_cast, where there is no output operator for the
lexical_castunsigned short compiled for the
From: Daniel Frey [EMAIL PROTECTED]
On Sun, 22 Jun 2003 03:32:52 +0200, Terje Slettebø wrote:
--- Start ---
#include iostream
#define BOOST_DEFINE_MATH_CONSTANT(name)\ const struct name##_type\
{\
name##_type() {}\
templateclass T\
operator T() const;\
} name
From: Daniel Frey [EMAIL PROTECTED]
On Sun, 22 Jun 2003 22:01:19 +0200, Terje Slettebø wrote:
Another thing, are the ADD_OPERATOR macro in your code necessary? It
compiles fine without it on Intel C++ 7.1.
The GCC doesn't work without the operators, as it doesn't implicitly tries
(Because this reply is so late, I cc it, as well)
Sorry for the late reply.
I #included gregorian\greg_date.hpp and gregorian\parsers.hpp in my
code, and they indirectly #include lexical_cast.hpp. Here is the warning
I
get from the compiler (I am using MS Visual C++ 6):
*
In this comp.lang.c++.moderated thread
(http://www.google.com/groups?selm=2045294.t6ppZr3Erj%40technoboredom.net),
there was the following request:
--- Start quote ---
For some reason (I want to pass function pointers to certain libraries) I'd
like to convert a member function into a real
From: Alexander Terekhov [EMAIL PROTECTED]
Terje Slettebø wrote in message [EMAIL PROTECTED]:
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more/error_handling.html).
You should perhaps point out that this is from a comp.lang.c++.moderated
posting
From: [EMAIL PROTECTED]
Even if angle is added as a dimension, to an implementation using an
integer vector, it still wouldn't accommodate any other dimensions
added later, without rewriting the library and unit definitions.
how about having the basic SI dimensions and a couple of extra
If one were to implement currency conversion, how might that be done, in
general?
Does one need to store the conversion rates between any two currencies
(giving an N^2 size table), or might it be possible to convert any currency
to some universal currency, and from that again to any other, and
From: David Abrahams [EMAIL PROTECTED]
These are my (only slightly informed) opinions. I've heard Walter
Brown talk about angle in this context, which was a big influence.
Terje Slettebø [EMAIL PROTECTED] writes:
Regarding this angle dimension, should it be treated like the other
SI
From: [EMAIL PROTECTED]
we use the int-based template approach for a couple of years now in
our AGV controller software. We actually sometimes reach the stage that
it works when succesfully compiled and linked. Since our control software
is physics throughout (field of robotics), the type
From: Justin M. Lewis [EMAIL PROTECTED]
As for a function returning a single param, I agree, normally you'd just
return it, UNLESS it's some big structure you don't want being copied
all over the place, then passing it by reference to a function makes
more sense.
The compiler may elide such
Just to add some to my previous posting.
Also, from a maintenance POV, having variables that doesn't change
throughout a function (or program), tends to make it easier to understand.
Having functions which change their arguments goes rather against that.
One exception is input stream operators,
From: Justin M. Lewis [EMAIL PROTECTED]
Well, I guess, based on all the code I've been reading at work it didn't
seem so small, chasing down all kinds of functions across 100's of files
to see why exactly values are changing mid function I'm looking at
without warning.
Anyway, this would
From: Paul Mensonides [EMAIL PROTECTED]
Terje Slettebø wrote:
Is there some way (using PP-lib, or whatever), to pass a template-id
with more than one parameter (thus, it contains at least one comma),
to a macro?
E.g.:
#define TEST(a) testa t;
TEST(std::pairchar,int) // Won't
From: Alisdair Meredith [EMAIL PROTECTED]
I see that this has been the topic of much discussion lately, but just
confirming this little warning from the regressions has not snuck by
unnoticed:
# 'boost::bad_lexical_cast::what()' hides inherited virtual function
'std::exception::what()
From: Jason House [EMAIL PROTECTED]
I had 2 thoughts today...
1. Is it at all useful/possible to use a lambda-like notation?
In what way? Could you have given a rough syntax-example?
An example in BLL is:
std::for_each(v.begin(), v.end(), std::cout _1 '\n');
In the past, I've liked
Hi.
I've now uploaded the latest version of the composite stream operators
library at Yahoo Files
(http://groups.yahoo.com/group/boost/files/composite_stream_operators/) and
the Sandbox (boost/io/format/ and libs/io/format)..
Since the libraries in the Sandbox use the boost namespace, this one
From: Rozental, Gennadiy [EMAIL PROTECTED]
Even if none of the above looks sound for you I still argue that
lexical_cast *should not force* inclusion of typeinfo. It's not
inconvinience - it's showstopper. It's much more important
than providing
specific type info. In majority of the
From: Rozental, Gennadiy [EMAIL PROTECTED]
#include boost/io/format/std/vector.hpp
#include boost/io/format/std/map.hpp
#include boost/io/format/array.hpp
I am afraid boost/io/format will be confusing in a sight of presence of
Boost.Format.
I understand. Well, it's in a different
From: David Abrahams [EMAIL PROTECTED]
Rozental, Gennadiy [EMAIL PROTECTED] writes:
Even if none of the above looks sound for you I still argue that
lexical_cast *should not force* inclusion of typeinfo. It's not
inconvinience - it's showstopper. It's much more important
than providing
From: Rozental, Gennadiy [EMAIL PROTECTED]
Another way may be a macro. However, as has been mentioned in
this thread,
it appears that the config macros aren't geared for macros
with optional
exclusion of RTTI.
No. this has nothing to do with config
Well, as Dave A said in another
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) :
warning
C4512: 'no_lexical_conversionclass std
From: Gennaro Prota [EMAIL PROTECTED]
On Sat, 22 Mar 2003 09:52:07 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Kevlin Henney [EMAIL PROTECTED] writes:
However, the decision as to whether this should be in the 'what' string
is perhaps one that can be revisited. It would be feasible to
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
Terje Slettebø [EMAIL PROTECTED] writes:
I've tried the program below on Intel C++ 7.0 and MSVC 6, and I
haven't got
it to call terminate(). It may be that it doesn't handle exceptions
correctly, though
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
From: Gennaro Prota [EMAIL PROTECTED]
I'm happy that std::type_info has a private copy constructor. Hadn't
it been for that, my suggestion to use just a couple of typedefs would
have been routinely rejected
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
As it stands, it prints Exception - Constructor, as it throws
an exception in the constructor of the Exception exception. If
the throw-statement in the constructor is commented out, it
prints
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
What I meant (though sorry I was probably too blunt about it) was that
it's irrelevant whether you actually observed termination or not,
unless you're intending for lexical_cast to work just on that compiler
From: John Swartzentruber [EMAIL PROTECTED]
I downloaded 1.30.0 and tried to build my project. I got a few errors
that seem to be in boost, primarily in lexical_cast. Also,
weak_ptr.hpp uses bad_weak_ptr without including
boost/detail/shared_count.hpp anywhere. I can fix that by
including it
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) :
warning
C4512: 'no_lexical_conversionclass std::basic_stringchar,struct
std::char_traitschar,class std::allocatorchar ,long' : assignment
From: Beman Dawes [EMAIL PROTECTED]
A fresh version of the Win32 regression tests has just been posted. See
http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html
There are seven new fails in date_time tests; presumably all caused by
lexical_cast.hpp problems. See typical
From: Kevlin Henney [EMAIL PROTECTED]
In article [EMAIL PROTECTED], Terje Slettebø
[EMAIL PROTECTED] writes
However, the three failing tests for each of MSVC 6 and g++ 2.95
(different
ones for the two) are in the middle of some wide character tests.
My original intent was to disable wide
From: Beman Dawes [EMAIL PROTECTED]
At 03:13 AM 3/19/2003, Terje Slettebø wrote:
Ok, it seems we may have to exclude wide character support for
lexical_cast
on MSVC 6, to avoid breaking Date/Time. I suggest something like:
#if defined(BOOST_NO_STRINGSTREAM) || \
defined
From: Beman Dawes [EMAIL PROTECTED]
My patience has been exhausted. The folks that care about configuring
lexical_cast for GCC 2.95.3 with the SGI library need come forward
immediately and tell us how to deal with this, or 1.30.0 will ship as is.
I've applied John Maddock's suggestion to my
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
- With wide character support in lexical_cast enabled for MSVC 6, three
tests (of 137) fail. These are omitted for that compiler version, using
BOOST_WORKAROUND and BOOST_TESTED_AT.
You shouldn't be using
From: Rozental, Gennadiy [EMAIL PROTECTED]
lexical_cast_test.cpp(105): error in
test_conversion_to_intr: exception
boost::bad_lexical_cast is expected
lexical_cast_test.cpp(111): error in
test_conversion_to_intr: exception
boost::bad_lexical_cast is expected
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
Also these three tests, like MSVC 6, concerns tests where it doesn't
throw
when it's supposed to:
BOOST_CHECK_THROW(lexical_castint( 123), boost::bad_lexical_cast);
BOOST_CHECK_THROW(lexical_castint(std
From: Terje Slettebø [EMAIL PROTECTED]
From: Rozental, Gennadiy [EMAIL PROTECTED]
If these are omitted for g++ 2.95.x, all tests pass for that compiler.
However, as it compiles without errors on both MSVC 6 and g++
2.95.x, maybe
one shouldn't have any BOOST_WORKAROUND's in the test
From: Vladimir Prus [EMAIL PROTECTED]
Terje Slettebø wrote:
/home/boost/boost-regress/boost/boost/lexical_cast.hpp:173: syntax
error
before `;'
Looking at the CVS, it appears the reason for this is that
config/compiler/gcc.hpp no longer defines BOOST_NO_STRINGSTREAM, even
though
From: Gennaro Prota [EMAIL PROTECTED]
On Mon, 17 Mar 2003 14:47:20 +0300, Vladimir Prus [EMAIL PROTECTED]
wrote:
Gennaro Prota wrote:
Ok. I've forwarded this to Kevlin.
Maybe there's more than one problem here. I see that Vladimir talks
about warnings while Jeff about errors. Also
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
typedef std::vectorchar vector_char;
vector_char values;
// Fill with 'A', 'B', 'C'
std::cout io::formatvector_char([, ], , , \', \')
values;
Output:
['A', 'B', 'C']
However, is this overkill?
It seems
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
std::vectorstd::pairchar,int test;
std::cout test: // Using defaults
(('A',1),('B',2),('C',3))
I would suspect that chars don't get output with '' around them...
Is there even a way to specify/change that? Something
Hi.
When trying to use integer_traits on Intel C++ 7.0, I get the following
error (main line and branch):
boost/integer_traits.hpp(69): error: name followed by :: must be a class
or namespace name
public detail::integer_traits_basebool, false, true
^
This is the compiler's
From: Terje Slettebø [EMAIL PROTECTED]
When trying to use integer_traits on Intel C++ 7.0, I get the following
error (main line and branch):
boost/integer_traits.hpp(69): error: name followed by :: must be a class
or namespace name
public detail::integer_traits_basebool, false, true
From: Jeff Garland [EMAIL PROTECTED]
On Sun, 16 Mar 2003 17:34:18 -0500, Beman Dawes wrote
I'll go over the do-list again after dinner, but it looks like
almost all problems have been cleared except for this one.
I don't know if the Linux results are up to date, but
it appears that we
From: Victor A. Wagner, Jr. [EMAIL PROTECTED]
for the past 3 hours I've been getting:
...failed updating 300 targets...
...skipped 117 targets...
...updated 8 targets...
when trying to make the latest CVS update:
date /T update.log
time /t update.log
cvs -z3 update -A -P -d
From: Beman Dawes [EMAIL PROTECTED]
At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote:
The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc
3.2.2.
The error message appears at the top of:
http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test
From: Terje Slettebø [EMAIL PROTECTED]
The new
version of lexical_cast is Kevlin's own, which he recently made, not my
proposition. I think his version is better, though, as it's much shorter
and
removes duplication.
Just to point out that it's the kind of duplication which is not easily
A few months ago, Aleksey posted a cool way of doing lambda using function
notation. I hadn't followed the thread at the time, but I read up on it
recently. Like many others, I found it hard to understand how it worked, so
I asked Aleksey if he could make a minimal example of it, which he did.
From: Vladimir Prus [EMAIL PROTECTED]
Terje Slettebø wrote:
Right. There was a suggestion for allowing generic formats, though,
using
the same format for all instantiations of a template. The question is
how
to do it. The current version stores the format for each specific type,
as
you
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
From: Jason House [EMAIL PROTECTED]
Is there even a way to specify/change that?
It isn't currently, as the fundamental types aren't handled as composite
types, and therefore aren't formatted using any set format. Also
From: David Abrahams [EMAIL PROTECTED]
Dirk Gerrits [EMAIL PROTECTED] writes:
Dirk Gerrits wrote:
I'd say something like:
#ifdef STATIC_NDEBUG
#define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e)
#else
#define BOOST_STATIC_ASSERT2(e) (void(e))
#endif
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
I like the basic idea, but are you sure it will work in all the
contexts where BOOST_STATIC_ASSERT works? I think BOOST_STATIC_ASSERT
functions like a declaration
From: Beman Dawes [EMAIL PROTECTED]
At 05:58 PM 3/5/2003, Robert Klarer wrote:
The purpose of the static_string library is to offer an alternative to
string literals and the standard type const std::string. A
static_string uses no dynamically allocated memory, and is more
efficient at
From: Robert Klarer [EMAIL PROTECTED]
Terje Slettebø wrote:
If run-time computation is ok, and that one only wants to avoid
dynamical
allocation, then one might do something like I used in another posting
in
this thread:
templateclass CharType, int N
class fixed_size_string
From: Joel de Guzman [EMAIL PROTECTED]
Terje Slettebø wrote:
From: Joel de Guzman [EMAIL PROTECTED]
Dave Gomboc wrote:
So then reverse resource_manager and get managed_resource, or
just managed.
Why not just resource? Management is implied anyway; that's the
reason
From: Joel de Guzman [EMAIL PROTECTED]
managerwidget
Manager of widget. It's kind of implied that what is managed is the
resource itself, even though resource doesn't say anywhere. This is
similar to that you think it's implied that resourcewidget means it
manages the resource, even
From: Joel de Guzman [EMAIL PROTECTED]
Dave Gomboc wrote:
So then reverse resource_manager and get managed_resource, or just
managed.
Why not just resource? Management is implied anyway; that's the
reason for the existence of the class.
*laugh* I was thinking exactly the opposite.
From: Phil Nash [EMAIL PROTECTED]
[Rob Stewart]
There can still be a smart_ptr class, even if there's a
smart_resource class. Both may be separate manifestations,
possibly sharing some implementation details, of a SmartResource
concept. Equally plausible, smart_ptr could be implemented
From: Phil Nash [EMAIL PROTECTED]
[Terje Slettebø]
I also think this makes sense. However, I'm wondering how much
commonality
there is in such a broader concept. This is kind of making a library
implementation of the RAII idiom, and we have that already, in the form
of
constructors
From: Jason House [EMAIL PROTECTED]
std::vectorstd::pairchar,int test;
std::cout test: // Using defaults
(('A',1),('B',2),('C',3))
I would suspect that chars don't get output with '' around them...
Right. I was just thinking C++ code, here. :)
Is there even a way to
accepted in the Library TR), it may be good enough for the other types,
as well. :)
Terje Slettebø wrote:
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
Regarding this project. I've got doubts about the viability of it.
Well, I'm glad you've given it a greater level
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
From: Vladimir Prus [EMAIL PROTECTED]
Sorry for having taken so long to respond to these messages. I felt a
need
for a break, to consider how it might be done.
I was wondering about this line of discussion earlier today
From: Jason House [EMAIL PROTECTED]
Jason House wrote:
Terje Slettebø wrote:
Another possibility might be to have a sentry object, doing automatic
state
saving and restoring in the constructor and destructor. In fact, there
are
already such classes in Boost: Daryle Walker's I/O
From: Paul A. Bristow [EMAIL PROTECTED]
This looks really neat - and potentially very useful.
Thanks. :)
Sadly, array is one of the most interesting cases - so I'm sure I won't be
the
only one 'watching this space'.
I've looked more into it, and it seems this is a problem not just for MSVC,
From: Terje Slettebø [EMAIL PROTECTED]
const int array[3];
std::cout array;
MSVC 7 - C
Intel C++ 7 - C
g++ 3.2 - C
const char array[3];
std::cout array;
MSVC 7- A (S or C)
Intel C++ 7 - C
g++ 3.2 - C
std::cout Test;
MSVC 7 - A (S or C)
Intel 7 - C
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
It should handle maps and pairs
reasonably well. I think that I have the same complaints about this
as
io_manip
The saving of information to the stream means that you can affect all
future output...
For instance
From: Vladimir Prus [EMAIL PROTECTED]
Terje Slettebø wrote:
From: Vladimir Prus [EMAIL PROTECTED]
after having to output std::vector to stream again and again using
custom
solution, I started to wonder why we don't have a solution in boost.
Does it makes sense to include operators
From: Paul A. Bristow [EMAIL PROTECTED]
This looks most useful - potentionally :-(
Alas the two files, test and composite_stream_operators.hpp
http://groups.yahoo.com/group/boost/files/composite_stream_operators/).
won't compile on MSVC 7.0.
test_composite_format.cpp
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
and given this:
int main()
{
char board[3][3]=
{
{'O','X','O'},
{'X','X','O'},
{'O','O','X'}
};
std::cout io_formatchar ()[3](\n|,|\n,|)
io_formatchar ()[3][3
From: Vladimir Prus [EMAIL PROTECTED]
Terje Slettebø wrote:
From: Vladimir Prus [EMAIL PROTECTED]
after having to output std::vector to stream again and again using
custom
solution, I started to wonder why we don't have a solution in boost.
Does it makes sense to include operators
From: Vladimir Prus [EMAIL PROTECTED]
after having to output std::vector to stream again and again using custom
solution, I started to wonder why we don't have a solution in boost.
Does it makes sense to include operators for vectors, sets, etc?
I was thinking about
boost/io/vector.hpp
From: Glenn G. Chappell [EMAIL PROTECTED]
Vladimir Prus wrote:
after having to output std::vector to stream again and again using
custom
solution, I started to wonder why we don't have a solution in boost.
Does it makes sense to include operators for vectors, sets, etc?
...
of the
metafunction.
As Terje Slettebø noticed in private mail, this is a general problem
for any 'compile-time function'.
Just to clarify here, what I meant was that this wasn't something specific
for this particular metafunction, of course, so it could be good to find a
general solution
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
As you note, if you change it to match, with unsigned long, it
works. I think EDG is right on this one, that there has to be an
exact match, except top-level cv-qualification.
cv-qualification?? Whoa
From: Gennaro Prota [EMAIL PROTECTED]
--- John Maddock [EMAIL PROTECTED] wrote:
One question though - a lot of people seem to have worked on this: which
people deserve the copyright/credit listing?
Rani only, IMO.
I think so, too.
Regards,
Terje
From: Gennaro Prota [EMAIL PROTECTED]
On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø
[EMAIL PROTECTED] wrote:
[...]
Roughly speaking B is a base of D if and only if
the base-specifier-list of D contains a class name for B or for a
class of which B is a base. Of course you can see
From: David Abrahams [EMAIL PROTECTED]
John Maddock [EMAIL PROTECTED] writes:
Maybe you had the following variation on Terje's code in mind.
The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
Hey, now that one really does work well, I'm still testing here (doesn't
From: Terje Slettebø [EMAIL PROTECTED]
From: David Abrahams [EMAIL PROTECTED]
S... Somewhere back in this thread Peter Dimov raised a serious
question about whether this implements the semantics we want. Was
there ever agreement on that?
As I mentioned in an earlier posting, Rani's
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
No. You can't prove a negative, an impossibility.
I think that's wrong, and here's my one white crow to prove it ;-)
I can prove that there can never exist a positive integral multiple of 2
which
is both
From: Daniel Frey [EMAIL PROTECTED]
David Abrahams wrote:
Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man.
Personally I would go with his suggestion about having two (or more)
separate metafunctions, at least for the sake of generality
I'd rather settle on
[Note to moderators: This is just to reply, including giving possible
alternative places to discuss this]
From: Jason House [EMAIL PROTECTED]
The first part of this is probably a stupid question
Not at all. :)
Terje Slettebø wrote:
What makes the template typedef proposal different from
From: Terje Slettebø [EMAIL PROTECTED]
Given that supertype/subtype has such a general meaning, how should an
is_super_and_subtype be defined? I guess the proposal mean to define it in
terms of inheritance, only, and in that case, it would work like
is_base_and_derived, with the addition
From: Gennaro Prota [EMAIL PROTECTED]
On Thu, 30 Jan 2003 11:13:23 +0100, Terje Slettebø
[EMAIL PROTECTED] wrote:
From: Gennaro Prota [EMAIL PROTECTED]
On Tue, 28 Jan 2003 10:47:52 -0800, Andrei Alexandrescu
[EMAIL PROTECTED] wrote:
Peter Dimov [EMAIL PROTECTED] wrote in message
From: Gennaro Prota [EMAIL PROTECTED]
On Thu, 30 Jan 2003 12:33:04 +0100, Terje Slettebø
[EMAIL PROTECTED] wrote:
From: Andrei Alexandrescu [EMAIL PROTECTED]
Even if we also define is_super_and_subtype,
void is hardly a supertype of everything.
Well, it could be. It's like an abstract
From: John Maddock [EMAIL PROTECTED]
This is tested on Comeau 4.3, Intel C++ 6/7 and g++ 3.2.
Except it *doesn't work* !
The problem is that your static assertion don't test anything, changing
to:
//typedef char TestA[is_base_and_derivedB, D::result]; // Multiple bases
(error on g++)
From: Gennaro Prota [EMAIL PROTECTED]
On Thu, 30 Jan 2003 12:20:32 -, John Maddock
[EMAIL PROTECTED] wrote:
Can you show, with an example, why the code used for named template
arguments can't reasonably use an expression?
It doesn't have access to one, only a type: the usage is take
From: Jason House [EMAIL PROTECTED]
2. Section 2.5 (Different Declarations) rubs me the wrong way. Thr
proposal does say that some people dislike this, and I guess I'm one of
them.
If
template A,B class X;
template A typedef foo XA,B;
then I'm opposed to typeof(XA,B) != typeof(fooA)
As
From: John Maddock [EMAIL PROTECTED]
Before changing the documentation please consider the following improved
implemetation that overcomes ambiguity and access control issues of the
current is_base_and_derived implemetation (I lately posted it to
c.l.c++.m)
That's really interesting, but
From: Aleksey Gurtovoy [EMAIL PROTECTED]
David Abrahams wrote:
It appears to be just bad luck that higher order functional
programming with function templates is impossible in C++.
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
Perhaps it might be possible to do some compile-time/run-time lambda
(similar to Boost.Lambda for runtime, and MPL's lambda), so you could do
something like:
mpl::for_eachmy_list(my_function_(s
From: Terje Slettebø [EMAIL PROTECTED]
I can imagine something like this:
templateclass Sequence, class T, templateclass void Function(T)
struct for_each;
Possibly using overloaded class templates, as well (another possible
extension).
Come to think of it, the latter wouldn't be needed
From: David Abrahams [EMAIL PROTECTED]
Andrei Alexandrescu [EMAIL PROTECTED] writes:
Or (barring my lack of mastering some syntactic details):
inline void do_my_function(string, void_) {}
template class Lst
inline void do_my_function(string s, Lst lst)
{
From: Gennaro Prota [EMAIL PROTECTED]
On Sat, 18 Jan 2003 20:16:36 -0700, Greg Colvin
[EMAIL PROTECTED] wrote:
At a meeting years ago I proposed to make string literals more
useful as constant expressions, but we decided against that.
As I recall part of the problem is that linkers are free
From: Peter Dimov [EMAIL PROTECTED]
From: Terje Slettebø [EMAIL PROTECTED]
I understand the concern. For one thing, we don't have template
typedefs,
yet, although me may get a similar effect (if not the same type) with
e.g.:
templateclass T
struct shared_ptr : smart_ptrT, policies
From: Greg Colvin [EMAIL PROTECTED]
At 07:33 AM 1/18/2003, Peter Dimov wrote:
It is not simply declaration complexity that Dave's talking about - it
can
be avoided by making smart_ptrT be shared_ptrT by using default
parameters. It is semantic complexity. shared_ptr is fairly deep by
itself
From: David Abrahams [EMAIL PROTECTED]
Please don't take this to mean I'm against a
policy-based smart pointer; quite the opposite. I've
said all along it would be great to have one in boost.
I've even wished I had an appropriate occasionally.
I just don't want to trivialize what I
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
Why would we want that? What is this useful for?
It would be useful for writing a templated implicit conversion
operator with restricted applicability via SFINAE.
Right. I've read up properly on the thread
From: Paul Mensonides [EMAIL PROTECTED]
From: David Abrahams [EMAIL PROTECTED]
Here's an interesting turn-of-the-tables: I was experimenting with
using SFINAE to disable conversion operators, and I discovered that
almost every compiler except vc6/7 rejects this code:
template
From: Terje Slettebø [EMAIL PROTECTED]
From: Gennaro Prota [EMAIL PROTECTED]
In some old newsgroup post, searched through Google a while ago, I
also read that the committee rejected a proposal to allow the
generalized form f(T) with T=void, but I've never read the proposal
itself (I
1 - 100 of 150 matches
Mail list logo
