On Tuesday, November 20, 2018 11:04:08 AM MST Johan Engelen via Digitalmars-
d-learn wrote:
> On Tuesday, 20 November 2018 at 03:38:14 UTC, Jonathan M Davis
>
> wrote:
> > For @safe to function properly, dereferencing null _must_ be
> > guaranteed to be memory safe, and for dmd it is, since it
On Tuesday, November 20, 2018 8:38:40 AM MST Kagamin via Digitalmars-d-learn
wrote:
> On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
>
> Hermoso wrote:
> > When I was first playing with D, I managed to create a segfault
> > by doing `SomeClass c;` and then trying do something with
On Tue, 20 Nov 2018 23:14:27 +, Johan Engelen wrote:
> When you don't call `a.foo()` a dereference, you basically say that
> `this` is allowed to be `null` inside a class member function. (and then
> it'd have to be normal to do `if (this) ...` inside class member
> functions...)
That's what
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
But really, it's the act of using a pointer to read/write the
data it points at which causes the segfault. And in D, we
assume that this action is @safe because of the MMU protecting
the first page.
This is like me
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class objects explicit, which
makes it harder to see where the dereference is happening.
Again, the terms are confusing. You just said the
Try to learn D.
Put writeln in deconstructor to prove it works as expected
Make random changes, program never runs again.
Takes 30+ minutes to realize that writeln("my string") is fine,
but writeln("my string " ~ value) is an allocation / garbage
collection which crashes the program without a
On Tuesday, 20 November 2018 at 15:29:50 UTC, Kagamin wrote:
On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
This only applies to little scripts and unittests maybe.
Not when you're writing any kind of relatively larger
application that involves being run for longer or if there's
On 11/20/18 1:54 PM, Adnan wrote:
Godbolt: https://godbolt.org/z/SWWOu7
When I write `something!(aNumber)()` and if a number is an
immutable/enum it should be able to be read at compile time, right? Why
is this different?
auto fizzbuzz(uint N)() {
static string accumulate;
string is
On 11/20/18 1:04 PM, Johan Engelen wrote:
On Tuesday, 20 November 2018 at 03:38:14 UTC, Jonathan M Davis wrote:
For @safe to function properly, dereferencing null _must_ be
guaranteed to be memory safe, and for dmd it is, since it will always
segfault. Unfortunately, as understand it, it is
On Tue, Nov 20, 2018 at 06:54:58PM +, Adnan via Digitalmars-d-learn wrote:
> Godbolt: https://godbolt.org/z/SWWOu7
>
> When I write `something!(aNumber)()` and if a number is an
> immutable/enum it should be able to be read at compile time, right?
> Why is this different?
[...]
Read this
On Tuesday, 20 November 2018 at 18:54:58 UTC, Adnan wrote:
Godbolt: https://godbolt.org/z/SWWOu7
When I write `something!(aNumber)()` and if a number is an
immutable/enum it should be able to be read at compile time,
right? Why is this different?
auto fizzbuzz(uint N)() {
static string
Godbolt: https://godbolt.org/z/SWWOu7
When I write `something!(aNumber)()` and if a number is an
immutable/enum it should be able to be read at compile time,
right? Why is this different?
auto fizzbuzz(uint N)() {
static string accumulate;
return fizzbuzz!N(accumulate);
}
auto
On Tuesday, 20 November 2018 at 03:38:14 UTC, Jonathan M Davis
wrote:
For @safe to function properly, dereferencing null _must_ be
guaranteed to be memory safe, and for dmd it is, since it will
always segfault. Unfortunately, as understand it, it is
currently possible with ldc's optimizer to
On Tue, 20 Nov 2018 15:29:50 +, Kagamin wrote:
> On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
>> This only applies to little scripts and unittests maybe.
>>
>> Not when you're writing any kind of relatively larger application that
>> involves being run for longer or if there's
On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
Because the more you learn about D the less you want to use
classes.
classes rock. You just initialize it. You're supposed to
initialize *everything* anyway.
On Tuesday, 20 November 2018 at 09:27:03 UTC, aberba wrote:
Does D have a linter which warns about certain style of coding
like this?
dscanner might check it. I don't know though.
On Tuesday, 20 November 2018 at 09:27:03 UTC, aberba wrote:
Does D have a linter which warns about certain style of coding
like this?
AFAIK, dscanner does some linting.
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a segfault
by doing `SomeClass c;` and then trying do something with the
object I thought I had default-created, by analogy with C++
syntax.
D is more similar to
On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
This only applies to little scripts and unittests maybe.
Not when you're writing any kind of relatively larger
application that involves being run for longer or if there's
more possible permutations of your state variables.
Umm...
On Tuesday, 20 November 2018 at 13:28:21 UTC, Boris-Barboris
wrote:
On Tuesday, 20 November 2018 at 13:20:08 UTC, Stanislav Blinov
wrote:
https://dlang.org/changelog/2.083.0.html#reboot14246
Nvm, found the info in the issue tracker, thank you for the
link.
You're welcome. It's one of those
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
Why does nobody seem to think that `null` is a serious problem
in D?
Because the more you learn about D the less you want to use
classes. I view class as compatibility feature when you want to
port Java code to D.
On Tuesday, 20 November 2018 at 13:20:08 UTC, Stanislav Blinov
wrote:
https://dlang.org/changelog/2.083.0.html#reboot14246
Wording "object" means both classes and structs?
On Tuesday, 20 November 2018 at 13:20:08 UTC, Stanislav Blinov
wrote:
https://dlang.org/changelog/2.083.0.html#reboot14246
Nvm, found the info in the issue tracker, thank you for the link.
On Tuesday, 20 November 2018 at 13:01:40 UTC, Boris-Barboris
wrote:
https://run.dlang.io/is/LdylJX
Notice no "B destructor" line in stdout.
Just got bitten by the assumption that my Buffer struct that
transactionally aquires multiple external resources in
constructor will rollback via member
On Tuesday, 20 November 2018 at 13:01:40 UTC, Boris-Barboris
wrote:
https://run.dlang.io/is/LdylJX
Notice no "B destructor" line in stdout.
Just got bitten by the assumption that my Buffer struct that
transactionally aquires multiple external resources in
constructor will rollback via member
https://run.dlang.io/is/LdylJX
Notice no "B destructor" line in stdout.
Just got bitten by the assumption that my Buffer struct that
transactionally aquires multiple external resources in
constructor will rollback via member destructors that were
successfully completed before the throw.
On Tuesday, 20 November 2018 at 12:01:49 UTC, Stanislav Blinov
wrote:
On Tuesday, 20 November 2018 at 11:54:59 UTC, welkam wrote:
On Monday, 19 November 2018 at 22:14:25 UTC, Neia Neutuladh
wrote:
Nothing stops you from writing:
SomeStruct myStruct;
On Tuesday, 20 November 2018 at 11:54:59 UTC, welkam wrote:
On Monday, 19 November 2018 at 22:14:25 UTC, Neia Neutuladh
wrote:
Nothing stops you from writing:
SomeStruct myStruct;
fd.rawRead((cast(ubyte*))[0..SomeStruct.sizeof]);
Standard caveats about byte order and alignment.
On Monday, 19 November 2018 at 22:14:25 UTC, Neia Neutuladh wrote:
Nothing stops you from writing:
SomeStruct myStruct;
fd.rawRead((cast(ubyte*))[0..SomeStruct.sizeof]);
Standard caveats about byte order and alignment.
Never would I thought about casting struct to static array. If I
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so
I just don't see it as a big deal. You lose a
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so
I just don't see it as a big deal. You lose a
On Monday, 19 November 2018 at 19:52:31 UTC, kinke wrote:
On Monday, 19 November 2018 at 10:04:25 UTC, willo wrote:
Im trying to get MSVC to debug my binary. I've added...
"dflags": ["-g"],
at the top level in dub.json to try and get LDC to generate
debug info. But doesnt seem to have done
32 matches
Mail list logo
