> 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
"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
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
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
>> 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
>>
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
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
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: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:
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
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
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
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
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
--- 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
--- 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.
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
>> 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 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
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 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
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
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
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: "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,
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
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::
> 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
> > 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
> 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
> 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 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
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
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 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),
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
36 matches
Mail list logo
