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
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
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
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
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?
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
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
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
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
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
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
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
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,
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
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
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.
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
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
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...
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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
On Monday, 14 September 2015 at 20:54:55 UTC, Jonathan M Davis
wrote:
On Monday, September 14, 2015 01:12:02 Ola Fosheim Grostad via
Digitalmars-d-learn wrote:
On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
wrote:
> Regardless, idiomatic D involves a lot more st
On Monday, 14 September 2015 at 20:34:03 UTC, Jonathan M Davis
wrote:
I'm not sure why it wouldn't be suitable for the typical use
case. It's quite performant. It would still not be suitable for
many games and environments that can't afford to stop the world
for more than a few milliseconds,
On Sunday, 13 September 2015 at 17:16:02 UTC, ponce wrote:
On Sunday, 13 September 2015 at 17:00:30 UTC, Ola Fosheim
If this was true then Go would not have a concurrent collector.
I was speaking of the D language.
Go only added concurrent GC now at version 1.5 and keep improving
it to
On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
wrote:
stop-the-world GC. For instance, this has come up in
discussions on games where a certain framerate needs to be
maintained. Even a 100 ms stop would be way too much for them.
In fact, it came up with the concurrent GC that
48 matches
Mail list logo
