Re: wanting to try a GUI toolkit: needing some advice on which one to choose

On Tuesday, 1 June 2021 at 05:27:41 UTC, Imperatorn wrote: On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote: [...] Yeah, "fragmentation" is a problem. We do a lot of things 90%. We need more "100% projects" that are just plug n play rather than plug n pray The solution is to reduce

Re: Why is this allowed? Inheritance variable shadowing

On Wednesday, 26 May 2021 at 18:58:47 UTC, JN wrote: Is there any viable usecase for this behavior? I am not buying the "C++ does it and it's legal there" argument. There's a reason most serious C++ projects use static analysis tools anyway. D should be better and protect against dangerous

Re: Template and alloca?

On Wednesday, 26 May 2021 at 08:38:29 UTC, Imperatorn wrote: On Wednesday, 26 May 2021 at 07:34:06 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 25 May 2021 at 17:55:17 UTC, Ola Fosheim Grostad wrote: Is it possible to use a template to write a "function" that provides initialized stack

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

On Tuesday, 25 May 2021 at 18:12:27 UTC, Gavin Ray wrote: Would this fix it, or is it just not super viable to hack around C++ multiple inheritance in D? You can do anything you want with structs, raw memory, and casting, so it is viable, if you have a strong interest for this. But if you

Template and alloca?

Is it possible to use a template to write a "function" that provides initialized stack allocated memory (alloca)? Maybe I would have to use mixin?

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

On Monday, 24 May 2021 at 18:52:22 UTC, Ola Fosheim Grostad wrote: If an informal description is needed then the best option is to search the Clang mailing list. Btw clang docs say they strive to match msvsc, so apparently it is platform dependent. The only sensible option is to check with

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

On Monday, 24 May 2021 at 18:46:00 UTC, Guillaume Piolat wrote: Multiple inheritance is a rare topic here, I doubt too many people know how it works internally. It is described in the link I gave, or? If I tried to give an informal description I would probably be inaccurate and that would be

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

On Sunday, 23 May 2021 at 21:02:31 UTC, Gavin Ray wrote: I don't really know anything at all about compilers or low-level code -- but is there any high-level notion of "inheritance" after it's been compiled? Yes, in the structure of the vtable, which is why the spec is so hard to read. If

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

On Sunday, 23 May 2021 at 19:44:01 UTC, Gavin Ray wrote: So one of the problems with generating D code for bindings to C++ is that there's no true/direct multiple inheritance. If anyone happens to understand well how vtables work and the way the compiler treats these things, is there a way to

Re: ugly and/or useless features in the language.

On Sunday, 23 May 2021 at 12:08:31 UTC, Alain De Vos wrote: It is sufficient to have a bit complex gui and database access and the @safe annotation can nowhere be used in your program. The compiler misses scopes checks without. I think you are supposed to use @trusted to tell the compiler

Re: ugly and/or useless features in the language.

On Sunday, 23 May 2021 at 10:24:53 UTC, Ola Fosheim Grostad wrote: On Sunday, 23 May 2021 at 08:35:31 UTC, Tony wrote: On Saturday, 15 May 2021 at 21:15:01 UTC, Ola Fosheim Grostad wrote: Why is metaprogramming added features better than the same features added in the language? One is standard

Re: ugly and/or useless features in the language.

On Sunday, 23 May 2021 at 08:35:31 UTC, Tony wrote: On Saturday, 15 May 2021 at 21:15:01 UTC, Ola Fosheim Grostad wrote: Why is metaprogramming added features better than the same features added in the language? One is standard between entities, the other is not. There are many reasons, one

Re: ugly and/or useless features in the language.

On Saturday, 22 May 2021 at 17:32:34 UTC, sighoya wrote: But I think providing an external ast tree mapped onto the changing internal one used by DMD would be a feasible approach. It is feasible, but if you want to do it well you should think in terms of rewrite engines with patternmatching,

Re: ugly and/or useless features in the language.

On Sunday, 16 May 2021 at 16:16:22 UTC, H. S. Teoh wrote: I cannot live without auto return types and Voldemort types. They are my bread and butter. Take them away, and I might as well go back to C/C++. C++ has both? What I find ugly: - shared, and all of its quirks and incomplete

Re: ugly and/or useless features in the language.

On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote: Feature creep can make your own code unreadable. Having many ways to express the same concept makes code harder to read. This is an issue in C++, but you can combat it by creating coding norms. In general it is better to have

Re: Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"

On Sunday, 18 April 2021 at 00:38:13 UTC, Ali Çehreli wrote: I heard about safety issues around allowing full I/O during compilation but then the following points kind of convinced me: - If I am compiling a program, my goal is to execute that program anyway. What difference does it make

Re: styx, a programming languange written in D, is on the bootstrap path

On Monday, 18 January 2021 at 17:58:22 UTC, Basile B. wrote: On Monday, 18 January 2021 at 17:51:16 UTC, Basile B. wrote: on the internet nobody knows you're a dog ;) https://de.fakenamegenerator.com/ Awww... And here I thought you were a fellow Norwegian... But I guess a dog is ok too.

Re: Why many programmers don't like GC?

On Monday, 18 January 2021 at 01:41:35 UTC, James Blachly wrote: Those were not aberba's words, but the author of the first link, in which one does find a conceptual, high level description of GC. I read it, it said nothing of relevance to the D collector. That is not TLDR informative.

Re: I want to create my own Tuple type

On Monday, 11 January 2021 at 01:49:26 UTC, Paul Backus wrote: Why are these particular implementation details important to you? It is for object.d. I want to allow fast runtime indexing if all elements are of the same type. If the types are different I want static indexing, so the plan is

Re: Printing shortest decimal form of floating point number with Mir

On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote: I suppose the answer would be that D doesn't pretend to support all C++ template features and the bug is not a bug because we live with this somehow for years. But it is a bug even if there was no C++... An alias should work by simple

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

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: Mir vs. Numpy: Reworked!

On Monday, 7 December 2020 at 13:48:51 UTC, jmh530 wrote: On Monday, 7 December 2020 at 13:41:17 UTC, Ola Fosheim Grostad wrote: On Monday, 7 December 2020 at 13:17:47 UTC, jmh530 wrote: [snip] "no need to calculate inverse matrix" What? Since when? I dont know what he meant in this

Re: Mir vs. Numpy: Reworked!

On Monday, 7 December 2020 at 13:17:47 UTC, jmh530 wrote: On Monday, 7 December 2020 at 11:21:16 UTC, Igor Shirkalin wrote: [snip] Agreed. As a matter of fact the simplest convolutions of tensors are out of date. It is like there's no need to calculate inverse matrix. Mir is the usefull work

Re: low-latency GC

On Sunday, 6 December 2020 at 17:28:52 UTC, Bruce Carneal wrote: D is good for systems level work but that's not all. I use it for projects where, in the past, I'd have split the work between two languages (Python and C/C++). I much prefer working with a single language that spans the

Re: low-latency GC

On Sunday, 6 December 2020 at 17:35:19 UTC, IGotD- wrote: Is automatic atomic reference counting a contender for kernels? In kernels you want to reduce the increase/decrease of the counts. Therefore the Rust approach using 'clone' is better unless there is some optimizer that can figure it

Re: low-latency GC

On Sunday, 6 December 2020 at 14:44:25 UTC, Paulo Pinto wrote: And while on the subject of low level programming in JVM or .NET. https://www.infoq.com/news/2020/12/net-5-runtime-improvements/ Didnt say anything about low level, only simd intrinsics, which isnt really low level? It also

Re: low-latency GC

On Sunday, 6 December 2020 at 14:11:41 UTC, Max Haughton wrote: On Sunday, 6 December 2020 at 11:35:17 UTC, Ola Fosheim Grostad wrote: On Sunday, 6 December 2020 at 11:27:39 UTC, Max Haughton wrote: [...] No, unique doesnt need indirection, neither does ARC, we put the ref count at a

Re: low-latency GC

On Sunday, 6 December 2020 at 12:58:44 UTC, IGotD- wrote: I was thinking about how to deal with this in D and the question is if it would be better to be able to control move as default per type basis. This way we can implement Rust style reference counting without intruding too much on the

Re: low-latency GC

On Sunday, 6 December 2020 at 11:27:39 UTC, Max Haughton wrote: ARC with a library will have overhead unless the compiler/ABI is changed e.g. unique_ptr in C++ has an indirection. No, unique doesnt need indirection, neither does ARC, we put the ref count at a negative offset. shared_ptr is

Re: low-latency GC

On Sunday, 6 December 2020 at 10:44:39 UTC, Max Haughton wrote: On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim Grostad wrote: It has to be either some kind of heavily customisable small GC (i.e. with our resources the GC cannot please everyone), or arc. The GC as it is just hurts the

Re: low-latency GC

On Sunday, 6 December 2020 at 08:59:49 UTC, Ola Fosheim Grostad wrote: Well, you could in theory avoid putting owning pointers on the stack/globals or require that they are registered as gc roots. Then you don't have to scan the stack. All you need then is write barriers. IIRC Abd read

Re: low-latency GC

On Sunday, 6 December 2020 at 08:36:49 UTC, Bruce Carneal wrote: Yes, but they don't allow low level programming. Go also freeze to sync threads this has a rather profound impact on code generation. They have spent a lot of effort on sync instructions in code gen to lower the latency AFAIK.

Re: low-latency GC

On Sunday, 6 December 2020 at 07:45:17 UTC, Bruce Carneal wrote: GCs scan memory, sure. Lots of variations. Not germane. Not a rationale. We need to freeze the threads when collecting stacks/globals. D is employed at multiple "levels". Whatever level you call it, Go and modern JVMs

Re: low-latency GC

On Sunday, 6 December 2020 at 05:41:05 UTC, Bruce Carneal wrote: OK. Some rationale? Do you, for example, believe that no-probable-dlanger could benefit from a low-latency GC? That it is too hard to implement? That the language is somehow incompatible? That ... The GC needs to scan all

Re: low-latency GC

On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote: How difficult would it be to add a, selectable, low-latency GC to dlang? Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"? I've heard Walter mention performance

Re: Questions about D

On Friday, 27 November 2020 at 19:56:38 UTC, Walter wrote: On Friday, 27 November 2020 at 19:46:52 UTC, Ola Fosheim Grostad wrote: Why not? What are you looking for? I'm looking for a general purpose which I can use everywhere It is fairly general, but I don't think it is the best option for

Re: Questions about D

On Friday, 27 November 2020 at 19:34:41 UTC, Walter wrote: Hi, I have some questions to ask regarding D: 1) Should I learn D ? Why not? What are you looking for? 2) Can I cross-compile D programs? You should be able to with ldc/gdc if you have some experience. 3) Is it a low-level

Re: const and immutable values, D vs C++?

On Thursday, 5 December 2019 at 00:05:26 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven Schveighoffer wrote: void main() { foo!a(); // const(int) foo!b(); // immutable(int) foo!c(); // const(int) } Ok, so one has to use a wrapper and then

Re: wiki: D on AVR

On Thursday, 28 November 2019 at 18:40:17 UTC, Ernesto Castellotti wrote: Yes LDC sets size_t for the platform, not violating the spec. int in D is 32-bit as you said, that if you compare it with the size of the types of AVR-GCC it would be long, This is not a problem, just use the type aliases

Re: Quora: Why hasn't D started to replace C++?

On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit wrote: On Sunday, 11 February 2018 at 00:03:16 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!

Re: How programmers transition between languages

On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote: If you use an IDE or analysis/lint tool, you'll get type checking. The interpreter will happily ignore those annotations. You need to use a type checker to get type checking... No surprise there, but without standard type

Re: Old Quora post: D vs Go vs Rust by Andrei Alexandrescu

On Thursday, 4 January 2018 at 19:04:36 UTC, jmh530 wrote: Pony relates to Rust in terms of what they are trying to accomplish with ownership. Pony's iso reference capability seems to mirror Rust's borrow checker rule that you can only have one mutable reference. But Rust isn't using garbage

Re: We're looking for a Software Developer! (D language)

On Wednesday, 29 November 2017 at 15:11:17 UTC, Paulo Pinto wrote: Wirth puts it nicely, it is all about algorithms, data structures and learning how to apply them to any language. Yes, they also mention machine learning, which borrows from many fields close to applied mathematics. Linear

Re: Thoughts about D

On Thursday, 30 November 2017 at 03:29:56 UTC, Walter Bright wrote: The code *size* causes problems because it pushes the executing code out of the cache. Not if you do a branch to a cold cacheline on assert failure.

Re: We're looking for a Software Developer! (D language)

On Wednesday, 29 November 2017 at 10:47:31 UTC, aberba wrote: to death learning these stuff in lectures. I learnt them beyond the syllables years back on my own at a much quicker pase. CS isnt about the languages themselves, that is trivial. Basically covered in the first or second semester.

Re: Thoughts about D

On Tuesday, 28 November 2017 at 06:58:58 UTC, Elronnd wrote: In that case, why is libstdc++ 12MB, while libphobos2 is half the size, at 5.5MB? I havent checked, if true then probably because it contains code that goes beyond the minimal requirements (legacy, bloat, portability, tuning, etc).

Re: Thoughts about D

On Tuesday, 28 November 2017 at 02:26:34 UTC, Neia Neutuladh wrote: On Monday, 27 November 2017 at 17:35:53 UTC, Ola Fosheim Grostad wrote: On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote: I last used C++ professionally in 2015, and we were still rolling out C++11.

Re: Precise GC state

On Monday, 27 November 2017 at 18:32:39 UTC, Ola Fosheim Grøstad wrote: You get this: shared_ptr -> control_block -> object Actually, seems like the common implementation uses 16 bytes, so that it has a direct pointer as well. So twice the size of unique_ptr.

Re: Thoughts about D

On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote: I last used C++ professionally in 2015, and we were still rolling out C++11. std::string_view is part of C++17. You're calling me stupid for not having already known about it. (Yes, yes, you were sufficiently indirect to have a

Re: Precise GC state

Btw, it would improve the discourse if people tried to distinguish between language constructs and library constructs...

Re: Precise GC state

On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky wrote: Then watch Herb’s Sutter recent talk “Leak freedom by default”. Now THAT guy must be out of his mind :) He could be, I havent seen it... Shared_ptr isnt frequently used, it is a last resort, atomic_shared_pointer is

Re: Precise GC state

On Monday, 27 November 2017 at 10:13:41 UTC, codephantom wrote: But in a discussion about GC, some technical details might prove to be very useful to those of us following this discussion. Precise scanning of pointers makes sense when you have many cachelines on the GC with no pointers in

Re: Precise GC state

On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote: Please stop this flame There is no flaming. Current GC in D is shit and all this speaking won't improve situation. If so, why are you here? But you are fundamentally wrong. Precise GC will not bring a general improvement, for

Re: Precise GC state

On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov [ZombineDev] wrote: the shared_ptr itself) and you can't opt out of that even if you're not sharing the shared_ptr with other threads. Well, the compiler can in theory ellide atomics if it csn prove that the memory cannot be accessed by

Re: Precise GC state

On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky wrote: Last time I check shared_ptr can be safely shared across threads, hence RC is takling synchronization and most likely atomics since locks won’t be any better. The controlblock can, but it is crazy to use shared_ptr for

Re: Precise GC state

On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote: likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly. No, you dont. Nobody in their right mind would do so in C++ as a general solution.

Re: Thoughts about D

On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote: You might say that I could use C++ style manual memory management and get even better performance. And you'd be wrong. No... Not if you do it right, but it takes more planning. I.e. Design. Which is why scripting and high

Re: Precise GC state

On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis wrote: We can't even have different heaps for immutable and mutable stuff, because it's very common to construct something as mutable and then cast it to immutable (either explicitly or This is easy to fix, introduce a uniquely

Re: Precise GC state

On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky wrote: Sadly you can’t “skip” write barriers in your @system code because it may run as part of larger @safe. Which is where they Well, you can if you carefully lock the gc runtime or if you dont modify existing scannable pointers

Re: .NET introduces Span, basically D slices

On Sunday, 26 November 2017 at 05:36:15 UTC, Guy wrote: It's funny you say that because they just announced the introduction of ranges and I believe they return Spans. Well, basic dataflow pipelines with implicit transfer of buffer ownership. So it is a language feature with implicit RAII

Re: Homework services

On Saturday, 25 November 2017 at 14:29:08 UTC, Steven Schveighoffer wrote: If you're looking to use D for web development, this is what I recommend: SEO...spam...

Re: [OT] Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Saturday, 25 November 2017 at 01:23:03 UTC, codephantom wrote: And thankyou. This a much more constructive option for users that disagree with something I say. i.e. Now they can just hide me, instead of attacking me. Dont worry, both Walter and Andrei have done far worse in these fora

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 01:16:59 UTC, codephantom wrote: That's why we have the concept of 'undefined behaviour'. Errr, no. High level programming languages don't have undefined behaviour. That is a C concept related to the performance of the executable. C tries to get as close to

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 01:33:39 UTC, codephantom wrote: On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: By what proof? And what do you mean by mathematics? A mathematical claim, that cannot be proven or disproven, is neither true or false. What you are

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom wrote: true up to a number < n ... does not address the conjecture correctly. So what? We only need to a proof up to N for regular programming, if at all. hint. It's not a problem that mathmatics can solve. By what proof? And

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Tuesday, 21 November 2017 at 06:03:33 UTC, Meta wrote: I'm not clear on whether he means that Java's type system is unsound, or that the type checking algorithm is unsound. From what I can tell, he's asserting the former but describing the latter. He claims that type systems with

Re: ESR on post-C landscape

On Friday, 17 November 2017 at 00:36:21 UTC, codephantom wrote: On Thursday, 16 November 2017 at 11:52:45 UTC, Ola Fosheim Grostad wrote: Uhm, no? What do you mean by 'primary focus of program design' and in which context? I the context that, this is specifically what Stroustrup says in

Re: ESR on post-C landscape

On Thursday, 16 November 2017 at 18:02:10 UTC, Patrick Schluter wrote: The shear amount of inscrutable cruft and rules, plus the moving target of continuously changing semantics an order or two of magnitude bigger than C added to the fact that you still need to know C's gotchas, makes it one

Re: ESR on post-C landscape

On Thursday, 16 November 2017 at 18:06:22 UTC, Patrick Schluter wrote: On Tuesday, 14 November 2017 at 16:38:58 UTC, Ola Fosheim Grostad wrote: changing. C no longer models the hardware in a reasonable manner. Because of the flawed interpretation of UB by the compiler writers, not because of

Re: ESR on post-C landscape

On Thursday, 16 November 2017 at 11:24:09 UTC, codephantom wrote: On Thursday, 16 November 2017 at 06:35:30 UTC, Ola Fosheim Grostad wrote: Yes, I agree that classes are a powerful modelling primitive, but my point was that Stroustrup made classes the 'primary focus of program design'. Yes,

Re: ESR on post-C landscape

On Thursday, 16 November 2017 at 06:51:58 UTC, rikki cattermole wrote: On 16/11/2017 6:35 AM, Ola Fosheim Grostad wrote: Thing is, it is a failure, the way most people use it. You can say that about most things: exceptions, arrays, pointers, memory, structs with public fields... But I guess

Re: ESR on post-C landscape

On Thursday, 16 November 2017 at 02:12:10 UTC, codephantom wrote: Perhaps the mistake C++ made, was concluding that 'classes' were the "proper primary focus of program design" (chp1. The Design and Evolution of C++). No, classes is a powerful modelling primitive. C++ got that right. C++ is

Re: ESR on post-C landscape

On Wednesday, 15 November 2017 at 10:40:50 UTC, codephantom wrote: On Wednesday, 15 November 2017 at 09:26:49 UTC, Ola Fosheim Grøstad wrote: I don't think Go is much affected by the corporate… Umm "We made the language to help make google more productive and helpful internally" - Rob

Re: ESR on post-C landscape

On Tuesday, 14 November 2017 at 11:55:17 UTC, codephantom wrote: The reason he can dismiss D, so easily, is because of his starting premise that C is flawed. As soon as you begin with that premise, you justify searching for C's replacement, which makes it difficult to envsion something like D.

Re: Actor model & D

On Saturday, 11 November 2017 at 21:47:53 UTC, Dmitry Olshansky wrote: On Saturday, 11 November 2017 at 20:37:59 UTC, Ola Fosheim That's a library So what? Should we say that c doesn’t support threads because they are implemented in the library. Regular C is not a concurrent language. D

Re: Actor model & D

On Saturday, 11 November 2017 at 18:30:33 UTC, Dmitry Olshansky wrote: On Saturday, 11 November 2017 at 13:31:20 UTC, Ola Fosheim Grøstad wrote: On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote: Can anyone please explain me what it means for the D language to follow the Actor

Re: Webassembly?

On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote: so you can seamlessly pass objects to javascript. I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same. You would have to emulate the stack...

Re: Isn't it about time for D3?

On Wednesday, 14 June 2017 at 22:01:38 UTC, bachmeier wrote: It's a bigger problem for D than for those languages. If you introduce too many changes, the tools stop working, and we don't have the manpower to fix them. The same goes for libraries. A language with a larger group of developers,

Re: A Few thoughts on C, C++, and D

On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote: On 2017-05-30 14:27, Ola Fosheim Grøstad wrote: Maybe even turning some macros into functions? DStep can do that today. That's cool! How robust is in practice on typical header files (i.e zlib and similar)? What were the

Re: A Few thoughts on C, C++, and D

On Tuesday, 30 May 2017 at 01:46:02 UTC, bachmeier wrote: I'm not necessarily disagreeing with RW's post. My reading is that the goal would be to get D into the enterprise, but maybe I misinterpreted. If D as a successor to Vala leads to more projects like Tilix, that's great. I never quite

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 05:39:41 UTC, Nick Sabalausky (Abscissa) wrote: Did you intend that as a response to my post or to the OP? Sounds more like it was directed at the OP. I tried to reply to: <

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 01:56:19 UTC, Nick Sabalausky (Abscissa) wrote: On 05/28/2017 03:06 PM, Meta wrote: If you didn't know that the function takes its parameters by ref or out... You're should've RTFM. That's the same reasoning that's been used to excuse just about every API blunder

Re: Safe code as an I/O requirement

On Sunday, 28 May 2017 at 16:58:53 UTC, aberba wrote: https://lwn.net/Articles/708196/ From the look of things and feedbacks from several security analysts and system developers, [exposed] I/O needs to be memory safe. GStreamer multimedia library developed in C has safety issues [see

Re: Trip notes from Israel

On Saturday, 27 May 2017 at 20:21:56 UTC, Meta wrote: On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad wrote: Don't mistake my intentions. I proposed removing `body` because not being able to use it as a symbol name is often complained about on the forums, because it is a small,

Re: What would break if class was merged with struct

On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote: Sure, and the definition requires it. [1] https://dlang.org/spec/abi.html#delegates Please note that an ABI is an implementation specific linkage detail, it cannot be portable so it does not define language semantics.

Re: What would break if class was merged with struct

On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote: On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad wrote: On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote: Here, `bar`, takes a (pointer to a) class instance as parameter `foo`. `foo` is a single

Re: The syntax of sort and templates

On Friday, 26 May 2017 at 15:49:06 UTC, Ali Çehreli wrote: For example, Stroustrup has the article "Learning Standard C++ as a New Language"[1]. It compares sorting performance of C to C++ in section 3, "Efficiency". With those old C and C++ compilers he used (in May 1999), C++ was 1.74 to

Re: Warning, ABI breakage from 2.074 to 2.075

On Friday, 26 May 2017 at 13:23:20 UTC, Jason King wrote: wanted to fix a problem with the underlying system. Trying to build something on top of an unstable ABI is building your foundations on sand. All I’m saying is if no attention is going to be paid to this (it doesn’t mean you can’t

Re: std.functional.memoize : thread local or __gshared memoization?

On Thursday, 25 May 2017 at 20:43:36 UTC, Jonathan M Davis wrote: complication to the language. Certainly, from what I know of Rust, it's far more complicated because of that sort of thing, and glancing over that link on Pony, it looks like it's getting a fair bit of complication as well in

Re: [OT] Algorithm question

On Friday, 12 May 2017 at 18:43:53 UTC, H. S. Teoh wrote: I'm surprised there are no (known) incremental algorithms for generating a random permutation of 0..n that requires less than O(n) space. I've told you all you need to know...

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote: On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: On 04/28/2017 04:26 PM, Atila Neves wrote: > The other day I was reminded that in C++ land one has to > manually write `operator<<`

Re: Garbage Collector?

On Friday, 28 April 2017 at 21:21:13 UTC, jmh530 wrote: To be fair, C++ effectively has multiple pointer types too with raw pointers, unique_ptr, shared_ptr, and weak_ptr. However, each of the extra ones has a unique purpose and are opt-in. As a result, people happily use them when it makes

Re: Garbage Collector?

On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner wrote: Working on the memory chunk layer is memory management. Working on the object layer is object lifetime management. D offers you both automatic memory management and automatic lifetime management via its GC. D offers sound

Re: Duplicated functions not reported?

On Sunday, 16 April 2017 at 15:54:16 UTC, Stefan Koch wrote: sorting has O(n^2) worst case complexity. Therefore totaling to O(n^2) worst case again. Sorting with comparison is solved in O(n log n). If you have an upper limit on signature length then the problem is solvable for the whole

Re: Rename 'D' to 'D++'

On Friday, 10 March 2017 at 23:00:16 UTC, XavierAP wrote: IMHO... Only from a typical C++ centric perspective can it be claimed that C++11 and higher have not copied (not from D which was most of the time not first). Neither C++ or D have any significant original features. the first. And

Re: Clarification on D.

On Thursday, 9 March 2017 at 14:38:32 UTC, Guillaume Piolat wrote: On Thursday, 9 March 2017 at 14:08:00 UTC, Ola Fosheim Grøstad wrote: I don't really want to talk with you. Whatever suits you, but don't pretend that people that express views about D online are the competition. They are

Re: Google is apparently now better at searching programming-related questions

On Friday, 3 March 2017 at 18:28:50 UTC, Nick Sabalausky (Abscissa) wrote: startpage.com is another way to get clean (or at least clean-ish) results. Although, it's conceivable (probable?) it's really giving out results based on a "user" that's really an aggregate of startpage.com's users.

Re: If you needed any more evidence that memory safety is the future...

On Saturday, 25 February 2017 at 22:37:15 UTC, Chris Wright wrote: The undefined behavior is what happens after the would-be assertion failure occurs. The compiler is free to emit code as if the assertion passed, or if there is no way for the assertion to pass, it is free to do anything it

Re: If you needed any more evidence that memory safety is the future...

On Saturday, 25 February 2017 at 21:49:43 UTC, Chris Wright wrote: On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote: On 25.02.2017 15:38, Chris Wright wrote: On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: If 'disable' (as can be reasonably expected) means the compiler will behave

  1   2   >