On Saturday, 13 February 2016 at 22:42:34 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 13 February 2016 at 21:41:06 UTC, Lars T.
Kyllingstad wrote:
Whose expectations? The formal expectation, as per the C++
standard, is that the moved-from object be left in a "valid
but unspecified state".
On Saturday, 13 February 2016 at 12:14:43 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 13 February 2016 at 09:11:06 UTC, Lars T.
Kyllingstad wrote:
In my experience, in the vast majority of cases a C++ move
operation boils down to a memberwise copy (of value types) or
copy-and-reset (of
On Wednesday, 3 February 2016 at 15:56:48 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 3 February 2016 at 15:44:25 UTC, Sönke Ludwig
wrote:
seems like pretty clear semantics. And in C++ you'd have the
same situation once somefunction decides to move/swap the
value somewhere else before
On Thursday, 11 February 2016 at 00:32:11 UTC, Matt Elkins wrote:
Maybe this is what you are referring to, but the primary use I
get out of move semantics (in general, not language-specific)
has little to do with performance-on-copy. It is for handling
resources which logically aren't
On Saturday, 13 February 2016 at 19:25:37 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 13 February 2016 at 17:47:54 UTC, Lars T.
Kyllingstad wrote:
[...]
C++ does indeed put the burden on the library programmer and is
not a good language for "non-professional" use. But it is
flexible by
On Tuesday, 18 August 2015 at 19:35:02 UTC, Walter Bright wrote:
Here's the pattern that works a lot better:
1. spend hundreds if not thousands of hours developing
something really cool
Check!
2. spend 10 minutes writing the announcement to D.announce. Be
sure to include:
who, what,
On Tuesday, 18 August 2015 at 19:35:56 UTC, Walter Bright wrote:
On 8/16/2015 2:22 AM, Lars T. Kyllingstad wrote:
I am happy to announce the (somewhat overdue) release of ∅MQD
v1.0!
https://www.reddit.com/r/programming/comments/3hgg00/mqd_d_library_for_zeromq_v10_released/
Lars, please post
On Tuesday, 18 August 2015 at 20:44:25 UTC, Suliman wrote:
Lars, did you thought about full port? I read post of etcimon
about his Botan lib. He eventual decided to rewrite original
lib from C++ to D to make code more easier maintainable.
I considered it, yes, but it is a *lot* more work, and
I am happy to announce the (somewhat overdue) release of ∅MQD
v1.0!
∅MQD is a D library that wraps the low-level C API of the ∅MQ
(aka. ZeroMQ) messaging framework. It is a rather thin wrapper
that maps closely to the C API, while providing modern D features
that make the framework safer,
On Sunday, 16 August 2015 at 12:53:39 UTC, Nick Sabalausky wrote:
Cool. I haven't actually used ZeroMQ yet, but it's something
I've had my eye on.
If you want to look into it, I heartily recommend the ZeroMQ
Guide:
http://zguide.zeromq.org/
In addition to being a comprehensive and
As of today, the main SciD repository will be hosted under the
DlangScience organisation on GitHub:
https://github.com/DlangScience/scid
SciD is a collection of freely usable numerical routines for,
among other things,
- numerical integration (quadrature) and differentiation
-
∅MQD is a D library that wraps the low-level C API of the ∅MQ
(aka. ZeroMQ) messaging framework. It is a rather thin wrapper
that maps closely to the C API, while making it safer, easier and
more pleasant to use. The API is designed to feel familiar to
existing ∅MQ users, yet natural to D
On Thursday, 11 December 2014 at 15:04:53 UTC, Jacob Carlborg
wrote:
On 2014-12-11 08:21, Lars T. Kyllingstad wrote:
I'm not sure what is the best way to achieve this in D, but
one option is to use
an (associative?) array of Variants.
How does Boost implement this?
Classes that contain
On Tuesday, 9 December 2014 at 17:06:45 UTC, Dmitry Olshansky
wrote:
Then we could use interfaces as tags for exceptions and catch
using one of many interfaces an exception has.
I think that is an excellent idea! I have looked a bit at
boost::exception, and wanted for a while to incorporate
On Tuesday, 9 December 2014 at 18:00:05 UTC, Sean Kelly wrote:
All the stack tracing stuff is wired through Throwable, so some
duplication may need to occur if it were changed to an
interface.
I can think of two ways to solve this:
1. rename the current Throwable (to e.g. ThrowableBase) and
On Tuesday, 12 August 2014 at 07:53:44 UTC, Timothee Cour via
Digitalmars-d wrote:
The deprecation message in 2.066(rc): 'Deprecation: function
std.process.system is deprecated - Please use executeShell
instead' is
often not what user wants.
Wait, what? The pull request that deprecated
On Wednesday, 13 August 2014 at 01:58:15 UTC, Timothee Cour via
Digitalmars-d wrote:
On Tue, Aug 12, 2014 at 3:41 PM, Vladimir Panteleev via
Digitalmars-d
digitalmars-d@puremagic.com wrote:
And why `cast(Redirect)0`? It's not necessary.
it is, otherwise it defaults to Redirect.all which
On Wednesday, 13 August 2014 at 06:29:11 UTC, Timothee Cour via
Digitalmars-d wrote:
On Tue, Aug 12, 2014 at 11:09 PM, Lars T. Kyllingstad via
Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 12 August 2014 at 07:53:44 UTC, Timothee Cour via
Digitalmars-d wrote:
The deprecation
On Wednesday, 13 August 2014 at 01:14:24 UTC, Timothee Cour via
Digitalmars-d wrote:
There used to be a table; not anymore; the table seems
flattened as text as
follows:
The following table compactly summarises the different process
creation
functions and how they relate to each other: Runs
On Saturday, 12 July 2014 at 15:03:13 UTC, Peter Alexander wrote:
http://pointersgonewild.wordpress.com/2014/07/11/the-constness-problem/
I can relate to this. I don't use classes much in D, but I find
it frustrating that you need to reach to
std.typecons.Rebindable for what I would consider
On Friday, 30 May 2014 at 11:48:57 UTC, Chris wrote:
There's _always_ something you can learn, even if you think you
know it all.
Like the fact that you can @disable this() for a struct, even
though you can't implement it. I didn't know that, but I have the
perfect use case for it (and it's
Is it possible to temporarily prevent the garbage collector from
collecting a memory block even if there are no references to it?
The use case is as follows: I want to call a C library function
which expects to take ownership of a buffer. It looks something
like this:
alias FreeFunc =
On Thursday, 24 April 2014 at 20:09:38 UTC, Justin Whear wrote:
You can use GC.addRoot() from core.memory before passing the
pointer to
the C function, then use GC.removeRoot in your myFree function.
Perfect, thanks!
On Monday, 21 April 2014 at 15:15:22 UTC, Aleksandar Ruzicic
wrote:
Yes, there were numerous studies about line length (I don't
have any links to back this with but I'm sure that searching
for web typography line length on google would provide some
useful articles). And optimal line length is
On Sunday, 20 April 2014 at 13:01:53 UTC, Gary Willoughby wrote:
On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad
wrote:
However, in D, all functions defined in the same module as a
class will have access to the private state of that class, on
an equal footing with its member
On Sunday, 20 April 2014 at 20:36:58 UTC, Andrei Alexandrescu
wrote:
On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:
The fact that private really means module private in D
means that
any number of functions can break when a class/struct
implementation
changes.
No, only those in that
On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:
Autofocus breaks site navigation: instead of returning to where
you were previously, you end up focused on search box, which is
really annoying. It also breaks page navigation (similar
mistake: floating top panel on dart site). Whether
On Monday, 21 April 2014 at 12:45:12 UTC, Steven Schveighoffer
wrote:
[...]
Reasons off the top of my head not to make them module
functions:
1. You can import individual symbols from modules. i.e.:
import mymodule: MyType;
If a large portion of your API is module-level functions, this
On Monday, 21 April 2014 at 13:03:50 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 21 April 2014 at 08:33:21 UTC, Lars T. Kyllingstad
wrote:
On Sunday, 20 April 2014 at 13:01:53 UTC, Gary Willoughby
wrote:
Yeah it does. If the function can be used generically across
many different parts of the
On Monday, 21 April 2014 at 14:10:08 UTC, Steven Schveighoffer
wrote:
[...]
module m1;
import std.stdio;
class C {}
void foo(C c)
{
writeln(C.foo);
}
void bar(C c)
{
writeln(C.bar);
}
module m2;
import m1;
import std.stdio;
void foo(T)(T t)
{
writeln(m2.foo);
}
void bar(T)(T t,
On Monday, 21 April 2014 at 14:38:53 UTC, Lars T. Kyllingstad
wrote:
What you've demonstrated feels wrong, somehow.
As in it shouldn't be that way, not as in I think you're wrong
about this. :)
In his article How non-member functions improve encapsulation
[1], Scott Meyers makes a good argument for why free functions
should generally be preferred over class methods in C++. TL;DR:
Fewer member functions means fewer functions that break when the
class implementation changes, and free
On Sunday, 20 April 2014 at 08:25:47 UTC, monarch_dodra wrote:
One thing to keep in mind, is that with the module system, and
templates, is that free functions can only be called if the
module *knows* about your free function.
For example int[] is a range thanks to the free
front/popFront,
On Sunday, 20 April 2014 at 11:01:27 UTC, Gary Willoughby wrote:
This is a quote from Walter that sums the reasoning up
perfectly:
A huge reason for them is to head off the temptation to write
What does them refer to here?
‘kitchen sink’ classes that are filled with every conceivable
On Sunday, 20 April 2014 at 08:38:25 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 19 Apr 2014 13:00, Lars T. Kyllingstad via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer
wrote:
I don't share your opinion that the web site
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer
wrote:
I don't share your opinion that the web site need to be
modern to avoid warding off potential adopters. If they are
turned off of using a system programming language by a bland
(debatable) site look and feel, then I think
Say I have two structs, defined like this:
struct A { /* could contain whatever */ }
struct B { A a; }
My question is, is it now guaranteed that A.sizeof==B.sizeof,
regardless of how A is defined (member variable types, alignment,
etc.)? More to the point, say I have a function
On Saturday, 19 April 2014 at 12:26:16 UTC, Andrej Mitrovic via
Digitalmars-d-learn wrote:
On 4/19/14, Lars T. Kyllingstad via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Say I have two structs, defined like this:
struct A { /* could contain whatever */ }
struct B
38 matches
Mail list logo
