Re: C++ or D?
On Thursday, 31 December 2020 at 07:17:45 UTC, RSY wrote: It's like the story with the GC You want everyone to like D because it has a GC despite it being not updated in ages, and proved to not scale well Fun fact: the c++ GC Oilpan ( used in Chrome ) has more features than the one in D...
Re: C++ or D?
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
Re: C++ or D?
On Thursday, 31 December 2020 at 07:23:17 UTC, RSY wrote:
C++ you need to write duplicate code (.h and .cpp)
C++ you need to care about header include order
C++ you need to forward declare everything you gonna use if it
is not included before
C++ you need to waste time waiting for compile
Fixed with C++20 modules.
---
He said fixed with c++20 modules, when you still have to
predeclare everything, as it is was a better solution
LOL, i can't believe it, bad worm
```
export module app;
export int main()
{
say_hi();
}
void say_hi()
{
printf("hi\n");
}
```
// error C3861: 'say_hi': identifier not found
O it doesn't compile, it doesn't know what say_hi is, wow
great c++ module system
Clearly supperior to D /s
Re: C++ or D?
C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. --- He said fixed with c++20 modules, when you still have to predeclare everything, as it is was a better solution LOL, i can't believe it, bad worm
Re: C++ or D?
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote: On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote: It's not the problem mentioned but I had to struggle with DLLs and D's Variant-type. The problem is that Variant uses TypeInfo which does not pass DLL boundaries correctly so that int != int in runtime even it's in fact a simple int. If you need to exchange unknown data between a DLL and your application you need to get a workaround and cannot use that elsewhere settled nice feature. But it's a Windows specific issue - it works as expected on other systems. Which is basically same as in C++, despite the fact it does have real working SO/DLL runtime's many large projects have their own RTTI implementation. LLVM has its own RTTI because standard type info is "inefficient", Unreal Engine has its own, IIRC Qt too has its own, etc... Same thing with D Variant, some people say it is "inefficient"... so we ended up having multiple libraries. Not saying anything about how good or bad all this, just the facts. C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities. It's like the story with the GC You want everyone to like D because it has a GC despite it being not updated in ages, and proved to not scale well You do the same with modules and reflections now, D is clearly better but for some reasons you don't want people to believe that, worse you want people to see them as inferior to the poor C++ one, because you clearly didn't mention any of that poor 1 phase compilation model What is your goal here? you for sure don't want D to take off
Re: C++ or D?
On Thursday, 31 December 2020 at 07:07:04 UTC, RSY wrote: On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote: On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote: It's not the problem mentioned but I had to struggle with DLLs and D's Variant-type. The problem is that Variant uses TypeInfo which does not pass DLL boundaries correctly so that int != int in runtime even it's in fact a simple int. If you need to exchange unknown data between a DLL and your application you need to get a workaround and cannot use that elsewhere settled nice feature. But it's a Windows specific issue - it works as expected on other systems. Which is basically same as in C++, despite the fact it does have real working SO/DLL runtime's many large projects have their own RTTI implementation. LLVM has its own RTTI because standard type info is "inefficient", Unreal Engine has its own, IIRC Qt too has its own, etc... Same thing with D Variant, some people say it is "inefficient"... so we ended up having multiple libraries. Not saying anything about how good or bad all this, just the facts. C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities. and you still have the predeclaration issue, since the whole process is done 1 way and this is the summary of the whole C++ has X, but it is either half backed, or just plain bloated you can't say c++ will have module without saying it is implemented poorly, you still have the dirty and ugly quirks D module system remains superior because the whole experience is just plain superior and more sane And you can't say C++23 will have Y therfore it is a reasonable choice TODAY No, it's either you have it or you don't, everyone can implement Z, even Rust borrow checker, that doesn't make language 0 relevant when you compare solutions TODAY And even more when you take into account that D is interopable with both C/C++ Invalidating D, just because X Y Z will have K and have poorly implemented N, is very unfortunate, BAD, and plain SAD, because you just don't care about what D has to offer when you take into account the whole feature set
Re: C++ or D?
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote: On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote: It's not the problem mentioned but I had to struggle with DLLs and D's Variant-type. The problem is that Variant uses TypeInfo which does not pass DLL boundaries correctly so that int != int in runtime even it's in fact a simple int. If you need to exchange unknown data between a DLL and your application you need to get a workaround and cannot use that elsewhere settled nice feature. But it's a Windows specific issue - it works as expected on other systems. Which is basically same as in C++, despite the fact it does have real working SO/DLL runtime's many large projects have their own RTTI implementation. LLVM has its own RTTI because standard type info is "inefficient", Unreal Engine has its own, IIRC Qt too has its own, etc... Same thing with D Variant, some people say it is "inefficient"... so we ended up having multiple libraries. Not saying anything about how good or bad all this, just the facts. C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities. and you still have the predeclaration issue, since the whole process is done 1 way and this is the summary of the whole C++ has X, but it is either half backed, or just plain bloated you can't say c++ will have module without saying it is implemented poorly, you still have the dirty and ugly quirks D module system remains superior because the whole experience is just plain superior and more sane
Re: C++ or D?
On Wednesday, 30 December 2020 at 21:17:25 UTC, sighoya wrote:
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim
Grøstad wrote:
(which does not work, but maybe there is some other
way to express it?):
See:
https://forum.dlang.org/thread/ooxzbrmbrzpsefiro...@forum.dlang.org?page=1
Ok, so basically just add alias:
void foo(alias T)(T!int x) {
Ok. :)
Re: C++ or D?
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim Grøstad wrote: (which does not work, but maybe there is some other way to express it?): See: https://forum.dlang.org/thread/ooxzbrmbrzpsefiro...@forum.dlang.org?page=1
Re: C++ or D?
On Wednesday, 30 December 2020 at 20:42:49 UTC, jmh530 wrote:
You mean like this
struct Foo(T)
{
T x;
}
void foo(T : Foo!V, V)(T x) {
Not quite, "Foo" would be a template parameter, so something like
this (which does not work, but maybe there is some other way to
express it?):
struct Foo(T)
{
T x;
}
void foo(T)(T!int x) {
import std.stdio: writeln;
writeln("here");
}
void main() {
Foo!int x;
foo(x);
}
Re: C++ or D?
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote: It's not the problem mentioned but I had to struggle with DLLs and D's Variant-type. The problem is that Variant uses TypeInfo which does not pass DLL boundaries correctly so that int != int in runtime even it's in fact a simple int. If you need to exchange unknown data between a DLL and your application you need to get a workaround and cannot use that elsewhere settled nice feature. But it's a Windows specific issue - it works as expected on other systems. Which is basically same as in C++, despite the fact it does have real working SO/DLL runtime's many large projects have their own RTTI implementation. LLVM has its own RTTI because standard type info is "inefficient", Unreal Engine has its own, IIRC Qt too has its own, etc... Same thing with D Variant, some people say it is "inefficient"... so we ended up having multiple libraries. Not saying anything about how good or bad all this, just the facts. C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities.
Re: C++ or D?
On Wednesday, 30 December 2020 at 19:51:07 UTC, Ola Fosheim
Grøstad wrote:
[snip]
Sort of, in C++ it would be something like this
template class OuterName>
void myfunction(OuterName x){ stuff(); }
[snip]
You mean like this
struct Foo(T)
{
T x;
}
void foo(T : Foo!V, V)(T x) {
import std.stdio: writeln;
writeln("here");
}
void main() {
Foo!int x;
foo(x);
}
Re: C++ or D?
On Wednesday, 30 December 2020 at 19:24:19 UTC, sighoya wrote:
In my eyes, adding proper support for opImplicitCoercion
enables the reuse of interfaces as typeclasses, yielding more
potential for idiomatic development than utilizing C++ concepts
alone.
Not sure what you mean? A D interface is a dynamic runtime
feature?
Btw, did D ever get to add nested template parameters? I know
people asked for it a long time ago, but cannot remember if
that was resolved somehow?
Oh, what's this? Did you mean true Higher Kinded Types (HKT)
```
fun(R,S,T:R=>S)
```
Sort of, in C++ it would be something like this
template class OuterName>
void myfunction(OuterName x){ stuff(); }
That would be great, but they're simply arguing to use alias
symbols instead. The downside with aliases is however a more
restricted type inference:
That is clearly a type unification bug. An alias isn't an alias
if it interferes with type unification!
Re: C++ or D?
On Wednesday, 30 December 2020 at 18:45:03 UTC, Ola Fosheim Grøstad wrote: Some people in the D community has for a long time wanted stack-less coroutines. This is now available in C++20, and maybe D can borrow the C++ implementation for LDC? That is an interesting possibility for sure. Hmm, I don't know much about them, but it seems they are a restriction to stackful coroutines, maybe a keyword addition like @stackless to prohibit nested suspension does the trick? The main addition for C++20 is concepts. Basically wrapping up ugly tests in a simple template parameter type specifier so that you can specify that a template parameter MUST support Addition or be a Stack or whatever you want to require with very simple syntax. (It also makes it easier to specify tests.) In my eyes, adding proper support for opImplicitCoercion enables the reuse of interfaces as typeclasses, yielding more potential for idiomatic development than utilizing C++ concepts alone. Btw, did D ever get to add nested template parameters? I know people asked for it a long time ago, but cannot remember if that was resolved somehow? Oh, what's this? Did you mean true Higher Kinded Types (HKT) ``` fun(R,S,T:R=>S) ``` That would be great, but they're simply arguing to use alias symbols instead. The downside with aliases is however a more restricted type inference: https://github.com/dlang/DIPs/blob/bf5157d3dc29a591826e22d188448fbc04ca81b2/DIPs/DIP1023.md https://forum.dlang.org/thread/dnyqxmgdazczwmmva...@forum.dlang.org?page=4 I almost never use multiple inheritance myself, but if you don't use it, it does not affect you at all? So how could it be a problem to have the option? *shrugs* It's right, at least theoretically, practically you are often forced to use the feature in order to utilize the functionality you need. But the more general point against this was the clash of fields and methods. However, this is akin to the problem with generic specialization, and likewise it can be solved by simply defining a new default instance, that's it.
Re: C++ or D?
On Wednesday, 30 December 2020 at 18:24:41 UTC, sighoya wrote: On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim Grøstad wrote: Most of the statements are wrong too... "4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D Could you elaborate a bit more, please? I'm interested. Some people in the D community has for a long time wanted stack-less coroutines. This is now available in C++20, and maybe D can borrow the C++ implementation for LDC? That is an interesting possibility for sure. "template metaprogramming only capable of being understood by mensa member": some aspects of C++20 metaprogramming is easier than D That would me interest, too! The main addition for C++20 is concepts. Basically wrapping up ugly tests in a simple template parameter type specifier so that you can specify that a template parameter MUST support Addition or be a Stack or whatever you want to require with very simple syntax. (It also makes it easier to specify tests.) Btw, did D ever get to add nested template parameters? I know people asked for it a long time ago, but cannot remember if that was resolved somehow? Just to say, I think not including multiple inheritance was a mistake for Java and all its descendants, though not a big one. Multiple inheritance needs just a good convention, that's all. I almost never use multiple inheritance myself, but if you don't use it, it does not affect you at all? So how could it be a problem to have the option? *shrugs*
Re: C++ or D?
On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim Grøstad wrote: Most of the statements are wrong too... "4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D Could you elaborate a bit more, please? I'm interested. "unsatisfying standard library": not really, unless you need to avoid exceptions "template metaprogramming only capable of being understood by mensa member": some aspects of C++20 metaprogramming is easier than D That would me interest, too! "multiple-inheritance hell": no idea what this means, MI is usually used for the same as D interfaces Just to say, I think not including multiple inheritance was a mistake for Java and all its descendants, though not a big one. Multiple inheritance needs just a good convention, that's all.
Re: How to Install D on my new MacBook with M1 ARM computer
On Wednesday, 30 December 2020 at 00:22:14 UTC, Guillaume Piolat wrote: Hello, 1. Download ldc2-1.24.0-osx-x86_64.tar.xz (or later version) from this page: https://github.com/ldc-developers/ldc/releases [...] Thank you very much. This got me going. Right now I don't expect to be distributing any consumer software. Dave Chapman
Re: Reading files using delimiters/terminators
On Tuesday, 29 December 2020 at 14:50:41 UTC, Steven Schveighoffer wrote: Are you on Windows? If so, your double newlines might be \r\n\r\n, depending on what editor you used to create the input. Use a hexdump program to see what the newlines are in your input file. I've tried \r\n\r\n as well, which sadly also did not work. Using vscode I have also switched between CRLF and LF, which also did not do the trick. I'm getting the sense the implementation might have a specific workaround for \r\n / CRLF line-endings, though I haven't checked the sourcecode yet. Note that this is not really a problem for me specifically, I've long used a different approach, however it seemed like a design issue. I'll try replicating this in isolation later, maybe something was wrong last time I tried.
Re: C++ or D?
On Wednesday, 30 December 2020 at 14:17:38 UTC, Rekel wrote: On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote: https://ibb.co/syQRs9v I hope I'm not the only one that thinks 'designers and std lib writers unable to name anything correctly' is kind of ironic. And don't get me started on documentation return values. Most of the statements are wrong too... "Forgot null terminator": that is C, not C++. "undecidable grammer": wrong, not context free != undecidable "can't execute arbitrary functions at compile time": same as D, more or less "4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D "unsatisfying standard library": not really, unless you need to avoid exceptions "template metaprogramming only capable of being understood by mensa member": some aspects of C++20 metaprogramming is easier than D "multiple-inheritance hell": no idea what this means, MI is usually used for the same as D interfaces "iterators": and ranges... Anyway, bashing C++ does not get D anywhere. At best it makes D users look uninformed.
Re: 64-bit compilation in Wine
On Tuesday, 29 December 2020 at 21:13:59 UTC, Raikia wrote: That certainly helped, but when running the program on a fresh Windows install, I still get the error "The program can't start because vcruntime140.dll is missing from your computer". In my (limited) experience, I think its because it is using msvcrt (which is dynamically linked) instead of libcmt (which is static). The static MS libs cannot be redistributed by 3rd parties thanks to their license, that's why LDC and DMD only come with MinGW-based import libraries depending on an installed MSVC++ runtime. [DMD works with (default) -m32 because that uses Walter's DigitalMars C runtime.]
Re: C++ or D?
On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote: https://ibb.co/syQRs9v I hope I'm not the only one that thinks 'designers and std lib writers unable to name anything correctly' is kind of ironic. And don't get me started on documentation return values.
Re: Hardcoded filepaths in compiled exe
On 12/29/20 11:43 PM, Basile B. wrote:
On Wednesday, 30 December 2020 at 01:21:37 UTC, Steven Schveighoffer wrote:
On 12/29/20 7:46 PM, Basile B. wrote:
On Tuesday, 29 December 2020 at 23:11:25 UTC, Steven Schveighoffer
wrote:
But I would think a feature should exist that masks the base
directory of exception file names.
Probably worth an enhancement request.
Also aren't dmd output binaries supposed to be "reproducible" ?
If you had an option to change __FILE__ to be canonical, then it could
be.
i.e. instead of:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d
you stored:
(imports)\std\file.d
where (imports) (or maybe some other token) was substituted in for the
base of every import. Files passed on the command line would just
store the __FILE__ as it was passed.
actually the string "C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d"
looks like it comes from how the ini file variables are expanded.
__FILE__ is not supposed to represent an absolute file name unless the
compiler get passed absolute file names. That why __FILE_FULL_PATH__ was
added at some point.
When I tested this code, it spit out a full path:
import std.stdio;
import std.range;
void main()
{
char[] str = [0xff, 0xff];
writeln(str.front);
}
--
std.utf.UTFException@/Users/steves/.dvm/compilers/dmd-2.094.2/osx/bin/../../src/phobos/std/utf.d(1508):
Invalid UTF-8 sequence (at index 1)
The path comes from the ini file to generate the import directory. I
believe the ini configuration gives a full path (the path to the ini
file, and then the relative path to the import).
I think if the import was in the project and not the dmd compiler
directory, then full paths wouldn't be happening.
But that doesn't mean you can't FORCE the compiler to behave better via
an option switch when importing from elsewhere.
-Steve
