On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer
wrote:
IIRC, Tango did not depend on libc at all. It only used system
calls. So it certainly is possible.
How did they invoke those system calls? They are usually access
via libc on POSIX systems, so you don't have to implement
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer
wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer
wrote:
But I would use a close method, and not destroy(obj). The
reason is because often times, you have wrapper
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
In the following code, the `_foo` pointer (of the Foo struct)
is null in the first call to the destructor. Why is this? I
think it's got something to do with the foreach loop but I'm
not sure. Any ideas?
struct Bar
{
On Thursday, 25 May 2017 at 08:34:54 UTC, JN wrote:
One of my favourite language features of Dart (other one being
factory constructors) are auto-assign constructors, for example
(writing it in pseudo-D):
class Person
{
string name;
int age;
this(this.age, this.name);
}
would translate
On Thursday, 25 May 2017 at 10:42:00 UTC, ag0aep6g wrote:
On 05/25/2017 10:34 AM, JN wrote:
class Person
{
string name;
int age;
mixin(AutoConstructor!(age, name));
}
[...]
I am not looking for code, I can try that myself, just asking
if such things are possible?
I know you're not
On Thursday, 25 May 2017 at 13:53:01 UTC, ag0aep6g wrote:
On 05/25/2017 03:13 PM, Moritz Maxeiner wrote:
After thinking about this a bit I think I know why it doesn't
work without static and it's not a compiler bug. Since
---
string AutoConstructor(fields ...)() {}
---
is just syntax sugar
On Thursday, 25 May 2017 at 12:35:57 UTC, Moritz Maxeiner wrote:
On Thursday, 25 May 2017 at 11:31:43 UTC, ag0aep6g wrote:
On 05/25/2017 12:52 PM, Moritz Maxeiner wrote:
Be aware, though, that constructors mixed in via a mixin
template behave differently with regards to overloading[1].
[1]
On Thursday, 25 May 2017 at 11:31:43 UTC, ag0aep6g wrote:
On 05/25/2017 12:52 PM, Moritz Maxeiner wrote:
Be aware, though, that constructors mixed in via a mixin
template behave differently with regards to overloading[1].
[1] https://issues.dlang.org/show_bug.cgi?id=11500
Of course it
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote:
C++ allows one to create types that are pointer types but wrap
a primitive pointer to give RAII handling of resources. For
example:
class Dvb::FrontendParameters_Ptr {
private:
dvb_v5_fe_parms * ptr;
public:
On Saturday, 3 June 2017 at 17:40:32 UTC, Russel Winder wrote:
Would one be considered more idiomatic D, or is it a
question of different circumstances different approaches. The
differences are mainly in construction I believe.
Well, the differences I spot are:
- null check in destructor:
On Saturday, 3 June 2017 at 19:21:58 UTC, ag0aep6g wrote:
On 06/03/2017 09:06 PM, Moritz Maxeiner wrote:
- null check in destructor: That's just because I forgot to
add it. If you add `@disable(this)` (disable the default
constructor), all elaborate constructors ensure it is not
null, and no
On Saturday, 3 June 2017 at 20:25:22 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner wrote:
Calling std.algorithm.move is explicit programmer intent, I
consider that about as accidental as calling memcpy with a
source full of zeroes.
In any case, having
On Saturday, 3 June 2017 at 21:16:08 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner wrote:
Quite, but if you backtrack to my initial statement, it was
about ptr not being/becoming null (implicitly) in the first
place, which *might* allow you to skip
On Saturday, 3 June 2017 at 19:55:30 UTC, ag0aep6g wrote:
On 06/03/2017 09:37 PM, Moritz Maxeiner wrote:
Of course, but AFAIK you'd need to explicitly assign it to an
object, so `ptr` won't null by accident, but only by explicit
programmer intent (same as overwriting the memory the object
On Saturday, 3 June 2017 at 21:46:45 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 21:39:54 UTC, Moritz Maxeiner wrote:
It's always true, because I explicitly wrote *might*, not
*will*, to indicate that it depends on your use case. Your
example is a common use case where you can't
On Sunday, 18 June 2017 at 11:11:59 UTC, Johan Engelen wrote:
On Sunday, 18 June 2017 at 09:56:50 UTC, Steven Schveighoffer
wrote:
On Sunday, 18 June 2017 at 09:28:57 UTC, Johan Engelen wrote:
Reviving this thread to see whether anything has changed on
the topic.
If Timon gets static for
On Thursday, 25 May 2017 at 19:09:06 UTC, ag0aep6g wrote:
[...]
Also, simply instantiating a function template inside a class
doesn't result in a method. If it did, the function/method
should be able to access class members. But it can't:
int ft()() { return age; } /* Error: undefined
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
Now the issue is that I now need to call this function more
than once every second. I worry that it will create large
amounts of uncollected "garbage" which will eventually lead to
problems.
Since nobody has mentioned Allocator,
On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat
wrote:
On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
- Replace calls by the GC to `~this` with calls to `finalize`
(or invent some cool other shortened name for the latter)
My point is that in such a "finalize()"
On Wednesday, 13 September 2017 at 15:12:57 UTC, Vino.B wrote:
On Wednesday, 13 September 2017 at 11:03:38 UTC, Moritz
Maxeiner wrote:
On Wednesday, 13 September 2017 at 07:39:46 UTC, Vino.B wrote:
Hi Max,
[...]
Program Code:
[...]
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
On Monday, 11 September 2017 at 22:38:21 UTC, Walter Bright wrote:
If an address is taken to a TLS object, any relocations and
adjustments are made at the time the pointer is generated, not
when the pointer is dereferenced.
Could you elaborate on that explanation more? The way I thought
On Tuesday, 12 September 2017 at 01:13:29 UTC, Hasen Judy wrote:
Is this is a common beginner issue? I remember using an earlier
version of D some long time ago and I don't remember seeing
this concept.
D's ranges can take getting used to, so if you haven't already,
these two articles are
On Monday, 18 September 2017 at 02:04:49 UTC, bitwise wrote:
The following code will run fine on Windows, but crash on iOS
due to the misaligned access:
Interesting, does iOS crash such a process intentionally, or is
it a side effect?
char data[8];
int i = 0x;
int* p =
On Monday, 18 September 2017 at 15:11:34 UTC, Moritz Maxeiner
wrote:
gets rewritten to
---
t.opIndex("b").opIndexAssign(t["a"].value, "c");
---
Sorry, forgot one level of rewriting:
---
t.opIndex("b").opIndexAssign(t.opIndex("a").value, "c");
---
On Sunday, 17 September 2017 at 18:52:39 UTC, SrMordred wrote:
struct Test{ [...] }
Test t;
As described in the spec [1]
t["a"] = 100;
gets rewritten to
---
t.opIndexAssign(100, "a");
---
, while
t["b"]["c"] = t["a"].value;
gets rewritten to
---
On Sunday, 17 September 2017 at 05:33:12 UTC, rikki cattermole
wrote:
Skip Revo-Uninstaller, no idea why you'd ever use such trial
software.
Anyway what you want is CCleaner, standard software that all
Windows installs should have on hand.
On Monday, 18 September 2017 at 20:55:21 UTC, Sasszem wrote:
If I write "auto a = new De()", then it calls the scope first,
no matter where I place it.
Because with `new`
a) your struct object is located on the heap (and referred to by
pointer - `De*`) instead of the stack (which means no
On Tuesday, 10 October 2017 at 19:55:36 UTC, Chirs Forest wrote:
I keep having to make casts like the following and it's really
rubbing me the wrong way:
void foo(T)(T bar){...}
byte bar = 9;
[...]
Why?
Because of integer promotion [1], which is inherited from C.
[1]
On Wednesday, 6 September 2017 at 02:43:20 UTC, Psychological
Cleanup wrote:
I'm having to create a lot of boiler plate code that creates
"events" and corresponding properties(getter and setter).
I'm curious if I can simplify this without a string mixin.
If I create my own attribute like
On Tuesday, 29 August 2017 at 09:59:30 UTC, Jacob Carlborg wrote:
[...]
But if I keep the range internal, can't I just do the
allocation inside the range and only use "formattedWrite"?
Instead of using both formattedWrite and sformat and go through
the data twice. Then of course the final
On Monday, 11 September 2017 at 10:18:41 UTC, Oleg B wrote:
Hello. I try using destructor in betterC code and it's work if
outer function doesn't return value (void). Code in `scope
(exit)` works as same (if func is void all is ok).
In documentation I found
On Wednesday, 13 September 2017 at 07:39:46 UTC, Vino.B wrote:
On Tuesday, 12 September 2017 at 21:01:26 UTC, Moritz Maxeiner
wrote:
On Tuesday, 12 September 2017 at 19:44:19 UTC, vino wrote:
Hi All,
I have a small piece of code which executes perfectly 8 out
of 10 times, very rarely it
On Tuesday, 12 September 2017 at 09:11:20 UTC, Joseph wrote:
I have two nearly duplicate files I added a static this() to
initialize some static members of an interface.
On one file when I add an empty static this() it crashes while
the other one does not.
The exception that happens is
On Tuesday, 12 September 2017 at 19:44:19 UTC, vino wrote:
Hi All,
I have a small piece of code which executes perfectly 8 out of
10 times, very rarely it throws an assertion error, so is there
a way to find which line of code is causing this error.
You should be getting the line number as
On Tuesday, 12 September 2017 at 19:59:52 UTC, Joseph wrote:
On Tuesday, 12 September 2017 at 10:08:11 UTC, Moritz Maxeiner
wrote:
On Tuesday, 12 September 2017 at 09:11:20 UTC, Joseph wrote:
I have two nearly duplicate files I added a static this() to
initialize some static members of an
On Sunday, 27 August 2017 at 10:46:53 UTC, Andrew Chapman wrote:
[...]
Oh interesting. Does DUB support passing through the
--enable-contracts flag to ldc? Also, if this is an ldc
specific thing it's probably not a good idea i'd imagine, since
in the future one may want to use a GDC, or
On Sunday, 27 August 2017 at 10:46:53 UTC, Andrew Chapman wrote:
On Sunday, 27 August 2017 at 10:37:50 UTC, Moritz Maxeiner
wrote:
[...]
Oh interesting. Does DUB support passing through the
--enable-contracts flag to ldc?
Sure, using platform specific build settings [1] such as
On Sunday, 27 August 2017 at 10:17:47 UTC, Andrew Chapman wrote:
On Sunday, 27 August 2017 at 10:08:15 UTC, ag0aep6g wrote:
On 08/27/2017 12:02 PM, Andrew Chapman wrote:
However, I am finding that BOTH enforce and assert are
compiled out by dmd and ldc in release mode. Is there a
standard
On Sunday, 27 August 2017 at 19:47:59 UTC, Alex wrote:
Hi, all.
Can anybody explain to me why
void main()
{
import std.numeric;
assert(gcd(0.5,32) == 0.5);
assert(gcd(0.2,32) == 0.2);
}
fails on the second assert?
I'm aware, that calculating gcd on doubles is not so
On Sunday, 27 August 2017 at 19:47:59 UTC, Alex wrote:
[..]
Is there a workaround, maybe?
To expand on the earlier workaround: You can also adapt a
floating point to string algorithm in order to dynamically
determine an upper bound on the number of after decimal point
digits required. Below
On Monday, 28 August 2017 at 21:52:58 UTC, Andre Pany wrote:
[...]
To make my question short:) If ColumnsArray is a class I can
access the attribute "reference" but not if it is a struct. I
would rather prefer a struct, but with a struct
it seems I cannot access "reference".
How can I
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be
On Monday, 28 August 2017 at 22:47:12 UTC, Andre Pany wrote:
On Monday, 28 August 2017 at 22:28:18 UTC, Moritz Maxeiner
wrote:
On Monday, 28 August 2017 at 21:52:58 UTC, Andre Pany wrote:
[...]
To make my question short:) If ColumnsArray is a class I can
access the attribute "reference" but
On Monday, 28 August 2017 at 14:27:19 UTC, Jacob Carlborg wrote:
I'm working on some code that sanitizes and converts values of
different types to strings. I thought it would be a good idea
to wrap the sanitized string in a struct to have some type
safety. Ideally it should not be possible to
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses LLP64, which uses 32bit longs. Am I correct in
assuming you're on
On Tuesday, 29 August 2017 at 02:47:34 UTC, Johnson Jones wrote:
[...]
Seems only long and ulong are issues.
With respect to the currently major platforms you can reasonable
expect software to run on, yes.
Just don't try to use D on something with e.g. 32 bit C shorts
unless you bind to it
On Friday, 25 August 2017 at 16:45:16 UTC, Vino.B wrote:
Hi,
Request your help on the below issue,
Issue : While appending data to a array the data is getting
duplicated.
Program:
import std.file: dirEntries, isFile, SpanMode;
import std.stdio: writeln, writefln;
import std.algorithm:
On Tuesday, 29 August 2017 at 07:59:40 UTC, Andre Pany wrote:
On Monday, 28 August 2017 at 23:12:40 UTC, Moritz Maxeiner
wrote:
In both cases S doesn't inherently how about C, which means a
solution using default initialization is not feasible, as
S.init can't know about any particular
On Thursday, 31 August 2017 at 07:06:26 UTC, Jacob Carlborg wrote:
On 2017-08-29 19:35, Moritz Maxeiner wrote:
void put(T t)
{
if (!store)
{
// Allocate only once for "small" vectors
store = alloc.makeArray!T(8);
if (!store)
On Friday, 1 September 2017 at 09:33:08 UTC, Alex wrote:
On Sunday, 27 August 2017 at 23:13:24 UTC, Moritz Maxeiner
wrote:
On Sunday, 27 August 2017 at 19:47:59 UTC, Alex wrote:
[...]
To expand on the earlier workaround: You can also adapt a
floating point to string algorithm in order to
On Saturday, 2 September 2017 at 23:02:18 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 21:56:15 UTC, Jean-Louis Leroy
wrote:
[...]
Hmmm I see...I was thinking of spinning the runtime part of my
openmethods library into its own module (like here
On Saturday, 2 September 2017 at 21:56:15 UTC, Jean-Louis Leroy
wrote:
[...]
Hmmm I see...I was thinking of spinning the runtime part of my
openmethods library into its own module (like here
https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being
On Saturday, 2 September 2017 at 16:23:57 UTC, bitwise wrote:
On Saturday, 2 September 2017 at 15:53:25 UTC, bitwise wrote:
[...]
This seems to work well enough.
string toAsciiHex(string str)
{
import std.array : appender;
auto ret = appender!string(null);
ret.reserve(str.length
On Saturday, 2 September 2017 at 17:43:08 UTC, Vino.B wrote:
Hi All,
Request your help on how to solve the issue in the below
code as when i execute the program with -vgc it state as below:
NewTD.d(21): vgc: using closure causes GC allocation
NewTD.d(25): vgc: array literal may cause GC
On Saturday, 2 September 2017 at 18:07:51 UTC, bitwise wrote:
On Saturday, 2 September 2017 at 17:45:30 UTC, Moritz Maxeiner
wrote:
If this (unnecessary waste) is of concern to you (and from the
fact that you used ret.reserve I assume it is), then the easy
fix is to use `sformat` instead of
On Saturday, 2 September 2017 at 18:08:19 UTC, vino.b wrote:
On Saturday, 2 September 2017 at 18:02:06 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 17:43:08 UTC, Vino.B wrote:
[...]
Line 25 happens because of `[a.name]`. You request a new
array: the memory for this has to be
On Saturday, 2 September 2017 at 18:59:30 UTC, Vino.B wrote:
On Saturday, 2 September 2017 at 18:32:55 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 18:08:19 UTC, vino.b wrote:
On Saturday, 2 September 2017 at 18:02:06 UTC, Moritz
Maxeiner wrote:
On Saturday, 2 September 2017
On Saturday, 2 September 2017 at 20:02:37 UTC, bitwise wrote:
On Saturday, 2 September 2017 at 18:28:02 UTC, Moritz Maxeiner
wrote:
In UTF8:
--- utfmangle.d ---
void fun_ༀ() {}
pragma(msg, fun_ༀ.mangleof);
---
---
$ dmd -c utfmangle.d
_D6mangle7fun_ༀFZv
---
Only universal
On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy
wrote:
So I have:
jll@ORAC:~/dev/d/tests/modules$ tree
.
├── foo
│ └── bar.d
└── foo.d
foo.d contains:
import foo.bar;
bar.d is empty.
This means bar.d's module name will be inferred by the compiler
[1], which will ignore
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so
many other issues where Generics
On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy
wrote:
On Saturday, 2 September 2017 at 20:48:22 UTC, Moritz Maxeiner
wrote:
So the compiler wants you to import it by the name it has
inferred for you (The fix being either specifying the module
name in foo/bar.d as `module
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
[...]
The contexts being independent of each other doesn't change
that we would still
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2
On Monday, 4 September 2017 at 03:08:50 UTC, EntangledQuanta
wrote:
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September
On Wednesday, 1 November 2017 at 06:44:44 UTC, Tobias Pankrath
wrote:
On Tuesday, 31 October 2017 at 11:21:30 UTC, Moritz Maxeiner
wrote:
On Tuesday, 31 October 2017 at 11:04:57 UTC, Tobias Pankrath
wrote:
[...]
??:? pure @safe void
std.exception.bailOut!(Exception).bailOut(immutable(char)[],
On Thursday, 2 November 2017 at 19:05:46 UTC, Tobias Pankrath
wrote:
Including Phobos? Your posted backtrace looks to me like
templates instantiated within Phobos, so I think you'd need
Phobos with debug symbols for those lines.
---
int main(string[] argv)
{
return argv[1].length > 0;
}
---
On Tuesday, 31 October 2017 at 11:04:57 UTC, Tobias Pankrath
wrote:
[...]
??:? pure @safe void
std.exception.bailOut!(Exception).bailOut(immutable(char)[],
ulong, const(char[])) [0xab5c9566]
??:? pure @safe bool std.exception.enforce!(Exception,
bool).enforce(bool, lazy const(char)[],
101 - 168 of 168 matches
Mail list logo
