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_convertible 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 copy&paste
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
>http://gr
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
> 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
> Error : illegal access from 'B' to protected/private member
> 'B::B(const B &)'
> (instantiating: 'Metrowerks::is_convertible')
> msl_utility line 472 tatic const bool value =
> sizeof(is_convertible_helper::test(make())) == 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
> 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 gener
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
>struct is_random_access_iterator
>{
>private:
> typedef typename std::iterator_traits::
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 ch
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,
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,
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
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
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_conv
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 fr
>> 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 thorn
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 un
--- 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.
--- 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
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: http://list
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 ass
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
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 efi
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: http:
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
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
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
>> 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
>>
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?
>
> That's the way I read 5.2.2/7. I see little
> difference between that example and:
>
> class B
> {
> int foo();
> };
>
> in
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 th
> 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 fo
36 matches
Mail list logo
