Access violation when using IShellFolder2
Consider the following code:
import core.sys.windows.windows;
import core.sys.windows.shlobj;
import core.sys.windows.wtypes;
import std.exception;
pragma(lib, "Ole32");
void main()
{
OleInitialize(null);
scope(exit) OleUninitialize();
IShellFolder desktop;
LPITEMIDLIST pidlRecycleBin;
enforce(SUCCEEDED(SHGetDesktopFolder()), "Failed to
get desktop shell folder");
assert(desktop);
scope(exit) desktop.Release();
enforce(SUCCEEDED(SHGetSpecialFolderLocation(null,
CSIDL_BITBUCKET, )), "Failed to get recycle bin
location");
assert(pidlRecycleBin);
scope(exit) ILFree(pidlRecycleBin);
IShellFolder2 recycleBin;
enforce(SUCCEEDED(desktop.BindToObject(pidlRecycleBin, null,
_IShellFolder2, cast(LPVOID *))), "Failed to get
recycle bin shell folder");
assert(recycleBin);
scope(exit) recycleBin.Release();
IEnumIDList enumFiles;
with(SHCONTF) enforce(SUCCEEDED(recycleBin.EnumObjects(null,
SHCONTF_FOLDERS | SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN,
)), "Failed to enumerate objects in recycle bin");
enumFiles.Release();
}
For me this code crashes with error:
object.Error@(0): Access Violation
0x75B4EBB8 in SHELL32_CLocationContextMenu_Create
0x004023A9
0x0040493B
0x004048B5
0x0040474E
0x00402C9A
0x0040250B
0x75816359 in BaseThreadInitThunk
0x76F07C24 in RtlGetAppContainerNamedObjectPath
0x76F07BF4 in RtlGetAppContainerNamedObjectPath
However if I change the type of recycleBin variable to
IShellFolder (not IShellFolder2), the crash does not happen.
Does IShellFolder2 require some special handling?
Re: how to run 'dub upgrade' from within VisualD?
On Monday, 24 August 2020 at 21:19:14 UTC, mw wrote: Hi, Just wonder how to run 'dub upgrade' from within VisualD? on Windows of course. As a work around, I just delete the proj.sln, and regenerated it: ``` C:\\ dub.exe generate visuald ``` then it have the latest package versions.
Re: Range checked assignment
On Tuesday, 8 September 2020 at 14:18:14 UTC, Cecil Ward wrote: I assumed I would have to create a struct type definition and handle various operators. How many will I have to handle? I would of course make it a template so I can reuse this otherwise horribly repetitive code. You can see a full list of overloadable operators here: https://dlang.org/spec/operatoroverloading.html Most likely you will want to handle all of the binary operators, unary operators, and assignment operators. For runtime checking, you will probably want to use an invariant, rather than writing individual checks in each member function: https://dlang.org/spec/contracts.html#Invariants
Re: Range checked assignment
On Tuesday, 8 September 2020 at 14:18:14 UTC, Cecil Ward wrote:
What I would like to do is (in pseudo-code) :
declare_var my_var : int range 0..7; // i.e. 0 <= val <= 7;
my_var = 6; // ok
my_var = 8; // bang ! static assert fail or assert fail at
runtime
my_var = 6;
my_var += 2; // bang ! value 8 is > 7
So every assignment is range-checked at either compile-time if
at all possible or else at runtime. This includes things like
+= and initialisers of course, not just straight assignment.
I assumed I would have to create a struct type definition and
handle various operators. How many will I have to handle? I
would of course make it a template so I can reuse this
otherwise horribly repetitive code.
If you want to define an integral-like type which is more-or-less
interchangeable with the native integral types, you'll need to
provide the following overloads and members:
* An enum member named `min` which provides an instance of the
lowest possible value of the type.
* An enum member named `max` which provides an instance of the
highest possible value of the type.
* A constructor.
* `opAssign`.
* `opOpAssign` for the operators: `-`; `+`; `/`; `*`; `%`; `^^`;
`&`; `|`; `^`; `<<`; `>>`; `>>>`.
* `opEquals`, which should be a const member function.
* `opCmp`, which should be a const member function.
* `opUnary` for the operators: `-`; `+`; `~`, which should be a
const member function.
* `opUnary` for the operators: `--`; `++`, which should be a
mutable member function.
* `opBinary` for the operators: `-`; `+`; `/`; `*`; `%`; `^^`;
`&`; `|`; `^`; `<<`; `>>`; `>>>`, which should be a const member
function.
* `opCast`, which should be a const member function.
Although in your specific case, implementing the bitwise
operators may not make sense.
Ideally, all the operator overloads, and the constructor, should
be able to take any native integral type, and any instances of
your type, as arguments.
Here's a skeleton implementation of an integral-like type:
import std.algorithm;
import std.traits;
template isConstrainedInt (Instance)
{
enum bool isConstrainedInt = __traits(
isSame,
TemplateOf!Instance,
ConstrainedInt
);
}
template ConstrainedInt (long lower, long upper)
if (lower <= upper)
{
struct ConstrainedInt
{
enum typeof(this) min = typeof(this)(lower);
enum typeof(this) max = typeof(this)(upper);
this (Integer) (const Integer value)
if (isIntegral!Integer || isConstrainedInt!Integer)
{}
void opAssign (Integer) (const Integer value)
if (isIntegral!Integer || isConstrainedInt!Integer)
{}
void opOpAssign (string operator, Integer) (const Integer
value)
if (
canFind(
operator,
"-", "+", "/", "*", "%", "^^",
"&", "|", "^",
"<<", ">>", ">>>"
)
&& (isIntegral!Integer ||
isConstrainedInt!Integer)
)
{}
bool opEquals (Integer) (const Integer value) const
if (isIntegral!Integer || isConstrainedInt!Integer)
{}
int opCmp (Integer) (const Integer value) const
if (isIntegral!Integer || isConstrainedInt!Integer)
{}
typeof(this) opUnary (string operator) () const
if (
canFind(
operator,
"-", "+",
"~"
)
)
{}
typeof(this) opUnary (string operator) ()
if (canFind(operator, "--", "++"))
{}
typeof(this) opBinary (string operator, Integer) (const
Integer value) const
if (
canFind(
operator,
"-", "+", "/", "*", "%", "^^",
"&", "|", "^",
"<<", ">>", ">>>"
)
&& (isIntegral!Integer ||
isConstrainedInt!Integer)
)
Re: Range checked assignment
On Tuesday, 8 September 2020 at 14:18:14 UTC, Cecil Ward wrote:
What I would like to do is (in pseudo-code) :
declare_var my_var : int range 0..7; // i.e. 0 <= val <= 7;
my_var = 6; // ok
my_var = 8; // bang ! static assert fail or assert fail at
runtime
my_var = 6;
my_var += 2; // bang ! value 8 is > 7
So every assignment is range-checked at either compile-time if
at all possible or else at runtime. This includes things like
+= and initialisers of course, not just straight assignment.
I assumed I would have to create a struct type definition and
handle various operators. How many will I have to handle? I
would of course make it a template so I can reuse this
otherwise horribly repetitive code.
I believe you could use Checked
(https://dlang.org/library/std/experimental/checkedint.html) with
custom hook or roll your own type with appropriate operator
overloading(https://dlang.org/spec/operatoroverloading.html).
Code for this won't be that bad, thanks to string mixins. Just
mixin("lhs" ~ op ~ "rhs") and Bob's your uncle :).
Range checked assignment
What I would like to do is (in pseudo-code) : declare_var my_var : int range 0..7; // i.e. 0 <= val <= 7; my_var = 6; // ok my_var = 8; // bang ! static assert fail or assert fail at runtime my_var = 6; my_var += 2; // bang ! value 8 is > 7 So every assignment is range-checked at either compile-time if at all possible or else at runtime. This includes things like += and initialisers of course, not just straight assignment. I assumed I would have to create a struct type definition and handle various operators. How many will I have to handle? I would of course make it a template so I can reuse this otherwise horribly repetitive code.
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 13:20:24 UTC, kinke wrote: On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote: How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking You can add -v as dub 'linker' flag, that will make LDC show the actual cmdline. LDC v1.23 defaults to `-linker=bfd` for Android targets though. And now I actually remember that you should get a startup error in case the linker sections arrangement is a problem, so it's most likely not the linker. The good feedback mentioned earlier, where the GC was apparently no problem: https://github.com/ldc-developers/ldc/issues/3461#issuecomment-648599814 Hmmm, very strange that I get crashes in the _D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm... I am using the SDL android-project as my project structure in Android studio. I am replacing the libmain.so which would normally be build from c/c++ with a libmain.so file created by D. Everything compiles, deploys, and seems to work as expected. Except for random crashes which went away after disabling the GC. It might be an interplay between Java, the SDL C trampoline code, and D threads or any of the other packages I am using (SDL_Mixer, SDL_Net, jni, d_android). The weirdest thing is that after a segfault, the app closes, but swiping up will show the app as still running, clicking on it will re-start the app from scratch
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 12:53:43 UTC, Adam D. Ruppe wrote: On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote: How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking If you are using the d_android setup thing, it actually edits ldc2.conf so it uses the linker from the NDK. Did you do that step? I manually updated the ldc2.conf file, to point to the right NDK
Re: Named parameters in function call
On Tuesday, 8 September 2020 at 09:40:11 UTC, Andre Pany wrote: On Tuesday, 8 September 2020 at 07:43:05 UTC, Cecil Ward wrote: I can’t remember, do Ada or Modula2 have something like myfunc( x => 100, y => 200, color => blue )[1] which has named parameters that can be passed in any order. [...] I hope we have it this year or next year, as we have this DIP https://www.github.com/dlang/DIPs/tree/master/DIPs%2FDIP1030.md Kind regards Andre I wonder if there is any way in which we could combine this with strong typing of some sort (how?) to detect errors such as int xcoord; int ycoord; myfunc( x : ycoord, y : xcoord, color : blue )[3] where the arguments are the wrong way around. Would have to change the types of the xcoord and ycoord variables somehow, something I have asked about earlier.
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote: How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking You can add -v as dub 'linker' flag, that will make LDC show the actual cmdline. LDC v1.23 defaults to `-linker=bfd` for Android targets though. And now I actually remember that you should get a startup error in case the linker sections arrangement is a problem, so it's most likely not the linker. The good feedback mentioned earlier, where the GC was apparently no problem: https://github.com/ldc-developers/ldc/issues/3461#issuecomment-648599814
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote: How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking If you are using the d_android setup thing, it actually edits ldc2.conf so it uses the linker from the NDK. Did you do that step?
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 12:23:43 UTC, kinke wrote: On Tuesday, 8 September 2020 at 11:17:45 UTC, Danny Arends wrote: Does anyone have any experience with using D on android, and using the garbage collector ??? I've never run anything on Android myself, but I've gotten good feedback on AArch64 at least. Make sure to use a recent LDC, and especially to use the bfd linker, not gold or lld, as mentioned in various places. Thanks, I compile for AArch64, and am using the latest version 1.23.0 How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking Linking... C:\ldc2-1.23.0-windows-multilib\bin\ldc2.exe -of.dub\build\android-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-555146BAEC3641EAD156A00213211307\libmain.so .dub\build\android-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-555146BAEC3641EAD156A00213211307\main.o C:\Users\Arends\AppData\Local\dub\packages\arsd-official-8.4.0\arsd-official\.dub\build\library-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-FB68B3ECD76B5B393C4A14B20D11A5C9\libarsd-official_jni.a ..\bindbc-gles\.dub\build\dynamicBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-B2DF1F93BE637030294C2E6219F2659F\libBindBC_GLES.a C:\Users\Arends\AppData\Local\dub\packages\bindbc-sdl-0.19.1\bindbc-sdl\.dub\build\dynamicBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-E89B5B92EC516794E9D7694E40626205\libBindBC_SDL.a C:\Users\Arends\AppData\Local\dub\packages\bindbc-loader-0.3.2\bindbc-loader\.dub\build\yesBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-44C0A0E484E57B7F1481E669A0811B65\libBindBC_Loade! r.a -L--no-as-needed -L-landroid -L-ldl -mtriple=aarch64--linux-android -shared -g
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 11:17:45 UTC, Danny Arends wrote: Does anyone have any experience with using D on android, and using the garbage collector ??? I've never run anything on Android myself, but I've gotten good feedback on AArch64 at least. Make sure to use a recent LDC, and especially to use the bfd linker, not gold or lld, as mentioned in various places.
GC.LDC2 on Android
Hey all, I'm porting my 3D engine to Android (so far most of the work is going smoothly). However, I had random crashes which I first suspected was due to how I do multi-threading, but after debugging it turns out that the Garbage Collector is the issue. The crash always happens after entering the function: _D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm The critical sections of the 3D engine are @nogc, but for some non-critical parts of the application I still use the GC. Does anyone have any experience with using D on android, and using the garbage collector ???
Re: Named parameters in function call
On Tuesday, 8 September 2020 at 07:43:05 UTC, Cecil Ward wrote: I can’t remember, do Ada or Modula2 have something like myfunc( x => 100, y => 200, color => blue )[1] which has named parameters that can be passed in any order. [...] I hope we have it this year or next year, as we have this DIP https://www.github.com/dlang/DIPs/tree/master/DIPs%2FDIP1030.md Kind regards Andre
Re: Install multiple executables with DUB
Thanks everybody! My folder structure looks like this: . ├── bin ├── dub.sdl ├── src │ ├── biophysics │ │ └── ... │ └── tools │ │ └── ... └── test ├── ... Following the advice of drug, I moved the "tools" folder from src to the parent directory, added a dependency to "biophysics" with path ".." and build the binaries with "dub build --single tools/..." This works fine, however, now I have a problem when editing with Emacs: Flycheck gives errors as it cannot find my package anymore and company autocomplete does not work anymore neither. By the way, I have the same problem when I clone tsv-utils and open the source file with Emacs. I have to admit I am using emacs' d-mode as a black-box since there seems to be no documentation, and I am not very fluent in elisp... I tried keeping the tools folder in src and added the following line to dub.sdl: `excludedSourceFiles "./src/tools/*.d"` however, this does not seem to make any difference. A solution that works is putting dub.sdl into src, adding `sourcePaths "biophysics"`, however, "dub build --single" is only working in the src-folder and not the parent folder...
Named parameters in function call
I can’t remember, do Ada or Modula2 have something like
myfunc( x => 100, y => 200, color => blue )[1]
which has named parameters that can be passed in any order.
Does D have anything like this? If not, would anyone support a
development like the above [1] ?
If D does not have this, I am wondering about how to write such a
thing but the cure might very very easily be worse than the
disease. I have little clue here. I have seen a hack for C
(written by RevK) that involves assignments to fields in a struct
and the struct is then passed to a function.
Something like
myfunc( { field2: 20, field1: 10, fieldstr : "a string" } )
[2]
and preprocessor trickery was used to get rid of the unsightly {
} by making a macro call to a wrapper macro that takes variadic
... arguments.
