Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
On Thursday, 30 August 2018 at 12:18:10 UTC, Elie Morisse wrote: On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer wrote: I filed a bug about a similar thing (calling private functions instead of using private variables), but it seemed to be agreed upon that this is expected behavior: https://issues.dlang.org/show_bug.cgi?id=15897 You may find some more insight from reading that discussion. I don't agree with the conclusion, as it is very surprising behavior to me. -Steve Not the same, bauss' case is a template method that wouldn't get the depreciation warning if it wasn't templated. Template instances not always having the same access privileges as their template declaration's is definitely a bug. Or actually since I didn't test the code it's more likely just due to T being Bar, in which case there's no reason to make the cast to Foo mandatory since Foo's field get accessed from Foo's method.
Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer wrote: I filed a bug about a similar thing (calling private functions instead of using private variables), but it seemed to be agreed upon that this is expected behavior: https://issues.dlang.org/show_bug.cgi?id=15897 You may find some more insight from reading that discussion. I don't agree with the conclusion, as it is very surprising behavior to me. -Steve Not the same, bauss' case is a template method that wouldn't get the depreciation warning if it wasn't templated. Template instances not always having the same access privileges as their template declaration's is definitely a bug.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values": https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md Yay! Thank you Manu for taking the time to write the DIP, and I greatly hope that it will get accepted and implemented quickly. Code interacting with C++ libraries will become infinitely more readable, and from the endless past discussions on the topic no real drawback ever emerged, in my opinion.
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote: On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote: Know what is a heavyweight problem worth our while? Having dmd be able to directly read C .h files, so the poor user does not have to manually translate them. We've already got a huge chunk of that problem solved. The Digital Mars C/C++ front end is now Boost licensed. It can be used. It's already been converted to D! The preprocessor in it is a bit dated and a bit too specific to Windows - but we've got Warp now! Replace the preprocessor in dmc++ with Warp, slice off the back end, and make it a module that dmd can import. Wouldn't it be nice to support: import stdio.h;// Look, Ma! C headers! There are some intractable issues, and it may be impossible to get 100% to "it just works", but looking past that it might be a huge win for us. Wow, you converted DMC++'s front-end to D? To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described isn't dead (it just revived a few weeks ago from a long slumber) and it should be possible to make a smaller codegen-less version for DMD that only depends on a few Clang and LLVM support libraries. Another possibility..
Re: Solving the spurious forward/cyclic reference errors in DMD
I'll start working on this tomorrow, so if you believe this effort will be in vain, please leave a comment.
Solving the spurious forward/cyclic reference errors in DMD
Timon, any update on this? What are the insights you gained with
your frontend?
I recently reported two cases without a simple fix:
https://issues.dlang.org/show_bug.cgi?id=17656
https://issues.dlang.org/show_bug.cgi?id=17194#c1
and have seen a lot more referencing errors with Calypso,
especially when this gets enabled:
https://github.com/Syniurge/Calypso/commit/1e1ae319e32120bd9ef0009716ddabed92f69ac2
Calypso makes its mapped C++ symbols go through the same
importAll -> semantic1,2,3 route that D symbols take. Ultimately
this is mostly useless work that should be skipped, the reason it
currently works this way being that I wasn't familiar yet with
the DMD source code when I started. But what this hard and
ungrateful work has also been doing (and many large libraries are
blocked by this) is exposing a seemingly infinite number of bogus
forward/circular/misc referencing DMD errors.
Those errors boil down to semantic calls getting triggered at the
wrong time, on symbols that the caller doesn't really depend upon.
Because most of the time, the semantic() call on the LHS of
DotXXXExp, inside AggregateDeclaration.determineSize, etc. is
there in case there are:
- mixins to expand
- attributes whose members have to be added to the parent symtab
- if LHS is a template to instantiate
These are (AFAIK) the only cases where the symtab of the LHS or
the aggregate may get altered, and if I understand correctly
that's what the semantic call is checking before searching for
the RHS or determining the aggregate fields and then its size.
So would splitting semantic() into determineMembers() preceding
the rest of semantic() be worth exploring? The thing is, this
would help in most cases but I can imagine scenarios where simply
splitting may not be enough. Example:
enum E { OOO = S.UUU }
import std.conv;
string genMember1() { return "enum G8H9 = " ~
(cast(int)E.OOO).to!string; }
string genMember2() { return "enum UUU = 1;"; }
struct S {
mixin(genMember1());
mixin(genMember2());
}
We'll have S.determineMembers -> E.OOO.semantic ->
S.determineMembers, and although in this case the value of OOO
may be interpreted to 1, at this point the compiler can't easily
know whether mixins will generate zero, one or more UUU members
or not. To attenuate the problem determineMembers() could be made
be callable multiple times (recursively), each time starting from
where the previous (on-going) call left off, so in this
particular case the second S.determineMembers call would expand
the second mixin to enum UUU = 1. But then how does the compiler
knows and react if genMember1 generate a new UUU member? Ok a
second UUU enum will error, but what if UUU was a function and
genMember1() generates a more specialized overload of UUU? I.e:
enum E { OOO = S.UUU(1) }
import std.conv;
string genMember1() { return "static int UUU(int n) { return n;
}; enum G8H9 = " ~ (cast(int)E.OOO).to!string; }
string genMember2() { return "static int UUU(int n, int a = 5) {
return n + 5; }"; }
struct S {
mixin(genMember1());
mixin(genMember2());
}
At this point well it's getting a bit contrived, so maybe it's
not really worth finding a solution to make this compile (but
ideally the compiler should still warn the user).
Should I try splitting semantic() and make a PR? It might be a
lot of work, so I'd like to know if this makes sense first.
Re: Need DMD AST expertise
On Tuesday, 21 June 2016 at 19:42:54 UTC, Elie Morisse wrote: On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet wrote: « (cast(TypeFunction) fd->type)->parameters » Mixing C++ and D once more..
Re: Need DMD AST expertise
On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet wrote: I'll have a look at `parameters` from TemplateDeclaration [2] but I still need to match it to the function arguments somehow. The templated function is the child symbol of the TemplateDeclaration which shares the same name i.e Dsymbol* s; Dsymbol.oneMembers(tempdecl->members, &s, tempdecl->ident); auto fd = cast(FuncDeclaration) s; You then need to visit the templated function parameters « (cast(TypeFunction) fd->type)->parameters » and look for identifiers that match the TemplateDeclaration.parameters[].ident. In the simplest cases the types of templated function parameters are TypeIdentifier.
Re: D frontend
On Friday, 6 May 2016 at 09:34:39 UTC, Timon Gehr wrote: One major goal of this project is to figure out a good way to handle non-trivial compile-time dependency structures (i.e. solving the "forward reference error" problem). As it does explicit dependency tracking on AST nodes, it can possibly be used for fine-grained (AST-level) incremental compilation in the future. Great initiative! While mapping big C++ librairies with a lot of templates with Calypso I still hit forward referencing errors from time to time. Some of them were easily fixed but I feel that making the whole thing more robust is a complex task that can't be achieved through small fixes/hacks, it needs a drastic solution like yours.
Re: Fun with extern(C++)
On Tuesday, 26 January 2016 at 15:53:39 UTC, Manu wrote:
So, you're saying that if you have an 'I' pointer, which may be
implemented by a C++ class, it still needs to be able to cast
to Object, and therefore fails? I wonder if a C++ class could
somehow be promoted to a D class when being derived in D, by
having an Object placed somewhere.
It helps that Object is a just a handful of virtual methods.
On Tuesday, 26 January 2016 at 16:25:35 UTC, Benjamin Thaut wrote:
For a D class the first entry in the vtable is the classinfo.
Thus the problem if you derive a D class from a extern(C++)
base class. I don't see any way to actually fix this, adjusting
the this pointer won't help. Once you derive a D class from a
extern(C++) base class it is no longer a fully functional D
class. For example monitor (e.g. synchronized methods) won't
work.
Calypso has "hybrid" D classes inheriting from C++, with this
layout:
- D vptr
- D monitor
{ start of C++ class }
- C++ vptr
- C++ fields...
- might be other vptr and fields if the C++ class has more than
one base
{ end of C++ class }
- D fields...
and when downcasted to the C++ base class the "this" pointer gets
adjusted to point towards the start of the C++ class.
Re: Catching C++ Exceptions in D
On Tuesday, 5 January 2016 at 20:07:11 UTC, Walter Bright wrote: On 1/5/2016 10:51 AM, Elie Morisse wrote: why not distinguish C++ exceptions from D ones in the personality routine? How? Are you aware of https://syniurgeblog.wordpress.com/2015/11/20/calypso-catching-cpp-exceptions-in-d/? For DMD if the personality functions sees the C++ exception class (3rd arg passed to the personality func) would it be hard to make it look for C++ catch clauses? With Calypso those catch clauses are std::type_info pointers wrapped inside a D class so that cast() is used to differentiate D catch clauses from C++ ones in the action table, and the personality function match those std::type_info against the one from the C++ exception header by calling the virtual function type_info::__do_catch(type_info*). A single personality routine handles both D and C++ exceptions, and I don't think having a different one for C++ exceptions would make things much easier. The tricky part for DMD is probably the std::type_info generation.
Re: Catching C++ Exceptions in D
On Tuesday, 5 January 2016 at 17:23:38 UTC, Walter Bright wrote: Function bodies cannot mix catching C++ and D exceptions. (The reason is C++ catch types need to be distinguished from D catch types, and the most straightforward method to deal with that is have a different 'personality' function for functions that catch C++ exceptions.) why not distinguish C++ exceptions from D ones in the personality routine?
Re: Catching C++ std::exception in D
Sorry for the delay, here's the initial commit for C++ exception catching in Calypso: https://github.com/Syniurge/Calypso/commit/8b55ec1f013c29df86455ab055fbba91a72d92af https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1 The main files of interest are: https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/cpp/gnu.d https://github.com/Syniurge/Calypso/blob/master/gen/cpp/cppeh.cpp And a basic example which segfaults at e.what() because __cxa_begin_catch returns null: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d Resulting IR : https://paste.kde.org/pvi2bokqx catch (C++) were added to be able to catch any type, and that's the only cost for being able to catch any C++ exception and not just std::exception I think, Clang and the libstdc++ makes working with std::type_info very easy. For the time the handler uses unwind-cxx.h copied from GNU's libstdc++ (it's an internal header which doesn't ship with any Ubuntu package). Its license is more permissive than the GPL, but if it isn't compatible it could be replaced by its libc++ equivalent.
Re: Catching C++ std::exception in D
On Thursday, 12 November 2015 at 06:50:31 UTC, Walter Bright wrote: In order to interoperate with modern C++, it has been abundantly clear for some time that D needs some support for C++ exception handling: 1. Have D finally blocks executed in D code that sits between a C++ try and catch 2. Have C++ finally blocks executed in C++ code that sits between a D try and catch 3. Be able to catch in D code an std::exception* or a C++ class derived from that. 4. Throw an std::exception* from D code. That's the minimum credible support, and is likely all D will actually need. I also started working on C++ exception handling for LDC/Calypso, I almost caught my first std::exception yesterday! (it went into the right catch and the IR looks right but _cxa_begin_catch() seems to return null instead of the exception object for some reason) Clang and Calypso made the std::type_info stuff a breeze, getting the type_info value for any C++ type was one line of code. I'll push the changes as is into a branch tonight, it's about ~400 lines. The tricky part with the personality function will likely be recognizing std::exception* exceptions. I wonder if forwarding the call to __gxx_personality_v0 will work. From what I gathered even if you manage to make the format of the LSDA tables compatible with __gxx_personality_v0, one blocker is that it still expects std::type_info pointers in the action table so will choke if it encounters D's TypeInfo_Class in there. To check if a type_info from a catch clause handles the thrown exception it calls the virtual method type_info::__do_catch (which is what Calypso does too) so can't work with D classes.
Re: DMD 2.68's promised C++ interface
On Monday, 20 July 2015 at 16:06:43 UTC, Shriramana Sharma wrote: I really really want to interface to Qt 5 and am groping in the dark here as to what to do with c'tors, inheritance, &c &c... Maybe not the original meaning of the promise but: http://forum.dlang.org/thread/xzjsdsuskarkllhmw...@forum.dlang.org Despite the lack of update it has kept progressing and I'm within an inch or two of breaking the silence and making a new announcement. It's pretty close to usability with C++ libraries of any complexity. The approach is not the official one though, and ties yourself to LDC until probably a very long time. (Calypso was helped by the code cleanness of Clang, does GCC offer things like template instantiation or vtable manipulation by an outsider without having to alter too much the code of GCC? and a DMD version would probably be multiple orders of magnitude harder to do)
Re: Mitigating the attribute proliferation - attribute inference for functions
Freeing D users from the burden of writing redundant attributes that the compiler can infer would be a fantastic enhancement imo. For public functions I was thinking of a way to make inference safer: generating a .di file with the inferred attributes and auto substituted by the return type, and then make the compiler check the inferred attributes against the previous ones and trigger an error if there was an API breakage, forcing the programmer to acknowledge it by removing the function from the .di file, or by fixing the function to match its previous signature. Would this make inference safe enough for public functions?
Re: Mid-term vision review
On Friday, 3 April 2015 at 21:59:38 UTC, Kai Nacke wrote: On Friday, 3 April 2015 at 18:04:14 UTC, deadalnix wrote: Also, what are the plan for GDC and LDC if we move toward DDMD ? My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work... Regards, Kai Bindings for LLVM and GCC would still have to be written/generated (and work). Calypso could help with building D versions of GDC and LDC, H1 seems a bit early but it's shaping up.
Re: C++ to D
On Tuesday, 31 March 2015 at 20:37:37 UTC, Jeff Jones wrote: Is it possible to modify either a C++ compiler or in code to make classes more D ish? e.g., instead of just the vtable(which, IIRC is slightly different between the two) add the metadata pointer and whatever else? What I'm getting at, is there a somewhat simple way(not creating a new C++ but either through macros, small compiler changes, or whatever) to make C++ objects D compatible instead of the other way? I.e., we can't take anything away from D classes since we will break D. But we should be able to add to C++ classes without breaking C++. If we can add the info that D needs then both should get along happily? I'm mainly talking about a simple code based solution but I'm also curious about how easily this would be by compiler modification. You can't make the layout of C++ classes inheriting from multiple bases match D's class layouts because D's multiple inheritance is more limited. Also a big downside is that "D-flavored ABI" C++ binaries couldn't interact easily with "normal ABI" C++ binaries because even if the modified C++ compiler is explicitly told which library/set of headers is normal and which isn't, the usage of any class from the normal C++ libs by D-flavored ones will form a mixture of both ABI so not usable by D, and it's not helping that some classes can be codegen'd into several libs. So every C++ lib would need to be recompiled to avoid the ramifications of interacting with both ABI? From my time poking around Clang's code it just seems easier and more convenient to reimplement C++ multiple inheritance and downcasts in DMD.
Re: DDMD just went green on all platforms for the first time
On Saturday, 21 February 2015 at 14:02:41 UTC, Daniel Murphy wrote: https://auto-tester.puremagic.com/?projectid=10 This is a pretty big milestone for the project. For the first time, an unpatched dmd can build ddmd, and that ddmd can build druntime and phobos and pass all the test suites. Hopefully in the next couple of weeks the remaining minor issues will be fixed (eg makefile changes, ddmd runs out of memory compiling std.algorithm unittests on win64) and we can start adding ddmd to master alongside the C++ compiler. A big thanks to Brad for upgrading the autotester, and to everyone who has helped fix bugs and get patches merged over the last couple of years. Github shows 376 closed DDMD pull requests, which is about 8% of all dmd pull requests ever. WOW!²
Re: Kythe
On Tuesday, 27 January 2015 at 18:55:13 UTC, Andrei Alexandrescu wrote: Google just open sourced https://github.com/google/kythe. Would it help Calypso? -- Andrei Not sure how it would help. Kythe seems to handle every C++ feature but if I understand correctly it translates the AST into its own representation and that's it with Clang, whereas Calypso needs to make Clang instantiate templates and to use its codegen. Maybe if Kythe was expanded it could serve as the basis for language extensions, make the writing of new plugins easier and more uniform. If they add GCC to the supported C++ compilers that'd form a single interface to both Clang and GCC's AST.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 19:35:11 UTC, Laeeth Isharc wrote: I posted some thoughts on web docs writeup of C+= interface here. http://forum.dlang.org/thread/fmjehcyzhnirybmnj...@forum.dlang.org#post-fmjehcyzhnirybmnjloj:40forum.dlang.org Do you think we could make binaries of calypso available for download ? I know it is alpha, but it is so strategically important, and just getting clang to build is not always so easy given the stuff in gcc 4.9 with size__align_t ? We should mention calypso in the web docs, and link to it too (with appropriate caveats). It feel slightly too early, Calypso shouldn't be far from getting most of the C++ standard library to work but it still chokes on most tangles of templates (afaics it all boils down to a few issues). Also operators, function templates and merging latest LDC would be nice and not a lot of work away (last merge was mid-October, before better Win64 ABI support). As soon as this is done I'll make builds for Windows and Linux users.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 00:37:02 UTC, Walter Bright wrote: Excuse the creator's bias :) I agree that Jacob's description makes things more clear, added!
Re: Calypso and the future of D
On Sunday, 25 January 2015 at 22:45:31 UTC, Walter Bright wrote: Not what I meant. What does parse.c have to do with the user of Calypso? How does the user use Calypso? Where is Calypso? How do I run Calypso? A user of Calypso will be baffled when encountering user documentation of Calypso that explains it in terms of dmd internal source code. Is the new README any better? Once I succeed making the nature of Calypso intelligible does the showcase example seem self-explaining enough to make the usage straightforward?
Re: Calypso and the future of D
On Sunday, 25 January 2015 at 10:18:34 UTC, Walter Bright wrote:
Next, in the README example, it says:
$ clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o
$ ar rcs libshowcase.a showcase.cpp.o
$ ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++
showcase.d
Where's Calypso in that?
On Sunday, 25 January 2015 at 11:12:50 UTC, Kelly wrote:
Calypso is part ldc2 and, as far as I understand it, is invoked
via the "-cpp-args" command line arg.
-cpp-args is only to pass arguments to Clang while generating the
precompiled header.
Calypso registers itself as a "language plugin", and when parse.c
encounters « import (ABC) xxx.yyy; » it asks the registered
plugins if one of them handles the "ABC" language id. If that's
the case it lets the plugin create the Import symbol by itself,
for instance Calypso creates a cpp::Import which derives from
Import and has a completely different load() method, which won't
look for modules in .d files but inside the PCH generated by
Clang.
Here's the LangPlugin interface:
class LangPlugin
{
public:
// returns -1 if said lang isn't handled by this plugin, or
its id number
// to be passed to createImport otherwise
virtual int doesHandleModmap(const utf8_t *lang) = 0;
virtual Modmap *createModmap(int langId,
Loc loc, Expression *arg) = 0;
// returns -1 if said tree isn't handled by this plugin, or
its id number
// to be passed to createImport otherwise
virtual int doesHandleImport(const utf8_t *tree) = 0;
virtual Import *createImport(int treeId,
Loc loc, Identifiers *packages, Identifier *id,
Identifier *aliasId, int isstatic) = 0;
// = - - - - - = //
virtual Expression *getRightThis(Loc loc, Scope *sc,
AggregateDeclaration *ad,
Expression *e1, Declaration *var, int flag = 0) = 0;
// = - - - - - = //
virtual FuncDeclaration *buildDtor(AggregateDeclaration *ad,
Scope *sc) = 0;
virtual FuncDeclaration *buildCpCtor(StructDeclaration *sd,
Scope *sc) = 0;
// = - - - - - = //
virtual CodeGen *codegen() = 0;
};
getRightThis, buildDtor and buildCpCtor are needed because they
"override" the global functions with the same name.
About Andrei's query about a general plugin system I don't know
how one could be architectured. The hooks created for Calypso are
specific to C++, so the help I could get is simply to be open to
those hooks (which aren't really intrusive and don't uglify the
code except for one or two that could probably be done
differently:
https://github.com/Syniurge/Calypso/commit/debd83f49363bf6805573d141a62b25d068d8a14)
The problem with arbitrarily limiting where the hooks could occur
is that it might force the plugins to copy and paste redundantly
the base functions, which is bad especially for big semantic()
functions.
This probably deserves more thought, maybe there's a more elegant
way waiting to be found.
Re: Calypso and the future of D
The README should be clearer now about what Calypso is supposed to do, links to the showcase example which I improved and expanded with a template partial and explicit spec example, and explains how to build it and link it to a C++ library. (thanks to the simple partial spec example a nasty oversight about partial specializations was also fixed in the process, which may well be the #1 source of the snags I hit while importing Ogre)
Re: Calypso and the future of D
On Friday, 23 January 2015 at 00:24:45 UTC, Andrei Alexandrescu wrote: I think it's important that we enable Calypso (https://github.com/Syniurge/Calypso) and related tooling that interfaces D with other languages, notably C++. A key topic in 2015 for D is playing well with C++. A good C++ interface will give access to a host of mature C++ libraries, starting of course with the C++ standard library. More importantly, it will provide a smooth migration path for organizations that want to do development in D whilst taking advantage of their legacy code. I'd like to open the topic of "what can we do in core D to make Calypso better". But first, I want to get better acquainted with Calypso and raise awareness of it with coworkers and the larger community. To my dismay, the github homepage provides exactly zero "look and feel" use examples beyond the mechanics of building Calypso itself. To Calypso's creator: is it possible to beef up the documentation of Calypso with a few use cases? Ideally there'd be a soup-to-nuts step by step guide of making a C++ library (either artificial or extant) interfacing with D. Also: what things on the D side would be necessary to make the interface better? Exceptions would be an obvious topic on which we have an attack already (more on it later). Andrei thanks for finally sharing your thoughts on the matter :-) I'll see what I can do this week-end to expand examples and write a tutorial. As for what could be done in core D, I haven't struck anything blocking while writing Calypso. Exception catching is next after the first light of my Ogre3D demo, Clang will probably simplify handling of C++ exceptions a lot.
Re: @api: One attribute to rule them All
On Tuesday, 6 January 2015 at 12:07:21 UTC, Joseph Rushton
Wakeling wrote:
I think you have missed the point I was making.
If you have final-by-default for classes, and you accidentally
forget to tag a public method as 'virtual', then you can fix
that without breaking any downstream user's code. If by
contrast you have virtual-by-default and you accidentally
forget to tag a public method as 'final', then you can't fix
that without the risk of breaking downstream; _someone_ may
have relied on that function being virtual.
For people making libraries which really need to keep ABI
compatibility there should be some quick trick to tell the
compiler to build those ABI-stable interfaces like:
class {
final @api:
...
virtual @api:
...
}
It's imho a small price to pay for not having to always write
explicit attributes for most D functions.
Re: D and Nim
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote: Hey folks, I've been recently checking out Nim/rod and feel like it takes a lot of inspiration from D (I think the creator was in the D community too as some point). How do you think it compares? What areas does D, in principle, makes it a better choice? To give you my background, I like creating games (mostly using SDL bindings) using new languages, aiming for the most efficient yet concise way to write the engine and game logic. FYI, this is NOT a language war thread. I'm just curious about what separates them from a principle level. D and Nim have similar goals (conciseness, CTFE, other advanced metaprogramming features to reduce code redundancies to zero..), but although Nim has cool ideas it's not without some drawbacks: - Only limited polymorphism, Nim doesn't use virtual tables but dispatch trees for performance, and that means that you can't have "opaque" base classes running derived methods if the overriding methods are unknown to the compiler: http://nim-lang.org/manual.html#multi-methods http://forum.nimrod-lang.org/t/278 - No conditional evaluation of code - No type traits - Declarations are order-dependent - Generics are redundant with templates (they are going to be removed though: http://forum.nimrod-lang.org/t/638 ) IMHO the two languages are similar but D is more advanced, and apart from AST macros I don't see any notable appealing features from Nim compared to D.
Re: Happy new year!
Happy new year everyone!
Re: 2 types of D users, both can live together happily if we adjust
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote: (...) IMHO you should be ready to debug the compiler. DMD's codebase can be obscure at times (while the LDC mid-end is pretty straightforward) so the first time looking for the source of a bug may be a frustrating and time-consuming learning experience, but you'll be empowered to tackle compiler bugs without relying on volunteers to do it for you, and without stopping D from evolving.
Re: Stroustrup's slides about c++11 and c++14
On Saturday, 13 September 2014 at 20:10:55 UTC, eles wrote:
Are those points valid?:
static if is a total abomination
• Unstructured, can do everything (just like goto)
• Complicates static analysis (AST-based tools get hard to
write)
• Blocks the path for concepts
• Specifies how things are done (implementation)
• Is three slightly different “ifs” using a common syntax
• Redefines the meaning of common notation (such as { ... })
The lack of « something like static if » in C++ and his
opposition to it (which dates back from many years ago) is what
made me search for better languages and discover D.
C++ has only half-assed metaprogramming limited to types, and the
lack of static if has forced me so many times to rewrite very
similar code from one function to another.
With D I can have a « function skeleton » and avoid all
redundancies with static if. Plus mixins expand enormously on the
C preprocessor (although AST macros would be even better).
IMHO it's all good for D, full-featured metaprogramming is a
killer feature and can save a great amount of time and headaches.
The more backwards C++ chooses to remain the faster alternatives
will grow.
