Re: Why does nobody seem to think that `null` is a serious problem in D?
On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh wrote: Programmers coming from nearly any language other than C++ would find it expected and intuitive that declaring a class instance variable leaves it null. What do you think about making the syntax slightly more explicit and warn or possibly error out if you don't do it that way? Either SomeClass c = null; or SomeClass c = new SomeClass(); and nothing else. The compiler *could* give you a warning that you're using an uninitialized variable in a way that will lead to a segfault, but that sort of flow analysis gets hard fast. Nulls/Nones are always a big gap in a language's type system. A common alternative is to have some Option/Maybe type like Rust or Haskell or D's Variant. How about making that required to plug the null gap? If you wanted the default constructor to be called implicitly, Yeah, maybe this bit of C++ syntax isn't the best idea. What about other alternatives?
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer wrote: A null pointer dereference is an immediate error, and it's also a safe error. It does not cause corruption, and it is free (the MMU is doing it for you). Is this always true for all arches that D can compile to? I remember back in the DOS days with no memory protection you really could read OS data around the beginning. Consistent segfaults are generally easy to figure out. I think I would still prefer a stack trace like other kinds of D errors. Is this too difficult?
Why does nobody seem to think that `null` is a serious problem in D?
When I was first playing with D, I managed to create a segfault by doing `SomeClass c;` and then trying do something with the object I thought I had default-created, by analogy with C++ syntax. Seasoned D programmers will recognise that I did nothing of the sort and instead created c is null and my program ended up dereferencing a null pointer. I'm not the only one who has done this. I can't find it right now, but I've seen at least one person open a bug report because they misunderstood this as a bug in dmd. I have been told a couple of times that this isn't something that needs to be patched in the language, but I don't understand. It seems like a very easy way to generate a segfault (and not a NullPointerException or whatever). What's the reasoning for allowing this?
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 10 July 2018 at 20:28:00 UTC, Seb wrote: Maybe looking at the recent DMD Backend to D conversion PRs (https://github.com/dlang/dmd/pulls?utf8=%E2%9C%93=is%3Apr+label%3A%22D+Conversion%22+) helps? Here -betterC is used. Octave is so far from -betterC, though. It's very C++-heavy, with C++11 features being used since the last couple of years. It's an old codebase that started circa 1992. Just getting it into -betterC territory seems like a very daunting task.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 19:57:55 UTC, jmh530 wrote: I'm not sure adding D to the GNU Octave code base is necessarily the biggest value add... I'm daydreaming of being able to rewrite all of Octave in D. I just was trying to think of where to start.
Is it feasible to slowly rewrite a C++ codebase in D?
I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas?
Re: What's the proper way to use std.getopt?
On Tuesday, 12 December 2017 at 20:57:28 UTC, Jon Degenhardt wrote: On Monday, 11 December 2017 at 20:58:25 UTC, Jordi Gutiérrez Hermoso wrote: What's the proper style, then? Can someone show me a good example of how to use getopt and the docstring it automatically generates? [snip] See: https://github.com/eBay/tsv-utils-dlang/blob/master/tsv-sample/src/tsv-sample.d Oh, thanks! This is more or less what I wanted. I suppose showing all of the docstring when the arguments are bad is possibly stupid and I shouldn't be doing that to begin with. I'll adopt this style to only show which argument was bad.
Re: What's the proper way to use std.getopt?
On Monday, 11 December 2017 at 21:24:41 UTC, Mike Wey wrote:
try
{
auto helpInformation = getopt(
args,
"input|i", "The input", ,
"output|o", "The output",
);
if (helpInformation.helpWanted)
{
defaultGetoptPrinter("Description", helpInformation.options);
exit(0);
}
}
catch (GetOptException e)
{
writeln(e.msg);
exit(1);
}
But I would like to show the help docstring when processing the
exception. It's pretty standard behaviour. If you give a program
bad arguments, it just spits out a docstring of all options and
what each does. Can this be achieved?
Re: Why is there no std.stream anymore?
On Monday, 11 December 2017 at 21:21:51 UTC, Steven Schveighoffer wrote: Use the undead repository: Wow, really? Is the removal of stream from D some kind of error that hasn't been corrected yet?
What's the proper way to use std.getopt?
I don't quite understand what to do if getopt throws. I would
have hoped for something like
int arg1;
string arg2;
auto parser = getopt("opt1", "docstring 1", , "opt2",
"docstring 2", );
try {
auto opts = parser.parse(args)
}
except(BadArguments) {
parser.showHelpString();
}
but instead, the docstring from getopt is only generated if all
arguments are valid, i.e. when it's the least needed because the
user already knew what to input.
What's the proper style, then? Can someone show me a good example
of how to use getopt and the docstring it automatically generates?
Why is there no std.stream anymore?
I'd like to read from a file, one byte at a time, without loading
the whole file in memory.
I was hoping I could do something like
auto f = File("somefile");
foreach(c; f.byChar) {
process(c);
}
but there appears to be no such way to do it anymore. Instead,
the stdlib seems to provide several functions to do chunked reads
from the file where I have to manually manage the buffer. I see
that D1 had a stream, but it's no longer here and I understand
ranges are supposed to be used instead.
What's the explanation here? Why is there no more stream and what
am I supposed to use instead? Do I really need to be manually
managing the read buffer myself?
