On 6/26/2013 11:08 AM, bearophile wrote:
> A simpler example:
>
> enum INPUT_VALUE = 2;
> void f(uint flags) {
>      if (flags | INPUT_VALUE) {}
> }
>
>
> I have just added it to Bugzilla:
> http://d.puremagic.com/issues/show_bug.cgi?id=10480

We've discussed this one before. I oppose it, on grounds I added to the enhancement request.

On 6/26/2013 2:47 PM, Paulo Pinto wrote:
> I have been an adept of iostreams since day one and never understood why people
> complain so much about them or the operator<< and operator>>
> for that matter.

Even if you can get past the execrable look of it, it suffers from at least 3 terrible technical problems:

1. not thread safe

2. not exception safe

3. having to acquire/release mutexes for every << operation rather than once for the whole expression

On 6/26/2013 3:56 PM, Walter Bright wrote:
> On 6/26/2013 2:47 PM, Paulo Pinto wrote:
>> I have been an adept of iostreams since day one and never understood why people
>> complain so much about them or the operator<< and operator>>
>> for that matter.
>
> Even if you can get past the execrable look of it, it suffers from at least 3
> terrible technical problems:
>
> 1. not thread safe
>
> 2. not exception safe
>
> 3. having to acquire/release mutexes for every << operation rather than once for
> the whole expression


Oh, and the cake topper is IOStreams performs badly, too.

On Wednesday, June 26, 2013 23:47:32 Paulo Pinto wrote:
> I have been an adept of iostreams since day one and never understood why
> people complain so much about them or the operator<< and operator>>
> for that matter.

I actually like them (particularly because I really don't like how primitive printf is with regards to types), but they fail completely when it comes to formatting, and you have to break up your strings too much. e.g.

cout << "[" << value1 << ", " << value2 << "]" << endl;

instead of

printf("[%d, %d]\n", value1, value2);

writefln fixes the typing problem that printf has in that it's not only type safe, but it allows you to just use %s everywhere (and you don't have to use c_str() on strings all over the place like with C++'s std::string), so I definitely think that what we have with D is far better than either iostreams or printf.

But with C++, which I use depends on my mood and the code, because both iostreams and printf suck. They just suck differently. But I've never actually minded that they used the shift operators for I/O beyond the fact that putting a bunch of values in the middle of a string with iostreams breaks things up too much (unlike with format strings).

- Jonathan M Davis

On 06/27/2013 01:01 AM, Walter Bright wrote:
> On 6/26/2013 3:56 PM, Walter Bright wrote:
>> On 6/26/2013 2:47 PM, Paulo Pinto wrote:
>>> I have been an adept of iostreams since day one and never understood
>>> why people
>>> complain so much about them or the operator<< and operator>>
>>> for that matter.
>>
>> Even if you can get past the execrable look of it, it suffers from at
>> least 3
>> terrible technical problems:
>>
>> 1. not thread safe
>>
>> 2. not exception safe
>>
>> 3. having to acquire/release mutexes for every << operation rather
>> than once for
>> the whole expression
>

If it's not thread safe, why does it have to acquire mutexes?

>
> Oh, and the cake topper is IOStreams performs badly, too.

Yes, but that's just a default.

std::ios_base::sync_with_stdio(false);
std::cin.tie(0);

On 6/26/2013 4:48 PM, Timon Gehr wrote:
> On 06/27/2013 01:01 AM, Walter Bright wrote:
>> On 6/26/2013 3:56 PM, Walter Bright wrote:
>>> On 6/26/2013 2:47 PM, Paulo Pinto wrote:
>>>> I have been an adept of iostreams since day one and never understood
>>>> why people
>>>> complain so much about them or the operator<< and operator>>
>>>> for that matter.
>>>
>>> Even if you can get past the execrable look of it, it suffers from at
>>> least 3
>>> terrible technical problems:
>>>
>>> 1. not thread safe
>>>
>>> 2. not exception safe
>>>
>>> 3. having to acquire/release mutexes for every << operation rather
>>> than once for
>>> the whole expression
>>
>
> If it's not thread safe, why does it have to acquire mutexes?

It's not thread safe because global state can be set and reset for every << operation:

  a << b << setglobalstate << c << resetglobalstate << d;


>> Oh, and the cake topper is IOStreams performs badly, too.
>
> Yes, but that's just a default.
>
> std::ios_base::sync_with_stdio(false);
> std::cin.tie(0);

Yeah, to make it as fast as C stdio you use C stdio. That's a ringing endorsement!

On 27/06/13 10:33, Walter Bright wrote:
> On 6/26/2013 4:48 PM, Timon Gehr wrote:
>> On 06/27/2013 01:01 AM, Walter Bright wrote:
>>> On 6/26/2013 3:56 PM, Walter Bright wrote:
>>>> On 6/26/2013 2:47 PM, Paulo Pinto wrote:
>>>>> I have been an adept of iostreams since day one and never understood
>>>>> why people
>>>>> complain so much about them or the operator<< and operator>>
>>>>> for that matter.
>>>>
>>>> Even if you can get past the execrable look of it, it suffers from at
>>>> least 3
>>>> terrible technical problems:
>>>>
>>>> 1. not thread safe
>>>>
>>>> 2. not exception safe
>>>>
>>>> 3. having to acquire/release mutexes for every << operation rather
>>>> than once for
>>>> the whole expression
>>>
>>
>> If it's not thread safe, why does it have to acquire mutexes?
>
> It's not thread safe because global state can be set and reset for every
> << operation:
>
>    a << b << setglobalstate << c << resetglobalstate << d;
>
>
>>> Oh, and the cake topper is IOStreams performs badly, too.
>>
>> Yes, but that's just a default.
>>
>> std::ios_base::sync_with_stdio(false);
>> std::cin.tie(0);
>
> Yeah, to make it as fast as C stdio you use C stdio. That's a ringing
> endorsement!

This form of output usually causes problems with i18n as not all languages have the same types of grammar and sometimes the order of items needs to be changed to achieve a valid grammatical form in the translation.

Peter

On 6/26/13 1:31 PM, Andrej Mitrovic wrote:
> On 6/26/13, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> Actually this is good because it allows to customize the format string
>> to print only a subset of available information (I've actually used this).
>
> Note that this works:
>
> writefln("%d", x, x);
>
> But the following throws since v2.061:
>
> writeln(format("%d", x, x));
>
> std.format.FormatException@C:\dmd-git\dmd2\windows\bin\..\..\src\phobos\std\string.d(2346):
> Orphan format arguments: args[1..2]
>
> I find the latter to be quite useful for debugging code, and wanted
> this feature for a long time.

I think that's a bug in format that we need to fix.

Andrei

On 6/26/13 1:50 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Actually this is good because it allows to customize the format string
>> to print only a subset of available information (I've actually used
>> this).
>
> Your use case is a special case that breaks a general rule.

There's no special case here.

> That
> behavour is surprising, and it risks hiding some information silently.

Doesn't surprise me one bit.

> I
> think format() is more correct here.

I think it has a bug that diminishes its usefulness.

> If you want a special behavour you
> should use a special function as partialWritefln that ignores arguments
> not present in the format string.

That behavior is not special.


Andrei

On 6/26/13 2:47 PM, Paulo Pinto wrote:
> Am 26.06.2013 20:52, schrieb H. S. Teoh:
>> On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
>>> An interesting blog post found through Reddit:
>>>
>>> http://randomascii.wordpress.com/2013/06/24/two-years-and-thousands-of-bugs-of-/
>>>
>> [...]
>>> The most common problem they find are errors in the format string of
>>> printf-like functions (despite the code is C++):
>>
>> None of my C++ code uses iostream. I still find stdio.h more comfortable
>> to use, in spite of its many problems. One of the most annoying features
>> of iostream is the abuse of operator<< and operator>> for I/O. Format
>> strings are an ingenious idea sorely lacking in the iostream department
>> (though admittedly the way it was implemented in stdio is rather unsafe,
>> due to the inability of C to do many compile-time checks).
>
> I have been an adept of iostreams since day one and never understood why
> people complain so much about them or the operator<< and operator>>
> for that matter.

The problems with C++ iostreams are well-known and pernicious:

1. Extremely slow by design.

2. Force mixing representation with data by design

3. Keep conversion state within, meaning they force very bizarre tricks even for simple things such as printing/scanning hex numbers.

4. Approach to exception safety has the wrong default.

5. Approach to internationalization (locales) has the most byzantine design I've ever seen. Even people who took part to the design can't figure it all out.


Andrei