Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Jonathan Wakely 

On 07/10/14 21:10 +0200, Andreas Schwab wrote:

That cannot work.  std::__convert_from_v always passes __prec before
__v, but the format is %a.


Ah yes. I'm testing this fix now.

commit 543771e2db1642715854ae4bec81d803ca8e2e59
Author: Jonathan Wakely jwak...@redhat.com
Date:   Wed Oct 8 10:39:27 2014 +0100

	* include/bits/locale_facets.tcc (num_put::_M_insert_float): Do not
	pass precision when using hexfloat format.
	* src/c++98/locale_facets.cc (__num_base::_S_format_float): Always
	output precision if C99 hexfloat conversion specifiers not available.

diff --git a/libstdc++-v3/include/bits/locale_facets.tcc b/libstdc++-v3/include/bits/locale_facets.tcc
index cf12a08..88adc0d 100644
--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -988,20 +988,32 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
 	__num_base::_S_format_float(__io, __fbuf, __mod);
 
 #ifdef _GLIBCXX_USE_C99
+	// Precision is always used except for hexfloat format.
+	const bool __use_prec =
+	  (__io.flags()  ios_base::floatfield) != ios_base::floatfield;
+
 	// First try a buffer perhaps big enough (most probably sufficient
 	// for non-ios_base::fixed outputs)
 	int __cs_size = __max_digits * 3;
 	char* __cs = static_castchar*(__builtin_alloca(__cs_size));
-	__len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
-  __fbuf, __prec, __v);
+	if (__use_prec)
+	  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+	__fbuf, __prec, __v);
+	else
+	  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+	__fbuf, __v);
 
 	// If the buffer was not large enough, try again with the correct size.
 	if (__len = __cs_size)
 	  {
 	__cs_size = __len + 1;
 	__cs = static_castchar*(__builtin_alloca(__cs_size));
-	__len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
-	  __fbuf, __prec, __v);
+	if (__use_prec)
+	  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+	__fbuf, __prec, __v);
+	else
+	  __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+	__fbuf, __v);
 	  }
 #else
 	// Consider the possibility of long ios_base::fixed outputs
diff --git a/libstdc++-v3/src/c++98/locale_facets.cc b/libstdc++-v3/src/c++98/locale_facets.cc
index 7ed04e6..b3ca5dc 100644
--- a/libstdc++-v3/src/c++98/locale_facets.cc
+++ b/libstdc++-v3/src/c++98/locale_facets.cc
@@ -71,7 +71,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 ios_base::fmtflags __fltfield = __flags  ios_base::floatfield;
 
+#ifdef _GLIBCXX_USE_C99
+// Precision is always used except for hexfloat format.
 if (__fltfield != (ios_base::fixed | ios_base::scientific))
+#endif
   {
 // As per DR 231: not only when __flags  ios_base::fixed || __prec  0
 *__fptr++ = '.';

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Rainer Orth 
Jonathan Wakely jwak...@redhat.com writes:

 On 28/03/14 08:56 +0900, Luke Allardyce wrote:
It looks like the new standard also requires the precision to be
ignored for hexfloat

For conversion from a floating-point type, if floatfield !=
 (ios_base::fixed | ios_base:: scientific), str.precision() is specified
 as precision in the conversion specification. Otherwise, no precision is
 specified.

 I've made this change and adjusted the test so that it doesn't make
 any assumptions about the exact format of hexadecimal float output, as
 it's unspecified whether you get e.g. 0x1.ep+3 or 0xfp+0 for 15.

 As Luke pointed out, this changes the behaviour of some valid C++03
 programs, but I think that's the right thing to do in this case. I'll
 document that in the release notes.

 Tested x86_64-linux, committed to trunk.

On Solaris 11 (both SPARC and x86), the test execution FAILs:

Assertion failed: os  std::stod(os.str()) == d, file 
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc,
 line 51, function test01
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test

With -DTEST_NUMPUT_VERBOSE, I get

got: 0x1.0p-1074

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Jonathan Wakely 

On 08/10/14 13:27 +0200, Rainer Orth wrote:

On Solaris 11 (both SPARC and x86), the test execution FAILs:

Assertion failed: os  std::stod(os.str()) == d, file 
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc,
 line 51, function test01
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test

With -DTEST_NUMPUT_VERBOSE, I get

got: 0x1.0p-1074


Thanks, I'll look into that too.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Jonathan Wakely 

On 08/10/14 11:07 +0100, Jonathan Wakely wrote:

On 07/10/14 21:10 +0200, Andreas Schwab wrote:

That cannot work.  std::__convert_from_v always passes __prec before
__v, but the format is %a.


Ah yes. I'm testing this fix now.


Committed.

I assume it was working for me because __convert_from_v(%a, 6, 272.)
happens to pass the double differently from the integer, and vsnprintf
looks for a double in the relevant register and ignores the integer
argument.



commit 543771e2db1642715854ae4bec81d803ca8e2e59
Author: Jonathan Wakely jwak...@redhat.com
Date:   Wed Oct 8 10:39:27 2014 +0100

* include/bits/locale_facets.tcc (num_put::_M_insert_float): Do not
pass precision when using hexfloat format.
* src/c++98/locale_facets.cc (__num_base::_S_format_float): Always
output precision if C99 hexfloat conversion specifiers not available.

diff --git a/libstdc++-v3/include/bits/locale_facets.tcc 
b/libstdc++-v3/include/bits/locale_facets.tcc
index cf12a08..88adc0d 100644
--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -988,20 +988,32 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
__num_base::_S_format_float(__io, __fbuf, __mod);

#ifdef _GLIBCXX_USE_C99
+   // Precision is always used except for hexfloat format.
+   const bool __use_prec =
+ (__io.flags()  ios_base::floatfield) != ios_base::floatfield;
+
// First try a buffer perhaps big enough (most probably sufficient
// for non-ios_base::fixed outputs)
int __cs_size = __max_digits * 3;
char* __cs = static_castchar*(__builtin_alloca(__cs_size));
-   __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
- __fbuf, __prec, __v);
+   if (__use_prec)
+ __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+   __fbuf, __prec, __v);
+   else
+ __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+   __fbuf, __v);

// If the buffer was not large enough, try again with the correct size.
if (__len = __cs_size)
  {
__cs_size = __len + 1;
__cs = static_castchar*(__builtin_alloca(__cs_size));
-   __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
- __fbuf, __prec, __v);
+   if (__use_prec)
+ __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+   __fbuf, __prec, __v);
+   else
+ __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
+   __fbuf, __v);
  }
#else
// Consider the possibility of long ios_base::fixed outputs
diff --git a/libstdc++-v3/src/c++98/locale_facets.cc 
b/libstdc++-v3/src/c++98/locale_facets.cc
index 7ed04e6..b3ca5dc 100644
--- a/libstdc++-v3/src/c++98/locale_facets.cc
+++ b/libstdc++-v3/src/c++98/locale_facets.cc
@@ -71,7 +71,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

ios_base::fmtflags __fltfield = __flags  ios_base::floatfield;

+#ifdef _GLIBCXX_USE_C99
+// Precision is always used except for hexfloat format.
if (__fltfield != (ios_base::fixed | ios_base::scientific))
+#endif
  {
// As per DR 231: not only when __flags  ios_base::fixed || __prec  0
*__fptr++ = '.';

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Jonathan Wakely 

On 08/10/14 12:37 +0100, Jonathan Wakely wrote:

On 08/10/14 13:27 +0200, Rainer Orth wrote:

On Solaris 11 (both SPARC and x86), the test execution FAILs:

Assertion failed: os  std::stod(os.str()) == d, file 
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc,
 line 51, function test01
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test

With -DTEST_NUMPUT_VERBOSE, I get

got: 0x1.0p-1074


Thanks, I'll look into that too.


I suspect this was the bug Andreas pointed out (which didn't show up
on x86_64-linux)  and so should be fixed now.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Rainer Orth 
Jonathan Wakely jwak...@redhat.com writes:

 On 08/10/14 12:37 +0100, Jonathan Wakely wrote:
On 08/10/14 13:27 +0200, Rainer Orth wrote:
On Solaris 11 (both SPARC and x86), the test execution FAILs:

Assertion failed: os  std::stod(os.str()) == d, file
 /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc,
 line 51, function test01
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution 
test

With -DTEST_NUMPUT_VERBOSE, I get

got: 0x1.0p-1074

Thanks, I'll look into that too.

 I suspect this was the bug Andreas pointed out (which didn't show up
 on x86_64-linux)  and so should be fixed now.

I'd already tried that patch before you committed it, and unfortunately
it didn't help.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Jonathan Wakely 

On 08/10/14 16:21 +0200, Rainer Orth wrote:

I'd already tried that patch before you committed it, and unfortunately
it didn't help.


Oh dear. Did you do a clean build, or at least
'touch libstdc++-v3/src/*/*.cc' to ensure the library sources get
rebuilt?  Changes to headers do not trigger everything to be rebuilt,
because we don't have proper dependencies in the makefiles.

If it's still happening I'll have to hope I can reproduce it on one of
the targets I have access to and debug it there.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-08 Thread Rainer Orth 
Jonathan Wakely jwak...@redhat.com writes:

 On 08/10/14 16:21 +0200, Rainer Orth wrote:
I'd already tried that patch before you committed it, and unfortunately
it didn't help.

 Oh dear. Did you do a clean build, or at least
 'touch libstdc++-v3/src/*/*.cc' to ensure the library sources get
 rebuilt?  Changes to headers do not trigger everything to be rebuilt,
 because we don't have proper dependencies in the makefiles.

Not before, because I didn't realize that the .tcc file is effectively a
header.

 If it's still happening I'll have to hope I can reproduce it on one of
 the targets I have access to and debug it there.

I've now done a clean rebuild (make clean; make) and the failure
remains.

There's been talk about getting Solaris into the compile farm, but I
haven't pursued that yet.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-07 Thread Andreas Schwab 
Jonathan Wakely jwak...@redhat.com writes:

 diff --git a/libstdc++-v3/src/c++98/locale_facets.cc 
 b/libstdc++-v3/src/c++98/locale_facets.cc
 index 3669acb..7ed04e6 100644
 --- a/libstdc++-v3/src/c++98/locale_facets.cc
 +++ b/libstdc++-v3/src/c++98/locale_facets.cc
 @@ -69,19 +69,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  if (__flags  ios_base::showpoint)
*__fptr++ = '#';
  
 -// As per DR 231: _always_, not only when 
 -// __flags  ios_base::fixed || __prec  0
 -*__fptr++ = '.';
 -*__fptr++ = '*';
 +ios_base::fmtflags __fltfield = __flags  ios_base::floatfield;
 +
 +if (__fltfield != (ios_base::fixed | ios_base::scientific))
 +  {
 +// As per DR 231: not only when __flags  ios_base::fixed || __prec 
  0
 +*__fptr++ = '.';
 +*__fptr++ = '*';
 +  }
  
  if (__mod)
*__fptr++ = __mod;
 -ios_base::fmtflags __fltfield = __flags  ios_base::floatfield;
  // [22.2.2.2.2] Table 58
  if (__fltfield == ios_base::fixed)
*__fptr++ = 'f';
  else if (__fltfield == ios_base::scientific)
*__fptr++ = (__flags  ios_base::uppercase) ? 'E' : 'e';
 +#ifdef _GLIBCXX_USE_C99
 +else if (__fltfield == (ios_base::fixed | ios_base::scientific))
 +  *__fptr++ = (__flags  ios_base::uppercase) ? 'A' : 'a';
 +#endif

That cannot work.  std::__convert_from_v always passes __prec before
__v, but the format is %a.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-10-06 Thread Jonathan Wakely 

On 28/03/14 08:56 +0900, Luke Allardyce wrote:

It looks like the new standard also requires the precision to be
ignored for hexfloat


For conversion from a floating-point type, if floatfield != (ios_base::fixed | 
ios_base:: scientific), str.precision() is specified as precision in the 
conversion specification. Otherwise, no precision is specified.


I've made this change and adjusted the test so that it doesn't make
any assumptions about the exact format of hexadecimal float output, as
it's unspecified whether you get e.g. 0x1.ep+3 or 0xfp+0 for 15.

As Luke pointed out, this changes the behaviour of some valid C++03
programs, but I think that's the right thing to do in this case. I'll
document that in the release notes.

Tested x86_64-linux, committed to trunk.
commit 7090c2fca0e3858ea527b66a1eb44fd504f1ba4e
Author: Jonathan Wakely jwak...@redhat.com
Date:   Mon Sep 22 23:10:54 2014 +0100

2014-10-06  Rüdiger Sonderfeld  ruedi...@c-plusplus.de
	Jonathan Wakely  jwak...@redhat.com

	PR libstdc++/59987
	* doc/xml/manual/status_cxx2011.xml: Remove hexfloat from notes.
	* doc/html/manual/status.html: Regenerate.
	* include/bits/ios_base.h (hexfloat): New function.
	(defaultfloat): New function.
	* src/c++98/locale_facets.cc (__num_base::_S_format_float): Support
	hexadecimal floating point format.
	* testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:
	New file.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 5b36556..108de36 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -2131,7 +2131,6 @@ particular release.
   entry
 Missing codeio_errc/code and codeiostream_category/code.
 codeios_base::failure/code is not derived from codesystem_error/code.
-	Missing codeios_base::hexfloat/code.
   /entry
 /row
 row
diff --git a/libstdc++-v3/include/bits/ios_base.h b/libstdc++-v3/include/bits/ios_base.h
index fb448fd..5e33b81 100644
--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -984,6 +984,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 return __base;
   }
 
+#if __cplusplus = 201103L
+  // New C++11 floatfield manipulators
+
+  /// Calls
+  /// base.setf(ios_base::fixed|ios_base::scientific, ios_base::floatfield)
+  inline ios_base
+  hexfloat(ios_base __base)
+  {
+__base.setf(ios_base::fixed | ios_base::scientific, ios_base::floatfield);
+return __base;
+  }
+
+  /// Calls @c base.unsetf(ios_base::floatfield)
+  inline ios_base
+  defaultfloat(ios_base __base)
+  {
+__base.unsetf(ios_base::floatfield);
+return __base;
+  }
+#endif
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
diff --git a/libstdc++-v3/src/c++98/locale_facets.cc b/libstdc++-v3/src/c++98/locale_facets.cc
index 3669acb..7ed04e6 100644
--- a/libstdc++-v3/src/c++98/locale_facets.cc
+++ b/libstdc++-v3/src/c++98/locale_facets.cc
@@ -69,19 +69,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 if (__flags  ios_base::showpoint)
   *__fptr++ = '#';
 
-// As per DR 231: _always_, not only when 
-// __flags  ios_base::fixed || __prec  0
-*__fptr++ = '.';
-*__fptr++ = '*';
+ios_base::fmtflags __fltfield = __flags  ios_base::floatfield;
+
+if (__fltfield != (ios_base::fixed | ios_base::scientific))
+  {
+// As per DR 231: not only when __flags  ios_base::fixed || __prec  0
+*__fptr++ = '.';
+*__fptr++ = '*';
+  }
 
 if (__mod)
   *__fptr++ = __mod;
-ios_base::fmtflags __fltfield = __flags  ios_base::floatfield;
 // [22.2.2.2.2] Table 58
 if (__fltfield == ios_base::fixed)
   *__fptr++ = 'f';
 else if (__fltfield == ios_base::scientific)
   *__fptr++ = (__flags  ios_base::uppercase) ? 'E' : 'e';
+#ifdef _GLIBCXX_USE_C99
+else if (__fltfield == (ios_base::fixed | ios_base::scientific))
+  *__fptr++ = (__flags  ios_base::uppercase) ? 'A' : 'a';
+#endif
 else
   *__fptr++ = (__flags  ios_base::uppercase) ? 'G' : 'g';
 *__fptr = '\0';
diff --git a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
new file mode 100644
index 000..485a485
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
@@ -0,0 +1,152 @@
+// { dg-options -std=gnu++11 }
+
+// 2014-03-27 Rüdiger Sonderfeld
+// test the hexadecimal floating point inserters (facet num_put)
+
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-04-17 Thread Jonathan Wakely 
On 17 April 2014 01:56, Luke Allardyce wrote:
 Thanks, I was wrong about that.

 Then I think we should just bite the bullet and provide the new
 behaviour. If we do have an abi_tag on those types in the next release
 then we can preserve the old behaviour in the old ABI and use the
 C++11 semantics for the abi_tagged type, which will be used for both
 C++03 and C++11 code. I am not too concerned that people who use a
 meaningless modifier in C++03 code get the C++11 behaviour. If they
 really want %g or %G then they shouldn't use fixed|scientific.

 Does that mean abi_tag will be enabled with separate compiler flag /
 define rather than checking against the __cplusplus value?

I'm going to send a mail later on today, but the plan is that it's not
going to depend on __cplusplus at all. That makes it possible to pass
the abi_tagged types between C++03 and C++11 code.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-04-16 Thread Jonathan Wakely 

On 16/04/14 14:26 +0900, Luke Allardyce wrote:

Also the old standard seems to require that ios_base::fixed |
ios_base::scientific (or any other combination) falls through to the
uppercase test; I was trying to use abi_tag for a solution as not only
would two versions of _S_format_float be necessary, but also num_get
due to the pre-instantiated templates for char and wchar, which
led me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60642. It might
just be more trouble than it's worth.


I don't think we need to worry about that, if I understand correctly
the combination of fixed|scientific has unspecified behaviour in
C++03, so we can make our implementation do exactly what it does in
C++11.


It seems to me that it is well defined, going from  [lib.facet.num.put.virtuals]


6 All tables used in describing stage 1 are ordered. That is, the first line 
whose condition is true applies.
A line without a condition is the default behavior when none of the earlier 
lines apply.


So fixed|scientific would be equivalent to specifying neither
according to table 58, and the resulting specifier would be %g or %G
depending on whether uppercase is set or not.


Thanks, I was wrong about that.

Then I think we should just bite the bullet and provide the new
behaviour. If we do have an abi_tag on those types in the next release
then we can preserve the old behaviour in the old ABI and use the
C++11 semantics for the abi_tagged type, which will be used for both
C++03 and C++11 code. I am not too concerned that people who use a
meaningless modifier in C++03 code get the C++11 behaviour. If they
really want %g or %G then they shouldn't use fixed|scientific.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-04-16 Thread Luke Allardyce 
 Thanks, I was wrong about that.

 Then I think we should just bite the bullet and provide the new
 behaviour. If we do have an abi_tag on those types in the next release
 then we can preserve the old behaviour in the old ABI and use the
 C++11 semantics for the abi_tagged type, which will be used for both
 C++03 and C++11 code. I am not too concerned that people who use a
 meaningless modifier in C++03 code get the C++11 behaviour. If they
 really want %g or %G then they shouldn't use fixed|scientific.

Does that mean abi_tag will be enabled with separate compiler flag /
define rather than checking against the __cplusplus value?

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-04-15 Thread Jonathan Wakely 
On 27 March 2014 23:56, Luke Allardyce wrote:
 It looks like the new standard also requires the precision to be
 ignored for hexfloat

For conversion from a floating-point type, if floatfield != (ios_base::fixed 
| ios_base:: scientific), str.precision() is specified as precision in the 
conversion specification. Otherwise, no precision is specified.

Thanks for pointing out that difference. We'll need a test for that.

 Also the old standard seems to require that ios_base::fixed |
 ios_base::scientific (or any other combination) falls through to the
 uppercase test; I was trying to use abi_tag for a solution as not only
 would two versions of _S_format_float be necessary, but also num_get
 due to the pre-instantiated templates for char and wchar, which
 led me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60642. It might
 just be more trouble than it's worth.

I don't think we need to worry about that, if I understand correctly
the combination of fixed|scientific has unspecified behaviour in
C++03, so we can make our implementation do exactly what it does in
C++11.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-04-15 Thread Luke Allardyce 
 Also the old standard seems to require that ios_base::fixed |
 ios_base::scientific (or any other combination) falls through to the
 uppercase test; I was trying to use abi_tag for a solution as not only
 would two versions of _S_format_float be necessary, but also num_get
 due to the pre-instantiated templates for char and wchar, which
 led me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60642. It might
 just be more trouble than it's worth.

 I don't think we need to worry about that, if I understand correctly
 the combination of fixed|scientific has unspecified behaviour in
 C++03, so we can make our implementation do exactly what it does in
 C++11.

It seems to me that it is well defined, going from  [lib.facet.num.put.virtuals]

 6 All tables used in describing stage 1 are ordered. That is, the first line 
 whose condition is true applies.
 A line without a condition is the default behavior when none of the earlier 
 lines apply.

So fixed|scientific would be equivalent to specifying neither
according to table 58, and the resulting specifier would be %g or %G
depending on whether uppercase is set or not.

Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

2014-03-27 Thread Jonathan Wakely 

On 27/03/14 17:00 +0100, Rüdiger Sonderfeld wrote:

Hello Jonathan,

thanks for your comments.


N.B. patches to the ChangeLog rarely apply cleanly (because someone
else may have changed the ChangeLog since the patch was created) so
the convention is to send the ChangeLog entry in the email body, or as
a separate attachment, or by using 'git log -p @{u}..' so the commit
log shows it, rather than as part of the patch.


Yes, ChangeLog's can be a bit of a pain.  I removed the ChangeLog from the
patch.  But FYI there is a ChangeLog merge driver hidden in gnulib, which
can be helpful when dealing with ChangeLog files in git (and potentially
other version control systems)

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c


Yes, I use that myself, and generate patches with the 'git lgp'
command shown at http://gcc.gnu.org/wiki/GitMirror


We could document that (fixed|scientific) has that effect in c++98
mode.


Where should it be documented?


Probably somewhere in doc/xml/manual/io.xml but I'm happy to do that
once the patch is committed if you like.

Thanks for the updated patch, I will try to remember to commit it when
stage 1 starts. If you don't get a mail from me then please ping me as
a reminder.