Thank you Jürgen! Looks good at a quick glance, I'll test those changes once I have long enough free time slot. :-)
On a somewhat related note, do you have a road map for new features and/or releases? Description says current implementation supports (almost) complete ISO 13751, what exactly is missing? Overall, I quite like GNU APL as a calculator REPL and would probably try to replace Python which I'm usually using for this purpose. ./danfe On 7/5/19, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote: > Hi Alexey, > > I applied most of your patches, thanks for submitting them. > > I have left the preferences file as is because changing it could come as a > surprise > to users that are happily using the current default. > > I also changed the rlim_t comparison warnings in a different way. Please > complain > if that doesn't work. > > SVN 1179. > > BR, > Jürgen > > > On 7/4/19 5:52 PM, Alexey Dokuchaev wrote: >> >> On 7/4/19, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote: >>> >>> Regarding signed vs. unsigned, the question is not so much if the chosen >>> type can hold the value but the number of comparisons needed to compute >>> if a value fits into a range (where the vast majority of cases the range >>> starts at 0). >>> >>> A signed X falls into range [0, N] iff: X ≥ 0 and X < N >>> An unsigned X falls into range [0, N] iff: X < N >> >> Understood. It should not be too hard to fix, just make sure that >> your desired types do not conflict with system types like rlim_t, then >> either use a compatible type or employ a typecast as a last resort >> (typecasts are evil and should be avoided). >> >>> This fired back badly (with milllions of warnings) when I replaced >>> Simple_string<X> with std::string<X> which uses unsigned for the length. >> >> Been these, done that. :-) Usually, the safest approach when handling >> sizes is to use size_t type (which is unsigned, just as you prefer) >> and only reluctantly fallback to ssize_t if you need/must to handle >> negative sizes for some reason in the same variable (e.g. for error >> handling). Reluctantly because it is generally a bad idea to convey >> errors by abusing the data type itself. Unfortunately, in many >> traditional languages there is no support for algebraic data types to >> handle these situations in a correct, type-safe way. >> >> ./danfe >> > >
