June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
On 27/06/13 14:20, H. S. Teoh wrote:
> On Thu, Jun 27, 2013 at 01:56:31PM +1000, Peter Williams wrote:
> [...]
>> While you're fixing it can you modify it so that the format string
>> can specify the order in which the arguments are replaced? This is
>> very important for i18n. I apologize if it can already do this but
>> I was unable to find any documentation of format()'s format string
>> other than examples with %s at the appropriate places.
> [...]
>
> You can use positional arguments for this purpose. For example:
>
> writefln("%2$s %1$s", "a", "b");
>
> outputs "b a".
Yes, I eventually found the documentation in std.format while I expected it to be in std.string along with the documentation the format() function. A reference to std.format in the documentation for format() (in std.string) would be nice.
Peter
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | On 6/26/13 8:05 PM, Andrej Mitrovic wrote:
> If you are the type of programmer who often tests their own code, why
> are you passing more arguments than needed to format?
My point is they're needed.
Andrei
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | On 6/26/13 8:26 PM, Andrej Mitrovic wrote: > The way I see it, write/writef is primarily used for debugging and > benefits having some lax features, whereas format is used in more > heavy-duty work where it's important not to screw things up at the > call site. Then I think all the more format should allow more arguments than format specifiers. That does help serious use. > But the bottom line is I don't think we need to force anything on > anybody. If anything, we could split up the internal format > implementation and provide format and safeFormat functions. > > format("%s %s", 1); // no exceptions NO! This is exactly the kind of code that is buggy and useless. The right use cases involve more arguments than format specifiers. Andrei |
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 6/26/13 8:36 PM, Jonathan M Davis wrote: > On Wednesday, June 26, 2013 19:18:27 Andrei Alexandrescu wrote: >> 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. > > I have never heard anyone other than you even suggest this sort of behavior. > Granted, I may just not talk with the right people, but that at least makes it > sound like what you're suggesting is a very special case. I'm not surprised. Not many people deal with things like localization or internalization. >>> That >>> behavour is surprising, and it risks hiding some information silently. >> >> Doesn't surprise me one bit. > > Well, it shocks most of us. I'm also not moved by argumentum ad populum. > We expect the number of arguments to a function to > match the number of parameters, and with format strings, you're basically > declaring what the parameters are, and then the other arguments to format or > writefln are the arguments to the format string. Most of us don't even think > about swapping out the format string at runtime. That is the smoking gun. Andrei |
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Williams | On 6/26/13 10:35 PM, Peter Williams wrote:
> On 27/06/13 14:20, H. S. Teoh wrote:
>> On Thu, Jun 27, 2013 at 01:56:31PM +1000, Peter Williams wrote:
>> [...]
>>> While you're fixing it can you modify it so that the format string
>>> can specify the order in which the arguments are replaced? This is
>>> very important for i18n. I apologize if it can already do this but
>>> I was unable to find any documentation of format()'s format string
>>> other than examples with %s at the appropriate places.
>> [...]
>>
>> You can use positional arguments for this purpose. For example:
>>
>> writefln("%2$s %1$s", "a", "b");
>>
>> outputs "b a".
>
> Yes, I eventually found the documentation in std.format while I expected
> it to be in std.string along with the documentation the format()
> function. A reference to std.format in the documentation for format()
> (in std.string) would be nice.
The only point I'd negotiate would be to not throw with positional arguments, and throw with sequential arguments. All code that cares uses positional specifiers anyway.
Andrei
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, June 26, 2013 23:49:41 Andrei Alexandrescu wrote:
> The only point I'd negotiate would be to not throw with positional arguments, and throw with sequential arguments. All code that cares uses positional specifiers anyway.
That sounds like a good compromise.
- Jonathan M Davis
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, June 26, 2013 23:47:15 Andrei Alexandrescu wrote:
> >>> That
> >>> behavour is surprising, and it risks hiding some information silently.
> >>
> >> Doesn't surprise me one bit.
> >
> > Well, it shocks most of us.
>
> I'm also not moved by argumentum ad populum.
ad populum obviously isn't enough. But if we make a design decision that favors 1% of our user base and causes problems for the other 99%, then I think that we've made a big mistake. And while having most everyone disagree with one person does not make that person wrong, it _does_ make it more likely that they're wrong. So, while ad populum should not be the sole reason to make a decision, I think that it's generally a bad idea to ignore it. I'm not trying to say anything about this particular discussion and whether we should go with the majority on this; I'm just pointing out that ignoring what the majority thinks is not necessarily a good idea.
- Jonathan M Davis
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 6/26/13 11:59 PM, Jonathan M Davis wrote:
> On Wednesday, June 26, 2013 23:47:15 Andrei Alexandrescu wrote:
>>>>> That
>>>>> behavour is surprising, and it risks hiding some information silently.
>>>>
>>>> Doesn't surprise me one bit.
>>>
>>> Well, it shocks most of us.
>>
>> I'm also not moved by argumentum ad populum.
>
> ad populum obviously isn't enough. But if we make a design decision that
> favors 1% of our user base and causes problems for the other 99%
My point is it doesn't cause any problem except for the 0.0001% who refuse to even take ONE look at the output of the format.
Andrei
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 6/26/13 11:59 PM, Jonathan M Davis wrote:
> I'm just pointing out that ignoring what the majority
> thinks is not necessarily a good idea.
Of course. In this case it is.
Andrei
|
June 27, 2013 Re: Notes from C++ static analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 27 June 2013 at 02:25:54 UTC, Andrei Alexandrescu wrote:
> 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
I always liked their OO model and for the type of applications we use performance never was a problem.
My iostreams experience is mostly coupled to serialization of data structures, simple console applications.
Exception safety might be an issue, sadly I was never able to write portable C++ code at work that used either RTTI or exceptions. Just too many issues, which always lead to the architects forbidding their use.
Thanks for the explanation.
--
Paulo
|
Copyright © 1999-2021 by the D Language Foundation