On Fri, 24 Jan 2003 22:50:42 +0100, Gennaro Prota
[EMAIL PROTECTED] wrote:
Is there any danger than
that :-)
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, 25 Jan 2003 01:45:37 +0200, Peter Dimov [EMAIL PROTECTED]
wrote:
But how does this apply to is_convertibleX, int when a private X::operator
int()? Or are you discussing something else?
I see no reason to make that undefined behavior. It's either false, true
(Comeau says true BTW),
Maybe this is a useful info: I've noticed some people just copypaste
groups.google addresses when giving references to threads. Well, maybe
that's just laziness; if not that, it can be useful to know that much
of the information in the url is actually not strictly necessary: e.g.
given
On Fri, 24 Jan 2003 21:12:01 -0500, Howard Hinnant
[EMAIL PROTECTED] wrote:
But it is amusing (amazing?) how
many traits like tests are today passing non-POD classes to an
ellipsis, and invoking undefined behavior! :-)
Well, the problem is what does passing means. I noticed that this is
the
I think we must still answer the fundamental question: *why* we need
is_convertible applied to a type instead of an expression? If you
check convertibility it's because you want to convert something,
right? Then what can you legally convert if not an expression? Given
that, why not using the
Error : illegal access from 'B' to protected/private member
'B::B(const B )'
(instantiating: 'Metrowerks::is_convertibleB, A')
msl_utility line 472 tatic const bool value =
sizeof(is_convertible_helperU::test(makeT())) == 1;
Haven't tried it with boost::is_convertible, but I suspect
I think that a better solution would be to not define BOOST_HAS_THREADS
unconditionally for GCC, and rely on _MT, _REENTRANT, _POSIX_THREADS.
_MT and _REENTRANT yes, _POSIX_THREADS in general no (most platforms define
this unconditionally). I've reverted the bsd.hpp config header back the way
I'm beginning to think that the only way to deal with this is to add
array
types to the list of types banned from the To parameter. Otherwise we
get
into the old context sensitive answer problem.
I think that no special ban list is necessary. Given the specification
Returns true if and
A string literal (narrow or wide) is an lvalue.
Yes, you're right, however it's still a non-issue: array to pointer
conversions are allowed (int[2] to const int* for example), so this will do
the right thing anyway. The string literal to pointer conversion is just a
special case of a more
On Sat, 25 Jan 2003 11:48:52 -, John Maddock
[EMAIL PROTECTED] wrote:
There are all kind of useful uses for is_convertible that do not involve
converting anything as such, for example:
template class I
struct is_random_access_iterator
{
private:
typedef typename
Gennaro Prota:
Am I missing something?
Yes. I have, in fact, previously explained how to use choose_n correctly.
Please read more carefully. If something doesn't appear to make sense,
reconsider your basic assumptions. Only after you have carefully
reconsidered your assumptions, should you
From: John Maddock [EMAIL PROTECTED]
I think that no special ban list is necessary. Given the specification
Returns true if and only if an lvalue of type From is convertible to To
(4p3) the implication is that is_convertible should return false when
To
is
an array type, as
typedef
From: Howard Hinnant [EMAIL PROTECTED]
Furthermore, it is undefined to pass a non-pod to an ellipse (5.2.2/7):
int foo(...);
class B
{
public:
B();
private:
B(const B);
};
int main()
{
foo(B()); // undefined behavior
}
If you stick that in a sizeof, it is still undefined:
From: Joe Gottman [EMAIL PROTECTED]
Pavel Vozenilek [EMAIL PROTECTED] wrote in message
b0svlm$l1q$[EMAIL PROTECTED]">news:b0svlm$l1q$[EMAIL PROTECTED]...
Robert Ramey [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Is there such a thing as
I am interested in this library for my large scale project that will be the
complete project based on Boost.
Mohammed
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, 25 Jan 2003 15:35:48 +0200, Peter Dimov [EMAIL PROTECTED]
wrote:
I.e. it is up to you to decide whether this is a bug or a
feature. My opinion is that it is a bug... except that From and To must be
complete, of course, or is_convertible may violate ODR.
I'm even more radical than that.
From: Gennaro Prota [EMAIL PROTECTED]
On Sat, 25 Jan 2003 15:35:48 +0200, Peter Dimov [EMAIL PROTECTED]
wrote:
I.e. it is up to you to decide whether this is a bug or a
feature. My opinion is that it is a bug... except that From and To must
be
complete, of course, or is_convertible may
On Sat, 25 Jan 2003 12:17:18 -, John Maddock
[EMAIL PROTECTED] wrote:
A string literal (narrow or wide) is an lvalue.
Yes, you're right, however it's still a non-issue: array to pointer
conversions are allowed (int[2] to const int* for example)
Yes, but the special conversion is from const
The idea is that all alarms should share on timer thread and a thread
pool and a priority queue (or maybe these things should be in an
alarm_queue class which an alarm is associated with, but there should be
a system default if an
alarm_queue class isn't given). There are some thorny issues
On Saturday, January 25, 2003, at 08:39 AM, Peter Dimov wrote:
Furthermore, it is undefined to pass a non-pod to an ellipse
(5.2.2/7):
int foo(...);
class B
{
public:
B();
private:
B(const B);
};
int main()
{
foo(B()); // undefined behavior
}
If you stick that in a sizeof, it is still
--- Peter Dimov [EMAIL PROTECTED] wrote:
From: Gennaro Prota [EMAIL PROTECTED]
I'm even more radical than that. Even the fact that is_convertible may
violate ODR is a limitation of the current solution. I think we must
*first* decide what we want then see how to implement it. If we want
--- Gennaro Prota [EMAIL PROTECTED] wrote:
Again, I like the approach to not put in the core language
facilities that can be implemented with normal code but the order is:
first I see what I want to get, then I see if it can be implemented.
Here we seem to do the inverse: we see what can be
In multi_array's reference manual, Table 2,
the three links in the sentence
Otherwise it models _Random Access Traversal Iterator_,
_Readable Iterator_, and _Writable Iterator_.
seem to be broken.
- Roland
___
Unsubscribe other changes:
On Sat, 25 Jan 2003 15:06:54 +0200, Vesa Karvonen
[EMAIL PROTECTED] wrote:
Gennaro Prota:
Am I missing something?
Yes. I have, in fact, previously explained how to use choose_n correctly.
Please read more carefully. If something doesn't appear to make sense,
reconsider your basic assumptions.
On Sat, 25 Jan 2003, Roland Richter wrote:
In multi_array's reference manual, Table 2,
the three links in the sentence
Otherwise it models _Random Access Traversal Iterator_,
_Readable Iterator_, and _Writable Iterator_.
seem to be broken.
Thanks for the note. Those links refer to
Paul Mensonides wrote:
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
You have a point, here. I'll look into the issue tonight.
Don't bother. What Hugo is doing is a sketchy use of the mechanism
precisely because of this type of problem. Even if you efine a
Considering what we've seen in the recent thread
BOOST_STATIC_CONSTANT and VC++ enums, I thought to add a warning for
VC++ users in the config docs. Also, there's a note saying
Note that in the above example value will have different
lvalueness, depending on whether the compiler supports
At 04:25 PM 1/24/2003, Jeffrey Yasskin wrote:
Just out of curiosity, which boost libraries are likely to be proposed to
the committee?
See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html
--Beman
___
Unsubscribe other changes:
At 04:50 PM 1/24/2003, Gennaro Prota wrote:
On Fri, 24 Jan 2003 10:43:28 -0500, Beman Dawes [EMAIL PROTECTED]
wrote:
A full proposal must include proposed wording for the actual
standardese
to go in the TR, as well as the usual supporting material. (Note that
the
committee may not act on the
At 04:28 PM 1/24/2003, Peter Dimov wrote:
From: Beman Dawes [EMAIL PROTECTED]
I've run the Win32 tests again, so you can see the new results.
One thing that I notice is that tests that are no longer in the Jamfile
are
kept in the table; for example, enable_shared_from_this_test.cpp is still
Michel André said:
Is it settled wether there will be some kind of portable id
(preferably streamable) i often put thread ids in log file entries.
Yes, though I'm still debating about whether or not the id will be
seperate from the boost::thread class itself. The current CVS state
has both.
Ok! Actually the only reason for me to want the old style is that it
will take longer for me to adopt 1.30 and later because I would have to
convince my CM guys to remake install and packaging, but thats more of a
political hurdle than a technical one. So it's ok. The only nitpick is
that
Howard Hinnant [EMAIL PROTECTED] writes:
On Saturday, January 25, 2003, at 08:39 AM, Peter Dimov wrote:
if(false) foo(B());
Is this undefined too?
shrug That's the way I read 5.2.2/7. I see little
difference between that example and:
class B
{
int foo();
};
int main()
{
Hello,
I was wondering whether anybody has any tips to fight code-bloat on GCC. I'm
using the MPL in rather 'extravagant' ways, and I have object files from 4
to 6 mb, and a final executable that is 16 mb. My object files and
executable using the Intel compiler and MSVC are a lot smaller (ca. 300
Jaap Suter [EMAIL PROTECTED] writes:
Hello,
I was wondering whether anybody has any tips to fight code-bloat on GCC. I'm
using the MPL in rather 'extravagant' ways, and I have object files from 4
to 6 mb, and a final executable that is 16 mb. My object files and
executable using the Intel
Try turning off debug symbols; GCC spends a long time and a lot of
disk generating them.
Thanks, works excellent! In fact, my GCC object files and executables are
the smallest now.
I was under the assumption that the -O3 option (full optimization) would
remove the debug information. Sorry for
36 matches
Mail list logo
