Hello, is there a way of getting CT info of a class' children?
If no, what do you think of a new feature for DMD: template this
static ctors/dtors:
class A
{
static this(this T)()
{
writeln(static this(, T.stringof, ));
}
}
class B : A
{
}
would output:
static this(A)
Any way to do it without patching druntime?
Ok, i've added a pull request to be discussed. It expands RTInfo
capability as Jacob suggested. What do you think?
https://github.com/D-Programming-Language/druntime/pull/775
On Thursday, 24 April 2014 at 06:08:11 UTC, Jacob Carlborg wrote:
On 24/04/14 00:29, Martin Nowak wrote:
Looks fairly interesting, because it partly solves the issue
to allow
custom rtinfo.
I don't like this solution for custom RTInfo. It requires you
to change your type. I would rather
I guess this could be done without modifying the compiler, just
extend RTInfo(T) to support this UDA, but there's a problem
with attributes. They don't propagate to class' children, thus
they can't solve the main question of this topic.
But as an additional feature such UDA might be useful.
Also, this whole thing is not only about RT registration, it may
be used differently. The next usage that comes to mind after RT
is validating proper inheritance. E.g. Some root class wants it's
subclasses to always have a default ctor available, which again
can be verified in CT.
rtInfo through attributes implemented. Jacob, have i done it the
way you wanted?
https://github.com/D-Programming-Language/druntime/pull/775#issuecomment-41278520
Hello D community,
What do you think of a new __traits(getImports, Scope), that
returns a tuple of strings, which are imports made in a scope? If
scope is a module, it will produce a tuple like (std.conv,
std.traits).
Adam, that doesn't seem to work for me:
import std.typetuple;
import std.string;
import std.stdio;
template isImport(string i)
{
static if (__traits(compiles, mixin(i).stringof)
mixin(i).stringof.startsWith(module ))
enum isImport = true;
else
enum isImport = false;
}
Hello, I've played a bit with monitors, trying to make them
optional, and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors
The whole idea is that Object doesn't contain __monitor field
anymore.
The only downside i see here is that finalization of every
object will now lookup for a corresponding monitor, if it's
class doesn't define embedded one.
Ok, i think i've found a simple yet effective solution.
Adding a flag to ClassFlags: hasAllocatedMonitors.
Mark m_flags with this flag in
Ok, i think i've found a simple yet effective solution.
Implemented and pushed to the repo. Any more thoughts before a PR?
On Wednesday, 14 May 2014 at 08:37:41 UTC, bearophile wrote:
What's the syntax to define a class without its __monitor? Are
you using an annotation like @no_monitor?
No syntax for that. The __monitor is not present by default
anywhere. If you need it, you need to define one.
class A
{
}
bearophile, good point. What do you think of the following
solution:
1. Declaring member variable with __monitor identifier is
disallowed.
2. class may be defined with @__monitor attribute, in which case
a __monitor variable will be added to it's beginning.
3. Subclass of such class may again
On Wednesday, 14 May 2014 at 11:14:47 UTC, bearophile wrote:
I suggest a name like @monitor. The is no need for the
underscores.
Done.
A more tidy design could require the @monitor in all classes
that inherit from a @monitor-annotated class. But this also
looks a little overkill. So let's
On Wednesday, 14 May 2014 at 13:07:32 UTC, bearophile wrote:
I'd like to know why you think D classes should not have the
monitor on default (this means why you don't plan for a
@no_pointer).
There are 4 reasons for that.
1. I'm thinking of monitors as members of Object class, so all
other
On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
These would be breaking changes. I see the benefit but...
Breaking, only if someone used to define __monitor in his class.
Which is kinda weird, and according to docs (identifiers starting
with __ should are reserved). Or if someone
On Wednesday, 14 May 2014 at 14:44:07 UTC, Marc Schütz wrote:
The object's layout and size also change, but the layout of
objects is implementation defined AFAIK, and its size shouldn't
be hard-coded anyway, so the breakage is minimal.
You're right. Shared libraries will need to be rebuilt.
On Wednesday, 14 May 2014 at 19:08:30 UTC, bearophile wrote:
You are good. Before this is ready for Walter's judgement I
think this needs some simple performance/memory benchmarks, to
compare the situation before and after this change.
I've made some minor optimizations, and rebased everything
On Sunday, 18 May 2014 at 04:44:56 UTC, Martin Nowak wrote:
Global hashmap is a bad idea IMO because it's possibly
expensive and impure. Rather deprecate synchronizing on classes
without an explicit monitor.
Totally agreed. Hashmap is done just not to break existing code.
I don't think i've
On Sunday, 18 May 2014 at 05:01:21 UTC, Walter Bright wrote:
While I agree with Andrei's agreements (!), the rationale for
the current approach is to make it relatively straightforward
to translate existing Java code into D. There was a fair amount
of this in the early days of D, I'm not sure
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The _monitor slot is also used for std.signals. It's been set
up in druntime to support more than just being a monitor.
We've also considered it for a hook for a reference count
(though that design had other problems).
I'm not
IMHO LDC problems would be addressed much faster, if it
officially becomes the reference D compiler. LLVM would also
benefit from another community using it. So those unhappy with
LLVM's performance could also contribute (don't smile here! =) to
LLVM.
On Monday, 8 September 2014 at 16:56:49 UTC, Andrei Alexandrescu
wrote:
FWIW we could do this for backward compatibility: objects
without @monitor use the hashtable, and those with @monitor use
a field.
And that's exactly what current PR suggests. However, it's
stalled due to another issue.
On Sunday, 27 July 2014 at 11:44:35 UTC, ketmar wrote:
preliminary, but working port of Cassowary Solver —
GUI-oriented constraint solver, toolkit-agnostic layout engine.
it's not D-spirited yet, but it works. todo list includes
templated classes and bindings for gtk.d. feel free to fork and
so it's not a completely trashcan work. ;-)
No way it could be! We don't like monopoly here, right? =)
I just ported the library for my own fun, and added a couple of
D-ish features, like operator overloads, etc. It's not claimed to
be the best one in the world =). Please feel free to
Hello, is there any way to static if(__ctfe)? I want to declare
class members which are only available in ctfe. Thanx.
On Wednesday, 7 May 2014 at 09:51:01 UTC, John Colvin wrote:
On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote:
Hello, is there any way to static if(__ctfe)? I want to
declare class members which are only available in ctfe. Thanx.
Sadly not as far as I know. What's the use-case? There may
Hello, is there a way of reducing size of an empty class to just
vtbl? I tried to declare it as extern(C++) which works, but has a
nasty side effect of limited mangling.
On Thursday, 8 May 2014 at 14:57:37 UTC, Steven Schveighoffer
wrote:
The de-facto minimum size of a class is 16 bytes, due to the
minimum block size of the heap.
8 bytes vtbl pointer on 64-bit systems would still allocate
into 16-byte blocks.
-Steve
Yes, but still the question remains
On Thursday, 8 May 2014 at 17:49:01 UTC, Steven Schveighoffer
wrote:
To what end? What are you trying to save?
I'm trying to reimplement std.variant in a nice OOP way, that
supports CTFE, zero-size and a minimal amount of void*-casts. For
that i'm using my VariantPayload(T) class, which i want
But my question more was about where do you plan to put so many
of these objects that you will save a significant amount of
bytes, aside from the heap (which already uses 16-byte blocks).
Hm.. Stack/emplace, arrays, n-dimensional arrays? :) Besides, if
we're talking of D as a system language to
How many of these? In order to justify saving 8 bytes per
instance, you have have a lot. I don't see emplacing thousands
or tens of thousands of objects on the stack.
Ok, i guess i have to agree with you. But. Why are you protecting
__monitors so eagerly? :)
Arrays of objects are stored as
Also take a look at the Rust language, that avoids some of your
problems :-)
Done already =). Rust is great, but I like D, and i strongly
believe it's the next big language. If only it could allow a bit
more tweaks ;)
I don't doubt your reasons, but then again, you have what you
have right now in D. Asking for more, you have to provide it,
or convince others to. If it's the latter, you need to make a
very very strong case.
I want to provide it, but before i do, i want to know if there
were any decisions
Imho, offtop, also i'm a C++/Obj-C guy and that might partially
explain my preferences, but here are some more reasons:
1. I like the concept of CT-reflection and CTFE a lot. This makes
metaprogramming extremely powerful without any RT overheads. It
brings a lot more control to what goes to RT.
flamencofantasy, thanx for that! Where do we vote here? =)
On Tuesday, 13 May 2014 at 17:09:01 UTC, Daniel Murphy wrote:
What exactly is the mangling problem with extern(C++) classes?
Can't use D arrays (and strings) as function argument types.
Can't use D array types as template arguments.
extern (C++) MyClass(T)
{
}
MyClass!string a; // Mangling
On Wednesday, 14 May 2014 at 08:47:38 UTC, Daniel Murphy wrote:
I'm not getting any errors with the development head. What
os/compiler version?
Hm, now that's strange. Building with latest public version seems
to work. However, development head is doing the following:
$ ./test.d
Error: ICE:
On Wednesday, 14 May 2014 at 10:21:00 UTC, Dejan Lekic wrote:
that should not compile at all. Perhaps you thought extern(C++)
interface MyClass(T) ?
Ok, how about this one?
http://dpaste.dzfl.pl/04655ff6ddfd
It doesn't compile either.
Ali, i think that paragraph is talking about another case, which
is not my case. I'm not trying to use C++ templates, nor to
export a D template to C++. Besides, i guess that D template,
implementing a C++ interface is perfectly valid, regardless it's
template arguments, since it is
On Thursday, 15 May 2014 at 11:51:38 UTC, Daniel Murphy wrote:
This version seems to compile - the new manger can't handle
extern(C++) functions with D arrays as arguments or return
types.
Ok, i can understand that, but what about this one:
http://dpaste.dzfl.pl/6a9961e32e6d
It doesn't use d
42 matches
Mail list logo
