It's very useful to me ,,,thank you Jacob,
On 16.1.2013 22:53, Maxim Fomin wrote:
> Yes, it happens so (shared function made it a member). Casting away
> shared is UB but it can be done if your are sure.
Ok. But that leaves me with an unanswered question from one of my
previous posts.
What happens when you cast from and to shared? Is ther
UDAs very design point is to never change type they are attached
to.
If you want to inject code in a class/struct at compile-time,
template mixins are supposed tools.
On Thursday, 17 January 2013 at 08:46:22 UTC, Martin Drasar wrote:
Ok. But that leaves me with an unanswered question from one of
my
previous posts.
Casting away shared in undefined behavior. Although it may be not
written explicitly in dlang.org, once D will have a standard like
C or C++,
On 17.1.2013 12:56, Maxim Fomin wrote:
> Casting away shared in undefined behavior. Although it may be not
> written explicitly in dlang.org, once D will have a standard like C or
> C++, it will be name like so.
>
> In practice this means that behavior of program is uncertain and may
> result in m
On 2013-01-17 08:20, Era Scarecrow wrote:
Oh yes, do UDA's only work on types? or do they work on
functions/methods/delegates too? If you have it on a function how could
that be useful?
You can basically attach an UDA to any declaration. I think the
exception is parameters.
--
/Jacob Carl
17-Jan-2013 07:53, Era Scarecrow пишет:
Well got a few curious problems. Slicing doesn't seem it wants to work
as a separate type and can cause problems.
Let's take an example. Say our slice is..
struct BitArraySlice {
BitArray* ba;
ulong start, end;
}
Now how much does i
On Thursday, 17 January 2013 at 18:12:28 UTC, Dmitry Olshansky
wrote:
Well, the slice was invalidated by shrinking an array. I don't
expect the below to work.
It just seems like shrinking/expanding the array should still
work, perhaps I'm thinking of them too much like a normal array
slice.
On Mon, 14 Jan 2013 10:02:04 -, Regan Heath
wrote:
I'm more than happy to upload the database file here,but I can't find
how to.May I have your mail address?Appreciated for all the help!
My email address in the from is valid: regan at netmail dot co dot nz
Ok, solved the issue I thin
17-Jan-2013 22:34, Era Scarecrow пишет:
Thoughts? Feedback? I'm about ready to drop this and resume my
previous version and enhance it with recent experiences.
Feel free to do it how you see it. It's just that I think the
semantics of the previous version can't be improved to a consistent
st
On Thursday, 17 January 2013 at 04:38:14 UTC, Ali Çehreli wrote:
On 01/16/2013 05:59 PM, Joseph Cassman wrote:
[...]
/* This template is not directly related. (I expect it to be in
Phobos; maybe
* it's already there. (?))
*/
template hasAttribute(T, AttributeInQuestion)
[...]
Ali
hasAtt
On Thursday, 17 January 2013 at 07:27:35 UTC, Jacob Carlborg
wrote:
On 2013-01-17 02:59, Joseph Cassman wrote:
I was wondering what the syntax is for user defined attributes
(i.e. bug
9222) implemented in release 2.061. I was still unclear after
reading
the thread
forum.dlang.org/thread/k7afq6
On Thu, Jan 17, 2013 at 11:36:33PM +0400, Dmitry Olshansky wrote:
[...]
> I'm thinking that a opSlice of stack-allocated must be @system and a
> heap allocated can be @safe.
[...]
Related: http://d.puremagic.com/issues/show_bug.cgi?id=8838
T
--
Who told you to swim in Crocodile Lake without li
On Thursday, 17 January 2013 at 19:36:34 UTC, Dmitry Olshansky
wrote:
I'm thinking that a opSlice of stack-allocated must be @system
and a heap allocated can be @safe.
That's just a small part of the problem. With the new design,
90% of it can be safe; Just the actual slice buffer when you
r
On Thursday, 17 January 2013 at 07:17:57 UTC, Jonathan M Davis
wrote:
I'd still like to break it up a bit, but I'm not going to do it
unless some
variant of DIP15 or DIP16 is implemented so that it can be done
without
breaking any code. So, it probably won't be broken up any time
soon. It's not
The usual way to link in D libs into D code is to include the
required D module source files, but that gives away all of the
source code which in some instances is not possible to do (eg
legal reasons). The other way is to create a c-style API using
extern (C), but that means translating some s
On Fri, 18 Jan 2013 02:01:52 +0100, Rob T wrote:
> The usual way to link in D libs into D code is to include the required D
> module source files, but that gives away all of the source code which in
> some instances is not possible to do (eg legal reasons). The other way
> is to create a c-style A
On 1/18/13, Rob T wrote:
> The usual way to link in D libs into D code is to include the
> required D module source files, but that gives away all of the
> source code which in some instances is not possible to do (eg
> legal reasons). The other way..
The other way is to use D interface files, wh
On Friday, 18 January 2013 at 01:07:05 UTC, Justin Whear wrote:
You can use "extern(D)" or simply "extern"; this is described
here:
http://dlang.org/attribute.html#linkage
Justin
So there is an extern (D), excellent! Slightly embarrassed I
didn't find this for myself.
--rt
On Friday, 18 January 2013 at 02:08:46 UTC, Andrej Mitrovic wrote:
The other way is to use D interface files, which the compiler
can
automatically generate for you if you pass the -H switch. Also
use the
-op switch if you're generating multiple files at once, which
will
preserve directory path
On 1/18/13, Rob T wrote:
> however I read somewhere that it pretty much does nothing but
> strip out the comments because it needs the full source code for
> a inlining, CTFE, and templates.
There was a recent pull that implemented better header generation
(https://github.com/D-Programming-Langua
On 2013-01-18 05:37, Rob T wrote:
The documentation says that the interface files will only contain the
parts of a module's source code that is required for linking, however I
read somewhere that it pretty much does nothing but strip out the
comments because it needs the full source code for a i
22 matches
Mail list logo
