Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Output Stream Formatting
65 views
Skip to first unread message
MikeCopeland
Apr 3, 2015, 6:22:43 PM4/3/15
to
How do I accomplish this:
printf(myStr, "%6.1f", shirtCounts[ii]*100.0/totalShirts);
with streams? (When I put the expression in an output stream I get e-
notation with some values...) TIA
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
printf(myStr, "%6.1f", shirtCounts[ii]*100.0/totalShirts);
with streams? (When I put the expression in an output stream I get e-
notation with some values...) TIA
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Victor Bazarov
Apr 3, 2015, 6:29:47 PM4/3/15
to
On 4/3/2015 6:22 PM, MikeCopeland wrote:
> How do I accomplish this:
>
> printf(myStr, "%6.1f", shirtCounts[ii]*100.0/totalShirts);
>
> with streams? (When I put the expression in an output stream I get e-
> notation with some values...) TIA
See iostream manipulators (<iomanip>), like 'std::fixed', 'std::width',
> How do I accomplish this:
>
> printf(myStr, "%6.1f", shirtCounts[ii]*100.0/totalShirts);
>
> with streams? (When I put the expression in an output stream I get e-
> notation with some values...) TIA
'std::precision', etc. IOW, RTFM.
V
--
I do not respond to top-posted replies, please don't ask
Message has been deleted
Message has been deleted
Öö Tiib
Apr 3, 2015, 7:36:24 PM4/3/15
to
On Saturday, 4 April 2015 01:58:56 UTC+3, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >#include <iostream> // ::std::cout
> >#include <ostream> // ::std::ostream (<<)
> >#include <iomanip> // ::std::setw, ::std::setprecision
> >#include <ios> // ::std::fixed
> >#include <cmath> // ::std::atan2
> >#include <cstdlib> // ::std::printf
> >
> >int main()
> >{ constexpr double pi = 4 * atan2( 1, 1 );
> > ::std::cout << ::std::fixed << ::std::setw( 6 )<<
> > ::std::setprecision( 1 ) << pi << "\n";
> > ::std::printf( "%6.1f\n", pi ); }
>
> Recently, Herb Sutter compared a piece of Python to
> an equivalent piece of C++ and said that the C++ was
> not very much longer. I just now become aware of the
> fact that he omitted the »#include«s from the C++ code!
Including <iostream> is guaranteed to include also <ios>,
<streambuf>, <istream>, <ostream> and <iosfwd>.
So you actually needed <iostream> and <iomanip>
>
> Also, he compared Java and Python as they are now with
> C++ as it will possibly be when C++ 17 is published
> (he used concepts in the C++ code).
>
> Also, what is really annoying with those manipulators:
> Some of them change the stream just for the next output
> operation, while others change the stream forever, and
> I am not aware of a rule to derive which of the manipulators
> only modify a stream for the next output operation.
>
> And then, some need »#include <iomanip>« and some seem to
> need »#include <ios>«, and I am also not aware of a rule
> to determine which require which header.
>
> In the case of »printf« the »%6.1f« /always/ only refers to
> a single output operation and the include /always/ is
> »#include <cstdio>«.
Yeah, using the C++ I/O manipulators a lot is somewhat annoying.
> Concepts really would blend good together with a C++doc
> system, so that we have a standard to express semantic
> requirements for the operations of a concept. Like, for
> example, a kind of Doxygen becoming part of ISO C++.
We will see. I suspect we maybe hope too lot from those long
promised things like concepts, reflection or modules.
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >#include <iostream> // ::std::cout
> >#include <ostream> // ::std::ostream (<<)
> >#include <iomanip> // ::std::setw, ::std::setprecision
> >#include <ios> // ::std::fixed
> >#include <cmath> // ::std::atan2
> >#include <cstdlib> // ::std::printf
> >
> >int main()
> >{ constexpr double pi = 4 * atan2( 1, 1 );
> > ::std::cout << ::std::fixed << ::std::setw( 6 )<<
> > ::std::setprecision( 1 ) << pi << "\n";
> > ::std::printf( "%6.1f\n", pi ); }
>
> Recently, Herb Sutter compared a piece of Python to
> an equivalent piece of C++ and said that the C++ was
> not very much longer. I just now become aware of the
> fact that he omitted the »#include«s from the C++ code!
Including <iostream> is guaranteed to include also <ios>,
<streambuf>, <istream>, <ostream> and <iosfwd>.
So you actually needed <iostream> and <iomanip>
>
> Also, he compared Java and Python as they are now with
> C++ as it will possibly be when C++ 17 is published
> (he used concepts in the C++ code).
>
> Also, what is really annoying with those manipulators:
> Some of them change the stream just for the next output
> operation, while others change the stream forever, and
> I am not aware of a rule to derive which of the manipulators
> only modify a stream for the next output operation.
>
> And then, some need »#include <iomanip>« and some seem to
> need »#include <ios>«, and I am also not aware of a rule
> to determine which require which header.
>
> In the case of »printf« the »%6.1f« /always/ only refers to
> a single output operation and the include /always/ is
> »#include <cstdio>«.
Yeah, using the C++ I/O manipulators a lot is somewhat annoying.
> Concepts really would blend good together with a C++doc
> system, so that we have a standard to express semantic
> requirements for the operations of a concept. Like, for
> example, a kind of Doxygen becoming part of ISO C++.
We will see. I suspect we maybe hope too lot from those long
promised things like concepts, reflection or modules.
Bo Persson
Apr 4, 2015, 4:54:42 AM4/4/15
to
On 2015-04-04 00:58, Stefan Ram wrote:
>
> And then, some need »#include <iomanip>« and some seem to
> need »#include <ios>«, and I am also not aware of a rule
> to determine which require which header.
>
> In the case of »printf« the »%6.1f« /always/ only refers to
> a single output operation and the include /always/ is
> »#include <cstdio>«.
>
On the other hand, printf fails totally and miserably for user defined
>
> And then, some need »#include <iomanip>« and some seem to
> need »#include <ios>«, and I am also not aware of a rule
> to determine which require which header.
>
> In the case of »printf« the »%6.1f« /always/ only refers to
> a single output operation and the include /always/ is
> »#include <cstdio>«.
>
types.
Öö Tiib
Apr 4, 2015, 7:32:01 AM4/4/15
to
is pointless for 'printf' indeed. OTOH lot of text output goes not
to streams (for example to GUI) and so some form of 'to_string' is
even more likely than 'operator<<' overload.
All those standalone 'to_string' and member 'toString' may be used
like they are used with 'cout':
some_space::UserType variable = getItFromSomeWhere();
// cout
std::cout << "variable is " << to_string(variable) << "\n";
// printf
printf( "variable is %s\n", to_string(variable).c_str() );
It is matter of taste definitely but not exactly total and
miserable failure. May be I do not see some aspect of it clearly?
Vir Campestris
Apr 5, 2015, 7:43:17 AM4/5/15
to
On 04/04/2015 09:54, Bo Persson wrote:
> On the other hand, printf fails totally and miserably for user defined
> types.
I tend to take a leaf out of Java's book and define a tostring method.
> On the other hand, printf fails totally and miserably for user defined
> types.
Leaving the caMel hUmPs in random places to confuse the innocent & match
local coding standards of course ;)
Andy
Melzzzzz
Apr 5, 2015, 7:49:21 AM4/5/15
to
Lőrinczy Zsigmond
Apr 5, 2015, 8:51:42 AM4/5/15
to
sprintf is your friend
Öö Tiib
Apr 5, 2015, 9:00:59 AM4/5/15
to
(or "algorithm" or "utility") in std namespace when the behavior
matches. Saves some time of other guy who tries to write some
generic handling and has to otherwise write wrappers in style:
inline std::string to_string( Foo const& foo )
{
return foo.ConvertToStdString();
}
Öö Tiib
Apr 5, 2015, 9:19:03 AM4/5/15
to
On Sunday, 5 April 2015 15:51:42 UTC+3, Lőrinczy Zsigmond wrote:
> sprintf is your friend
That leads to:
A: No, 'sprintf' is security hole. 'snprintf' is safer.
B: But Windows/Ms does not have 'snprintf'.
A: Yes, but Windows/Ms has '_snprintf'.
C: Hey, '_snprintf' is broken/not compatible with 'snprintf'.
D: Why don't you guys use 'std::snprintf'?
So ... to keep things short ... 'std::snprintf' is your friend. ;-)
> sprintf is your friend
That leads to:
A: No, 'sprintf' is security hole. 'snprintf' is safer.
B: But Windows/Ms does not have 'snprintf'.
A: Yes, but Windows/Ms has '_snprintf'.
C: Hey, '_snprintf' is broken/not compatible with 'snprintf'.
D: Why don't you guys use 'std::snprintf'?
So ... to keep things short ... 'std::snprintf' is your friend. ;-)
Luca Risolia
Apr 5, 2015, 11:18:32 AM4/5/15
to
Il 04/04/2015 00:22, MikeCopeland ha scritto:
> How do I accomplish this:
>
> printf(myStr, "%6.1f", shirtCounts[ii]*100.0/totalShirts);
>
> with streams?
Write a simple user-defined manipulator as a combination of std::fixed,
> How do I accomplish this:
>
> printf(myStr, "%6.1f", shirtCounts[ii]*100.0/totalShirts);
>
> with streams?
std::setw and std::setprecision and use it wherever you need.
Message has been deleted
Öö Tiib
Apr 5, 2015, 5:05:01 PM4/5/15
to
On Sunday, 5 April 2015 19:31:23 UTC+3, Stefan Ram wrote:
> I use vsnprintf to obtain the size of the buffer, then allocate
> the buffer, and, finally, vsprintf to print to the buffer, when
> the size of the buffer needed is not statically known.
>
> (There should be some example code on:
>
> http://www.purl.org/stefan_ram/pub/c_faq_de
>
> see "salfmt", in case of 403 try to use a Google referrer.)
The 'va_list's are made to process the ellipsis '...' argument
of C. Ellipsis argument is too loose for my taste to use at all.
Lot of coding standards agree with me. It is better
to use overloads, templates or variadic templates in C++ since
those are lot more type safe.
> >B: But Windows/Ms does not have 'snprintf'.
>
> According to 27.9.2, C++ has snprintf. When someone is using
> a language without snprintf, this language is off topic here.
Is it? C++ has 'std::snprintf'. It wasn't standardized before
C++11. Is discussing older standards off topic here? C++ is
evolving faster than its compilers still in use so on such case
we haven't much to discuss left but sausages.
> >C: Hey, '_snprintf' is broken/not compatible with 'snprintf'.
>
> They should try -D__USE_MINGW_ANSI_STDIO when using a kind
> of MINGW.
Lot of people can not use mingw or cygwin. They have to use
msvc or icc because these make better-performing binaries for
their case or have tools they need or support compatibility
with other software they need.
> I use vsnprintf to obtain the size of the buffer, then allocate
> the buffer, and, finally, vsprintf to print to the buffer, when
> the size of the buffer needed is not statically known.
>
> (There should be some example code on:
>
> http://www.purl.org/stefan_ram/pub/c_faq_de
>
> see "salfmt", in case of 403 try to use a Google referrer.)
The 'va_list's are made to process the ellipsis '...' argument
of C. Ellipsis argument is too loose for my taste to use at all.
Lot of coding standards agree with me. It is better
to use overloads, templates or variadic templates in C++ since
those are lot more type safe.
> >B: But Windows/Ms does not have 'snprintf'.
>
> a language without snprintf, this language is off topic here.
Is it? C++ has 'std::snprintf'. It wasn't standardized before
C++11. Is discussing older standards off topic here? C++ is
evolving faster than its compilers still in use so on such case
we haven't much to discuss left but sausages.
> >C: Hey, '_snprintf' is broken/not compatible with 'snprintf'.
>
> of MINGW.
Lot of people can not use mingw or cygwin. They have to use
msvc or icc because these make better-performing binaries for
their case or have tools they need or support compatibility
with other software they need.
Christian Gollwitzer
Apr 7, 2015, 11:48:35 AM4/7/15
to
Am 04.04.15 um 13:31 schrieb Öö Tiib:
cout can't. Imagine a langugage that requires to say "%s is the
variable". Impossible with your first line by just changing the string.
Modern printf-like engines support syntax for positional arguments. So
%1$s has %2$d bytes
can be translated to
%2$d bytes are contained in %1$d.
How would you do this with iostreams? I'm all-in for a typesafe
printf-like engine using variadic templates.
Christian
> All those standalone 'to_string' and member 'toString' may be used
> like they are used with 'cout':
>
> some_space::UserType variable = getItFromSomeWhere();
>
> // cout
> std::cout << "variable is " << to_string(variable) << "\n";
>
> // printf
> printf( "variable is %s\n", to_string(variable).c_str() );
>
>
> It is matter of taste definitely but not exactly total and
> miserable failure. May be I do not see some aspect of it clearly?
>
The printf version can be translated into foreign languages, while the
> like they are used with 'cout':
>
> some_space::UserType variable = getItFromSomeWhere();
>
> // cout
> std::cout << "variable is " << to_string(variable) << "\n";
>
> // printf
> printf( "variable is %s\n", to_string(variable).c_str() );
>
>
> It is matter of taste definitely but not exactly total and
> miserable failure. May be I do not see some aspect of it clearly?
>
cout can't. Imagine a langugage that requires to say "%s is the
variable". Impossible with your first line by just changing the string.
Modern printf-like engines support syntax for positional arguments. So
%1$s has %2$d bytes
can be translated to
%2$d bytes are contained in %1$d.
How would you do this with iostreams? I'm all-in for a typesafe
printf-like engine using variadic templates.
Christian
Christopher Pisz
Apr 7, 2015, 1:03:33 PM4/7/15
to
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Scott Lurndal
Apr 7, 2015, 1:22:45 PM4/7/15
to
Christopher Pisz <nos...@notanaddress.com> writes:
>On 4/7/2015 10:48 AM, Christian Gollwitzer wrote:
>> Am 04.04.15 um 13:31 schrieb 嘱 Tiib:
>On 4/7/2015 10:48 AM, Christian Gollwitzer wrote:
>>> All those standalone 'to_string' and member 'toString' may be used
>>> like they are used with 'cout':
>>>
>>> some_space::UserType variable = getItFromSomeWhere();
>>>
>>> // cout
>>> std::cout << "variable is " << to_string(variable) << "\n";
>>>
>>> // printf
>>> printf( "variable is %s\n", to_string(variable).c_str() );
>>>
>>>
>>> It is matter of taste definitely but not exactly total and
>>> miserable failure. May be I do not see some aspect of it clearly?
>>>
>>
>> The printf version can be translated into foreign languages, while the
>> cout can't. Imagine a langugage that requires to say "%s is the
>> variable". Impossible with your first line by just changing the string.
>>
>> Modern printf-like engines support syntax for positional arguments. So
>>
>> %1$s has %2$d bytes
>>
>> can be translated to
>>
>> %2$d bytes are contained in %1$d.
>>
>> How would you do this with iostreams? I'm all-in for a typesafe
>> printf-like engine using variadic templates.
>>
>> Christian
>
>
>http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
>
Doesn't matter how you pretty it up, it's still a pig :-)
>>> like they are used with 'cout':
>>>
>>> some_space::UserType variable = getItFromSomeWhere();
>>>
>>> // cout
>>> std::cout << "variable is " << to_string(variable) << "\n";
>>>
>>> // printf
>>> printf( "variable is %s\n", to_string(variable).c_str() );
>>>
>>>
>>> It is matter of taste definitely but not exactly total and
>>> miserable failure. May be I do not see some aspect of it clearly?
>>>
>>
>> The printf version can be translated into foreign languages, while the
>> cout can't. Imagine a langugage that requires to say "%s is the
>> variable". Impossible with your first line by just changing the string.
>>
>> Modern printf-like engines support syntax for positional arguments. So
>>
>> %1$s has %2$d bytes
>>
>> can be translated to
>>
>> %2$d bytes are contained in %1$d.
>>
>> How would you do this with iostreams? I'm all-in for a typesafe
>> printf-like engine using variadic templates.
>>
>> Christian
>
>
>http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
>
Christopher Pisz
Apr 7, 2015, 2:38:12 PM4/7/15
to
On 4/7/2015 12:22 PM, Scott Lurndal wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> On 4/7/2015 10:48 AM, Christian Gollwitzer wrote:
>>> Am 04.04.15 um 13:31 schrieb Öö Tiib:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> On 4/7/2015 10:48 AM, Christian Gollwitzer wrote:
>>>> All those standalone 'to_string' and member 'toString' may be used
>>>> like they are used with 'cout':
>>>>
>>>> some_space::UserType variable = getItFromSomeWhere();
>>>>
>>>> // cout
>>>> std::cout << "variable is " << to_string(variable) << "\n";
>>>>
>>>> // printf
>>>> printf( "variable is %s\n", to_string(variable).c_str() );
>>>>
>>>>
>>>> It is matter of taste definitely but not exactly total and
>>>> miserable failure. May be I do not see some aspect of it clearly?
>>>>
>>>
>>> The printf version can be translated into foreign languages, while the
>>> cout can't. Imagine a langugage that requires to say "%s is the
>>> variable". Impossible with your first line by just changing the string.
>>>
>>> Modern printf-like engines support syntax for positional arguments. So
>>>
>>> %1$s has %2$d bytes
>>>
>>> can be translated to
>>>
>>> %2$d bytes are contained in %1$d.
>>>
>>> How would you do this with iostreams? I'm all-in for a typesafe
>>> printf-like engine using variadic templates.
>>>
>>> Christian
>>
>>
>> http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
>>
>
> Doesn't matter how you pretty it up, it's still a pig :-)
>
I think the same of sprintf and its ilk, but we've been over all that
>>>> like they are used with 'cout':
>>>>
>>>> some_space::UserType variable = getItFromSomeWhere();
>>>>
>>>> // cout
>>>> std::cout << "variable is " << to_string(variable) << "\n";
>>>>
>>>> // printf
>>>> printf( "variable is %s\n", to_string(variable).c_str() );
>>>>
>>>>
>>>> It is matter of taste definitely but not exactly total and
>>>> miserable failure. May be I do not see some aspect of it clearly?
>>>>
>>>
>>> The printf version can be translated into foreign languages, while the
>>> cout can't. Imagine a langugage that requires to say "%s is the
>>> variable". Impossible with your first line by just changing the string.
>>>
>>> Modern printf-like engines support syntax for positional arguments. So
>>>
>>> %1$s has %2$d bytes
>>>
>>> can be translated to
>>>
>>> %2$d bytes are contained in %1$d.
>>>
>>> How would you do this with iostreams? I'm all-in for a typesafe
>>> printf-like engine using variadic templates.
>>>
>>> Christian
>>
>>
>> http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
>>
>
> Doesn't matter how you pretty it up, it's still a pig :-)
>
already.
Öö Tiib
Apr 7, 2015, 5:18:48 PM4/7/15
to
command line tools do typically ignore locale. So the
i18n means GUI. There are no standard GUI frameworks.
GUI frameworks typically contain some i18n facility.
GUIs do not use printf or iostreams.
Bo Persson
Apr 8, 2015, 12:19:06 PM4/8/15
to
On 2015-04-07 17:48, Christian Gollwitzer wrote:
> Am 04.04.15 um 13:31 schrieb Öö Tiib:
>> All those standalone 'to_string' and member 'toString' may be used
>> like they are used with 'cout':
>>
>> some_space::UserType variable = getItFromSomeWhere();
>>
>> // cout
>> std::cout << "variable is " << to_string(variable) << "\n";
>>
>> // printf
>> printf( "variable is %s\n", to_string(variable).c_str() );
>>
>>
>> It is matter of taste definitely but not exactly total and
>> miserable failure. May be I do not see some aspect of it clearly?
>>
>
> The printf version can be translated into foreign languages, while the
> cout can't. Imagine a langugage that requires to say "%s is the
> variable". Impossible with your first line by just changing the string.
>
> Modern printf-like engines support syntax for positional arguments. So
>
> %1$s has %2$d bytes
>
> can be translated to
>
> %2$d bytes are contained in %1$d.
>
You still have to add code to get "1 byte is contained". And even more
> Am 04.04.15 um 13:31 schrieb Öö Tiib:
>> All those standalone 'to_string' and member 'toString' may be used
>> like they are used with 'cout':
>>
>> some_space::UserType variable = getItFromSomeWhere();
>>
>> // cout
>> std::cout << "variable is " << to_string(variable) << "\n";
>>
>> // printf
>> printf( "variable is %s\n", to_string(variable).c_str() );
>>
>>
>> It is matter of taste definitely but not exactly total and
>> miserable failure. May be I do not see some aspect of it clearly?
>>
>
> The printf version can be translated into foreign languages, while the
> cout can't. Imagine a langugage that requires to say "%s is the
> variable". Impossible with your first line by just changing the string.
>
> Modern printf-like engines support syntax for positional arguments. So
>
> %1$s has %2$d bytes
>
> can be translated to
>
> %2$d bytes are contained in %1$d.
>
code to support languages with different forms for one, a few, and many.
Bo Persson
0 new messages