Re: HTOD
On Tuesday, 22 August 2017 at 22:50:46 UTC, Walter Bright wrote: On 8/22/2017 2:50 PM, Steven Schveighoffer wrote: But it is generating D code, no? Sure. And the C subset of D has been very stable, too. Used the tool 2 years ago. Worked like a charm.
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner wrote:
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
Dynamic initialization is done by constructor:
class Test
{
static ubyte[1000] s;
ubyte[] buf;
this()
{
buf=s;
}
}
It's also unambiguous as to how it works.
Re: Static inline field initialization
On Wednesday, 23 August 2017 at 09:12:19 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner
wrote:
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
Dynamic initialization is done by constructor:
[...]
It's also unambiguous as to how it works.
I am aware, as I have pointed out the same in the above, but the
post you quote is explicitly not about dynamic initialization
(i.e. the result of new points into the heap), but about static
initialization (the result of new points into sections of the
binary format).
Specifically, it's about static initialization done for variables
put into classic global storage (e.g. ELF sections .data/.bss)
and variables put into thread local storage (e.g. ELF sections
.tdata/.tbss).
Re: HTOD
On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg wrote: On 2017-08-22 19:47, 12345swordy wrote: Use Clang frontend? DStep [1] is doing that. It handles both GCC and Microsoft extensions. [1] https://github.com/jacob-carlborg/dstep "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang.
Re: @safe(bool)
On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] [...] There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. Platitudes cause poor language design, not the completely reasonable expectation of good tools. And who is "Platitude" here specifically?
Re: HTOD
On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote: "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang. Very disappointing? It's not trivial to call C++ from another language.
Re: Community Rant
But lets be honest. If I was just interested to learn about this "modern system programming language" that is C++ done right, I would dismiss D very quickly. We need to get together as a community and rethink your priorities, because with problems like this we're making it very hard for newcomers to trust in this very poorly adapted language. Programming tools used by day to day programmers should be a priority. Because everyone expects valgrind to work. The standard library should be a priority. It's far from complete (hopefully my company will contribute in this respect in the near future). The DUB package repository is horrible! More often than not, the packages are so poorly written I end up just writing my own implementation. Adding the ability to "rate" packages would go a long way in improving the situation. I understand hacking the frontend is way more interesting to most of the community. But if we don't find the time to improve on our visibility and language maturity, D will never get the attention it deserves. +1
gdc and ldc in MacPorts
Whilst DMD seems to be in MacPorts, GDC and LDC appear not to be. Is this right? If it is then it is wrong – it would be great if the person handling the DMD port could be supported to get a LDC and GDC ports in place. I am a user of MacOS maybe once per year, but I'll help as I can.
Re: Community Rant
On 08/22/2017 08:24 AM, ixid wrote: On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: various. Out of interest did you pick up D before or after joining the start up? If before did you introduce D to them or were they already using it? Weka uses D after their CTO Liran's evaluation of a number of programming languages. Liran explains why he chose D and why he still thinks D was the right choice in his a couple of DConf talks. I worked at Weka for a while where I met many wonderful people like Jonathan. Although they were being "forced" to use D, nobody was seriously complaining. :) Now I work with an ex-Weka employee as an ex-Weka employee myself. That other person insisted that he should use D in his piece of the product. Sanity exists... ;) Ali
Re: HTOD
On Wednesday, 23 August 2017 at 14:12:55 UTC, jmh530 wrote: On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote: "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang. Very disappointing? Yes I find it disappointing. Does my disappointment bother you?
Re: Quora
A few other ones : https://www.quora.com/Is-C++-the-best-programming-language-to-learn-first https://www.quora.com/What-are-some-programming-languages-that-I-should-learn https://www.quora.com/How-do-I-learn-coding-7 https://www.quora.com/What-should-I-start-with-in-order-to-learn-computer-programming-well-Which-languages-and-any-other-basic-skills-What-are-some-experiences-which-people-have-had By the way, I think that the D tutorial on TutorialsPoint should be promoted A LOT more on the Dlang.org website. And even if I agree like everybody that Ali's book is probably the best one around, a website is free and directly accessible to anybody interested in learning programming with D...
Re: gdc and ldc in MacPorts
On Wednesday, 23 August 2017 at 18:03:22 UTC, lanphuonglien wrote: Whilst DMD seems to be in MacPorts, GDC and LDC appear not to be. Is this right? If it is then it is wrong – it would be great if the person handling the DMD port could be supported to get a LDC and GDC ports in place. I am a user of MacOS maybe once per year, but I'll help as I can. If you aren't set on MacPorts, you can use homebrew for ldc. With regards to gdc: A word of caution: Supporting it as a separate package is a bit of a hassle, since it technically lives as part of the main gcc codebase (and you actually compile gcc with the D frontend enabled).
Re: HTOD
On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg wrote: On 2017-08-22 19:47, 12345swordy wrote: Use Clang frontend? DStep [1] is doing that. It handles both GCC and Microsoft extensions. [1] https://github.com/jacob-carlborg/dstep "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang. Do you know another language or tool that can call C++ natively? I'm looking for native C++ interop either built in or via tooling. bye, lobo
Re: Community Rant
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: [...] But lets be honest. If I was just interested to learn about this "modern system programming language" that is C++ done right, I would dismiss D very quickly. We need to get together as a community and rethink your priorities, because with problems like this we're making it very hard for newcomers to trust in this very poorly adapted language. Programming tools used by day to day programmers should be a priority. Because everyone expects valgrind to work. [...] This kind of criticism comes up fairly often in the forums, maybe once every few weeks. I can link to the recent threads on the matter, but I'm sure you can make an educated guess about the responses therein. The gist of it, in my view, is that: "[Making] D more approachable and attractive to people thinking of picking up the language." just isn't a high priority right now.
Re: Community Rant
On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote: On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: [...] But lets be honest. If I was just interested to learn about this "modern system programming language" that is C++ done right, I would dismiss D very quickly. We need to get together as a community and rethink your priorities, because with problems like this we're making it very hard for newcomers to trust in this very poorly adapted language. Programming tools used by day to day programmers should be a priority. Because everyone expects valgrind to work. [...] This kind of criticism comes up fairly often in the forums, maybe once every few weeks. I can link to the recent threads on the matter, but I'm sure you can make an educated guess about the responses therein. The gist of it, in my view, is that: "[Making] D more approachable and attractive to people thinking of picking up the language." just isn't a high priority right now. That's one way to look at it. Another, slightly more accurate and nuanced version is that there are many areas for improvement, and those that are doing work to improve things are doing them in areas they believe are important and useful for their work. That there's not more in the area , that you (and others) believe is important, merely shows that the number that believe is important enough to work on right now is close to zero. That doesn't mean that isn't also important, just that it's not at the top of the priority list for those getting things done. Convince someone that is higher priority than the things they're working on then you might see some movement on those fronts. Or convince yourself that it's important enough to engage in yourself. This isn't really a community level issue so much as a very personal level issue. It's not sufficient for something to be declared a community level priority if no one at the personal level is interested enough to contribute their time.
Re: Future of export
On Wednesday, 23 August 2017 at 03:19:55 UTC, Nicholas Wilson
wrote:
I have as part of DIP 1012
```
enum SymbolExport
{
neither,
dynamicImport,
dynamicExport
}
alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```
to replace the `export` storage visibility, So that one can do
```
version(MyLib_Build)
enum MyLibExport = dynamicExport;
else
enum MyLibExport = dynamicImport;
// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x) { ... }
```
However Martin said in
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"
Last I heard (from Benjamins Thaut's DConf 2016 talk) was that
nobody was using export because there was no corresponding
import and no way to switch between them. Benjamin suggested
that making it an attribute would fix that, hence it is part of
DIP 1012.
What is planned for export?
There's already a DIP on the subject
(https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.
Re: @safe(bool)
On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote: On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote: [...] Platitudes cause poor language design, not the completely reasonable expectation of good tools. And who is "Platitude" here specifically? http://lmgtfy.com/?q=platitude ;)
Re: HTOD
> Do you know another language or tool that can call C++ natively? nim: it supports both targetting C++ (as well as C or javascript) and also calling C++ via foreign function interface, eg here are some links: https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim https://forum.nim-lang.org/t/1056 for D, there's a project to support full C++ natively using clang library is calypso, unfortunalty I haven't been able to use it, either from OSX or ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41, hoping someone can help here! On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d wrote: > On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote: >> >> On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg wrote: >>> >>> On 2017-08-22 19:47, 12345swordy wrote: >>> Use Clang frontend? >>> >>> >>> DStep [1] is doing that. It handles both GCC and Microsoft extensions. >>> >>> [1] https://github.com/jacob-carlborg/dstep >> >> >> "Doesn't translate C++ at all" >> >> That's very disappointing. IMO, it should at least aim for the c++ 11 >> feature via using clang. > > > Do you know another language or tool that can call C++ natively? I'm looking > for native C++ interop either built in or via tooling. > > bye, > lobo > >
Re: Future of export
On Thursday, 24 August 2017 at 00:31:26 UTC, solidstate1991 wrote: There's already a DIP on the subject (https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language. Thanks. The interesting bit of that DIP w.r.t DIP1012 is A single meaning of export The classical solution to handle dllexport/dllimport attributes on Windows is to define macro that depending on the current build setting expands to __declspec(dllexport) or to __declspec(dllimport). This complicates the build setup and means that object files for a static library can't be mixed well with object files for a DLL. Instead we propose that exported data definitions are accompanied with an _imp_ pointer and always accessed through them. See the implementation detail section for how this will work for data symbols and function symbols. That way a compiled object file can be used for a DLL or a static library. And vice versa an object file can be linked against an import library or a static library. I can't comment on the build system complexity that DIP1012 would add but It would allow us to do the C/C++ solution of export management. I'll have a proper look over DIP45's review thread and put a summary here and see if we can get some discussion on it.
Re: HTOD
On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote: [...] nim: it supports both targetting C++ (as well as C or javascript) and also calling C++ via foreign function interface, eg here are some links: https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim https://forum.nim-lang.org/t/1056 for D, there's a project to support full C++ natively using clang library is calypso, unfortunalty I haven't been able to use it, either from OSX or ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41, hoping someone can help here! On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d wrote: [...] Thanks, I'll revisit Nim. As a team we're testing new languages as a larger plan to switch from C++. Nim we struck off 6 months ago because we found it not quite production ready. bye, lobo
Re: HTOD
On Wed, Aug 23, 2017 at 10:38 PM, lobo via Digitalmars-d wrote: > On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote: >>> >>> [...] >> >> >> nim: >> it supports both targetting C++ (as well as C or javascript) and also >> calling C++ via foreign function interface, eg here are some links: >> https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim >> >> https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim >> https://forum.nim-lang.org/t/1056 >> >> for D, there's a project to support full C++ natively using clang library >> is calypso, unfortunalty I haven't been able to use it, either from OSX or >> ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41, >> hoping someone can help here! >> >> >> >> On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d >> wrote: >>> >>> [...] > > > Thanks, I'll revisit Nim. As a team we're testing new languages as a larger > plan to switch from C++. Nim we struck off 6 months ago because we found it > not quite production ready. > > bye, > lobo Would love to hear more about your reasoning as I'm also occasionally re-visiting it, do you have any writeup?
