Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| I really miss formality in the standard. Even answering a simple
| question like: "is static_cast(-1) guaranteed to give
| UINT_MAX on all conforming implementations?" is quite a project.
How so?
-- Gaby
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
___
Uns
"David B. Held" <[EMAIL PROTECTED]> writes:
| Does this have any merit whatsoever?
|
| template
| T* dangerous_cast(U* p)
| {
| return static_cast(static_cast(p));
| }
Is it any different from reinterpret_cast(p) ?
-- Gaby
___
Unsubscribe & other
David Abrahams <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > "David B. Held" <[EMAIL PROTECTED]> writes:
| >
| > | Does this have any merit whatsoever?
| > |
| > | template
| > | T* dangerous_cast(U* p)
| &g
David Abrahams <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > David Abrahams <[EMAIL PROTECTED]> writes:
| >
| > | Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| > |
| > | > "David B. Held" <[EMAIL PROTECT
"Eric Woodruff" <[EMAIL PROTECTED]> writes:
| [snip]
|
| > holder h;
| > new (h.storage) Foo;
|
| What is the meaning of that syntax?
placement-new: Construct a Foo at h.storage.
-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailma
Terje Slettebø <[EMAIL PROTECTED]> writes:
| >From: "Terje Slettebø" <[EMAIL PROTECTED]>
|
| > >From: "David Abrahams" <[EMAIL PROTECTED]>
| >
| > > Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| > >
| > > > Is it a
"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 th
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
"David B. Held" <[EMAIL PROTECTED]> writes:
| "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
| asli92$oqn$[EMAIL PROTECTED]">news:asli92$oqn$[EMAIL PROTECTED]...
| > [...]
| > > > > holder h;
| > > > > new (h.storage) Foo;
| > [...]
| > So the type really is of Foo,
| > [...]
|
| No, the ty
David Abrahams <[EMAIL PROTECTED]> writes:
| "Eric Woodruff" <[EMAIL PROTECTED]> writes:
|
| > "David B. Held" <[EMAIL PROTECTED]> wrote in message
| > aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]...
| >> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
| >> aslbsn$nt3$[EMA
Terje Slettebø <[EMAIL PROTECTED]> writes:
| >From: "Gabriel Dos Reis" <[EMAIL PROTECTED]>
|
| > Terje Slettebø <[EMAIL PROTECTED]> writes:
| >
| > | >From: "Terje Slettebø" <[EMAIL PROTECTED]>
| > |
| > | > >From: "Da
"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
"David B. Held" <[EMAIL PROTECTED]> writes:
| "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| > [...]
| > What do mean exactly by a "valid Foo*"?
|
| Hmm...I think 5.2.10/7 is m
David Abrahams <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > David Abrahams <[EMAIL PROTECTED]> writes:
| >
| > | "Eric Woodruff" <[EMAIL PROTECTED]> writes:
| > |
| > | > "David B. Held" <[EMAIL
"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
"David B. Held" <[EMAIL PROTECTED]> writes:
| "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| > [...]
| > What do mean exactly by a "valid Foo*"?
|
| I mean that reinterpret_cast<&
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
| >
| >ch
Hi,
Anthony Williams <[EMAIL PROTECTED]> writes:
[...]
| 3.10p15:
| "If a program attempts to access the stored value of an object through an
| lvalue of other than one of the following types the behavior is undefined:
|
| - the dynamic type of the object,
|
| ...
|
| - a char or u
Anthony Williams <[EMAIL PROTECTED]> writes:
| > Anthony Williams <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | 3.10p15:
| > | "If a program attempts to access the stored value of an object through an
| > | lvalue of other than one of the following types the behavior is undefine
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 inter
"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
| > dyn
"Eric Woodruff" <[EMAIL PROTECTED]> writes:
| "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| > "Eric Woodruff" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | >
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| Well, in fact those subsequent paragraphs intentionally give very few
| guarantee, and reinterpret_cast 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 gue
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 re
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| If void* is not a "pointer to an object" then reinterpret_cast
| 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 expressi
"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
holder.
One primary
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| > | In any case, do you agree that at least the
| > | result is unspecified?
| >
| > I don't think I agree with this part; at least if it means anything
| > other that converting a Foo* to void*.
|
| Well, then I don't think we can establish "th
I'll raise the issue the committee reflector.
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| > | char * p = ...
| > | reinterpret_cast(p)
| > |
| > | is illegal, because the sentence above talks about conversion to *a
| > | different* type. And the conversions that are not listed cannot
"David B. Held" <[EMAIL PROTECTED]> writes:
[...]
| 2) Under what circumstances is the following equivalent to the
| above:
|
| reinterpret_cast(p);
One of the issues that distinguishly arose during this disucssion is
whether
reinterpret_cast(ptr)
is well-formed. (My compilers don't reje
David Abrahams <[EMAIL PROTECTED]> writes:
| Terje Slettebø <[EMAIL PROTECTED]> writes:
|
| > Static constant members are lvalues. So, if you have a declaration such as
| >
| > void foo(int const&);
| >
| > and you pass it the result of a metaprogram
| >
| > foo(Pow3<7>::result);
| >
| > a compil
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 f
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
| >potenti
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
[...]
| However, this
| raises another interesting problem. Many enumerations used for this purpose
| are unnamed:
|
| template struct is_ptr {
| enum { value = false };
| };
|
| templat
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?
| >
| &
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 irr
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
"Peter Dimov" <[EMAIL PROTECTED]> writes:
[...]
| By the way, the current typedef template proposal prohibits deduction; this
| makes it less attractive for creating subpointers.
More accurately, there are *two* notions being considered:
1) typedef template;
2) template aliasing -- the th
David Abrahams <[EMAIL PROTECTED]> writes:
| "David B. Held" <[EMAIL PROTECTED]> writes:
|
| > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
| > 000d01c2c6f3$85038c30$1d00a8c0@pdimov2">news:000d01c2c6f3$85038c30$1d00a8c0@pdimov2...
| >> [...]
| >> By the way, the current typedef template pro
"David B. Held" <[EMAIL PROTECTED]> writes:
| "Beman Dawes" <[EMAIL PROTECTED]> wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| > [...]
| > Anyone interested might want to read the actual proposal. See
| > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1406.pdf
|
| Yes, I
David Abrahams <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > David Abrahams <[EMAIL PROTECTED]> writes:
| >
| > | "David B. Held" <[EMAIL PROTECTED]> writes:
| > |
| > | > "Peter Dimov" <
David Abrahams <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > "David B. Held" <[EMAIL PROTECTED]> writes:
| >
| > | "Beman Dawes" <[EMAIL PROTECTED]> wrote in message
| > | [EMAIL PROTECTED]">n
"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
"David B. Held" <[EMAIL PROTECTED]> writes:
| > [...]
| > template
| >Vec = std::vector >;
|
| 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 of "template
"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 tha
Vladimir Prus <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis 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++ 2.95.3 [no STLport]
| &g
"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 s
"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-
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
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
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
| > | >
| &
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 well-fo
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_cast(pthread_getspecific(__k_key));"
|
| It *isn't* a compile
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 comp
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
"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 C<&fk>. This is perfectly legal under the current language
| rules, and gives a type whose behaviour depends on the thread that
|
"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 templa
"Ken Hagan" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >
| > This analgoy does not cut it: You don't have a function "fk" by
| > thread. You have a -single- function designator. And the return
| > value depends on the calling thread.
"Thorsten Ottosen" <[EMAIL PROTECTED]> writes:
| 4. The code implement poor mans partial specialization to enable the
| container_traits to work with buggy compilers; so far so good; however,
| many compilers cannot even do partial ordering of function templates
| which is a real pain in the *
[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::function2 >&)':
| ../../../../boost/boost/f
"Paul A. Bristow" <[EMAIL PROTECTED]> writes:
| Indeed, I doubt if long double is practically useful for many applications -
| even 16 decimal place 64-bit double will be impracticable on MSVC where there
| isn't really a long double (you may need to use 80-bit calculations to get a
| 64-bit accur
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 i
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 b
[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
|
|
|
"jvd" <[EMAIL PROTECTED]> writes:
| Dear boosters,
|
| seems like this code
|
| template< typename T >
| bool is_nan( const T& v )
| {
| return std::numeric_limits::has_quiet_NaN && (v != v);
| }
|
| does not work correctly on some machines.
Yes. It is an incorrect (un
"Toon Knapen" <[EMAIL PROTECTED]> writes:
| > seems like this code
| >
| > template< typename T >
| > bool is_nan( const T& v )
| > {
| > return std::numeric_limits::has_quiet_NaN && (v != v);
| > }
| >
| > does not work correctly on some machines.
|
| Could you be more
[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
|
|
| [
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
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:
| > >
| > > |
"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 .
| >
| > 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 th
"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 sho
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_
"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 an
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 o
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();};
| > |
| > | Inspi
"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
"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
[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, Fe
[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 s
[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
| >
"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 recie
[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 vari
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 us
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 (non-emp
"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
"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
91 matches
Mail list logo
