On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote:
http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F
Just some usual C++ critique and very vague basic principles
about having a core language with some extensions and library
support, nothing constructive or informative really.
On Wednesday, 13 May 2015 at 19:24:09 UTC, Jacob Carlborg wrote:
One thing that is _not_ making things better is "enforce"
which, if I recall correctly, throws Exception by default.
Aye. enforce is one of those things that looks cool but I don't
think should actually be used.
It could perhap
On Tue, 12 May 2015 08:54:15 -0400, Namespace wrote:
As far as I know, the problem (or at least one of the biggest problems)
for rvalue references was that they could escape. Since DIP25 is
approved and already implemented this problem should be solved. Would it
be possible to allow rvalue
On Wednesday, 13 May 2015 at 17:49:38 UTC, Steven Schveighoffer
wrote:
OK, then consider that this:
void main()
{
string x;
x ~= "hello";
x ~= " world";
}
would require locking. That's unacceptable. Nobody would append
with strings if this all required locking for no reason. The
runt
On Tue, 12 May 2015 08:54:15 -0400, Namespace wrote:
As far as I know, the problem (or at least one of the biggest problems)
for rvalue references was that they could escape. Since DIP25 is
approved and already implemented this problem should be solved. Would it
be possible to allow rvalue
On Wednesday, 13 May 2015 at 21:45:30 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 13 May 2015 at 18:32:17 UTC, Idan Arye wrote:
On Wednesday, 13 May 2015 at 17:47:27 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 13 May 2015 at 14:54:05 UTC, Benjamin Thaut
wrote:
On Wednesday, 13 May 2015 at
On 5/13/15 3:24 PM, Jacob Carlborg wrote:
On 2015-05-13 17:08, Adam D. Ruppe wrote:
Have you ever done:
if(something) {
import std.conv;
throw new Exception("some error " ~ to!string(some_value));
}
Don't you hate it?
* having to import std.conv to see data from your exception is a pa
On Wednesday, 13 May 2015 at 18:32:17 UTC, Idan Arye wrote:
On Wednesday, 13 May 2015 at 17:47:27 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 13 May 2015 at 14:54:05 UTC, Benjamin Thaut
wrote:
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as
On Wednesday, 13 May 2015 at 20:34:24 UTC, weaselcat wrote:
On Wednesday, 13 May 2015 at 20:28:02 UTC, Laeeth Isharc wrote:
Is there value to having equivalents to the std.parallelism
approach that works with processes rather than threads, and
makes it easy to manage tasks over multiple machine
Tried to, couldn't get it to compile with git HEAD. Could you
please post the dmd and druntime git hashes, or are those forks
as well?
Atila
On Monday, 11 May 2015 at 19:41:36 UTC, Andrei Alexandrescu wrote:
As some might have inferred from my recent posts, there is good
progress on std.alloc
On 05/13/2015 04:54 PM, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as Base. Only one in-contract in
the inheritance chain must pass in order for the call to go through.
But wasn't exactly that the problem about the cur
On Wednesday, 13 May 2015 at 20:09:44 UTC, wobbles wrote:
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
import core.thread : Sleep;
but it fails when I compile on lin
On Wednesday, 13 May 2015 at 20:16:34 UTC, John Chapman wrote:
On Wednesday, 13 May 2015 at 20:09:44 UTC, wobbles wrote:
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
On Wednesday, 13 May 2015 at 20:28:02 UTC, Laeeth Isharc wrote:
Is there value to having equivalents to the std.parallelism
approach that works with processes rather than threads, and
makes it easy to manage tasks over multiple machines?
I'm not sure if you're asking because of this thread, bu
Is there value to having equivalents to the std.parallelism
approach that works with processes rather than threads, and makes
it easy to manage tasks over multiple machines?
I took a look at std.parallelism and it's beyond what I can do
for now. But it seems like this might be a useful projec
On Wednesday, 13 May 2015 at 20:09:44 UTC, wobbles wrote:
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
import core.thread : Sleep;
but it fails when I compile on lin
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
import core.thread : Sleep;
but it fails when I compile on linux, so I need to do a
version(Windows) import core.thread :
On Wednesday, 13 May 2015 at 19:24:09 UTC, Jacob Carlborg wrote:
Yeah, I really hate that people are using plain Exception
instead of creating a subclass. I'm trying to point this out in
pull requests and similar but it's hard to get people to listen.
With how range focused/@nogc a lot of ph
On 2015-05-13 17:08, Adam D. Ruppe wrote:
Have you ever done:
if(something) {
import std.conv;
throw new Exception("some error " ~ to!string(some_value));
}
Don't you hate it?
* having to import std.conv to see data from your exception is a pain
* it allocates eagerly and thus isn't su
Hi,
I think that many will find something interesting in this article:
-
https://translate.google.ru/translate?hl=ru&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F
-
Sorry translated using google translate.
On Wednesday, 13 May 2015 at 17:47:27 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 13 May 2015 at 14:54:05 UTC, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as Base. Only one
in-contract in the inheritance chain must pas
On Wednesday, 13 May 2015 at 14:54:05 UTC, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as Base. Only one
in-contract in the inheritance chain must pass in order for
the call to go through.
But wasn't exactly that the p
On 5/13/15 3:02 AM, Jakob Ovrum wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
Do you mean:
immutable(int)[] x = new int[5];
const(int)[] y = x;
?
Beca
On 5/13/15 1:35 AM, Dicebot wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
x ~= 1; // should this lock;
y ~= 1; // should this lock?
As per my udnerstand
On 5/13/15 8:26 AM, Vladimir Panteleev wrote:
So do we want a front page widget that's hosted on the wiki?
That would be a good idea generally though it opens the site for
vandalism. I'd say we start with a wiki page and work from there. -- Andrei
I didn't give much attention to the details. but I like the spirit very
much.
LMB
On Wed, May 13, 2015 at 12:08 PM, Adam D. Ruppe via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> Have you ever done:
>
> if(something) {
>import std.conv;
>throw new Exception("some error " ~ to!s
On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu
wrote:
It should be easy to update by the community, so a wiki might
be a good start. So I saw three links, any others? -- Andrei
If it's visible on the front page, more links should be submitted
quickly.
So do we want a front pa
On 5/13/15 3:34 AM, Mengu wrote:
On Wednesday, 13 May 2015 at 05:05:54 UTC, Andrei Alexandrescu
wrote:
On 5/12/15 3:57 PM, Max Klyga wrote:
On 2015-05-12 20:02:05 +, Brian Schott said:
On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
"But there are no vacancies..."
There's at le
From
http://blogs.windows.com/msedgedev/2015/05/11/microsoft-edge-building-a-safer-browser/
:
MemGC
As these mitigations have rolled out, attackers have adapted,
inventing new forms of attack. Microsoft in turn has responded
with new memory safety defenses that mitigate the most common
new
Have you ever done:
if(something) {
import std.conv;
throw new Exception("some error " ~ to!string(some_value));
}
Don't you hate it?
* having to import std.conv to see data from your exception is a
pain
* it allocates eagerly and thus isn't suitable for a lot of places
* inspecting the
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote:
This will accept the same arguments as Base. Only one
in-contract in the inheritance chain must pass in order for the
call to go through.
But wasn't exactly that the problem about the current
implementation? Shouldn't all 'in' contr
On Wednesday, 13 May 2015 at 13:50:52 UTC, Logan Capaldo wrote:
I _think_ if you only do this for D-mangled symbols you'll get
99% of the benefits (doing the right things for templates etc.)
without causing problems for the "corner cases".
Yes, that's the plan. I might even do it only for D
On Wednesday, 13 May 2015 at 13:31:15 UTC, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:57:35 UTC, Logan Capaldo wrote:
a.dll provides symbol s1
b.dll provides symbol s1
c.dll imports symbol s1 from a.dll, provides symbol s2
d.dll imports symbol s1 from b.dll, provides symbol s3
e.ex
On 5/13/2015 12:04 AM, Shachar Shemesh wrote:
I saved the git tag in which this happens and will try to isolate.
Thank you. This is very important.
On Wednesday, 13 May 2015 at 12:57:35 UTC, Logan Capaldo wrote:
a.dll provides symbol s1
b.dll provides symbol s1
c.dll imports symbol s1 from a.dll, provides symbol s2
d.dll imports symbol s1 from b.dll, provides symbol s3
e.exe imports symbol s2 from c.dll, imports symbol s3 from
d.dll. e.e
On Wednesday, 13 May 2015 at 10:34:46 UTC, Mengu wrote:
On Wednesday, 13 May 2015 at 05:05:54 UTC, Andrei Alexandrescu
wrote:
On 5/12/15 3:57 PM, Max Klyga wrote:
On 2015-05-12 20:02:05 +, Brian Schott said:
On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
"But there are no vacanc
On Wednesday, 13 May 2015 at 11:41:27 UTC, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote:
Yes it won't happen for explicit LoadLibrary's and
GetProcAddresses, but COM or other plugin systems is an
example of a situation where many DLLs may expose the sam
On 05/13/2015 02:16 PM, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One broken
thing was "in" contract within inheritance. If you add different
"in"-contract in
On 05/13/2015 02:16 PM, Idan Arye wrote:
I think the `in` contracts check should be statically dispatched, so
that only the contracts relevant to the reference-type you are calling
the method from will be checked.
https://issues.dlang.org/show_bug.cgi?id=6857
On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One
broken
thing was "in" contract within inheritance. If you add
different
"in"-contract in overridden parent and derived function only
o
On Wednesday, 13 May 2015 at 10:51:09 UTC, iackhtak wrote:
There was discussion about broken contract programing. One
broken
thing was "in" contract within inheritance. If you add different
"in"-contract in overridden parent and derived function only one
will be checked.
Not "only one" is chec
On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One
broken
thing was "in" contract within inheritance. If you add
different
"in"-contract in overridden parent and derived function only
o
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One broken
thing was "in" contract within inheritance. If you add different
"in"-contract in overridden parent and derived function only one
will be checked.
No, this is incorrect. Only one needs to p
"Timothee Cour via Digitalmars-d" wrote in
message news:mailman.928.1431451389.4581.digitalmar...@puremagic.com...
> g++ -m64: No such file or directory
Try setting it, it fails when I do.
I don't know what's going on. It 'make's no sense.
On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote:
Yes it won't happen for explicit LoadLibrary's and
GetProcAddresses, but COM or other plugin systems is an example
of a situation where many DLLs may expose the same named
symbols with different definitions, and there may be situ
On 2015-05-12 17:21:03 +, Steven Schveighoffer said:
Of course, array appending is an odd duck here, as generally you are
not generally able to add data to an immutable piece of data.
A similar odd duck would be reference counting (again, mutable metadata
attached to immutable data).
-
On Wednesday, 13 May 2015 at 07:49:26 UTC, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 07:41:27 UTC, Logan Capaldo wrote:
If my program only links against DLLs written in D, sure this
is no worse than the static library/version flag situation.
But one of D's features is C and C++ inter
On Tuesday, 12 May 2015 at 18:51:17 UTC, Vladimir Panteleev wrote:
On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
For those keeping track of every mentioning of D in the media
(Hi Andrei!):
The following article about Rust made it to the front page of
HN and /r/programming recently:
No draft so far?
There was discussion about broken contract programing. One broken
thing was "in" contract within inheritance. If you add different
"in"-contract in overridden parent and derived function only one
will be checked.
I thought that solution is to ban "in"-contract for derived
function. "In"-contract s
On Wednesday, 13 May 2015 at 09:52:08 UTC, Shachar Shemesh wrote:
On 13/05/15 12:29, Maxim Fomin wrote:
Giving how D is similar to C/C++ I am surprised that
non-familiriarity
with D is a big problem.
D is a fairly complex language (far too complex, IMHO, relative
to its age). Its complexiti
On Wednesday, 13 May 2015 at 05:05:54 UTC, Andrei Alexandrescu
wrote:
On 5/12/15 3:57 PM, Max Klyga wrote:
On 2015-05-12 20:02:05 +, Brian Schott said:
On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
"But there are no vacancies..."
There's at least one:
https://emsi.bamboohr.com
On 13/05/15 12:29, Maxim Fomin wrote:
Giving how D is similar to C/C++ I am surprised that non-familiriarity
with D is a big problem.
D is a fairly complex language (far too complex, IMHO, relative to its
age). Its complexities are both different than C++, and also of a
different kind.
I w
On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
For those keeping track of every mentioning of D in the media
(Hi Andrei!):
The following article about Rust made it to the front page of
HN and /r/programming recently: http://www.viva64.com/en/b/0324/
Here is the part mentioning D:
"
On Wednesday, 13 May 2015 at 09:20:36 UTC, Bienlein wrote:
"You are making a cool project and we'd like to contribute to
it, but we don't know and neither feel like studying this silly
D".
This is indeed a problem for many newly created languages.
Scala has somewhat managed to create its own
"You are making a cool project and we'd like to contribute to it,
but we don't know and neither feel like studying this silly D".
This is indeed a problem for many newly created languages. Scala
has somewhat managed to create its own eco system with Akka,
Spark, Spray in a specialized area lik
On Monday, 11 May 2015 at 09:31:34 UTC, Chris wrote:
Hm, I was thinking of something like that, however, it gets
more and more complicated if you have e.g. a class that uses
another class etc.
class Data // A singleton
{
// stores paths to resources etc.
}
class Loader
{
this()
this.da
On Wednesday, 13 May 2015 at 07:41:27 UTC, Logan Capaldo wrote:
If my program only links against DLLs written in D, sure this
is no worse than the static library/version flag situation. But
one of D's features is C and C++ interop. For instance if I
link against a DLL that happens to provide
On Wednesday, 13 May 2015 at 06:17:36 UTC, Benjamin Thaut wrote:
On Tuesday, 12 May 2015 at 17:48:50 UTC, Logan Capaldo wrote:
q could be a completely different type in a.dll vs. c.dll.
Please correct me if I am wrong, but my understanding of how
import libs get used you can't detect this at bu
On Wednesday, 13 May 2015 at 03:30:53 UTC, thedeemon wrote:
On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
"Wikipedia tells us that there were a lot of other attempts
besides D to kill C++ - for example Vala, Cyclone, Limbo,
BitC. How many of you have even heard of these languages?"
On Wednesday, 13 May 2015 at 06:23:40 UTC, Brad Anderson wrote:
On Wednesday, 13 May 2015 at 05:35:18 UTC, Dicebot wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y
On 13/05/15 08:48, Walter Bright wrote:
On 5/12/2015 10:13 PM, Shachar Shemesh wrote:
And this is before mentioning stability. I've lost count of the number
of times
my compilation failed with an assert thrown by dmd, and just last week
I've had
to refactor the code around a consistent segmentat
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
Do you mean:
immutable(int)[] x = new int[5];
const(int)[] y = x;
?
Because you can't append to or reassign an i
63 matches
Mail list logo
