SrMordred had already figured it (setjmp vs _setjmp(..., null))
out:
https://forum.dlang.org/post/abrjmdvvlqdmmnpxc...@forum.dlang.org
An old thread about the same problem:
https://forum.dlang.org/thread/mmxwhdypncaeikknl...@forum.dlang.org
struct jmp_buf {
byte[256] data;
}
jmp_buf my_jmp_buf;
extern(C) {
int setjmp(ref jmp_buf env);
void longjmp(ref jmp_buf env, int);
}
void
second() {
writefln("second");
What other libraries (if any) are part of Phobos?
The following compiles without pragma(lib, ...):
extern(C) {
const(char)* zlibVersion();
}
void main() {
const(char)* sz = zlibVersion();
}
D's type declarations seem to read right to left.
int an_integer;
int[10] an_array_of_10_integers;
int[10]* a_pointer_to_an_array_of_10_integers =
_array_of_10_integers;
int*[10] an_array_of_10_pointers_to_integers;
int*[10]* a_pointer_to_an_array_of_10_pointers_to_integers =
I see. I guess the other would be:
{
int[8192] bar;
int[8192][string] foo;
foo["a"] = bar;
foo["a"][8191] = -1;
}
// foo is an associative array/hashtable with
// key type: string
// value type: int[10]
//
int[10][string] foo;
// foo["a"] = new int[10]; // Range violation at runtime
// foo["a"][0] = 1; // Range violation at runtime
(@tipdbmp: The string gets turned into the function
_D3std10functional__T9binaryFunVAyaa5_61203c2062VQra1_61VQza1_62Z__TQBvTiTiZQCdFNaNbNiNfKiKiZb. No references to it remain with -O3; the LLVM IR obtained with -output-ll might be easier to read than assembly.)
I see. It seems that ldc 1.8.0
I can't read assembly but it seems to me that it doesn't:
https://godbolt.org/g/PCsnPT
I think C++'s sort can take a "function object" that can get
inlined.
Mostly, it's just a bad idea - it's very easy for a person
reading the code after you've written it to get the two x's
mixed up.
// example from: 19.17.1.3
void main()
{
{ static int x; }
{ static int x; } // error
{ int i; }
{ int i; } // ok
}
I don't really see how the
The following seems to work in C++, but errors in D, why is that?
int foo(int* num) {
{
static int x = 10;
x += 1;
*num += x;
}
{
static int x = 20; // error: foo.x is already defined in
another scope in foo
x += 2;
*num += x;
}
So is this a bug, or am I misunderstanding something?
//
// rdmd -m64 foo.d
//
module va_arg_x64_windows;
void foo(void* a, void* b, void *c, void* d, ...) {
import core.vararg : va_arg;
import std.stdio : writeln;
foreach (arg; _arguments) {
if (arg == typeid(int)) {
int x = va_arg!(int)(_argptr);
Appender is able to do this:
It seems that Appender allocates its own private data:
private struct Data
{
size_t capacity;
Unqual!T[] arr;
bool canExtend = false;
}
...
private Data* _data;
...
_data = new Data;
But hopefully its bug free unlike what I posted (missing
`T.sizeof
Have you checked what push_stuff actually returns with those
inputs?
Right, we get [0xFF, 0xFF, 'A'] and [0xFF, 0xFF].
I think the following is a pretty easy workaround though:
alias usize = size_t;
struct Push_Buf(T, usize stack_size) {
T[stack_size] stack_buf;
T[] heap_buf;
string push_stuff(char[] buf, int x) {
if (x == 1) {
buf ~= 'A';
buf ~= 'B';
buf ~= 'C';
return cast(string) buf[0 .. 3];
}
else {
buf ~= 'A';
buf ~= 'B';
return cast(string) buf[0 .. 2];
}
}
void foo() {
{
string push_stuff(char[] buf, int x) {
if (x == 1) {
buf ~= 'A';
buf ~= 'B';
buf ~= 'C';
return cast(string) buf[0 .. 3];
}
else {
buf ~= 'A';
buf ~= 'B';
return cast(string) buf[0 .. 2];
}
}
void foo() {
{
What is your definition of a dangling pointer?
A pointer pointing to freed memory, which presumably '[0]'
should be because it reallocates.
It seems that the '~=' operator "knows" that there's a reference
to 'a's old memory and it keeps it around instead of freeing it.
I just don't
char * get_dangling_ptr() {
char[] a;
a.reserve(15);
a ~= 'x';
char *x = [0];
auto a_initial_ptr = a.ptr;
foreach (_; 0 .. 30) {
a ~= 'y';
//a.assumeSafeAppend() ~= 'y';
}
assert(a.ptr != a_initial_ptr, "a should've reallocated");
// trying
dmd main.d C:\libs\my_module.d
That does not use the -I switch.
It compiles if I specify the full path to my_module.d:
dmd -IC:\libs main.d C:\libs\my_module.d
I don't understand the error message though.
// C:\libs\my_module.d
module my_module;
void foo() {}
// main.d
module main;
import my_module;
void main() {
foo();
}
Running dmd with:
dmd -IC:\libs main.d my_module.d
I get:
Error: module my_module is in file 'my_module.d' which cannot
be read
import path[0] = C:\libs
I think you have to decode your input to UTF-8.
stdin
.byLineCopy(No.keepTerminator)
.each!((string file_name_raw) {
// change Latin1String to the code page of your console;
// use the 'chcp' command to see the current code page of
your console
//
import std.encoding;
auto
import core.vararg;
string foo(fmt, ...) {
int args_len = _arguments.length;
if (args_len == 1) {
if (typeid(_arguments[0] == typeid(TypeInfo[]))) {
_arguments = va_arg!(TypeInfo[])(_argptr);
args_len = _arguments.length;
// how can I adjust
It seems to me that some of the language reference/spec pages
that are somewhat long,
could provide a Toc (Table of contents) which should help users
see an overview of what's
there and improve the searchability and the navigation of the
content.
The 'Functions' page has a Toc already.
24 matches
Mail list logo
