Guillaume Melquiond [EMAIL PROTECTED] writes:
| In the case of a 1-dimension space, connected and convex set are
| equals: they are segments (or half-line or line or empty). Date
| manipulated by the date-time library are in a 1-dimension space (the
| real line) and periods are segments
Jeff Garland [EMAIL PROTECTED] writes:
| On 18 Aug 2003 11:43:26 +0200, Gabriel Dos Reis wrote
| Guillaume Melquiond [EMAIL PROTECTED] writes:
|
| | In the case of a 1-dimension space, connected and convex set are
| | equals: they are segments (or half-line or line or empty). Date
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes:
| how about span ?
when read as the period of time spanned by these two, I can make
sense of it, even not as a mathematician :-)
Well, I don't know how it sounds to native speakers.
-- Gaby
___
Beman Dawes [EMAIL PROTECTED] writes:
| At 03:18 PM 8/18/2003, Victor A. Wagner, Jr. wrote:
|
| At Monday 2003-08-18 11:39, you wrote:
| Victor A. Wagner, Jr. [EMAIL PROTECTED] writes:
|
| | how about span ?
|
| when read as the period of time spanned by these two, I can make
| sense
[EMAIL PROTECTED] (Joerg Walter) writes:
[...]
| This whole thing (-fabi-version) is messy. It is what one gets by
| taking users for beta testers ;-)
|
| That's not the whole story. When testing with GCC 3.3.1 prerelease I noticed
| that setting -fabi-version isn't necessary anymore. So I
Beman Dawes [EMAIL PROTECTED] writes:
| At 07:02 PM 8/10/2003, Gabriel Dos Reis wrote:
|
| More seriously, did you have a chance to test GCC-3.3.1?
|
| I just tested 3.3.1 on Windows, and the 7 ublas tests which had been
| failing on 3.3 are now passing. The variant libraries variant_test4
Beman Dawes [EMAIL PROTECTED] writes:
| Current GCC and Intel compilers don't appear to allow using
| declarations at function scope, according to a bug report.
As far as I can tell, only versions of GCC pre 3.0 ignored using
declarations in function templates.
Which versions of GCC are you
[EMAIL PROTECTED] writes:
| En réponse à Gabriel Dos Reis [EMAIL PROTECTED]:
|
| [snip]
|
| | On a more general side, please keep in mind that *signaling* NaNs are meant to
| | trap when used (used can be a simple copy, the standard leaves it
| | implementation-defined).
|
| They trap
Fernando Cacciola [EMAIL PROTECTED] writes:
| |
| | What don't you understand in the expression isnan is a private function?
|
| What being private has to do with being trapping or not?
|
| Guillaume point is that this isnan(), being an implementation
| detail, is known to never recieve a sNAN,
[EMAIL PROTECTED] writes:
| Sorry for the late reply, I was enjoying some peaceful holidays.
There is no reason for sorrying.
| En réponse à Gabriel Dos Reis [EMAIL PROTECTED]:
|
| Guillaume Melquiond [EMAIL PROTECTED] writes:
|
| | On Fri, 4 Jul 2003, Fernando Cacciola wrote
[EMAIL PROTECTED] writes:
| En réponse à Gabriel Dos Reis [EMAIL PROTECTED]:
|
| [snip]
|
| | We are speaking about quiet NaNs here. And so I
| | was justifying why the interval library computes v != v in order to
| | detect quiet NaNs. I never intended to speak about signaling NaNs
Paul A. Bristow [EMAIL PROTECTED] writes:
| Thanks but this still leaves me feeling that there is a need for a
| 'Standard and Portable' way of indicating 'missing value',
sorry if I sounded negative, that wasn't the intent. I would to make
sure we all undertsand and agree on what is going on.
Paul A. Bristow [EMAIL PROTECTED] writes:
| | Signalling NaNs are used to indicate missing initialization values.
|
| This is OK for catching missing initialization by mistake - but not
| for OK for deliberately missing because there really is no value
| (measurement missing).
There is not
[EMAIL PROTECTED] (Joerg Walter) writes:
| - Original Message -
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| To: Boost mailing list [EMAIL PROTECTED]
| Sent: Monday, June 30, 2003 12:06 PM
| Subject: Re: [boost] Compiler status for GCC 3.3
|
|
| [...]
|
| | I'm not sure about
Beman Dawes [EMAIL PROTECTED] writes:
| At 02:44 AM 7/3/2003, Giovanni Bajo wrote:
|
| On Friday, July 04, 2003 12:38 AM [GMT+1=CET],
| David Abrahams [EMAIL PROTECTED] wrote:
|
| On the other hand if your native compiler is GCC and your system was
| not configured with that setting,
Guillaume Melquiond [EMAIL PROTECTED] writes:
| On Fri, 4 Jul 2003, Fernando Cacciola wrote:
|
| Gabriel Dos Reis [EMAIL PROTECTED] wrote in message
| news:[EMAIL PROTECTED]
| jvd [EMAIL PROTECTED] writes:
|
| | Dear boosters,
| |
| | seems like this code
| |
| | template
Fernando Cacciola [EMAIL PROTECTED] writes:
[...]
| Most compilers provide a non standard extension for this purpose.
| For instance, Borland uses _isnan.
| In general, these extensions are found on float.
|
| In fact, since it is not specified by the C++ standard, isnan comes from
|
Guillaume Melquiond [EMAIL PROTECTED] writes:
| On Sat, 5 Jul 2003, Fernando Cacciola wrote:
|
| Thanks to Gabriel we may have an is_nan() right now.
| Is there anything else that the interval library uses which might be better
| packed as a compiler-platform specific routine?
|
| All the
Paul A. Bristow [EMAIL PROTECTED] writes:
| I think this would be excellent (and overdue). It needs to support double and
| long double (and facilitate UDTs too if possible).
|
| There is also the matter of signalling and quiet NaN. Although signalling NaN
| may cause an hardware exception if
Joel de Guzman [EMAIL PROTECTED] writes:
| Fernando Cacciola [EMAIL PROTECTED] wrote:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote in
|
| Yes. It is an incorrect (unfortunately popular)
| implementation.
|
| Right. We should say that more often. It is incorrect
| however popular
Guillaume Melquiond [EMAIL PROTECTED] writes:
| On 4 Jul 2003, Gabriel Dos Reis wrote:
|
| Toon Knapen [EMAIL PROTECTED] writes:
|
| | seems like this code
| |
| | template typename T
| | bool is_nan( const T v )
| | {
| | return std::numeric_limitsT
Ben Woodhead [EMAIL PROTECTED] writes:
| Hello
|
| Was this -fabi-version flag just there for testing different version or do
| users have to know about this?
The latter. It is a documented flag, primarily designed for packagers
and/or distributors.
| Could you test the compiler version and
Howard Hinnant [EMAIL PROTECTED] writes:
| Another possible spelling for this animal is:
|
| class nat {nat();};
|
| Inspired from nan. In this case means Not A Type.
Ahem, a class is a type, no matter how you name it.
| It is nice and
| short which comes in handy for when there are a lot of
Howard Hinnant [EMAIL PROTECTED] writes:
| On Sunday, July 13, 2003, at 12:17 PM, Gabriel Dos Reis wrote:
|
| Howard Hinnant [EMAIL PROTECTED] writes:
|
| | Another possible spelling for this animal is:
| |
| | class nat {nat();};
| |
| | Inspired from nan. In this case means Not A Type
jvd [EMAIL PROTECTED] writes:
| Dear boosters,
|
| seems like this code
|
| template typename T
| bool is_nan( const T v )
| {
| return std::numeric_limitsT::has_quiet_NaN (v != v);
| }
|
| does not work correctly on some machines.
Yes. It is an incorrect
Toon Knapen [EMAIL PROTECTED] writes:
| seems like this code
|
| template typename T
| bool is_nan( const T v )
| {
| return std::numeric_limitsT::has_quiet_NaN (v != v);
| }
|
| does not work correctly on some machines.
|
| Could you be more specific. On
[EMAIL PROTECTED] (Joerg Walter) writes:
| - Original Message -
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| To: Boost mailing list [EMAIL PROTECTED]
| Sent: Monday, June 30, 2003 3:55 AM
| Subject: Re: [boost] Compiler status for GCC 3.3
|
|
| Beman Dawes [EMAIL PROTECTED] writes
Beman Dawes [EMAIL PROTECTED] writes:
[...]
| But some of the problems are clearly GCC bugs. For example, all the
| ublas tests are failing with this message:
|
| ...error: due to a defect in the G++ 3.2 ABI, G++ has assigned the
| same mangled name to two different types...
:-(
Indeed, a
Jason House [EMAIL PROTECTED] writes:
[...]
| Well, *practical* can mean a number of things to different people.
| Maybe performance constraints should be template parameters with default
| values?
Once, you have defined meaning for perfomance and workable proposal
I'd be glad to consider it.
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| g++ -g -O -W -Wall -Winline -c signal_base.ii
| ../../../../boost/boost/function/function_template.hpp: In constructor
| `
|boost::signals::detail::signal_base_impl::signal_base_impl(const
|boost::function2bool, boost::any, boost::any,
|
Ken Hagan [EMAIL PROTECTED] writes:
| Alexander Terekhov wrote:
|
| Uhmm. In return, I venture to suggest that MS-TLS can and shall be
| characterized as ``utterly busted.''
|
| Fine, but the OP asked about existing practice and the bugs
| don't change the fact that k can be a template
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| | OK, whatever. I guess I should've said that you can instantiate a
| | template on k with sensible results. Whether or not you want to call
| | it a constant is another semantic matter. I'd call
Ken Hagan [EMAIL PROTECTED] writes:
| I could write...
|
| int fk() { return k; }
|
| and re-cast my template to expect a pointer to function and then
| write Cfk. This is perfectly legal under the current language
| rules, and gives a type whose behaviour depends on the thread that
| is
David Abrahams [EMAIL PROTECTED] writes:
| Alexander Terekhov [EMAIL PROTECTED] writes:
|
| David Abrahams [EMAIL PROTECTED] writes:
|
| | I disagree with your conclusion. As I've said elsewhere, k can be a
| | compile-time constant in the same way that X::k is a compile-time
| |
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| David Abrahams [EMAIL PROTECTED] writes:
|
| | Gabriel Dos Reis [EMAIL PROTECTED] writes:
| |
| | However, my point is that
| |
| |* a class is closed: that is, by the time you put the closing
David Abrahams [EMAIL PROTECTED] writes:
| I disagree with your conclusion. As I've said elsewhere, k can be a
| compile-time constant in the same way that X::k is a compile-time
| constant.
Certainly, you've said that. But that assertion by itself does not
constitute a proof of the
Alexander Terekhov [EMAIL PROTECTED] writes:
| Ken Hagan wrote:
|
| [ ... k ... ]
|
| So presumably we are all now in complete agreement, except perhaps
|
| I, for one, believe strongly that k is nothing but
|
| static_casttypeof(k)*(pthread_getspecific(__k_key));
|
| It *isn't* a
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| Ken Hagan [EMAIL PROTECTED] writes:
|
| | Peter Dimov wrote:
| |
| | k does not exist yet at compile-time (in a pointer to int form), when
| | templates are instantiated.
| |
| | It doesn't have
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| David Abrahams [EMAIL PROTECTED] writes:
|
| | Let me reiterate, just in case somebody missed it: this is a similar
| | problem to that of using a pointer/reference-to-data-member as a
| | template
Ken Hagan [EMAIL PROTECTED] writes:
| Peter Dimov wrote:
|
| k does not exist yet at compile-time (in a pointer to int form), when
| templates are instantiated.
|
| It doesn't have to. We're instantiating a template, not calling a
| function, so if k has the type pointer to thread-local int
Joel de Guzman [EMAIL PROTECTED] writes:
| Hi,
|
| I'm not sure if you are aware of this but g++ 2.95.3 cannot
| handle the casts:
|
| g++ 2.95.3 [no STLport]
| C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr'
|not supported
| by dump_expr
This means that
Dave Abrahams [EMAIL PROTECTED] writes:
| On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET],
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| Joel de Guzman [EMAIL PROTECTED] writes:
|
| Hi,
|
| I'm not sure if you are aware of this but g++ 2.95.3 cannot
| handle the casts:
|
| g
David B. Held [EMAIL PROTECTED] writes:
| [...]
| templatetypename T
| Vec = std::vectorT, MyAllocT ;
|
| This looks cool! Is someone going to write a proposal for this before
| April?
Yes, I'll do.
| Or does this type of change not get considered at that time?
Well, the notion
David B. Held [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| [...]
| More accurately, there are *two* notions being considered:
|
| 1) typedef template;
| 2) template aliasing -- the thing
Terje Slettebø [EMAIL PROTECTED] writes:
| From: Gabriel Dos Reis [EMAIL PROTECTED]
|
| What I find confusing about the current rule is that it makes an
| exception for integral type const static data member. I think the old
| rule was less irregular.
|
| (Strangely enought, for long time
Gennaro Prota [EMAIL PROTECTED] writes:
| On 12 Jan 2003 10:49:09 +0100, Gabriel Dos Reis
| [EMAIL PROTECTED] wrote:
|
| I believe that that sentence may have been in the first printings of
| TC++PL3 [at the time, I got the third printing, which someone managed
| to steel :-(]
|
| Here are his
Paul Mensonides [EMAIL PROTECTED] writes:
[...]
| However, this
| raises another interesting problem. Many enumerations used for this purpose
| are unnamed:
|
| templateclass T struct is_ptr {
| enum { value = false };
| };
|
|
Gennaro Prota [EMAIL PROTECTED] writes:
| On 09 Jan 2003 18:02:51 +0100, Gabriel Dos Reis
| [EMAIL PROTECTED] wrote:
|
| So you propose that the presence/absence of an initializer turns an
| expression designating a static data member into an rvalue or lvalue?
|
| I can't speak
Daniel Frey [EMAIL PROTECTED] writes:
| Yes, a smarter compiler may do better, but such smarter compilers are
| quite rare :-)
| Yes, the thingy ends up in the link map (as a local symbol).
|
| Just to make sure: Do you vote in favor of enums?
I'm a long term pro-enum (mostly because for the
Gennaro Prota [EMAIL PROTECTED] writes:
| On 09 Jan 2003 15:29:30 +0100, Gabriel Dos Reis
| [EMAIL PROTECTED] wrote:
|
| I'm a long term pro-enum (mostly because for the meta programming
| stuff I had to do, it works very well), but I do understand the
| potential drawbacks raised by the pro
David B. Held [EMAIL PROTECTED] writes:
[...]
| 2) Under what circumstances is the following equivalent to the
| above:
|
| reinterpret_castT*(p);
One of the issues that distinguishly arose during this disucssion is
whether
reinterpret_castvoid*(ptr)
is well-formed. (My compilers don't
Gennaro Prota [EMAIL PROTECTED] writes:
[...]
| If void* is not a pointer to an object then reinterpret_castvoid*
| is invalid. Otherwise it just yields an undefined result. I haven't
| found a definition of pointer to object in the standard; anyhow
| certainly void is not an object type.
void*
Gennaro Prota [EMAIL PROTECTED] writes:
[...]
| I haven't
| | found a definition of pointer to object in the standard; anyhow
| | certainly void is not an object type.
|
| void* is the generic type of pointer to object.
|
| Well, as I said I don't find any definition of the expression pointer
Eric Woodruff [EMAIL PROTECTED] writes:
[...]
| Here's a question: Since h.storage is _meant_ to be accessed by those that
| do not know the type of the object inside, shouldn't it have been designed
I'm afraid the above is not an accurate description of the purpose of
holderT.
One primary
Hi,
Anthony Williams [EMAIL PROTECTED] writes:
[...]
| You made youself clear.
|
| However, there are two running issues originating from a claim of Dave
| that dangerous_cast might be better than reinterpret_cast in
| casting from U* to T* (dangerous_cast uses the intermediate step
Eric Woodruff [EMAIL PROTECTED] writes:
[...]
| Thus, given that h.storage is properly aligned, (which is the purpose of
| the
| other union member), after new(h.storage) Foo, h.storage contains a Foo
| object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the
| dynamic type
Gennaro Prota [EMAIL PROTECTED] writes:
[...]
| Well, in fact those subsequent paragraphs intentionally give very few
| guarantee, and reinterpret_castvoid* is exactly one of the cases
| which are left unspecified (the guarantee of 5.2.10/7 concerns casting
| to pointers to *object types*). So I
Gennaro Prota [EMAIL PROTECTED] writes:
| --- Gabriel Dos Reis [EMAIL PROTECTED] wrote:
| Gennaro Prota [EMAIL PROTECTED] writes:
|
| [...]
|
| | Well, in fact those subsequent paragraphs intentionally give very few
| | guarantee, and reinterpret_castvoid* is exactly one of the cases
David B. Held [EMAIL PROTECTED] writes:
| Does this have any merit whatsoever?
|
| template typename T, typename U
| T* dangerous_cast(U* p)
| {
| return static_castT*(static_castvoid*(p));
| }
Is it any different from reinterpret_castT*(p) ?
-- Gaby
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| David B. Held [EMAIL PROTECTED] writes:
|
| | Does this have any merit whatsoever?
| |
| | template typename T, typename U
| | T* dangerous_cast(U* p)
| | {
| | return static_castT
Eric Woodruff [EMAIL PROTECTED] writes:
| [snip]
|
| holderFoo h;
| new (h.storage) Foo;
|
| What is the meaning of that syntax?
placement-new: Construct a Foo at h.storage.
-- Gaby
___
Unsubscribe other changes:
David B. Held [EMAIL PROTECTED] writes:
| Because you want to get at the T in h in a portable way. Which brings
| me to my next point. Since it seems this is the only context in which this
| cast is guaranteed to give a meaningful result, maybe it should be called
| placement_cast?
But then,
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| Hmm, I have a couple of questions answers to which will help me
| get your point.
|
| 1) Why can't you do that with reinterpret_cast?
|
| You can, but the results are non-portable
No more non
Peter Dimov [EMAIL PROTECTED] writes:
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| David Abrahams [EMAIL PROTECTED] writes:
|
| | Gabriel Dos Reis [EMAIL PROTECTED] writes:
| |
| | Hmm, I have a couple of questions answers to which will help me
| | get your point.
| |
| | 1) Why
David B. Held [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| David Abrahams [EMAIL PROTECTED] writes:
|
| | [...]
| | if is_pointersource_type and is_pointerdest_type
| | return (d
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| Thanks for your patience.
|
| Now, imagine an implementation where the original type is remembered,
| then dereferencing the pointer obtained from
|
| char* - void* - T*
|
| may just eject you
David Abrahams [EMAIL PROTECTED] writes:
| [I actually wonder if we shouldn't add that flag to the GCC
| toolset. That seems like a nuisance warning for Boost code]
Same for the standard library implementation shipped with GCC itself.
-- Gaby
___
67 matches
Mail list logo
