On Monday, 16 November 2015 at 13:34:41 UTC, Kagamin wrote:
On Monday, 16 November 2015 at 10:47:36 UTC, Marc Schütz wrote:
Hmmm... why is `unpredictableSeed` only a `uint`? Surely most
PRNGs have more than 32 bits of internal state?
Maybe it's only worth 32 random bits? There's a rangified
On Saturday, 31 October 2015 at 23:16:04 UTC, Ali Çehreli wrote:
Although still years away from production, the Mill CPU will
have decimal floating point:
http://millcomputing.com/wiki/Instruction_Set
Mill is a fun project, and there are also base 10 floating point
FPGA coprocessors
On Wednesday, 4 November 2015 at 08:18:00 UTC, Ali Çehreli wrote:
Thanks. I've noticed that the parameter of the subtraction
functions should be named 'underflow', no?
Integer math cannot underflow, unless you define division to be
equivalent to division over reals.
overflow => higher/lower
On Wednesday, 4 November 2015 at 10:06:47 UTC, Ali Çehreli wrote:
Thanks. It looks like I've been making stuff up on this page: :(
http://ddili.org/ders/d.en/arithmetic.html
It's a common source for confusion, the word "underflow" is a bit
misleading. Maybe better to use the term
On Sunday, 18 October 2015 at 20:44:44 UTC, Mengu wrote:
i've seen the presentation and i can't stop thinking how it'd
be if they had chosen D instead of Go.
Not much better, probably worse, given that Go has stack
protection for fibers and D doesn't. So in Go you can get away
with 2K
On Thursday, 15 October 2015 at 09:24:52 UTC, Chris wrote:
Yep. This occurred to me too. Sorry Ola, but I think you don't
know how sausages are made.
I most certainly do. I am both doing backend programming and we
have a farm... :-)
Do you really think that all the websites out there are
On Thursday, 15 October 2015 at 07:57:51 UTC, Russel Winder wrote:
lot better than it could be. From small experiments D is (and
also Chapel is even more) hugely faster than Python/NumPy at
things Python people think NumPy is brilliant for. Expectations
Have you had a chance to look at
On Wednesday, 14 October 2015 at 15:49:20 UTC, David DeWitt wrote:
I agree but the quora question ask why it is popular despite
being slow and this is the reason. If you are doing tasks that
are computationally expensive in Python then yes it will be
slow but Python is popular largely because
On Wednesday, 14 October 2015 at 15:54:49 UTC, Laeeth Isharc
wrote:
For a long time, Ola, I am done discussing with you. But I
would ask you to take more responsibility for the effect of you
words. The piece you quote is from the question, and not from
what I wrote. You refer to it as flame
On Tuesday, 13 October 2015 at 23:26:14 UTC, Laeeth Isharc wrote:
https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow
Andrei suggested posting more widely.
That's flaimbait:
«Many really popular websites use Python. But why is that?
Doesn't it affect the performance of the
On Wednesday, 14 October 2015 at 18:37:40 UTC, Mengu wrote:
websites? nope. like booking.com, airbnb.com, reddit.com are
popular websites that have many parts which have to be dynamic
and responsive as hell and they cannot use caching,
pre-generated content, etc.
They can if they know what
On Wednesday, 14 October 2015 at 18:55:28 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 14 October 2015 at 18:37:40 UTC, Mengu wrote:
websites? nope. like booking.com, airbnb.com, reddit.com are
popular websites that have many parts which have to be dynamic
and responsive as hell and they
On Thursday, 15 October 2015 at 10:00:21 UTC, Chris wrote:
about the sausages you get out there ;) A lot of websites are
not "planned". They are quickly put together to promote an idea.
They are WordPress sites... :-(
If you designed a website from a programming point of view
first, you'd
On Sunday, 18 October 2015 at 12:50:43 UTC, Namespace wrote:
On Tuesday, 13 October 2015 at 23:26:14 UTC, Laeeth Isharc
wrote:
https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow
Andrei suggested posting more widely.
Maybe also interesting:
On Sunday, 18 October 2015 at 13:57:40 UTC, Namespace wrote:
I liked the fact that Python with PyPy is more performant than
Go (in contrast to the title "Python is slow") and that
Go-Routines leak.
Yes, Python apparently used less memory, which is rather
important when you write a service
On Sunday, 13 September 2015 at 16:53:20 UTC, ponce wrote:
GC is basically ok for anything soft-realtime, where you
already spend a lot of time to go fast enough. And if you want
hard-realtime, well you wouldn't want malloc either.
It's a non-problem.
If this was true then Go would not have
On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
wrote:
the GC heavily. And the reality of the matter is that the vast
majority of programs will have _no_ problems with using the GC
so long as they don't use it heavily. Programming like you're
in Java and allocating everything on
On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
Personally, when I make a strong claim about something and find
that I am wrong (the claim that D needs to scan every pointer),
I take a step back and consider my view rather than pressing
harder. It's beautiful to be wrong
On Monday, 14 September 2015 at 00:53:58 UTC, Jonathan M Davis
wrote:
So, while the fact that D's GC is less than stellar is
certainly a problem, and we would definitely like to improve
that, the idioms that D code typically uses seriously reduce
the number of performance problems that we get.
And this:
class TestInt: Test {
alias opIndex = super.opIndex!int;
}
class TestString: Test {
alias opIndex = super.opIndex!string;
}
And this?
auto ref qua(T)(Test t){
struct wrap {
Test t;
T opIndex(int i){ return t.opIndex!T(i); }
}
return wrap(t);
}
void main()
{
auto test = new Test();
writeln(test.qua!string[0], test.qua!int[0]);
}
On Tuesday, 6 October 2015 at 09:28:29 UTC, Marc Schütz wrote:
I see, this is a new problem introduced by `char + int = char`.
But at least the following could be disallowed without
introducing problems:
int a = 'a';
char b = 32;
But strictly speaking, we already accept overflow
On Wednesday, 6 January 2016 at 01:41:03 UTC, Basile B. wrote:
Until a certain "time" my answers were useful. But I recognize
that after this "time" I've managed to turn the topic into
something totally delirious because, to be honest I was
completly sratched by alcohool. I'm sorry but life is
On Tuesday, 5 January 2016 at 22:02:47 UTC, Basile B. wrote:
du bist normal oder idiot ?
https://youtu.be/7kjTXMecCrM
Ding dong!
On Tuesday, 5 January 2016 at 22:40:22 UTC, Basile B. wrote:
https://en.wikipedia.org/wiki/Turing_Award
Si tu crois que tu es un génie, il y a de forte chance que tu
sois un gros bouffon.
Jeg hadde faktisk 2001 vinnerne av Turing prisen som forelesere
på universitetet og Kristen Nygaard var
On Tuesday, 5 January 2016 at 21:01:55 UTC, Basile B. wrote:
Awww... I'm so sorry.
https://youtu.be/uyMUck2RRjw
Sorry about being off-topic, let's get back on topic:
https://youtu.be/MPwLKIXYEPE?t=1m20s
On Tuesday, 5 January 2016 at 23:26:12 UTC, Basile B. wrote:
access to pix is easy...
This is the learn forum. Maybe one should be able to figure it
out without asking, but there is nothing wrong with asking in
depth on this forum. The threshold for asking should be low in
here. At worst,
On Thursday, 24 December 2015 at 00:16:16 UTC, rsw0x wrote:
restrict it to 'programming' to get a more accurate assessment
of D.
https://google.com/trends/explore#cat=0-5-31=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q=1%2F2010%2061m=q=Etc%2FGMT-2
removed C++ because
On Wednesday, 8 June 2016 at 15:52:06 UTC, ketmar wrote:
On Wednesday, 8 June 2016 at 15:40:48 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 8 June 2016 at 15:31:34 UTC, ketmar wrote:
i'm trying to hint that there is no reason to reimplement
*everything* in D. bad engineers reinvent, good
On Wednesday, 8 June 2016 at 16:28:54 UTC, dewitt wrote:
On Wednesday, 8 June 2016 at 15:18:27 UTC, ketmar wrote:
On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad
wrote:
People check out stuff like that. The forum backend also use
a standard NNTP server, not implemented in D?
On Wednesday, 8 June 2016 at 16:53:32 UTC, ketmar wrote:
go write it! nope? why do you think that D devs should? they
have other work to do, it would be *stupid* to not reuse
existing tools.
If I thought that D was good for the purpose, I would. I have not
made such claims. I am pointing out
On Wednesday, 8 June 2016 at 14:45:58 UTC, Mike Parker wrote:
What does that have to do with the website? The forum software
is written in D and has a reputation for performance. This is
simply a matter of it not popping up on anyone's radar and has
nothing to do with the GC or performance
On Wednesday, 8 June 2016 at 16:07:26 UTC, ketmar wrote:
On Wednesday, 8 June 2016 at 15:57:42 UTC, Ola Fosheim Grøstad
wrote:
Huh? No, as long as D is not backed by some giant like Google
or Apple it has to do its own marketing and showcase its own
stuff where it can.
the key words are
On Wednesday, 8 June 2016 at 15:18:27 UTC, ketmar wrote:
On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad
wrote:
People check out stuff like that. The forum backend also use a
standard NNTP server, not implemented in D? That's ok too as
there is no D forum software...
it's even
On Wednesday, 8 June 2016 at 16:36:50 UTC, ketmar wrote:
On Wednesday, 8 June 2016 at 16:23:13 UTC, Ola Fosheim Grøstad
wrote:
Yes, no point in writing your own forum software.
ah, sure, there was the reason to write DFeed! that's why
forum.dlang.org is using engine written in D.
DFeed is
On Wednesday, 8 June 2016 at 16:44:00 UTC, ketmar wrote:
On Wednesday, 8 June 2016 at 16:38:02 UTC, Ola Fosheim Grøstad
wrote:
They do of course use golang for their blog and make it
available as a download.
As they _should_.
google. money. does that rings the bell?
No. The go blog
On Wednesday, 8 June 2016 at 15:04:24 UTC, Adam D. Ruppe wrote:
On Wednesday, 8 June 2016 at 14:57:11 UTC, Jonathan Marler
wrote:
However, I think you have to consider the emotional impact of
this.
nodejs.org's homepage is served by nginx. D is general purpose,
node is specifically web.
On Wednesday, 8 June 2016 at 15:31:34 UTC, ketmar wrote:
i'm trying to hint that there is no reason to reimplement
*everything* in D. bad engineers reinvent, good engineers reuse!
This is about marketing, not engineering.
Walter is arguing that vibe.d should be distributed with the
compiler.
On Wednesday, 8 June 2016 at 18:15:22 UTC, Seb wrote:
- good nosql interface
what's wrong with vibed's mongodb?
Probably nothing for those who use it. I only use:
https://cloud.google.com/datastore/
https://cloud.google.com/storage/
https://cloud.google.com/sql/
Amazon and Microsoft have
On Wednesday, 8 June 2016 at 16:58:42 UTC, Mike Parker wrote:
At any rate, we *are* using our own tech in several places. And
I think Seb has shown that in practice, it probably isn't that
big a deal that the entire website isn't served by a D project.
If you want to convince me, as a backend
On Wednesday, 8 June 2016 at 17:25:32 UTC, Brad Anderson wrote:
On Wednesday, 8 June 2016 at 14:41:55 UTC, Ola Fosheim Grøstad
wrote:
[snip]
I like the "are we fast yet" websites that various project put
up, displaying improvements over time.
You mean like this?
On Wednesday, 8 June 2016 at 17:43:23 UTC, dewitt wrote:
vibes website doesn't use a proxy.
Yes, but more people visit dlang.org, and it makes it more
official if it is showcased here as a visible part of the website
(one way or another).
But if D wants to compete in web then there are
On Wednesday, 8 June 2016 at 17:17:37 UTC, Adam D. Ruppe wrote:
bother with a proper setup. There's a reason ALL the other
major languages and frameworks use Apache/nginx/IIS on their
websites. It's the recommended way to do it.
Sure, you can have vibe.d behind nginx, if you want to, but it
On Wednesday, 8 June 2016 at 17:50:11 UTC, Seb wrote:
I agree that a showcase website for vibed (or another D web
framework) would be beneficial, but a real showcase has totally
different specs:
- > 1 million visitors per day
- highly dynamic content (high-throughput databases)
- solved
On Wednesday, 8 June 2016 at 14:33:50 UTC, Jonathan Marler wrote:
On Wednesday, 8 June 2016 at 13:32:00 UTC, Mike Parker wrote:
Why would we change over when Apache is working quite happily
to serve up static content?
I've heard that same argument as the reason people don't use
the D
On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer
wrote:
On 6/23/16 11:16 AM, Tofu Ninja wrote:
On Thursday, 23 June 2016 at 13:57:57 UTC, Steven
Schveighoffer wrote:
Whenever you work with floating point, the loss of precision
must be
expected -- a finite type cannot represent
On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote:
I am glad I was not the only one who thought that sounded a
little crazy... I thought D was supposed to be type safe. I
think I will make a bug report and see where that goes.
It is one of those cases where it made sense in C because
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Well, the latest Intel CPUs have a theoretical throughput of
30GB/s... so that makes for up to 30MB/ms.
But language changes are needed, I think.
I also
On Thursday, 4 February 2016 at 10:59:50 UTC, Mike Parker wrote:
IMO, while giving beginner's a helping hand is a great thing, I
don't think it's a good basis to use as a design for a standard
library.
Yes, better to have a "beginners toolkit" starting-point-codebase
and build a tutorial
On Thursday, 4 February 2016 at 10:03:13 UTC, Jonathan M Davis
wrote:
On Wednesday, February 03, 2016 23:55:42 Ali Çehreli via
Digitalmars-d-learn wrote:
std::uncaught_exception used to be considered useless:
I think that the only case I've ever had for it was for a unit
testing framework
On Thursday, 4 February 2016 at 14:25:21 UTC, bachmeier wrote:
Unfortunately there is no such thing and it is unlikely to
exist in the next decade.
Well, it is probably not the best point in time to have absolute
beginners use D anyway. But a well commented library, that don't
focus on
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
This prevents fast GC: Pointers.
This prevents precise GC: internal Pointers + FFI.
Go now has <10ms latency for small heaps, <20ms latency for up to
100GB heaps and
On Saturday, 6 February 2016 at 06:08:41 UTC, cy wrote:
Sorry, years of python programming have made me shy of
destructors. It just looks a little less "magic" to me if I
specify the destruction explicitly after creating the object,
using the "scope(exit)" syntax.
That is error-prone!
In
On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never trigger
RAII outside of (deprecated) scope allocations.
Not sure what you mean. The class instance doesn't have to
trigger anything?
You "retain(instance)" to increase the
On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote:
Might as well manually free and delete instead.
Not really, this was used in Objective-C before ARC.
But you can always move retain/release/borrow/unborrow into your
own pointer struct like shared_ptr.
On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim
Grøstad wrote:
Nothing prevents you from creating your own reference counting
mechanism.
A struct wrapper doesn't give the things you need to reliably
handle
On Sunday, 7 February 2016 at 02:46:39 UTC, Marco Leise wrote:
My code would not see much ref counting in performance critical
loops. There is no point in ref counting every single point in
a complex 3D scene.
I could imagine it used on bigger items. Textures for example
since they may be used
On Saturday, 6 February 2016 at 22:51:45 UTC, cy wrote:
auto e = somethingThatFails()
scope(failure) cleanup(e);
makes more sense to me, since it's blatantly obvious that the
construction (and entering) process isn't covered by the
cleanup routine.
Not sure what you mean by that.
On Saturday, 6 February 2016 at 11:33:05 UTC, rsw0x wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim
Grøstad wrote:
reference counting is incredibly slow, DIP74 attempts to
partially amend that in D as it can't be done any other way
besides compiler help.
IIRC, it essentially
On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote:
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim
Grøstad wrote:
What makes it impossible to have ref counted classes?
Nothing.
Then why do we need DIP74 ?
I think they aim for compiler optimizations, like ARC on Swift.
But
On Tuesday, 9 February 2016 at 08:35:21 UTC, tsbockman wrote:
When faced with a judgment call like this, we really ought to
err on the side of maintaining backwards compatibility -
especially since this does not preclude adding a separate
by-value version of `Tuple.slice`, as well. It was
On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
So what? Using that argument, you could just as well forbid
taking the address of any variable. What's so special about
tuples, in contrast to structs and arrays?
Some key common qualities for a tuple:
1. They are primarily used
On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go /
something else:
- Interfacing with native API without jumping through hoops
Well, but the hoops are there to get safe and fast GC.
- Incredibly high abstraction and
On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
No need to restrict the language here, there's nothing stopping
a decent compiler from storing tuples (actually _anything_) in
registers, in some cases even if references are taken. I'm
pretty sure LLVM can handle this.
If you
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to multiple pointer types
in D, it wouldn't happen.
You asked about things that prevent improvement, right? Here's
the big one, and a major
On Friday, 5 February 2016 at 07:31:24 UTC, cy wrote:
I think you might be talking about two very different concepts
here. Unwinding only happens within the context of a certain
scope.
The object itself is the scope (RAII). If you can test for
"uncaught_exceptions" you can implement the
On Friday, 12 February 2016 at 12:31:57 UTC, Guillaume Piolat
wrote:
Sorry if these questions are a bit basic, the implied subtext
is "and does it work well?".
Just in case you didn't know, browsers now support HTTP/2 (and
SPDY)...
https://en.wikipedia.org/wiki/HTTP/2
On Friday, 5 February 2016 at 12:35:14 UTC, Artur Skawina wrote:
call used to print diagnostics. What I saw made me never use or
look at D's std lib again. Except for meta programing and
toy/example programs where it doesn't matter.
What do you use instead? A buffer and Posix write() and
On Friday, 5 February 2016 at 07:04:27 UTC, cy wrote:
tl;dr speed demons use std.stream.InputStream.read() whenever
you can, and std.stream.OutputStream.write() its result.
Isn't std.stream deprecated?
Is there some reliable way to detect that a destructor is called
because of exception unwinding?
I basically want to change behaviour within a destructor based on
whether the destructor is called as a result of a regular or an
exceptional situation.
E.g. commit changes to a database on
On Wednesday, 3 February 2016 at 11:41:28 UTC, Jonathan M Davis
wrote:
AFAIK, there is no way to detect whether an exception is in
flight or not aside from the cases where scope(failure) or
catch would catch the exception, and from what I recall of the
last time that someone asked this
On Wednesday, 3 February 2016 at 21:35:38 UTC, Jonathan M Davis
wrote:
https://issues.dlang.org
At least that way, it's kept track of, though I certainly have
no idea when it might be implemented (presumably when someone
needs it enough that they take the time to do so).
Thanks, I think I
On Thursday, 4 February 2016 at 07:55:42 UTC, Ali Çehreli wrote:
std::uncaught_exception used to be considered useless:
http://www.gotw.ca/gotw/047.htm
Does that apply to D?
I've read that one, but Herb Sutter does not provide an argument,
just a claim that having different semantics on
On Wednesday, 3 February 2016 at 12:44:39 UTC, Jacob Carlborg
wrote:
* Worst case scenario, override "_d_throwc" [2]
For the trace handler and overriding "_d_throwc" you would just
use the default implementation plus store a boolean (or
counter) in a TLS variable indicating an exception has
On Wednesday, 24 February 2016 at 10:33:56 UTC, Tanel Tagaväli
wrote:
Hello!
I've been making some progress on the native D audio front:
https://github.com/clinei/daud/tree/28ac042a16ae6785605a9a501b5f867c8f962055
It's a continuous waveform generator, currently outputting a
saw wave that
On Wednesday, 24 February 2016 at 17:52:39 UTC, Guillaume Piolat
wrote:
Though it isn't fantastic aliasing-wise on the last octave, I
should try something than power-of-2s next time I need it.
Why would it help to not use 2^n sized tables? I guess you could
compute everything at 88khz and
On Thursday, 25 February 2016 at 15:15:20 UTC, Luis wrote:
- Wavetables
- band-limited resampling algorithm aka BLIP or BLEP algorithms
(See http://www.cs.cmu.edu/~eli/L/icmc01/hardsync.html and
http://slack.net/~ant/libs/audio.html#Blip_Buffer )
I suggest just porting STK from C++ to D. It
On Friday, 26 February 2016 at 13:21:12 UTC, Guillaume Piolat
wrote:
We are not talking of the same thing. I was thinking about the
table frequency cutoff which is 2x lower every level of mipmap
Ok. I think is most common to use high levels of oversampling for
tables so one can get better SNR
On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote:
My knowledge database engine I'm building cannot afford the
memory overhead of D's builtin associative arrays.
Sounds like a cool project! You could also look into using a trie.
On Friday, 18 March 2016 at 23:35:42 UTC, tsbockman wrote:
`ulong.max` and `-1L` are fundamentally different semantically,
even with two's complement modular arithmetic.
Different types implies different semantics, but not the literals
in isolation.
Under modular arithmetics for an ubyte
On Saturday, 19 March 2016 at 10:01:41 UTC, Basile B. wrote:
On Saturday, 19 March 2016 at 09:33:25 UTC, tsbockman wrote:
[...] The reason that *attempting* such a comparison produces
such weird results, is because the signed value is being
implicitly cast to an unsigned type.
Yes and that's
On Saturday, 19 March 2016 at 09:35:00 UTC, tsbockman wrote:
Both of the literals I used in my example explicitly indicate
the type, not just the value.
Yes, but few people specify unsigned literals and relies on them
being implicitly cast to unsigned. You don't want to type 0UL and
1UL all
On Monday, 7 March 2016 at 10:52:53 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 6 March 2016 at 17:53:47 UTC, Namespace wrote:
What would be the C++ way? Is there any comfortable way to
solve this problem in a nice way like D?
C++ has a non-idiomatic language culture. There are many ways
to
On Sunday, 6 March 2016 at 17:53:47 UTC, Namespace wrote:
What would be the C++ way? Is there any comfortable way to
solve this problem in a nice way like D?
C++ has a non-idiomatic language culture. There are many ways to
do it. One clean way could be to use a templated method, another
way
On Tuesday, 8 March 2016 at 08:12:04 UTC, Nordlöw wrote:
sparse_hash_set<> contained in
https://github.com/sparsehash/sparsehash
It appears to be very slow?
What do you need it for?
On Monday, 7 March 2016 at 16:30:48 UTC, Namespace wrote:
Thanks to the wildcard modifier inout. Is there any possible
way to do the same in C++?
In this specific case you could do it with a macro if you don't
mind dirty macros, but you really should implement the const
version explicitly or
On Monday, 7 March 2016 at 18:44:01 UTC, Namespace wrote:
Honestly speaking, I think this case is impossible to solve in
C++. I'll show my fellow students the advantages of D over C++
in next couple of weeks, and this example is pretty good. :)
:-) Good luck!
On Monday, 11 July 2016 at 21:28:58 UTC, Jonathan M Davis wrote:
If all you're doing is passing around int* and the like, then
the situation is the same as in C and is fine. But stuff like
int[] becomes problematic, because it assumes that you're using
the GC. But that's stuff that doesn't
On Tuesday, 5 July 2016 at 22:03:43 UTC, ketmar wrote:
On Tuesday, 5 July 2016 at 21:58:39 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 July 2016 at 21:46:19 UTC, ketmar wrote:
C++ templates vs D templates. this alone is enough.
They are almost the same...
yep. just like C is *almost* the
On Tuesday, 5 July 2016 at 21:46:19 UTC, ketmar wrote:
C++ templates vs D templates. this alone is enough.
They are almost the same...
On Saturday, 11 June 2016 at 04:11:59 UTC, Joerg Joergonson wrote:
Are you using any of their source code from the vst sdk? If you
hand re-write any of their source code, it is yours.
That could actually be considered to be a translation and a
derived work. If you implement from a
On Tuesday, 5 July 2016 at 16:20:52 UTC, ketmar wrote:
so, my PoV is: yes, D has it's warts, but they are much more
tolerable than C++ warts, for example. and D has alot to offer
which C++ simply won't be able to offer, ever.
D has «static if», but what else are you thinking of? The only
On Saturday, 2 July 2016 at 12:10:28 UTC, qznc wrote:
With AA cache eviction is inefficient. It requires to sort the
keys of the AA with respect to a field in the value. Stack
No, you just need the hash of the key in the object for many
types of hash-tables. There are many solutions, but here
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:
I'm wondering what
are the implications of the fact that current GC is a
Boehm-style conservative
GC rather than a precise one, I've never worked with a
conservative GC before.
The GC isn't competitive with the ones you find in GC
On Wednesday, 1 February 2017 at 09:50:42 UTC, osa1 wrote:
Thanks for the answer. Could you elaborate on the lacklustre
part? It's fine if I have to do manual memory management, but I
don't want any leaks. Ideally I'd have a precise GC + RAII
style resource management when needed.
Rust, Go,
On Saturday, 4 February 2017 at 15:23:53 UTC, Adam D. Ruppe wrote:
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote:
- Automatic but conservative. Can leak at any time.
All GCs are prone to leak, including precise ones. The point of
garbage collection is not to prevent leaks, but
On Saturday, 21 January 2017 at 19:30:31 UTC, Jack Stouffer wrote:
On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote:
Hi friends,
Is there a way to "compile" d code to C, similar to what nim
does?
That would be cool for greater portability.
No, and this is actually a terrible
On Monday, 23 January 2017 at 15:24:09 UTC, aberba wrote:
Unless you will be limited by tge limitations of C. Vala
programming language has that issue even though they utilize
GObject
What limitations? C/C++ programs go around "limitations" by using
compiler extensions and runtime libraries.
On Monday, 23 January 2017 at 14:53:54 UTC, Bauss wrote:
I'd guess the code generation you'd get from doing so with D
would be absolute horrific to read, because you'll get rid of
CTFE, templates, proper class structure, globals properly
stored, since everything in D is TLS and C doesn't then
1 - 100 of 259 matches
Mail list logo
