Re: reggae v0.10.0 - The meta build system just got better
On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote: https://code.dlang.org/packages/reggae For those who don't know, reggae is a meta-build system for and in D. It's like CMake... How mature is the build system? FWIW, I would like to stay in Meson if I can, since I use C++ also and that makes combining libs and other niceties easier.
Re: Best way to learn 2d games with D?
My two cents doing some 2D stuff for a while (a cards game). 1. stick to SDL2 if you want to have something that will work in many places. SFML AFAIK is not so compatible. From there, maybe I would start by mixing SDL2* libraries and using D with extern(C) interfaces if needed unless there is a well-maintained wrapper. The rest of the alternatives just brought trouble to me when trying to run in many systems.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei
Alexandrescu wrote:
https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
Andrei
I have submitted, already. My major complaints boils down to
the fact that they refuse to deprecated features due to
religious like devotions to backwards compatibility support.
Well, not religious but... they are removing things too slow.
There is a paper about stability and velocity of C++ that
proposes to widen things to move forward faster and... btw I
complained about exactly that as well. Things are getting bigger
and bigger, just discard things. I also complained about the
following:
1.- everyone is saying stop the preprocessor... modules support
no preprocessor after import... ok, then, why feature test
macros? They should be enums or constexpr but never a
preprocessor macro.
2.- the single thing that bothers me the most... initialization
is a mess, especially after adding {} vs (). With good intention,
but the cognitive overhead and room for surprises is too big.
3.- if constexpr cannot simply compete with static if. I
suggested adding: if constexpr that does not require a template
function, and some alternative if constexpr mechanism (I do not
care about the name or if it is a separate feature) that can
conditionally compile structs or block scopes a la version() in
D. This feature is needed to kill the preprocessor if they really
want to take that seriously, especially with modules on its way.
BTW, I have been trying a bit of D lately and I like how flexible
things such as opDispatch and static if are. I love modules as
well. I like a lot also the fact that you do not need to be
prefixing all things all the time because of potential hijacking.
The static reflection has also been useful for me. I was just
coding a SNES ROM parser but that was enough already to show some
of the advantages.
Re: Quora: Why hasn't D started to replace C++?
On Sunday, 11 February 2018 at 14:33:33 UTC, psychoticRabbit wrote: On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote: https://www.quora.com/Why-hasnt-D-started-to-replace-C++ Andrei Why indeed! "I am appalled at the monstrous messes that computer scientists can produce under the name of ‘improvements’. It is to efforts such as C++ that I here refer. These artifacts are filled with frills and features but lack coherence, simplicity, understandability and implementability. If computer scientists could see that art is at the root of the best science, such ugly creatures could never take birth." If it is not implementable (it is complex, I agree), why there are 3 major compilers? I think the future should go towards simplification a bit more for the idiomatic code. But there are features you cannot ignore in low-level languages: asm embedding, bit control, reference vs value, due to register efficiency and others. So I do not think it is such a *super bad* choice. In day-to-day life you need these things.
Re: opDispatch with string mixin does not work as I would expect.
On Saturday, 10 February 2018 at 07:47:58 UTC, Nicholas Wilson
wrote:
On Saturday, 10 February 2018 at 06:32:43 UTC, German Diago
Alternatively you could do something like
auto opDispatch(string name)()
if(hasMember!(HeaderData,name){
readHeader();
return mixin("headerData." ~ name);
}
Do not ask me why but now seems to work with my initial solution.
:)
opDispatch with string mixin does not work as I would expect.
Hello everyone,
I am trying to forward some member functions from a struct as a
Catch-all function, so I did something like this:
struct A {
struct HeaderData {
align(1):
char [21] id;
ubyte field1;
ubyte field2;
}
Nullable!(HeaderData) headerData;
auto opDispatch(string name)() {
readHeader();
static foreach (member; __traits(allMembers,
HeaderData)) {
static if (name == member) {
return mixin("headerData." ~ name);
}
}
}
The mixin line does not work. I want to generate the access to
the field. How could I achieve that?
Re: LDC 1.7.0
On Sunday, 7 January 2018 at 12:22:17 UTC, John Colvin wrote: On Saturday, 6 January 2018 at 16:25:46 UTC, German Diago wrote: - want no gc? Ok, at least there is BetterC, so if I invest myself quite a bit on D (I am the kind of programmer that likes to squeeze power out of machines, so this always means that I will not consider VM languages), I will always have. Also, it's perfectly possible to avoid most of the downsides of the GC (and keep some of the upsides) without worrying about BetterC. @nogc where you need it is great, BetterC is a much more extreme solution. Yes, that is my guess also, but there are chances that I will be in these extreme situations myself, not for my pet projects, but for some embedded stuff I want to do. That is why I want something without runtime for microcontrollers at some point. Just to have the possibility open. For now I think I will stick to C++ for that (a subset) until I am confident D can do perfectly ok there. I know D is designed for that also (modulo GC and runtime) but I still need to see the practical, day to day problems if I use D for such a thing instead of C++, which I know quite well.
Re: LDC 1.7.0
On Monday, 8 January 2018 at 03:14:32 UTC, Joakim wrote: On Saturday, 6 January 2018 at 16:25:46 UTC, German Diago wrote: negative points also as I use it :p. By the way, and a bit off-topic for the post, but, if I want to port my code to run on Android/iOS, what is the recommended way? 1. create a shared library and consume it? Is that possible and smooth enough for ARM? Yes, that is the way native apps are invoked on Android, see the wiki for more info: http://wiki.dlang.org/Build_D_for_Android iOS support is in limbo, as a contributor got very far with it but hasn't had time for it lately. Thanks for the link!
Re: LDC 1.7.0
On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.7. The highlights of this version in a nutshell: * Based on D 2.077.1. * Catching C++ exceptions supported on Linux and Windows. * LLVM for prebuilt packages upgraded to v5.0.1. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0 Thanks to all contributors! I just dropped here to say that I have been considering Nim and D for a while and, to some extent, Rust. You are guys doing a great job shaping D for *real projects*, which is what I care about the most. I think I will definitely go with D finally when I try an alternative to C++ (though C++ still remains my main language). I still have to give it a serious try, but this is what made me convinced: - a superior interoperability story (C and C++, Objective-C, Windows, now adding the C++ exception catching...). I cannot emphasize enough how important this is for me. - a reasonable relearning and upgrade coming from C++. - very powerful generative programming. I see that things like generating bindings for scripting languages and others have an edge with static introspection + mixins. - more mature than Nim, at least at this point. - want no gc? Ok, at least there is BetterC, so if I invest myself quite a bit on D (I am the kind of programmer that likes to squeeze power out of machines, so this always means that I will not consider VM languages), I will always have. I hope I can give it a try with one (or two, to be decided) hobby projects I have been doing for a while. I will report the negative points also as I use it :p. By the way, and a bit off-topic for the post, but, if I want to port my code to run on Android/iOS, what is the recommended way? 1. create a shared library and consume it? Is that possible and smooth enough for ARM? - easy to understand for - a superior metaprogramming experience that is
Re: Post about comparing C, C++ and D performance with a real world project
On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote: On 12/7/17 6:46 AM, Daniel Kozak wrote: Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author You can see the compilation command line if you compile with ninja -v
Re: [OT] LLVM Community Code of Conduct
On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei Alexandrescu wrote: I would agree that we're less polished than Go and other languages. This is something we need to work on - just show the world a completely defined and implemented language. -- Andrei Hello Andrei. A bit off-topic, but, you are on that now, right? I saw in the media you left Facebook to do D things and manage the D foundation. As a proficient C++ coder for many years, but not as much as you :), this was kind of the news of the year for me. I expect a push to the language. I have had high hopes for D, but C++ is also improving. I took a look at Nim and Rust. I think D is more practical for real use at this point. Though, did not try myself on a real scenario, I always end up choosing C++ for my taks because it has great support. My main concerns to changing to D are: - Garbage collector. I think there was a plan for Phobos without GC, but... what about the run-time, can be disabled? I am not sure this meets the requirements of some embedded devices I work/have worked with. - Memory-control: Allocators. I saw this has been solved. - Production-readiness: when I go to C++, the ecosystem is simply unbeatable. This keeps me away from moving to D. - Platform support: For C++, I can use it in phones, embedded, PCs... basically everywhere. What areas are considered "incomplete" as of now to consider D a production-ready product, in your opinion? As a long-term C++ user, I understand D quite well but did not try it a lot for real world use. The standard library looks very good to me, though, I do not know how much it relies on GC at this point. Something that, in C++, I do not need to worry about.
Re: [OT] LLVM Community Code of Conduct
On Friday, 16 October 2015 at 08:58:25 UTC, John Colvin wrote:
void main() @nogc
{
// try stuff out
}
Thanks for the tip. Is this 100% reliable?
As far as I know, yes. @nogc can be put on any function and
will guarantee that no GC code will run inside that function or
anything else it calls.
Is this a static check that fails at compile-time, or it means
that if, at
run-time, gc is invoked, an exception will be thrown? Sorry so
many questions,
I do not have access to a compiler at the moment here.
Re: [OT] LLVM Community Code of Conduct
On Friday, 16 October 2015 at 08:11:18 UTC, John Colvin wrote:
On Friday, 16 October 2015 at 08:03:06 UTC, German Diago wrote:
[...]
Just a small note FYI, there's an easy way to get a feel for
the current state of GC reliance:
void main() @nogc
{
// try stuff out
}
Thanks for the tip. Is this 100% reliable?
