Re: Are there any containers that go with allocators?
On Tuesday, 9 February 2021 at 12:23:52 UTC, rikki cattermole wrote: https://github.com/dlang-community/containers It uses the older design for allocators (dependency). Looks good, thank you
Are there any containers that go with allocators?
Normally I'm happy with the GC containers in D, they work well and suit my use. I have a few uses that would benefit from allocation in memory arenas or local stack based allocation. Looks like std.experimental has allocators for those use cases. But I can't find any containers to make use of those allocators. The built in ones use GC managed memory, there are std.container but they appear to use malloc/free which again is useful but not what I'm looking for. I'd like resizeable arrays, hashmaps and strings that I can allocate using an allocator? Am I missing something in the standard library, or a way to use the existing ones, or is it just that nobody has implemented this kind of thing yet?
Re: Contributing to D wiki
On Monday, 27 July 2020 at 16:58:13 UTC, H. S. Teoh wrote: On Mon, Jul 27, 2020 at 11:39:32AM +, John Burton via Digitalmars-d-learn wrote: [...] I tried looking there for information and examples of getting glfw3 statically linked into my program using LDC and didn't really find anything. I wonder if adding a page for static linking tips would be useful as it seems to be problematic and compiler and environment dependent? Perhaps I should go ahead and see if I can make a page and see if anyone objects :P Yes, please go ahead. I don't think there's a need to ask. :-) T I will try to add something in the coming days
Re: Contributing to D wiki
On Wednesday, 15 July 2020 at 22:18:47 UTC, H. S. Teoh wrote: On Wed, Jul 15, 2020 at 09:27:22PM +, tastyminerals via Digitalmars-d-learn wrote: [...] D wiki is badly outdated. This is not a fact but a gut feeling after reading through some of its pages. I was wondering who's owning it myself but never actually dared to just go and update. Why not? It's a *wiki*. Wikis are intended for the user community (i.e. you & me) to go and edit. That's the whole point of a wiki. If that wasn't the intention we wouldn't have set up a wiki in the first place. I tried looking there for information and examples of getting glfw3 statically linked into my program using LDC and didn't really find anything. I wonder if adding a page for static linking tips would be useful as it seems to be problematic and compiler and environment dependent? Perhaps I should go ahead and see if I can make a page and see if anyone objects :P
Re: Static link of glfw3 library fails for me
On Monday, 27 July 2020 at 08:53:25 UTC, Mike Parker wrote: On Monday, 27 July 2020 at 07:30:42 UTC, John Burton wrote: For reference I got this to work by doing the following :- 1) Installed visual studio build tools. I could not get this to work at all with the linker etc that comes with ldc2. 2) Copied the glfw3.lib vs2019 version file into my build directory (obviously could point the linker at it too which would be better) 3) Used the following dub.sdl name "game" description "Test Project" authors "Me" copyright "Copyright ┬® 2020, Me" license "proprietary" dependency "bindbc-glfw" version="~>0.10.0" dflags "-mscrtlib=ucrt" libs "glfw3" versions "BindGLFW_Static" The key seems to be using the dflags line to make it link with the "modern" C libraries, and using the microsoft linker. I appear to have glfw3 statically linked and working :) Cool. To be clear, you're still compiling with LDC, correct? I'm pretty sure DMD is using the universal C runtime out of the box when VS is installed. yes compiling with LDC (Installed via "scoop" (see https://scoop.sh) but I don't think that matter where it came from). I got it previously to work with DMD with no issue, my issue was with LDC only. I was using DMD for my project previously but started doing something where performance mattered so thought to use LDC instead.
Re: Static link of glfw3 library fails for me
On Sunday, 26 July 2020 at 12:24:06 UTC, John Burton wrote: On Sunday, 26 July 2020 at 10:41:27 UTC, Mike Parker wrote: On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote: And I get the following errors from the link :- lld-link: error: undefined symbol: __GSHandlerCheck lld-link: error: undefined symbol: __security_check_cookie lld-link: error: undefined symbol: __security_cookie I believe that's because the GLFW library was compiled with the Microsoft compiler's /GS option: For reference I got this to work by doing the following :- 1) Installed visual studio build tools. I could not get this to work at all with the linker etc that comes with ldc2. 2) Copied the glfw3.lib vs2019 version file into my build directory (obviously could point the linker at it too which would be better) 3) Used the following dub.sdl name "game" description "Test Project" authors "Me" copyright "Copyright ┬® 2020, Me" license "proprietary" dependency "bindbc-glfw" version="~>0.10.0" dflags "-mscrtlib=ucrt" libs "glfw3" versions "BindGLFW_Static" The key seems to be using the dflags line to make it link with the "modern" C libraries, and using the microsoft linker. I appear to have glfw3 statically linked and working :)
Re: Static link of glfw3 library fails for me
On Sunday, 26 July 2020 at 10:41:27 UTC, Mike Parker wrote: On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote: And I get the following errors from the link :- lld-link: error: undefined symbol: __GSHandlerCheck lld-link: error: undefined symbol: __security_check_cookie lld-link: error: undefined symbol: __security_cookie I believe that's because the GLFW library was compiled with the Microsoft compiler's /GS option: https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=vs-2019 The __security_* functions are MS extensions to the C standard library. A quick search suggests you should try linking with bufferoverflowU.lib. Either that or compile GLFW with /GS- to turn off the security checks. This is one reason I gave on on static linking pre-built C binaries long ago. I use the static bindings with import libraries, but I don't touch static libs unless I compile them myself. Thank you. I'll look into this. I wanted a single statically linked binary for an application I had in mind so thought I'd try this out. It's nice just to be able to send a single binary without needing to have an installer or copy multiple files for some use cases. This is the main reason I quite like go, not so much for the language but that things like "gitea" can be just one single binary and nothing else. I can rebuild glfw I guess, that's not a problem (but makes it harder for people if I want to share my code of course). Perhaps I ought to try this. I understand, as mentioned in your other reply, that I'll have to link with all the other dependencies of glfw too. I oversimplified my example a bit too much :)
Static link of glfw3 library fails for me
I'm trying to replicate a program I make in C++ using D. I am using the ldc2 compiler and want to *static* link in the glfw library. Following the docs I have an dub.sdl file that looks like the one below. The library I'm linking with is the vs2019 one from the GLFW zip file from their website. My program isn't work showing, it just calls glfwInit, creates a windows, and does a basic event loop. (This is a simplified test made when I couldn't get my real program to link) However I get link errors shown below. Am I doing this wrong? Am I using the wrong library to link with? (And if so which should I use). Am I missing any options etc? Or will this just not work with ldc2? Thanks for any help! My dub.sdl file looks like this :- name "game" description "Test Project" authors "Me" copyright "Copyright © 2020, Me" license "proprietary" dependency "bindbc-glfw" version="~>0.10.0" versions "BindGLFW_Static" libs "glfw3" lflags "-L..\\work\\3rdparty\\lib" And I get the following errors from the link :- lld-link: error: undefined symbol: __GSHandlerCheck lld-link: error: undefined symbol: __security_check_cookie lld-link: error: undefined symbol: __security_cookie
Re: How to get the pointer of "this" ?
On Monday, 25 May 2020 at 16:39:30 UTC, Mike Parker wrote: On Monday, 25 May 2020 at 08:39:23 UTC, John Burton wrote: I believe that in D *this* is a reference to the object and not a pointer like in C++. So I think that writing might be what you need? No. A class reference is a pointer under the hood. Getting its address will result in a pointer to the reference variable itself, not to the class instance. When passing a reference to a C API, casting it directly to the C type is correct. Ah I see. In that case I have some code I need to investigate as it's probably only working by accident!
Re: How to get the pointer of "this" ?
On Sunday, 24 May 2020 at 17:40:10 UTC, bauss wrote: On Sunday, 24 May 2020 at 17:05:16 UTC, Vinod K Chandran wrote: [...] I think your issue might be elsewhere because casting this should be fine and it should not complain about that in your given code. At least you should be able to pass this to another function or even cast it. Please show the full code and the full error which gives you the stacktrace of where it's called and from where. I believe that in D *this* is a reference to the object and not a pointer like in C++. So I think that writing might be what you need?
Is it safe in D to cast pointers to structures like this?
After years of C++ I have become paranoid about any casting of
pointers being undefined behavior due to aliasing so want to see
if :-
1) This is safe to do in D.
2) If not is there anything I can do to make it safe.
3) If not, what is the best approach?
I have a void* pointing to a block of allocated memory. In that
memory I have a header struct at the start, and some of the
members of that struct are offsets into the memory of other
structs.
Can I do this? It appears to compile and "work" in dmd 64 bit but
I need to make sure it's valid and reliable code. (This is a
minimal example without any error checking etc)
import std.stdio;
//
// getMemory is just an example to make this compile...
//
void* getMemory()
{
static byte[100] someData;
// Something fills in the data here
}
struct Header
{
ulong data1;
ulong data2;
}
struct Data1
{
int a;
}
struct Data2
{
int b;
float[10] d;
}
void main()
{
void* memory = getMemory();
auto header = cast(Header*)memory;
auto data1 = cast(Data1*)(memory + header.data1);
auto data2 = cast(Data2*)(memory + header.data2);
writeln(data1.a, " ", data2.b);
}
Re: Is there a nice syntax to achieve optional named parameters?
On Monday, 21 January 2019 at 07:57:58 UTC, Simen Kjærås wrote:
On Saturday, 19 January 2019 at 14:26:31 UTC, Zenw wrote:
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
[...]
how about this
auto With(string code,T)(T value)
{
with(value)
{
mixin(code ~";");
}
return value;
}
auto window = Window().With!q{title = "My window",width =
800,fullscreen = true};
The problem with using string mixins like that is when you want
to use some local variable:
int width = getWidth();
auto window = Window().With!q{width = width};
This would work:
struct Window {
string title;
int width;
bool fullscreen;
}
auto With(T, Args...)(T ctx, Args args) {
static foreach (i; 0..Args.length) {
mixin("ctx."~Args[i].name~" = args[i].value;");
}
return ctx;
}
struct args {
static opDispatch(string _name, T)(T value) {
struct Result {
enum name = _name;
T value;
}
return Result(value);
}
}
unittest {
auto window = Window().With(args.title = "My window",
args.width = 800, args.fullscreen = true);
assert(window.title == "My window");
assert(window.width == 800);
assert(window.fullscreen == true);
}
However, I don't see that there's all that much gain compared
to just assigning the fields the normal way.
--
Simen
Thanks everyone for your advice on this.
I'm decided to just use a parameter structure to pass in. Works
well and everyone can understand it. The question was really just
does D offer a nicer way and the answer appears to be "not
really". But the original approach isn't bad anyway.
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
struct Config
{
string title;
int width;
}
struct Window
{
this(Config config)
It likely is a bad idea for a small struct like this but if it
was much bigger would it makes sense to write this as :-
this(const ref Config config)
Which is what you might do in C++ or does D handle this
differently?
Re: Is there a nice syntax to achieve optional named parameters?
On Wednesday, 16 January 2019 at 14:59:01 UTC, Kagamin wrote:> On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote: auto window = Window(title = "My Window", width = 1000, fullscreen = true); In this particular case I would make the constructor take 3 parameters - title, width and height. Full screen is a rare functionality and shouldn't clutter the constructor, can it be set after the window is created? Well window was just an example really, my real use case is a similar object that needs a lot of configuration where mostly the default works but you might want to override, and the config is needed to create the object in the first place. For this example you are right though, and it may be that I'm overthinking the whole thing.
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
[...]
Let me throw this idea here:
struct Config
{
string title;
int width;
}
struct Window
{
this(Config config)
{
//use static foreach magic to set everything :P
}
}
auto NewWindow( alias code )()
{
mixin("Config config = {"~code~"};");
return Window(config);
}
//usage:
auto a = NewWindow!q{ title : "MainTitle" };
auto b = NewWindow!q{ title : "MainTitle", width : 800 };
auto c = NewWindow!q{ width : 1000 };
auto d = NewWindow!q{};
:)
Oh that's interesting!
Re: Is there a nice syntax to achieve optional named parameters?
On Wednesday, 16 January 2019 at 11:21:53 UTC, Dukc wrote: On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote: This is ok, but I'm not so keen on separating the creation and construction like this. Is there a better way that's not ugly? You can make the constructor a template that takes a single struct of arbitrary, and inspects (at compile time) if it has fields with certain names and types. Then, when constructing, you feed that constructor a std.typecons.Tuple with named fields. Or alternatively, use a separate builder type that makes a good struct to feed for the window constructor. The disadvantage is that you cannot link the constructor template directly for external programs. But for that, you define some sort of wrapper function that always takes all the parameters and then calls the template. Thanks, I tried out the tuple approach and it works very well. Constructing a tuple at the point of call with named fields works well, but looks a bit "ugly" to me but I might use it. I think on balance that creating a separate builder struct that I can set the fields in and pass to the "real" constructor might be the way to go though for me.
Re: Is there a nice syntax to achieve optional named parameters?
On Tuesday, 15 January 2019 at 12:15:41 UTC, rikki cattermole wrote: On 16/01/2019 1:05 AM, John Burton wrote: On Tuesday, 15 January 2019 at 11:26:50 UTC, rikki cattermole wrote: Longer term, you're better off with the builder. Thanks for your reply. But what is the builder? https://en.wikipedia.org/wiki/Builder_pattern One of the few OOP design patterns that I can agree with. Ah right, that. Thank you. Hmm that would work.
Re: Is there a nice syntax to achieve optional named parameters?
On Tuesday, 15 January 2019 at 11:26:50 UTC, rikki cattermole wrote: Longer term, you're better off with the builder. Thanks for your reply. But what is the builder? Creating windows is a very complex task that can balloon in scope. Well that was mostly just an example that I thought people could relate to more than my obscure real case :) But the principle is the same so the answer is likely too
Is there a nice syntax to achieve optional named parameters?
As an example let's say I have a type 'Window' that represents a win32 window. I'd like to be able to construct an instance of the type with some optional parameters that default to some reasonable settings and create the underlying win32 window. I'd ideally like some syntax like this :- auto window = Window(title = "My Window", width = 1000, fullscreen = true); Assume that title, width, fullscreen are optional and if not specified there are defaults to use. And that there are many other settings than just these 3 that I've chosen to just use the default here. I know that I can't do it like this is D but what is the best way to achieve this kind of thing? I can add properties and then do a specific "create" function to create the underlying win32 window once I'm done but that seems ugly. auto window = Window(); window.title = "My Window"; window.width = 1000; window.create(); This is ok, but I'm not so keen on separating the creation and construction like this. Is there a better way that's not ugly?
Re: DirectXMath alternative
On Wednesday, 5 December 2018 at 10:52:44 UTC, Guillaume Piolat wrote: On Wednesday, 5 December 2018 at 01:57:53 UTC, evilrat wrote: On Tuesday, 4 December 2018 at 20:41:54 UTC, Guillaume Piolat wrote: [...] I was using gl3n then switched to gfm math. Try gfm, IIRC it should work without much PITA because it stores matrices row-major way, so you don't have to transpose it like with OpenGL. Can't say anything about dlib though, I tried it a bit with dagon engine, but just didn't stick for long. I think you are mistaken, gfm:math also stores matrices line-major so you _have_ to transpose them. The problem with row-major is it makes matrix literals read transposed vs the math notation. I think in hlsl shader language you can declare your matrices to be either way anyway can't you? It's just the default that is this way around?
Re: DirectXMath alternative
On Wednesday, 5 December 2018 at 01:57:53 UTC, evilrat wrote: On Tuesday, 4 December 2018 at 20:41:54 UTC, Guillaume Piolat wrote: On Tuesday, 4 December 2018 at 20:33:07 UTC, John Burton wrote: What is the best alternative for D, assuming there is anything? (I want vector, matrix math for use in D3, things like inverting a matrix, getting perspective matrices etc) I can program something myself if necessary but I'd prefer notto You have the choice between the following packages: - dlib - gfm:math - gl3n I was using gl3n then switched to gfm math. Try gfm, IIRC it should work without much PITA because it stores matrices row-major way, so you don't have to transpose it like with OpenGL. Can't say anything about dlib though, I tried it a bit with dagon engine, but just didn't stick for long. These all look good, thank you. Although the first two bring in additional modules I don't want I guess I can just ignore them
DirectXMath alternative
There is a directx-d library which seems to work nicely for d3d11 but it doesn't include anything like DirectXMath.h presumably because it's all implemented as inline intrinsics and very visual c++ specific. What is the best alternative for D, assuming there is anything? (I want vector, matrix math for use in D3, things like inverting a matrix, getting perspective matrices etc) I can program something myself if necessary but I'd prefer notto
Re: DirectX bindings
On Tuesday, 30 October 2018 at 10:46:35 UTC, Mike Parker wrote: On Tuesday, 30 October 2018 at 10:30:48 UTC, John Burton wrote: I want to do some graphics using direct3d11 on windows. There are some bindings that I used once before https://github.com/evilrat666/directx-d However they are marked as [discontinued] While I'm sure they will continue to work so wouldn't worry about using this I wonder if there are any other options? https://code.dlang.org/packages/aurora-directx Thank you, I don't know why my search of the repository didn't find this. I think I was searching for direct3d perhaps :)
DirectX bindings
I want to do some graphics using direct3d11 on windows. There are some bindings that I used once before https://github.com/evilrat666/directx-d However they are marked as [discontinued] While I'm sure they will continue to work so wouldn't worry about using this I wonder if there are any other options?
When does GC run?
Is there any documentation or information about the specifics of the garbage collector? The information I have found indicates that it runs to free memory when the system runs out of memory to allocate. But will this try to use all the system memory or some other amount before trying to garbage collect? If I have a _lot_ of garbage, will it try to collect that before allocating any more system memory? Is this configurable in any way? Any information or just pointer to information that I've somehow failed to find would be appreciated.
Re: Is there an efficient byte buffer queue?
On Sunday, 14 October 2018 at 13:07:30 UTC, Heromyth wrote: On Monday, 8 October 2018 at 09:39:55 UTC, John Burton wrote: My use case is sending data to a socket. We have ported some containers from JAVA. ByteBuffer is a basic container interface and widely used in JAVA. See also: https://github.com/huntlabs/hunt/blob/master/source/hunt/container/ByteBuffer.d https://github.com/huntlabs/hunt/tree/master/examples/ContainerDemo/source Thanks for this, and everyone elses comments. This looks to be close to what I need.
Is there an efficient byte buffer queue?
My use case is sending data to a socket. One part of my program generates blocks of bytes, and the socket part tries to send them to the socket and then removes from the queue the number that got sent. I am currently using a byte[] and using concatenation and slicing to maintain the queue but this seems like it will do many unnecessary copies, allocations etc. than are needed. I would do much better to maintain a fixed size buffer and maintain read and write positions etc. I'm happy to write my own fixed sized buffer queue for this, but just wanted to ask if there was anything in the standard library that could be used to do this so I'm not reinventing it all? I don't need thread safety for this case. (I know i could probably use vibe-d to implement my whole socket sender but don't want to in this case for reasons)
Re: Can I create static c callable library?
On Tuesday, 25 September 2018 at 12:05:21 UTC, Jonathan M Davis wrote: [...] Thanks everyone. Is there any documentation anywhere that deals with calling D from C? I could find plenty the other way round. I think I'll give up on the idea though, and rewrite the whole thing in D :)
Can I create static c callable library?
I need to write a library to statically link into a c program. Can I write this library in D? Will I be able to use proper D abilities like gc? Obviously the public interface will need to be basic c callable functions... I 'main' is a c program will this work?
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that
Cross compile windows programs on linux
Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up?
Re: Garbage collected pointers?
On Thursday, 1 March 2018 at 12:20:08 UTC, Steven Schveighoffer wrote: On 3/1/18 7:05 AM, Gary Willoughby wrote: On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote: My question is how do I tell if a pointer is "garbage collected" or not? You could try `GC.addrOf()` or `GC.query()` in core.memory. I was going to say this, but then I realized, it's not that the pointer points at GC-allocated memory, but that the pointer itself is stored in a location that is scanned by the GC. That's not as easy to figure out, as you have to look at stacks, added ranges, etc. -Steve Ah it's where the pointer is stored. That makes some sense. Thanks
Garbage collected pointers?
In the language spec here :- https://dlang.org/spec/garbage.html#pointers_and_gc It refers to a distinction between pointers to garbage collected memory and pointers that are not. In particular it says that with a non garbage collected pointer you can do anything that is legal in C but with a garbage collected pointer there are a lot of undefined behaviors if you don't follow some restrictions. My question is how do I tell if a pointer is "garbage collected" or not? For example :- * Do not store magic values into pointers, other than null. So how do I tell if it's safe to do this for any individual pointer? What makes a pointer "garbage collected"?
Re: Temporary objects as function parameters or when-is-this-shit-going-to-end?
On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame wrote: If you don't want to get the great PITA, never create temporary objects in function parameters. I recently spent a whole day digging through my reference counted containers library. But nasty bug was not there, but in the compiler. Look at this: https://glot.io/snippets/eui2l8ov0r Result: Bar.this(int): 7FFD3D60CD38 fun: 7FFD3D60CD20 Bar.~this(): 7FFD3D60CD20 Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal? I don't think so. But that's not the most fun. Look at this: https://glot.io/snippets/eui2pjrwvi Result: Bar.this(int): 7FFF87DD2D31 fun: 7FFF87DD2CE0 Bar.~this(): 7FFF87DD2CE0 Bar.~this(): 7FFF87DD2D31 WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects. But if you create the structure before calling the function, then all will be well: https://glot.io/snippets/eui2vn2bu1 All this greatly angered me because there are several issues related wrong struct construction and destruction in the bugtracker. Because of these bugs my low level libraries full of strange hacks. I want to ask. How you guys are going to create a reliable RC library, if such fundamental bugs hang in the issue tracker for months and years. And instead of fixing them, you develop new minor bells and whistles. See: https://issues.dlang.org/buglist.cgi?quicksearch=destructor Since I myself can't fix such bugs (my knowledge in this area are extremely small), I have a question to Andrei Alexandrescu: Can I donate to the D Foundation and that my donations would be aimed at fixing exactly these bugs? Is this a bug? Reading the chapter "7.1.3.5 They Whys of this(this)" in my D Programming Language book it says that the compiler is free to elide the call to this(this) when it can prove that the source of the copy will not be used after the call. The explanations there make some sense to me. Is this actually working as intended? (Just not how you'd hope it works)?
Re: Assert and undefined behavior
On Thursday, 12 October 2017 at 14:22:43 UTC, Timon Gehr wrote:
On 11.10.2017 11:27, John Burton wrote:
Yes, that's what it is saying. (The other answers, that say or
try to imply that this is not true or true but not a bad thing,
are wrong.)
...
However, in practice, I think none of the current compiler
implementations actually uses assert expressions for
optimizations.
This is an example of what I mean :-
import std.stdio;
extern void control_nuclear_reactor(int[] data);
void test(int[] data)
{
if (data.length == 0) {
writeln("Not enough data!");
} else {
control_nuclear_reactor(data);
}
assert(data.length > 0);
}
So according to the spec, if data is size zero then the assert
fails and therefore the code has **undefined behavour**. What
this means in practice is that the compiler decides that it
doesn't matter what code is generated for that case as it
undefined what it is meant to do anyway, so the compiler can
"optimize" out the if condition as it only affects the case where
the language doesn't define what it's supposed to do anyway, and
compiles the code as if it was :-
void test(int[] data)
{
control_nuclear_reactor();
}
Which obviously could have very bad results if the test mattered.
Yes my program is invalid because I violated it's assumptions but
I find it very hard to argue that including the assert should
"break" the code before it.
C++ compilers can and do perform such optimizations so I was
wondering if assert in D could cause such behavior according to
the spec.
Assert and undefined behavior
The spec says this :- "As a contract, an assert represents a guarantee that the code must uphold. Any failure of this expression represents a logic error in the code that must be fixed in the source code. A program for which the assert contract is false is, by definition, invalid, and therefore has undefined behaviour." Now I worry about the words "undefined behavior" because in C++ compiler writers seem to have decided that these words mean that it's ok for the compiler to generate code to do whatever it feels like even in unconnected code and even before the undefined behavior is invoked because some subsequent code has undefined behavior. From my C++ experience this paragraph tells me that if I use "assert" to check my assumptions, and the assertion is false, then this could lead to my program failing in unpredictable ways unconnected with the actual assertion. I therefore feel like I ought to not use assert and should instead validate my assumptions with an if statement and a throw or exit or something. I feel like a failing assertion should not cause "undefined behavior" in the sense it is commonly used in C++ programming these days but should have exactly defined behavior that it will do nothing if the assert passes and throw the specified exception if it fails. Can I safely assume this despite the wording? I know this might seem like a small or pedantic point, but C++ compilers can and do use invoking undefined behavior as an excuse to do all kinds of unexpected things in generated code these days and I want to write safe code :) I feel that if D is specified in the same way then assert is not safe for me to use in a real program.
Is this defined behaviour in D?
If I have a int* pointer for example, that points to the start of an int array and step through the array until I get the value 123, is it defined in D what happens if you step off the end of the array? What I might expect to happen is for the code to just keep stepping through sequential memory locations until it finds one that happens to have a 123 in it, until it gets a memory protection fault of some kind, or failing that wrap around memory and go into an infinite loop. The options are really 1) I can rely on the compiler consistently doing what I'd "expect" on a specific platform. 2) There is some other defined behaviour 3) The compiler can do whatever crazy thing it feels like as this is considered broken code. I'm not for a moment suggesting this is a good idea, but what I'm really asking is does the D language say anything about this? C++ seems to have chosen (3). Personally I'd prefer (1) but it's most to know if the "standard" such as it is has anything to say on such matters.
Re: Is there any threadsafe queue?
On Wednesday, 13 September 2017 at 09:49:46 UTC, Jonathan M Davis wrote: On Wednesday, September 13, 2017 07:51:19 John Burton via Digitalmars-d- learn wrote: [...] You could probably do what you want with std.concurrency, since most of what it does is deal with sending and receiving data across threads, and that should be queuing up messages as part of what it does. But if you're looking for a data structure that you can mark as shared and have it handle all of the locking for you so that it will work safely across threads, then no, the standard library does not currently have anything like that. It's rather lacking in containers in general at this point, let alone ones designed with concurrency in mind. There may be something on code.dlang.org, but I don't know. Regardless, I'd suggest that you first try and see if you can get std.concurrency to work for your use case rather than jumping into implementing any containers yourself. Thanks, I took a better look. I was wanting to port some c++ code which is why I was looking for this. Actually it looks like "send" and "receive" functions from this package do exactly what I need (and are in fact exactly a thread safe queue...) :)
Is there any threadsafe queue?
Is there any threadsafe queue in the standard library? I've not been able to find anything but thought I'd check before making my own. I want to be able to assemble messages (Which are just streams of bytes) in one thread into a struct and push them to the queue, and then have a another thread be able to read and process the messages. Single producer and consumer.
Re: Address of data that is static, be it shared or tls or __gshared or immutable on o/s
On Sunday, 10 September 2017 at 21:38:03 UTC, Cecil Ward wrote:
On Wednesday, 6 September 2017 at 15:55:35 UTC, Ali Çehreli
wrote:
[...]
Ali, I have worked on operating systems' development in r+d. My
definitions of terms are hopefully the same as yours. If we
refer to two threads, if they both belong to the same process,
then they share a common address space, by my definition of the
terms 'thread' and 'process'. I use thread to mean basically a
stack, plus register set, a cpu execution context, but has
nothing to do with virtual memory spaces or o/s ownership of
resources, the one exception being a tls space, which by
definition is one-per-thread. A process is one or more threads
plus an address space and a set of all the resources owned by
the process according to the o/s. I'm just saying this so you
know how I'm used to approving this.
[...]
I wrote this program :-
import std.stdio;
import std.concurrency;
int data;
void display()
{
writeln("Address is ", );
}
void main()
{
auto tid1 = spawn();
auto tid2 = spawn();
auto tid3 = spawn();
}
It displayed :-
Address is 51AD20
Address is 51AD20
Address is 51F6D0
Address is 521AC0
This indicated to me that a thread local variable does in fact
have a different address to other thread's instances of the same
thread so you can in fact pass the address to another thread and
access it from there via pointer, which is what I'd hope.
Interesting it also (sometimes) prints one of the lines twice
quite often.
I wonder if this is the same "bug" as
https://issues.dlang.org/show_bug.cgi?id=17797 that doesnt even
require any reading? (platform is windows 7 DMD32 D Compiler
v2.076.0)
Understanding gc memory profile report
I wrote this simple program to test out my understanding of
memory allocation :-
import std.stdio;
void main()
{
int [] array = new int[250];
writeln(array.length, " elements ", array);
// Append one value to the array
array ~= 123;
writeln(array.length, " elements ", array);
}
I compiled it with 'dmd test.d -profile=gc'
After running it, the profile report was :-
bytes allocated, allocations, type, function, file:line
2000 1 int[] D main test.d:5
4 1 int[] D main test.d:10
This is not how I expected it to be. I would have expected that
the runtime either did not have to allocate at all at line 10 to
add a new element because there was already space or it would
have to allocate space for the new enlarged array and copy the
array to it, in which case I'd expect it to allocate 2004 bytes
(or more) to copy the enlarged array in to.
I would not expect that it could have allocated 4 bytes to add an
item separably from the original 2000. Is there some way that the
runtime can grown the original allocation by 4 bytes and that's
what I'm seeing? If so, is there a limit to how much it can do
this?
Can anyone help me understand what is going on here?
Re: writeln() sometimes double prints from main() if I run a thread checking for input?
On Thursday, 31 August 2017 at 21:06:17 UTC, Ivan Kazmenko wrote: On Thursday, 31 August 2017 at 14:43:39 UTC, Steven Schveighoffer wrote: Just a thought, but the "double printing" could be a misunderstanding. It could be printing Output\nOutput2, but not getting the 2 out there. Just to say that I can reproduce this on my system. Newly downloaded copy of v2.076.0 Window 7 "enterprise" 64 bit. Standard cmd.com command shell. I get Output2 duplicated most of the time. Occasionally I get Output duplicated. Occasionally Output2 is out of order...
Re: fromStringz for wide characters
On Tuesday, 5 September 2017 at 08:39:37 UTC, Jonathan M Davis wrote: On Tuesday, September 05, 2017 08:15:04 John Burton via Digitalmars-d-learn wrote: std.string.fromStringz will create me a string from a null terminated array of characters. But I have a zero terminated array of "short"s (from a win32 api call) which I'd like to turn into a wstring. But there doesn't seem to be a function to do this. Do I need to write my own, or am I missing something? I'm fairly certain that to!wstring will do it, but it will definitely allocate, whereas fromStringz just slices what it's given. I don't think that there's currently a wchar equivalent to fromStringz, but it would be pretty trivial to write if you didn't want to use to!wstring. fromStringz is just return cString ? cString[0 .. strlen(cString)] : null; and all you'd have to do would be to replace strlen with wcslen from core.stdc.wchar_. There's a decent chance that you'll want to allocate the string though, in which case to!wstring would be the right choice. Thank you. I wanted something that didn't allocate in this case. The underlying storage will be kept for other reasons so I might as well have a string that just refers to the data contained in it. I had done something like you suggested, but wondered if I'd missed something given the existence of a function for byte strings.
fromStringz for wide characters
std.string.fromStringz will create me a string from a null terminated array of characters. But I have a zero terminated array of "short"s (from a win32 api call) which I'd like to turn into a wstring. But there doesn't seem to be a function to do this. Do I need to write my own, or am I missing something?
Re: Append to dynamic array that was allocated via calloc
On Tuesday, 25 July 2017 at 13:24:36 UTC, Mike Parker wrote:
On Tuesday, 25 July 2017 at 12:40:13 UTC, John Burton wrote:
[...]
This should give you the answer:
writefln("Before: ptr = %s capacity = %s", slice.ptr,
slice.capacity);
slice ~= 1;
writefln("After: ptr = %s capacity = %s", slice.ptr,
slice.capacity);
It shows that before the append, the capacity is 0. That
indicates that any append will cause a new allocation -- from
the GC. The next writefln verifies this by showing a different
value for ptr and a new capacity of 15.
In order for this to work, you'll need to manually manage the
length and track the capacity yourself. If all you want is to
allocate space for 10 ints, but not 10 actual ints, then
something like this:
size_t capacity = 10;
int* ints = cast(int*)malloc(int.sizeof * capacity);
int[] slice = ints[0 .. 10];
slice.length = 0;
slice ~= 1;
--capacity;
Then reallocate the array when capacity reaches 0. Or just use
std.container.array.Array which does all this for you.
Ok so it sounds like this is "safe" in that it will copy my data
into GC memory and all work safely. I'll need to somehow keep
track of my original memory and free it to avoid a memory leak...
(I don't plan to do any of this, but I wanted to understand)(
Append to dynamic array that was allocated via calloc
I can create a "slice" using non-gc allocated memory. int* ptr = cast(int*)calloc(int.sizeof, 10); int[] data = ptr[0..10]; If I don't want a memory leak I have to call free(ptr) somewhere as it won't be GC collected when data or ptr go out of scope. I presume there is nothing wrong with doing the above, other than perhaps there being better ways (and the memory leak if not free'd) If I then write this :- data ~= 1; What happens? It seems to successfully append an extra value to the array. It appears to "work" when I try it in my compiler but I don't understand how. Will this be trying to write beyond the memory I calloc'ed?
Re: C style 'static' functions
On Wednesday, 19 July 2017 at 12:15:05 UTC, Mike Parker wrote: On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote: On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote: Try a newer compiler, this was fixed recently. Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated. Sorry for wasting everyones' time if that's so, and thanks for the help. Ah, great! Looks like it's https://wiki.dlang.org/DIP22 that changed this
Re: C style 'static' functions
On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote: Try a newer compiler, this was fixed recently. Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated. Sorry for wasting everyones' time if that's so, and thanks for the help.
Re: C style 'static' functions
On Wednesday, 19 July 2017 at 11:31:32 UTC, Jacob Carlborg wrote:
On 2017-07-19 09:22, John Burton wrote:
In C I can declare a function 'static' and it's only visible
from within that implementation file. So I can have a static
function 'test' in code1.c and another non static function
'test' in utils.c and assuming a suitable prototype I can use
'test' in my program and the one in code1.c will not interfere.
In D it seems that declaring functions as static in a module
does not affect visibility outside of a module. So if I
declare a static function in one module with a specific name
that is just used in internally for the implementation, and
then define a function with the same name in another module
that is intended to by 'exported' then in my main program they
still conflict and I have to take steps to avoid this.
It looked as if I could use 'private' instead of static but
although this prevents me from calling the "private" function,
it still conflicts with the one I want to call.
In C++ I could use static or an anonymous namespace for
implementation functions, but there doesn't seem to be
anything similar in D.
Is there any way to achieve what I want in D (Private
implementation functions)
I think it would be easier if you provide a small code example
of what you want to achieve.
Here is an artificial example of what I mean. The point is that I
can break main.d from compiling by adding what is meant to be a
purely internal implementation detail inside of lib1. - In C I
can make internal functions static to avoid this... Im D, none of
static, package, private etc seem to do this. They prevent it
from being called but don't hide the existence of the function
from the module importing it.
If there is no way to achieve this it's not a big problem, I'm
just curious now :)
lib1.d
private void init()
{
// init function used only as an implementation detail
}
void mything()
{
init();
}
lib2.d -
void init()
{
// init function meant to be used as part of the module
interface
}
main.d
import lib1;
import lib2;
void main()
{
init(); // This is meant to call lib2.init because it's the
only
// function of that name. lib1.init() is supposed to
be
// an entirely internal implementation detail of lib1
// Even though I can't call lib1.init() because it's
private
// this call still shows up as ambigous.
//
// In C I'd write "static void init()" in lib1.d to
indicate
// that the function was entirely local to that
file. However static
// does not appear to have that same effect in D
}
Re: C style 'static' functions
On Wednesday, 19 July 2017 at 07:51:11 UTC, Gary Willoughby wrote: On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote: In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D. Is there any way to achieve what I want in D (Private implementation functions) Try the package keyword: https://dlang.org/spec/attribute.html#visibility_attributes This appears to still have the same issue. I can't use the "package" function in the main program but it still conflicts with the one I can use from a different module. Unless I'm doing it wrong...
C style 'static' functions
In C I can declare a function 'static' and it's only visible from within that implementation file. So I can have a static function 'test' in code1.c and another non static function 'test' in utils.c and assuming a suitable prototype I can use 'test' in my program and the one in code1.c will not interfere. In D it seems that declaring functions as static in a module does not affect visibility outside of a module. So if I declare a static function in one module with a specific name that is just used in internally for the implementation, and then define a function with the same name in another module that is intended to by 'exported' then in my main program they still conflict and I have to take steps to avoid this. It looked as if I could use 'private' instead of static but although this prevents me from calling the "private" function, it still conflicts with the one I want to call. In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D. Is there any way to achieve what I want in D (Private implementation functions)
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote: I'm coming from a C++ background so I'm not too used to garbage collection and it's implications. I have a function that creates a std.socket.Socket using new and connects to a tcp server, and writes some stuff to it. I then explicitly close the socket, and the socket object goes out of scope. Am I doing this right? Or is there a better way to do this in D? Thanks. For my use case here, I'm increasingly thinking that just calling the underlying 'C' socket and send calls is better. No need for anything complicated at all for my actual program :)
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis wrote: On Tuesday, June 27, 2017 09:54:19 John Burton via Digitalmars-d-learn wrote: I'm coming from a C++ background so I'm not too used to garbage collection and it's implications. I have a function that creates a std.socket.Socket using new and connects to a tcp server, and writes some stuff to it. I then explicitly close the socket, and the socket object goes out of scope. Thank you for the advice everyone. The hardest part about learning D isn't the language, or how to program, it's unlearning what you know from C++ and learning the proper way to do things in D. I've tried D several times before and eventually stopped when I get to the stage of "how do I do this c++ thing in d" proves to be hard. Instead this time, I've started writing D programs as "better C" and then slowly started adding in higher level d features. It's going much better as I'm no longer trying so hard to write bad C++ in D :)
Advice wanted on garbage collection of sockets for c++ programmer using D
I'm coming from a C++ background so I'm not too used to garbage collection and it's implications. I have a function that creates a std.socket.Socket using new and connects to a tcp server, and writes some stuff to it. I then explicitly close the socket, and the socket object goes out of scope. I assume that I do need to explicitly call close on the socket as there is no deterministic destructor for class objects. I further assume that the runtime will garbage collect any memory allocated to the socket object at a later time. Am I doing this right with GC? In C++ I'd ensure that the Socket class had a destructor that closed the socket and I'd also assume that once it went out of scope there was no memory left allocated. In D am I right to assume I need to manually close the socket but there is no need to worry about the memory? Now the issue is that I now need to call this function more than once every second. I worry that it will create large amounts of uncollected "garbage" which will eventually lead to problems. Am I doing this right? Or is there a better way to do this in D? Thanks.
Arrays of structs
I'm a c++ programmer trying to understand how memory allocation works in D. I created a struct and added a destructor to it. My understanding is that structs have deterministic destructors - they are called when the struct goes out of scope (unless it is allocated with new). Now if I put instances of the struct in a fixed size array data[6] d; d[3] = data(1, 2, 3); then the destructor on all the contents is called when the array goes out of scope. However if I add them to a dynamic array... data[] d; d ~= data(1, 2, 3) Then the destructor appears to be called at some random time later. So it looks like it's the garbage collection that is doing this. That seems to go against the specification of how struct works... I'm not creating the item with new and as far as I can tell the array is storing instances of objects, not pointers to objects? Is my understanding correct? Is it documented anywhere how memory allocation works for this? Is a dynamic array in fact storing an array of GC'd pointers to the structs? Or something else...
Re: Arrays of structs
Ok that's great thank you. It's quite hard trying to get a proper understanding of memory allocation in D after years of C++ / RAII / unique_ptr / shared_ptr . I understand the details of course but it's going to take a while to really know it. Is there any way to explicitly free a dynamic array when I am done with it? (I'm more interested in the contained items destructors being called than in the memory / gc aspects) I fear I'm trying to write C++ in D and need to get my mind around different ways to do things...
Re: Arrays of structs
Thanks again for the updates. I've experimented some more and believe I understand. To be honest I'm finding it very hard to find the right idioms in D for safe and efficient programming when I'm so used to C++ / RAII everywhere. I'll adapt though :P
Re: Casting pointers
Ok thank you. Seems to me that there is enough doubt that this is supported that I'd be best to avoid relying on it, or at least ensure that it's all encapsulated in something I can easily change.
Casting pointers
This would be undefined behavior in c++ due to aliasing rules on
pointers. It appears to work reliably in D when I try it, but
that's obviously no guarantee that it's correct or will continue
to do so.
Is this correct code in D? And if not, what should I do instead
to cleanly and efficiently extract structured data from a
sequence of bytes?
import std.stdio;
struct data
{
int a;
int b;
}
void main()
{
byte[] x = [1, 2, 3, 4, 5, 6, 7, 8];
data* ptr = cast(data*)(x);
printf(%x %x\n, ptr.a, ptr.b);
}
