On Wednesday, 19 September 2012 at 21:36:56 UTC, Namespace wrote:
I count it to destroy it if it isn't used anymore.
What I'm saying though is that when your stacked_obj goes out
of scope, it gets destroyed, 100% of the time. The chunk
disappears, along with any object inside it. When that
On 2012-09-20 01:56, Jonathan M Davis wrote:
Yes. But the solution then is to not unit test your library that way. You
build it as a binary with an empty main and run that. It may be that compiling
it as a library and then linking should work, but unless you want to have the
unit test stuff
I'm new to D. While poking around the site I stumbled across
Uniform Function Call Syntax. This lead me here:
http://www.reddit.com/r/programming/comments/vvpfy/uniform_function_call_syntax_in_d_gamedevnet/c58f8yy
I seem to remember reading that empty function invocation parens
were now
On Thursday, September 20, 2012 09:40:53 Will Rubin wrote:
I'm new to D. While poking around the site I stumbled across
Uniform Function Call Syntax. This lead me here:
http://www.reddit.com/r/programming/comments/vvpfy/uniform_function_call_syn
tax_in_d_gamedevnet/c58f8yy
I seem to
20.09.2012 13:27, Denis Shelomovskij пишет:
Is there any guaranties that `ScopeTemp` will not be destroyed before
`f` call because it isn't used?
---
struct ScopeTemp
{
...
// allocates value
this(...) { ... }
@property void* value() { ... }
// destroys value
On Thursday, 20 September 2012 at 08:10:36 UTC, Namespace wrote:
You're right.
This is my next try: http://dpaste.dzfl.pl/02b32d33
Do you have anything else to say? :)
I think it looks good, but I'm unsure about move, or allowing
pass by value:
Classes can't be memcopied the way structs
Am Thu, 20 Sep 2012 10:11:37 +0200
schrieb Namespace rswhi...@googlemail.com:
You're right.
This is my next try: http://dpaste.dzfl.pl/02b32d33
Do you have anything else to say? :)
I think it shouldn't be possible to copy an OnStack struct. The
destructor is run for every copy, but the
Am Thu, 20 Sep 2012 12:06:28 +0200
schrieb monarch_dodra monarchdo...@gmail.com:
On Thursday, 20 September 2012 at 08:10:36 UTC, Namespace wrote:
You're right.
This is my next try: http://dpaste.dzfl.pl/02b32d33
Do you have anything else to say? :)
I think it looks good, but I'm unsure
Am Wed, 19 Sep 2012 12:34:18 -0700
schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Wednesday, September 19, 2012 20:50:08 Chris Molozian wrote:
Hey all,
I'm sure that this is a rather daft question but I've tried to
search the d.learn mailing list and must have missed a question
On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
But it should be possible.
I'm not arguing that it shouldn't be possible. I'm just pointing out that it
wouldn't really be useful. You have to build at least two versions of your
library anyway (one with -unittest and one without),
On Thursday, 20 September 2012 at 09:31:45 UTC, Denis
Shelomovskij wrote:
20.09.2012 13:27, Denis Shelomovskij пишет:
Is there any guaranties that `ScopeTemp` will not be destroyed
before
`f` call because it isn't used?
---
struct ScopeTemp
{
...
// allocates value
this(...) { ...
So I should disable the copy ctor (@disable this(this)) and drop
move, right?
As you can See if I pass a OnStack to function/class i'm using
.get all the Time. The only other method IMO would be to pass it
as OnStack by value and Store it in the other class also as
OnStack, right?
Thanks for the detailed reply. It's too early for me to have much
of an opinion but I'll take your approach and use @Property
without parens (as I would in C# for example) and stick with the
empty parens for non-property functions as it's a bit clearer to
see what's really going on at this
On Thursday, 20 September 2012 at 12:59:51 UTC, Will Rubin wrote:
Thanks for the detailed reply. It's too early for me to have
much of an opinion but I'll take your approach and use
@Property without parens (as I would in C# for example) and
stick with the empty parens for non-property
On Thursday, 20 September 2012 at 12:32:03 UTC, Namespace wrote:
So I should disable the copy ctor (@disable this(this)) and
drop move, right?
Yes, but at that point, what you have is scoped!T re-implemented
:/
As you can See if I pass a OnStack to function/class i'm using
.get all the Time.
On Thursday, 20 September 2012 at 14:02:01 UTC, monarch_dodra
wrote:
On Thursday, 20 September 2012 at 12:32:03 UTC, Namespace wrote:
So I should disable the copy ctor (@disable this(this)) and
drop move, right?
Yes, but at that point, what you have is scoped!T
re-implemented :/
As you can
On Thursday, 20 September 2012 at 14:09:29 UTC, Namespace wrote:
http://dpaste.dzfl.pl/edit/361a54eb
With
[code]
@disable this(this);
[/code]
this don't work (as expected). But with the copy ctor but
without .get you earn a segmentation fault (as you can see).
So you can disable the copy ctor
Just a _write_ property:
struct Bleem {
int _value;
public:
//@property int value() { return _value; }
@property int value(int newValue) { return _value = newValue; }
}
void main() {
auto bleem = Bleem();
writeln(Result: , bleem.value = 9);
}
Application Output
Result: 9
Off the top
On Thursday, 20 September 2012 at 14:31:55 UTC, Will Rubin wrote:
Just a _write_ property:
struct Bleem {
int _value;
public:
//@property int value() { return _value; }
@property int value(int newValue) { return _value = newValue;
}
}
void main() {
auto bleem = Bleem();
On Wednesday, 19 September 2012 at 17:31:41 UTC, Jacob Carlborg
wrote:
On 2012-09-19 12:35, Chris wrote:
I tried to create a JNI library that - via C - accesses a D
function.
Calling D from C is not a problem, but when the whole stuff is
wrapped
into a JNI library, I get the following error
On Thursday, 20 September 2012 at 14:15:23 UTC, monarch_dodra
wrote:
On Thursday, 20 September 2012 at 14:09:29 UTC, Namespace wrote:
http://dpaste.dzfl.pl/edit/361a54eb
With
[code]
@disable this(this);
[/code]
this don't work (as expected). But with the copy ctor but
without .get you earn a
TimeOfDay's roll function refers to an add method which would
increment or decrement the next greater unit of time when it
wraps a unit of time. This method seems to be absent, while
DateTime has it.
Sorry, the thread title was About std.ascii.toLower...
Actually I see DateTime's method is days and months only, why
aren't hours, minutes and seconds available?
On Thursday, 20 September 2012 at 15:04:48 UTC, Namespace wrote:
On Thursday, 20 September 2012 at 14:15:23 UTC, monarch_dodra
wrote:
On Thursday, 20 September 2012 at 14:09:29 UTC, Namespace
wrote:
http://dpaste.dzfl.pl/edit/361a54eb
With
[code]
@disable this(this);
[/code]
this don't work
I expect nothing, my only intention was to show you, that this
cannot work. But that it works with an explicit cast is very
impressive. I thought the alias this does it automatically.
I'm learning too. ;)
On Thursday, 20 September 2012 at 16:00:18 UTC, bearophile wrote:
This is the signature of a function of std.ascii:
http://dlang.org/phobos/std_ascii.html#toLower
pure nothrow @safe dchar toLower(dchar c);
If this function is supposed to be used on ASCII strings,
what's the point of
On 09/20/2012 09:02 AM, ixid wrote:
TimeOfDay's roll function refers to an add method
I see how The difference between rolling and adding ... implies that
there is also an add() function just like there is a roll() function. In
fact, adding is handled simply by operator overloading. You can
monarch_dodra:
It's not, it only *operates* on ASCII, but non ascii is still a
legal arg:
Then maybe std.ascii.toLower needs a pre-condition that
constraints it to just ASCII inputs, so it's free to return a
char.
Bye,
bearophile
On Thursday, September 20, 2012 18:02:04 ixid wrote:
TimeOfDay's roll function refers to an add method which would
increment or decrement the next greater unit of time when it
wraps a unit of time. This method seems to be absent, while
DateTime has it.
Create a Duration and use +. e.g.
auto
On Thursday, 20 September 2012 at 16:34:22 UTC, bearophile wrote:
monarch_dodra:
It's not, it only *operates* on ASCII, but non ascii is still
a legal arg:
Then maybe std.ascii.toLower needs a pre-condition that
constraints it to just ASCII inputs, so it's free to return a
char.
Bye,
monarch_dodra:
Would that actually change anything though? I mean what with
alignment and everything, wouldn't returning a char be just as
expansive? I'm not 100% sure.
If you are thinking about the number of operations, then it's the
same, as both a char and dchar value go in a register.
On Thursday, September 20, 2012 18:35:21 bearophile wrote:
monarch_dodra:
It's not, it only *operates* on ASCII, but non ascii is still a
legal arg:
Then maybe std.ascii.toLower needs a pre-condition that
constraints it to just ASCII inputs, so it's free to return a
char.
Goodness no.
On Thursday, 20 September 2012 at 13:57:54 UTC, monarch_dodra
wrote:
On Thursday, 20 September 2012 at 12:59:51 UTC, Will Rubin
wrote:
Thanks for the detailed reply. It's too early for me to have
much of an opinion but I'll take your approach and use
@Property without parens (as I would in C#
On Thursday, 20 September 2012 at 17:13:09 UTC, Jesse Phillips
wrote:
On Thursday, 20 September 2012 at 13:57:54 UTC, monarch_dodra
wrote:
On Thursday, 20 September 2012 at 12:59:51 UTC, Will Rubin
wrote:
Thanks for the detailed reply. It's too early for me to have
much of an opinion but I'll
On Thursday, 20 September 2012 at 17:05:18 UTC, bearophile wrote:
monarch_dodra:
Would that actually change anything though? I mean what with
alignment and everything, wouldn't returning a char be just as
expansive? I'm not 100% sure.
If you are thinking about the number of operations, then
Jonathan M Davis:
Goodness no.
:-)
1. Operating on a char is almost always the wrong thing to do.
A single char is often not so useful but I have to keep many
mutable chars, keeping them as char[] instead of dchar[] saves
both memory and reduces cache misses. The same is true for types
On 2012-09-20 13:14, Jonathan M Davis wrote:
On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
But it should be possible.
I'm not arguing that it shouldn't be possible. I'm just pointing out that it
wouldn't really be useful. You have to build at least two versions of your
library
On Thursday, 20 September 2012 at 00:23:33 UTC, Jonathan M Davis
wrote:
On Wednesday, September 19, 2012 22:25:46 Øivind wrote:
I am struggeling to get around the cycle detection kicking in
when I have static init in modules that depend on eachother.
I have seen some threads on 'fixes' for
Thanks a million, Jacob! I have just tested it with the latest
version of dmd and it works.
On Thursday, September 20, 2012 20:49:32 Øivind wrote:
Thanks for the explination. The trick you talk about has worked
for me before, but now I really need static init of modules that
depend on eachother. Only solution I can think of is to list all
modules in a script and generate d code from
On Thu, 20 Sep 2012, Jonathan M Davis wrote:
On Thursday, September 20, 2012 20:49:32 ?ivind wrote:
Thanks for the explination. The trick you talk about has worked
for me before, but now I really need static init of modules that
depend on eachother. Only solution I can think of is to list
On Sep 19, 2012, at 1:07 PM, Peter Sommerfeld nore...@rubrica.at wrote:
Hi Everyone!
I'm new to :D and have a small problem with std.json.
If I use parseJSON() or toJSON() all whitespaces are
removed. I would like it to have them preserved for
better readability for users.
In
Sean Kelly wrote:
It sounds like what you really want is pretty printing from toJSON.
It's really not too hard to add, and I'd like it too. I think this will
have to wait for the new std.json, whenever we get that though.
Agreed! Where can the version be seen which are on review ?
Peter
inconsistent:
auto a1=tuple(tuple(1));//CT error
auto a2=tuple(tuple(1),1);//works
bug?
On Thursday, 20 September 2012 at 23:03:34 UTC, timotheecour
wrote:
inconsistent:
auto a1=tuple(tuple(1));//CT error
auto a2=tuple(tuple(1),1);//works
bug?
I filed it here:
http://d.puremagic.com/issues/show_bug.cgi?id=8702
On 09/21/2012 01:04 AM, timotheecour wrote:
inconsistent:
auto a1=tuple(tuple(1));//CT error
auto a2=tuple(tuple(1),1);//works
bug?
Yes. In general, if there is a compile time error other than a static
assertion failure that points to Phobos code, you can assume that it is
a library bug.
47 matches
Mail list logo
