On Tuesday, 4 September 2018 at 11:25:15 UTC, Alex wrote:
On Tuesday, 4 September 2018 at 10:30:24 UTC, Timoses wrote:
However, of course this also fails because randomly assigning
the array elements will overwrite it. So the associative array
seems like the better idea. However, not being
On Friday, 31 August 2018 at 06:20:09 UTC, James Blachly wrote:
Hi all,
I am linking to a C library which defines a symbol,
const char seq_nt16_str[] = "=ACMGRSVTWYHKDBN";
In the C sources, this is an array of 16 bytes (17 I guess,
because it is written as a string).
In the C headers, it
On Monday, 6 August 2018 at 18:22:24 UTC, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
}
Instances of struct S are allocated by standard GC new and
S.data_ can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But
On Friday, 6 April 2018 at 13:10:23 UTC, Kayomn wrote:
ID tags are unique and spsecific to the class type. There
shouldn't be more than one type ID assigned to one class type.
The idea behind what it is I am doing is I am implementing a
solution to getting a type index, similar to
On Wednesday, 21 March 2018 at 16:22:45 UTC, Martin Tschierschke
wrote:
Is there an step by step introduction how to convert a C header
of an external lib into the right extern(C){} block?
A blog post or tutorial, or chapter in a D book? (I have those
from Packt Publishing)
(Especially I am
On Wednesday, 27 September 2017 at 20:24:24 UTC, DreadKyller
wrote:
The attitude of "some people use this feature incorrectly, so
let's ban it's use entirely" is honestly ridiculous to me, but
oh well, that's apparently the modern philosophy.
Not even modern, see Java :) ("I left out operator
On Wednesday, 27 September 2017 at 16:35:54 UTC, DreadKyller
wrote:
Been using D for a couple years now, however one problem I've
had, more so recently since I've been dealing a lot with OpenGL
is related to pointers.
I have a matrix object to aid with the matrix math required for
working
On Wednesday, 20 September 2017 at 19:25:58 UTC, Timon Gehr wrote:
Actually, it is useful enough to have a Wikipedia page:
https://en.wikipedia.org/wiki/Iverson_bracket
Mmmm... "The notation was originally introduced by Kenneth E.
Iverson in his programming language APL".
APL... yeah :)
On Wednesday, 20 September 2017 at 02:16:16 UTC, EntangledQuanta
wrote:
Your an idiot, I know about how operator precedence works far
more than you do. Wanna bet? how much? Your house? your wife?
Your life? It's about doing things correctly, you seem to fail
to understand, not your fault,
On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta
wrote:
Yeah, that is really logical! No wonder D sucks and has so many
bugs! Always wants me to be explicit about the stuff it won't
figure out but it implicitly does stuff that makes no sense.
The whole point of the parenthesis is
On Sunday, 17 September 2017 at 17:06:10 UTC, bitwise wrote:
I don't really see a way to deal with this aside from branching
the entire library and inserting something like
'FT_SIZE_REQUEST_TYPE__FORCE_INT = 0x' into every enum
incase the devs used it in a struct.
Just put the burden
On Saturday, 16 September 2017 at 03:06:24 UTC, Timothy Foster
wrote:
You are correct, however 6.7.2.2 "Enumeration specifiers"
states: "Each enumerated type shall be compatible with char, a
signed integer type, or an unsigned integer type. The choice of
type is implementation-defined, but
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster
wrote:
I believe C enum size is implementation defined. A C compiler
can pick the underlying type (1, 2, or 4 bytes, signed or
unsigned) that fits the values in the enum.
No, at least, not C99. See 6.4.4.3: "An identifier declared
On Wednesday, 13 September 2017 at 17:39:29 UTC, Steven
Schveighoffer wrote:
Correct. So given a function:
inout(int*) foo(inout(int*)p1, inout(int*)p2)
The table shows what inout is resolved as when calling the
function.
If you consider the column the mutability of p1, and the row
the
On Tuesday, 12 September 2017 at 19:59:52 UTC, Joseph wrote:
The compiler shouldn't arbitrarily force one to make arbitrary
decisions that waste time and money.
You might want to educate yourself about arbitrary decisions that
waste time and money:
On Monday, 11 September 2017 at 18:15:36 UTC, jmh530 wrote:
An interesting example. I'm not sure overriding is the issue so
most as what is in the overload set. I think foo(int) is not
part of the overload set yet. The compiler is able to cast the
long to int and then call the one in class B
On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
I suppose my issue is that final should prevent function
hijacking because I shouldn't be allowed to override string
bar(double d) anyway. It shouldn't be a worry.
It has nothing to do with overriding. Consider:
import std.stdio;
There is this little table in
https://dlang.org/spec/function.html#inout-functions:
Common qualifier of the two type qualifiers
mutable const immutable inout inout const
mutable (= m) m c c c c
const (= c)c c c c c
On Tuesday, 30 May 2017 at 21:16:26 UTC, Oleg B wrote:
Hello. I have this code
import std.stdio;
void foo(byte a) { writeln(typeof(a).stringof); }
void foo(short a) { writeln(typeof(a).stringof); }
void foo(int a) { writeln(typeof(a).stringof); }
void main()
{
foo(0); // int, and byte if
On Saturday, 27 May 2017 at 17:57:03 UTC, Mike B Johnson wrote:
And what if one isn't interfacing to C? All pointers should be
known.
Apparently some people are (were?) working on semi-precise GC:
https://github.com/dlang/druntime/pull/1603
That still scans the stack conservatively, though.
On Friday, 26 May 2017 at 11:27:19 UTC, zakk wrote:
I have a followup question: my background is C and in Wolfram
Mathematica, so my
knowledge of templates is limited to trivial examples in C++...
It seems to me that
when programming in D templates are something more powerful
Even in C++
On Wednesday, 3 May 2017 at 07:34:03 UTC, Daniel Kozák wrote:
print in A is template:
What :)
How does it interact with 'final'?
On Wednesday, 3 May 2017 at 06:54:15 UTC, nkm1 wrote:
final method type inference stuff
Jacob and Jonathan - thank you, this is clear to me now.
Hopefully it will get fixed at some point.
Consider:
import std.stdio;
class A
{
final print() { writeln(this); } // no return type
}
class B : A
{
final void print() { writeln(this); }
}
void main()
{
auto b = new B;
b.print();
A a1 = b;
a1.print();
A a2 = new A;
a2.print();
}
That compiles:
$ dmd
24 matches
Mail list logo
