On Wednesday, 26 September 2018 at 22:46:21 UTC, Jonathan wrote:
This code fails to compile: ("undefined identifier fun")
void main() {
fun();
void fun() {}
}
Having the call after the declaration works:
void main() {
void fun() {}
fun();
}
Is this how it is intended to work?
On Wednesday, 5 September 2018 at 07:48:34 UTC, Chris wrote:
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright
wrote:
Autodecode - I've suffered under that, too. The solution was
fairly simple. Append .byCodeUnit to strings that would
otherwise autodecode. Annoying, but hardly a
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, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis
wrote:
Folks are free to decide to support dxml for inclusion when the
time comes and free to vote it as unacceptable. Personally, I
think that dxml's approach is ideal for XML that doesn't use
entity references, and I'd much rather
On Sunday, 26 August 2018 at 13:40:17 UTC, Chris wrote:
You can get used to anything until you find out that it doesn't
need to be this way. You write unexciting Java code and hey, it
works and it always will. It took me a while to understand why
Java has been so successful, but now I know.
A
On Friday, 24 August 2018 at 13:34:57 UTC, Shachar Shemesh wrote:
On 24/08/18 13:43, nkm1 wrote:
I think Walter was talking more about "scope (failure)
destroy(this)" at the top of all your structs? I don't know if
it has some gotchas, though (as I don't use RAII in D...).
No, unlike
On Friday, 24 August 2018 at 10:16:34 UTC, Shachar Shemesh wrote:
On 23/08/18 15:03, Walter Bright wrote:
So you will excuse me, but I don't think this bug is being
taken as seriously as I think it should.
It is a serious problem. (There are workarounds available,
like using scope(failure).)
On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh
wrote:
Let's start with this one:
https://issues.dlang.org/show_bug.cgi?id=14246#c6
The problems I'm talking about are not easily fixable. They
stem from features not playing well together.
One that hurt me lately was a way to pass
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 Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:
jesus that became a long title.
Anyway as the title says, is it a bug that a parent class that
access its own private members from derived classes gets
deprecation warning?
Scenario narrowed down:
// module foo;
class Foo
{
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 Monday, 19 March 2018 at 02:56:32 UTC, Norm wrote:
+1024 bytes
I think D is a terrific language worthy of all the praise it
gets and it is way way more stable than it was 3yrs ago. But
the attitude of submit a PR if you want it fixed works very
much against D. Like it or not these forums
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu
wrote:
Hello, the vision document of the Founation for the first six
months of 2018 is here:
https://wiki.dlang.org/Vision/2018H1
According to the State of D Survey, 71% of
On Tuesday, 6 March 2018 at 17:36:08 UTC, Mario Kröplin wrote:
[REG2.071] Interface contracts retrieve garbage instead of
parameters
https://issues.dlang.org/show_bug.cgi?id=15984
This regression from 2016 causes random crashes if you use one
of the key features of D - Contract Programming.
On Thursday, 5 October 2017 at 10:23:17 UTC, Dukc wrote:
Does that work? If so, good. But still not optimal, because you
should be able to extend the functionality of code without
changing it.
It works, yes. The point is, additional methods in the struct
body, and free standing functions
On Thursday, 5 October 2017 at 11:22:27 UTC, nkm1 wrote:
Isn't that the "struct hack" (aka "flexible array member")? :)
(I mean, it would be in C :)
On Thursday, 5 October 2017 at 08:27:14 UTC, Dukc wrote:
and you have to rewrite many wrappers for Crng functions
despite the alias this because they either require return Crng
or gequire a pointer to one. This needs to be defined manually
for example:
Crng initByTime(int time){return
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 Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote:
This release comes with static foreach
Great! I noticed one small issue, though. When compiled with
warnings, it warns about unreachable code when static foreach in
a switch, for example:
void trySwitch(int x) {
import
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 Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:
DIP 1008 is titled "Exceptions and @nogc".
As someone who iis interested in @nogc (more precisely: in
avoiding GC pauses), I like this proposal... But it looks like
people are concerned about 'new' becoming contextual keyword
(that
On Saturday, 13 May 2017 at 02:53:16 UTC, Mike B Johnson wrote:
On Friday, 12 May 2017 at 22:05:54 UTC, Faux Amis wrote:
Somehow totally missed your message, welcome!
After reading all the GC comments on reddit:
https://www.reddit.com/r/programming/comments/6as1di/serialization_in_d/
I wish
So I spent last week (or so) learning D, and it's a great
language.
Initially I was apprehensive about GC (non generational,
conservative...), but now I realize that I can use D as an
improved C (combining malloc and GC :). I always liked C better
than C++ anyway.
I know that every bloody n00b
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
42 matches
Mail list logo
