On Mon, 06 Aug 2012 01:13:31 +0200, Klaim - Joël Lamotte
wrote:
For example, lot of C# based games have uncontrollable hics because of
garbage collector.
From what I understand, but i'm not a specialist, it is impossible to
avoid this with a garbage collector. I suppose it is one reason why
Hi people,
I am a game developer (using C++ and various other languages), I stop by
sometimes to see how D and it's community evolves.
I was reading this interesting (but a bit depressing) thread and I mus just
point something for new programmers not knowing a lot about game
development:
On Sat, A
On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis
wrote:
I'd be very surprised if all that many people compile with
-property.
Indeed. Sometimes I try it just to see what happens, and always
the same results: it doesn't s
On Sunday, August 05, 2012 12:38:56 Christophe Travert wrote:
> Jonathan M Davis , dans le message (digitalmars.D:174267), a écrit :
> > On Saturday, August 04, 2012 15:22:34 Jonathan M Davis wrote:
> >> On Sunday, August 05, 2012 00:15:02 Timon Gehr wrote:
> >> > T fun(T)(T arg) if(isSomeString!ar
On 8/5/2012 12:59 AM, Brad Roberts wrote:
To help with performance comparisons I ripped dmd's lexer out and got it
building as a few .d files. It's very crude.
It's got tons of casts (more than the original c++ version). I attempted no
cleanup or any other change than the
minimum I could to g
Adam D. Ruppe:
Maybe you should pay my mortgage.
I understand. The kind of programs I write enjoy run-time errors
raised on overflow on integral values operations. Recently I
opened a silly thread about this in D learn. Adding those to D
will help me pay my bills and better keep my mind.
On Sunday, 5 August 2012 at 09:56:09 UTC, David Nadlinger wrote:
On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:
It sounds like this should be targetable from ldc now.
Hm? It's great that the bigger part of Charles' work has
arrived in trunk in June or so, but what's still co
On Sunday, 5 August 2012 at 15:45:37 UTC, bearophile wrote:
What about turning octal into a propety to fix this problem?
octal actually works because it isn't a function.
But in general, changing non-properties to properties just for
syntax is backward anyway. Whether something is a property
Adam D. Ruppe:
octal!"555" - it is an enum, so gotta not use them) but
with UFCS, that's actually out the window now:
What about turning octal into a propety to fix this problem?
There's just no winning without redoing a LOT of code, changing
names, changing some expressions into statem
On Sun, 05 Aug 2012 16:32:49 +0200, Adam D. Ruppe
wrote:
import std.algorithm;
foreach(i; [1,2,3].map!"a+1") {
}
prophate.d(5): Error: not a property [1,2,3].map!("a+1")
Of course, this is relatively new, using ufcs in 2.059, so the breakage
probably isn't too bad, but I'm not the only o
On 05-Aug-12 18:32, Adam D. Ruppe wrote:
On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
I'd be very surprised if all that many people compile with -property.
Indeed. Sometimes I try it just to see what happens, and always the same
results: it doesn't solve problems and compl
On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
I'd be very surprised if all that many people compile with
-property.
Indeed. Sometimes I try it just to see what happens, and always
the same results: it doesn't solve problems and complains about
code.
Some examples of thin
On 2012-08-05 15:51, Adam D. Ruppe wrote:
And then I need to check the operator overloading.
I see.
I saw it, but one step at a time for now...
Hehe, yes, of course. No pressure :)
--
/Jacob Carlborg
On 2012-08-04 21:28, Jonathan M Davis wrote:
That would be kind of cool, though I would have suggested that putting
@property on a variable would make it so that you couldn't do anything with it
that you couldn't do with a property (e.g. taking the address of a variable
will break when it's swit
On Sunday, 5 August 2012 at 12:14:41 UTC, Jacob Carlborg wrote:
Doesn't this already work?
Yes, but it is in my test file to make sure it still works,
without any additional pointless function calls.
Right now the basics all work, but member template function that
happen to be getters can b
Paulo Pinto:
Thank you for your answer, but I think you have missed most
subtleties of my points.
I doubt Ada programmers would appreciate any other language,
given the type of high security applications Ada is used in.
I was not referring to just Ada programmers, but to programs that
peop
On Sunday, 5 August 2012 at 12:18:52 UTC, Jacob Carlborg wrote:
BTW, how will this interact with overloaded operators and
similar more advanced features? Say that I have a getter that
returns a struct/class which overloads the += operator.
I'm not sure yet... stuff like this is one reason why
Jonathan M Davis , dans le message (digitalmars.D:174267), a écrit :
> On Saturday, August 04, 2012 15:22:34 Jonathan M Davis wrote:
>> On Sunday, August 05, 2012 00:15:02 Timon Gehr wrote:
>> > T fun(T)(T arg) if(isSomeString!arg){
>> >
>> > return arg~arg[0];
>> >
>> > }
IMO, the behavior
On 2012-08-04 22:53, Adam D. Ruppe wrote:
I did this and now I think this thing is almost done
===
int a;
@property int funcprop() {
writeln("calling the getter and getting ", a);
return a;
}
@property int funcprop(int s) {
writeln("calling the setter with ", s);
return
On 2012-08-04 23:35, Adam D. Ruppe wrote:
OK, I just compiled one of my work apps with the hacked up dmd.
It caught me using properties as functions in a few places, which I had
to fix by removing the parenthesis from some places, and the @property
from a few other places (the functions weren't
On 2012-08-04 21:25, Adam D. Ruppe wrote:
Yes, I agree in general, but if a getter returns a ref, you should
be able to write to it... I think anyway, but it is an lvalue anyway.
Or we could disallow getters returning by reference.
What I just added to my hacked compiler is this:
=
el
On 2012-08-04 21:28, Jonathan M Davis wrote:
That would be kind of cool, though I would have suggested that putting
@property on a variable would make it so that you couldn't do anything with it
that you couldn't do with a property (e.g. taking the address of a variable
will break when it's swit
Andrej Mitrovic , dans le message (digitalmars.D:174259), a écrit :
> On 8/4/12, Jonathan M Davis wrote:
>> snip
>
> I agree with you. isSomeString!T predicate failing maybe isn't as
> serious as "!isSomeString!T" passing and ending up with wrong results.
> At the very least this should have been
On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:
It sounds like this should be targetable from ldc now.
Hm? It's great that the bigger part of Charles' work has arrived
in trunk in June or so, but what's still completely missing is
landing pad codegen – isn't it?
David
On Saturday, August 04, 2012 17:45:58 Dmitry Olshansky wrote:
> On 04-Aug-12 15:48, Jonathan M Davis wrote:
> > On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
> >> I see it as a compile-time policy, that will fit nicely and solve both
> >> issues. Just provide a templates with a few
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum
wrote:
On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
Does anyone else find this behavior too strict?
Yes. Sounds like yet another case of forcing bitwise const on something
that should only be logically const.
Pleas
On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen
wrote:
Does anyone else find this behavior too strict?
Yes. Sounds like yet another case of forcing bitwise const on
something that should only be logically const.
Please stop forcing bitwise constancy on everything. Not
everythi
On Sat, 04 Aug 2012 16:08:42 +0200, Andrei Alexandrescu
wrote:
I think a stance could be taken either way. Const invariants are like
the European police; non-const invariants are like US police.
Funny, my impression of the US/European police is the exact opposite.
--
Simen
To help with performance comparisons I ripped dmd's lexer out and got it
building as a few .d files. It's very crude.
It's got tons of casts (more than the original c++ version). I attempted no
cleanup or any other change than the
minimum I could to get it to build and run. Obviously there's t
05.08.2012 7:33, F i L пишет:
...I'm guessing because of boxing?...
There is no boxing in D language itself. One should use library
solutions for such functionality.
--
Денис В. Шеломовский
Denis V. Shelomovskij
30 matches
Mail list logo
