Re: Custom type / Typle type formatted reader
And regarding the rest,
I'm curious about reading back user types, without defining a new
seperate method for it, such as structs, unions and tuples,
(although I'm unsure to what extent tuples are really a
user-defined-type).
The other thing just resolved itself;
I was wondering, as slurp kind of already reads tuples from
files, whether or not it's possible to tell it what tuple you
want it to read, instead of redefining a possibly previously
aliased tuple.
It seems now I found a way to do just that . . . I honestly don't
know why this went wrong before, must have made a mistake
somewhere. This now works:
alias Entry = Tuple!(int, "a", char, "b");
Entry[] results = slurp!Entry("temp.txt", "%s %s");
results.writeln;
Im actually kind of surprised it does, as nothing in the
documentation seems to hint to me this makes sense, neither did I
find any example like it elsewhere.
Re: Custom type / Typle type formatted reader
On Thursday, 31 December 2020 at 18:19:54 UTC, Ali Çehreli wrote:
Can you describe it with a piece of code? If the code shows
what the current undesired output is and what you want instead,
perhaps we can find a solution.
Regarding the enum part;
While trying to do this I noticed one cannot use either slurp or
formattedRead to read enums, while it is possible to use
formattedWrite and write to write them.
Strangely enough this was also mentioned in old issue '18051'
(https://forum.dlang.org/thread/mailman.735.1512835762.9493.digitalmars-d-b...@puremagic.com) which should have been resolved.
Example code;
```
import std.stdio;
import std.file : slurp;
import std.format;
import std.typecons;
enum Thing {
A,
B
}
void main() {
File file = File("temp.txt", "r");
foreach (line; file.byLine) {
int integer;
Thing thing;
formattedRead!"%s %s"(line, integer, thing); // crashes with
thing as Thing, works with thing as char.
formattedWrite(stdout.lockingTextWriter, "%s %s\n", integer,
thing);
}
}
```
Re: Associative Array Question
On Friday, 1 January 2021 at 01:43:50 UTC, Chris Bare wrote: a1[10] = "testing a1"; this actually constructs a new thing since it is a straight x = y assignment. a2[10].name = "testing a2"; But this looks up something first. It doesn't construct a2[10], it looks it up first to fetch the name member... hence the range violation since it isn't constructed yet. a3[10] = new Project; and this again will construct since it is a straight x = y again. So you could also do a2[10] = Person() then do the lookup of name
Associative Array Question
I'm missing something about the way associative arrays are
allocated.
In the example below, case 1 and case 2 seem to be the same, a
type indexed by a long.
Case 2 fails with a Range violation.
Can someone explain the difference?
I found a work around (or the correct way) in case 3.
struct Project
{
string date;
string name;
}
// case 1
string[long] a1;
a1[10] = "testing a1";
foreach (f; a1)
writeln ("name ", f);
// case 2
Project[long] a2;
a2[10].name = "testing a2";
foreach (f; a2)
writeln ("name ", f.name);
// case 3
Project*[long] a3;
a3[10] = new Project;
a3[10].name = "testing a3";
foreach (f; a3)
writeln ("name ", f.name);
Re: C++ or D?
On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe wrote: On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim Grøstad wrote: What would you like to see? For shared to mean something. Stackless coroutines. Compile-time lifetime management, i.e. better ways to define ownership. I second that. At least some way to know whether a pointer takes ownership (GC/RC) or just is an auxiliary reference.
Re: C++ or D?
On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim Grøstad wrote: On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe wrote: It could take a few years indeed, but what will D do in that same time window? What would you like to see? For shared to mean something. Stackless coroutines. Compile-time lifetime management, i.e. better ways to define ownership.
Re: C++ or D?
On Thursday, 31 December 2020 at 18:13:40 UTC, Imperatorn wrote: I was a bit unclear. I meant features as in built in language constructs etc, not necessarily like keywords and so on. You mean like associative arrays and dynamic arrays? If so then I guess people have different taste, I think it was a mistake to make those builtins... I find code harder to read when symbols (e.g. "!") have so many meanings in D. I am creating my own experimental unicode-syntax now where each symbol has only one meaning... kinda like a prototype for testing the idea of using the full unicode charset for programming. So not necessarily a D specific issue, but D is a nice testbed for experimenting as it has so many features. Hmm, regarding features I'd like in C++, maybe better metaprogramming and fewer keywords? Haven't thought about that I've never run into meta programming problems that I cannot deal with in C++ in way that works out ok in the end, but sometimes you have to search the web. Fortunately there are many "recipes" for big languages... without that... uhm. Then C++ would be a very difficult thing to handle :-D. What I don't like about C++ is that things get verbose, but verbosity has some advantages when programs get very large because then you need more context to understand what is going on and where things are coming from. It isn't obvious that something that is good for a medium sized program will be good for a very large program (e.g. "where did this symbol come from?"). You won't really find out until you've tried... but most D programs are small, so. No need to worry about that...
Re: Missing D files
On Thursday, 31 December 2020 at 16:49:53 UTC, LorenDB wrote: On Thursday, 31 December 2020 at 16:28:03 UTC, Adam D. Ruppe wrote: Or just replace it in the generated files in a second pass. Maybe that could be my first useful (ok, first non-"Hello world!") program in D. So I've written a program that fixes these statements: https://github.com/LorenDB/modern-d-swig. It works fine and eliminates the error about C's string library; however, the problem is that the linux library error is still alive and kicking. I've looked around in the D include path and found that there isn't even a `linux.d` file (<= The markdown bug keeps getting me :D). Swig is trying to import `std.c.linux.linux`. My program changes that to `core.stdc.linux.linux`, which doesn't exist. There is a folder in the include path called "linux" that goes like this: `core/sys/linux/` but there isn't any linux.d file. Looking at the Swig-generated code, I think that I might be best off trying to import Linux's dll functions. Let me give it a go... ...and the Linux error is gone! I'll have to mark this one down for my modernizing app.
Re: Custom type / Typle type formatted reader
On 12/31/20 8:36 AM, Rekel wrote: 🤔I'm either asking a stupid question, asking it in a wrong way, or asking an important question. Clueless nontheless. . . Your post was interesting to me but trying to duplicate your situation seemed difficult. Can you describe it with a piece of code? If the code shows what the current undesired output is and what you want instead, perhaps we can find a solution. Ali
Re: C++ or D?
On Thursday, 31 December 2020 at 11:29:55 UTC, Ola Fosheim Grostad wrote: On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote: On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: nowhere. Just use D and be happy and let others use C++ and let them be happy. But they should be aware that C++ *as a language* has a long way to go before it gets all the features etc that D has. Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, but not for me. Which features are you most concerned about? I think the feature set is quite similar. D is less verbose and is easier to use for high level programming, but the clang++ and g++ have fewer bugs and quirks than the D compilers. The biggest difference is that C++ cannot change much, but D can! D really ought to make more of that advantage... More streamlining even if it breaks stuff. I was a bit unclear. I meant features as in built in language constructs etc, not necessarily like keywords and so on. Hmm, regarding features I'd like in C++, maybe better metaprogramming and fewer keywords? Haven't thought about that https://github.com/AnthonyCalandra/modern-cpp-features
Re: C++ or D?
On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe wrote: On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote: On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: [...] But they should be aware that C++ *as a language* has a long way to go before it gets all the features etc that D has. Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, but not for me. Au contraire; I find that C++ has modernised relatively successful and has a lot of great proposals in the pipeline. Of course they may all get rejected, but even if only some of them get accepted, C++ starts to have a leg up on D in my opinion. It could take a few years indeed, but what will D do in that same time window? That's true, but until that happens D is superior. Time will tell 😊
Re: Missing D files
On Thursday, 31 December 2020 at 16:28:03 UTC, Adam D. Ruppe wrote: Or just replace it in the generated files in a second pass. Maybe that could be my first useful (ok, first non-"Hello world!") program in D.
Re: Custom type / Typle type formatted reader
🤔I'm either asking a stupid question, asking it in a wrong way, or asking an important question. Clueless nontheless. . .
Re: Missing D files
On Thursday, 31 December 2020 at 15:54:58 UTC, Paul Backus wrote: The D module corresponding to the C header `string.h` is `core.stdc.string`, but it's trying to import it as `std.c.string`. It used to be std.c.* many years ago, so it is probably just an old converter. Probably an easy enough update if you have the source. Or just replace it in the generated files in a second pass.
Re: C++ or D?
On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe wrote: It could take a few years indeed, but what will D do in that same time window? What would you like to see?
Re: Missing D files
On Thursday, 31 December 2020 at 15:01:04 UTC, LorenDB wrote: I'm trying to learn D, but at the same time I'm trying to generate a Qt binding for D (yes, yes, Qte5, but I don't like the dynamic loading of libraries that Qte5 uses). I know that this is probably a bad stage of the game to be making bindings, but... Anyway, I'm using Swig to create a wrapper for the Qt files. While creating the first wrapper (QObject), I ran across some errors: ``` Performing "debug" build using ldc2 for x86_64. qt5-d ~master: building configuration "application"... source/QtCore/QObject_im.d(51,19): Error: module string is in file 'std/c/string.d' which cannot be read This looks like a bug in Swig. The D module corresponding to the C header `string.h` is `core.stdc.string`, but it's trying to import it as `std.c.string`.
Re: Missing D files
On 12/31/20 10:01 AM, LorenDB wrote: I'm trying to learn D, but at the same time I'm trying to generate a Qt binding for D (yes, yes, Qte5, but I don't like the dynamic loading of libraries that Qte5 uses). I know that this is probably a bad stage of the game to be making bindings, but... Anyway, I'm using Swig to create a wrapper for the Qt files. While creating the first wrapper (QObject), I ran across some errors: ``` Performing "debug" build using ldc2 for x86_64. qt5-d ~master: building configuration "application"... source/QtCore/QObject_im.d(51,19): Error: module string is in file 'std/c/string.d' which cannot be read import path[0] = source/ import path[1] = /usr/lib/ldc/x86_64-linux-gnu/include/d import path[2] = /usr/include/d source/QtCore/QObject_im.d(121,14): Error: module linux is in file 'std/c/linux/linux.d' which cannot be read import path[0] = source/ import path[1] = /usr/lib/ldc/x86_64-linux-gnu/include/d import path[2] = /usr/include/d ldc2 failed with exit code 1. ``` (This forum needs inline Markdown.) I have no idea where I'm supposed to get "std/c/linux/linux.d" and "std/c/string.d". I'm on Ubuntu 20.04 using the bundled ldc2 and corresponding libphobos. Any suggestions? That's pretty old. std.c is now core.stdc Swig may need some updating if it's generating links to that package. -Steve
Missing D files
I'm trying to learn D, but at the same time I'm trying to generate a Qt binding for D (yes, yes, Qte5, but I don't like the dynamic loading of libraries that Qte5 uses). I know that this is probably a bad stage of the game to be making bindings, but... Anyway, I'm using Swig to create a wrapper for the Qt files. While creating the first wrapper (QObject), I ran across some errors: ``` Performing "debug" build using ldc2 for x86_64. qt5-d ~master: building configuration "application"... source/QtCore/QObject_im.d(51,19): Error: module string is in file 'std/c/string.d' which cannot be read import path[0] = source/ import path[1] = /usr/lib/ldc/x86_64-linux-gnu/include/d import path[2] = /usr/include/d source/QtCore/QObject_im.d(121,14): Error: module linux is in file 'std/c/linux/linux.d' which cannot be read import path[0] = source/ import path[1] = /usr/lib/ldc/x86_64-linux-gnu/include/d import path[2] = /usr/include/d ldc2 failed with exit code 1. ``` (This forum needs inline Markdown.) I have no idea where I'm supposed to get "std/c/linux/linux.d" and "std/c/string.d". I'm on Ubuntu 20.04 using the bundled ldc2 and corresponding libphobos. Any suggestions?
Re: C++ or D?
On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote: On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: Sorry for the spam, but this is because of people like him that people like me (i discovered D recently) that can't be aware of why D is a great language They diminish all arguments that makes D better than alternatives You guys have to help me fight that kind of behavior, because it doesn't help D, as if it was their goal, do they want to make sure D doesn't eat specific market share, so some other language can? fishy fishy But they should be aware that C++ *as a language* has a long way to go before it gets all the features etc that D has. Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, but not for me. Au contraire; I find that C++ has modernised relatively successful and has a lot of great proposals in the pipeline. Of course they may all get rejected, but even if only some of them get accepted, C++ starts to have a leg up on D in my opinion. It could take a few years indeed, but what will D do in that same time window?
Re: C++ or D?
On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote: On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: nowhere. Just use D and be happy and let others use C++ and let them be happy. But they should be aware that C++ *as a language* has a long way to go before it gets all the features etc that D has. Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, but not for me. Which features are you most concerned about? I think the feature set is quite similar. D is less verbose and is easier to use for high level programming, but the clang++ and g++ have fewer bugs and quirks than the D compilers. The biggest difference is that C++ cannot change much, but D can! D really ought to make more of that advantage... More streamlining even if it breaks stuff.
Re: C++ or D?
On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: Sorry for the spam, but this is because of people like him that people like me (i discovered D recently) that can't be aware of why D is a great language They diminish all arguments that makes D better than alternatives You guys have to help me fight that kind of behavior, because it doesn't help D, as if it was their goal, do they want to make sure D doesn't eat specific market share, so some other language can? fishy fishy I have found that these kinds of language wars often get nowhere. Just use D and be happy and let others use C++ and let them be happy. But they should be aware that C++ *as a language* has a long way to go before it gets all the features etc that D has. Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, but not for me.
