Re: try/catch idiom in std.datetime
Jacob Carlborg wrote: I would say that it would be quite cumbersome and verbose to for the user to constantly validate the input. If the user level validation fails, shall we throw or assert or...? -- Jouko --- avast! Antivirus käynnissä, joten tässä sähköpostiviestissä ei ole viruksia tai haittaohjelmia. http://www.avast.com
Re: try/catch idiom in std.datetime
Jacob Carlborg wrote: On 2013-11-19 18:11, Jouko Koski wrote: If the user level validation fails, shall we throw or assert or...? Throw. Ok. What if the user is writing a library code which calls other system utilities? If the validation fails, is the answer now assert? I don't have a definite answer. However, I tend to follow the practice that all public API should do validation and throw on failures. I use assert for catching my own mistakes in more or less internal stuff. Usually I don't find separate validation API functions very practical. One can forget or ignore to do validation, just like one can fail to check errno after a call. Of course, validation is necessary and exceptions can assert (sic!) this. It might be more of a personal preference, but often I catch exceptions only for error reporting purposes. Exception is an indication of an unexpected condition in the program. The solution is to fix the program to be prepared for the condition, not trying to fix the condition afterwards as the exception has already fired. Not all APIs support this approach. -- Jouko
Re: DConf 2013 official car/room sharing thread
Walter Bright wrote: I nearly got run over several times just walking around London! Me too, but then I realized that they have left side traffic there. :-) -- Jouko
Re: C++ guys hate static_if?
Nick Treleaven wrote: On 09/03/2013 11:15, Artur Skawina wrote: - static-if not creating scopes/is/ confusing, but what would be a better alternative? Isn't it only confusing to newbies? It's not hard to learn and recognize. Maybe. This is just precisely the way how it all begun in C/C++. -- Jouko
Re: C++ guys hate static_if?
Walter Bright wrote:
Many of the criticisms in the paper are addressed by our positive
experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new
scope in a very similar-looking contexts.
--
Jouko
Re: Exception/Error division in D
deadalnix deadal...@gmail.com wrote: Le 31/05/2012 04:10, Walter Bright a écrit : The correct response to a server app crashing is to restart it, not attempt to keep a program in an invalid state running. Should I mention to restart it AFTER A GRACEFUL SHUTDOWN ? No. Abort with crash dump is good way to do controlled shutdown. If there is need for a cleanup, it is better to do it in the upcoming startup where the program state is valid.
Re: Line lengths discussed in eclipse forum and on reddit
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Anyhow, let's move on to date formats. I'm archiving some receipt right now, and I find the mm/dd/yy notation notation quite unpleasant... Touché! :-) -- Jouko
Re: std.format add dash separators to large numbers
Andrej Mitrovic andrej.mitrov...@gmail.com kirjoitti: Okay but I wasn't really thinking about locales, underscores between digits is a D syntax feature and it makes numbers more readable. I agree that using almost any (thousand) separator can make reading long numeric strings easier. I would still consider not exporting D's internal syntactical construct to outside world where it is never used that way. I do not favor any solution which is D-specific or suitable for insular Yankees only. This sort of wrestling has already carried out in the past. For instance, the C90 standard work was prolonged by about a year because of adding the locale.h features that international community required. D can utilize maybe brighter technical solution, but still: No D-specific solutions and no localization as afterthought, please! -- Jouko
Re: std.format add dash separators to large numbers
bearophile bearophileh...@lycos.com wrote: Andrej Mitrovic: auto str = format(%s, 100); assert(str == 1_000_000); I suggest to add such formatter/function to Phobos. While 1_000_000 may be the right thing in program code, the outside world would probably like to have numbers printed out according to their locale conventions. This is even more important with floating point or monetary values. So before just adding some formatter to Phobos, I think that such formatter's use cases should be considered quite carefully. -- Jouko
Re: Any D developer at GDC europe next week ?
Peter Alexander peter.alexander...@gmail.com wrote: Almost everyone in the games industry knows that C++ is a rubbish language. When I talk about D programming language to somebody, I prefer avoiding this sort of argumentation entirely. -- Jouko
Re: Any D developer at GDC europe next week ?
Nick Sabalausky a@a.a wrote: Any sentence involving the phrases C++ and it works needs to be appended with something like ...sort of or ...barely. When I talk about D programming language to somebody, I prefer avoiding this sort of tone entirely. -- Jouko
Re: Rename std.ctype to std.ascii?
Jonathan M Davis jmdavisp...@gmx.com wrote: On 2011-06-14 11:53, Jouko Koski wrote: I would not consider it being good idea to include this kind of ascii-only utilities in the standard-ish library. For some classes of operations, it makes perfect sense to be checking for ASCII characters only. For others, it's just people not worrying about internationalization like they should be. For instance, format strings don't care about unicode as far as their escape sequences go. %a, %d, etc. are all pure ASCII. Do we really need a common library utility for such a bounded domain? I would vote dropping ascii-only std.ctype altogether. Those who know and ensure that they are dealing with ascii-only, ebcdic-only or whatever-only representations can easily write their own utilities to their particular domains - maybe even better optimized than std.ctype because the domain may be even more restricted. A common use ascii-only utility will be used inevitably in places where it shouldn't. std.ctype/std.ascii deals with ASCII for those situations where you really do only care about ASCII. It deals with unicode characters, but it returns false for everything with them which returns a bool, and it never tries to change their case. std.uni actually deals with unicode and worries about things like whether a unicode character is uppercase or not. That is what ctype.h (or wctype.h) utilities do when the default locale setting is in effect. Some other posters seem to suggest that a more generalized library module does this, too, without losing performance. -- Jouko
Re: Rename std.ctype to std.ascii?
Jonathan M Davis jmdavisp...@gmx.com wrote: So, yes I understood. It's just that as far as I can tell, locales don't matter if you're completely restricting yourself to ASCII like std.ctype does. I would not consider it being good idea to include this kind of ascii-only utilities in the standard-ish library. It might be best to rename the module to std.ascii_for_insular_yankees_others_keep_away so that nobody would use it by accident. This way the name would also remind us about the historical terms which were used quarter of a century ago when ascii-only ctype.h utilities were first suggested to the intenational C standardization committee. -- Jouko
Re: Rename std.ctype to std.ascii?
Jonathan M Davis jmdavisp...@gmx.com wrote: std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters). What is your definition for ASCII character? Most of the ctype.h functions (or macros) are locale dependent, see setlocale() and locale.h. And there is the wctype.h, too. While the C standardized ways of doing things might not be most appropriate approach in D domain, we must not base our design decisions on deficient analysis. I just want this text uppercase is one of the hardest things in the _world_. The problem is not just the header or package naming. -- Jouko
Re: float equality
Walter Bright newshou...@digitalmars.com wrote: A reasonable way to do financial work is to use longs to represent pennies. After all, you don't have fractional cents in your accounts. I tend to favor using floating point, doing calculations in pennies, and explicitly rounding result to nearest full penny. This is almost the same as using longs except that division does not always truncate numbers. Fractional pennies are often useful in intermediate results. If there is some more appropriate type to use, I might be easily convinced otherwise. However, I don't think using some indefinite precision number type is a fits-for-all solution either, since... I.e. you have to know what you're doing :-) Touche! -- Jouko
Re: Loop optimization
div0 d...@users.sourceforge.net wrote: Jérôme M. Berger wrote: That depends. In C/C++, the default value for any global variable is to have all bits set to 0 whatever that means for the actual data type. Ah, I only do C++, where the standard is to not initialise. No, in C++ all *global or static* variables are zero-initialized. By default, stack variables are default-initialized, which means that doubles in stack can have any value (they are uninitialized). The C-function calloc is required to fill the newly allocated memory with zero bit pattern; malloc is not required to initialize anything. Fresh heap areas given by malloc may have zero bit pattern, but one should really make no assumptions on this. -- Jouko
Re: A floating-point puzzle
Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: After the above code has finished, the variable B contains the radix of the computer's numerical system. I guess I can just drop this part from my code, then. ;) Well, there is certain likelihood that decimal floating point will reappear in the future. However, determining the radix may be unnecessary, because decimal representations may get types of their own. Run-time computation of radix is bad anyway. -- Jouko
