Re: is char[] faster than string?
On Wed, Apr 05, 2017 at 09:58:16PM +, Inquie via Digitalmars-d-learn wrote: > I have a lot of string concatenation to do and I'm wondering if char[] > is faster? Does it simply extend the buffer or are new buffers created > every time? > > What I am looking for is something like StringBuilder in C#. If you are doing lots of concatenation and produce a single big string at the end, take a look at std.array.appender. Though if you're concerned about performance, you really should run a profiler. Last I heard, appender may not be that much faster than using ~=, but I could be wrong. But when it comes to optimization, my advice is, profile, profile, profile. I came from a C/C++ background and used to have all sorts of zany ideas about optimization, but eventually I learned that 95% of the time my efforts were wasted because the real bottleneck was somewhere else, usually in an unexpected place (that only made sense in retrospect). Always use a profiler before making decisions on optimizations. It will save you from a lot of headaches and unwarranted optimizations that tend to make your code needlessly convoluted. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
Re: is char[] faster than string?
On Wednesday, 5 April 2017 at 21:58:16 UTC, Inquie wrote: I have a lot of string concatenation to do and I'm wondering if char[] is faster? No, they are the same. Does it simply extend the buffer or are new buffers created every time? Both will extend the buffer when the runtime can guarantee it is allowed to, which it quite often can. Details here: http://dlang.org/d-array-article.html I recommend just trying it with ~= (avoid a ~ b though, a ~= b is better when possible) and see how it performs before getting too worried about it, the built in really isn't bad.
is char[] faster than string?
I have a lot of string concatenation to do and I'm wondering if char[] is faster? Does it simply extend the buffer or are new buffers created every time? What I am looking for is something like StringBuilder in C#.
Re: cmake-d and gdc/gdmd compiler
On Tuesday, 4 April 2017 at 19:59:19 UTC, Dragos Carp wrote: On Tuesday, 4 April 2017 at 18:42:45 UTC, timvol wrote: Hi guys, I'm trying to cross-compile a project using CMake and gdc (or better: the gdmd port). My CMakeLists-file is the following: For cross-compiling, CMake uses a so called "toolchain" file [1] where you define the system paths similar to the target system. I confess that never cross-compiled any code with cmake-d, but in principle it should work. Dragos [1] https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-linux Alright. Thank you Dragos. I thought it's possible without using a toolchain file but I'll give it a try :)
Re: Single exe vibe.d app
On Wednesday, 5 April 2017 at 12:42:23 UTC, evilrat wrote: On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote: Hi, How can I build single exe application with vibe.d (windows)? now it require zlib.dll, libeay32.dll and ssleay32.dll But I need it as single app. btw, if all you need is to ship it as a single file and don't care if it writes anything, you can probably compile-in those .dll's to your .exe as string with D import statement and write them on disk from static module ctor (static shared this{} at module scope) when it launched. Why is the writing to disk necessary? Seems like a costly step for no real benefit. The dll gets read in to memory anyways. https://github.com/fancycode/MemoryModule
Re: Single exe vibe.d app
On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote: Hi, How can I build single exe application with vibe.d (windows)? now it require zlib.dll, libeay32.dll and ssleay32.dll But I need it as single app. As Evilrat notes static libraries are one solution, the catch being you need to get them as static libraries. zlib you should easily be able to get as a static lib (making sure you use a compatible linker/ linker format. If for the other libraries that is not possible one approach is described on the d idioms list: http://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable The static library solution is probably the superior choice if available.
Re: Single exe vibe.d app
On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote: Hi, How can I build single exe application with vibe.d (windows)? now it require zlib.dll, libeay32.dll and ssleay32.dll But I need it as single app. btw, if all you need is to ship it as a single file and don't care if it writes anything, you can probably compile-in those .dll's to your .exe as string with D import statement and write them on disk from static module ctor (static shared this{} at module scope) when it launched.
Re: Covert a complex C header to D
On Wednesday, 5 April 2017 at 12:27:23 UTC, biocyberman wrote: On Monday, 3 April 2017 at 23:10:49 UTC, Stefan Koch wrote: On Monday, 3 April 2017 at 11:18:21 UTC, Nicholas Wilson wrote: prefer template over string mixins where possible. This will make the code much more readable. My advise would be the opposite. templates put much more pressure on the compiler then string-mixins do. Also the code that templates expand to is hard to get. Whereas the code that string mixins expand to can always be printed one way or another. Could you elaborate more about this (i.e. show where mixins is more readable, debugable and less stressful to the compiler) ? This kind of information is good for tuning stage later. My goal now is to finish the conversion and running of the header and the test code (https://github.com/attractivechaos/klib/blob/master/test/khash_test.c). @Ali: I noticed the -E option recently but haven't really used it. I now generated the pre-processed source and try to make use of it. While Stefan correctly notes that templates are slower than string mixins I generally find templates easier to read. In terms of debugability: you can pragma(msg, myGeneratedString) to see the generated code; the error messages you get from templates are slightly more difficult to read than normal error messages in that you have to figure out what the significance of a particular parameter is (is it missing a method or operator? is it a struct instead of a class?), properly constraining the templates helps with this although the compiler is usually pretty good.
Re: pyd: implementing __hash__ and __str__ for PyD wrapped classes
On Wednesday, 5 April 2017 at 11:39:47 UTC, Nicholas Wilson wrote: On Wednesday, 5 April 2017 at 09:31:09 UTC, harfel wrote: Dear all, [...] Following the documentation and code examples, I got the basic functionality working. However, I am struggling with implementing the magic functions __str__ and __hash__ of the extension class. >> Is there a way to declare these slots in PyD? I noticed that Repr does this for __repr__ and the operator overloads do this of course for their respective slots, but I could not find anything for __hash__ and __str__. [...] I haven't chased the source but most likely __hash__ and __str__ will be "magically" generated from toHash() and toString() respectively (both methods of Object, see:https://dlang.org/phobos/object.html#.Object). Unfortunately, this does not seem to be the case, as my D classes do override toHash and toString, but they are not called by the corresponding python classes.
Re: Covert a complex C header to D
On Monday, 3 April 2017 at 23:10:49 UTC, Stefan Koch wrote: On Monday, 3 April 2017 at 11:18:21 UTC, Nicholas Wilson wrote: prefer template over string mixins where possible. This will make the code much more readable. My advise would be the opposite. templates put much more pressure on the compiler then string-mixins do. Also the code that templates expand to is hard to get. Whereas the code that string mixins expand to can always be printed one way or another. Could you elaborate more about this (i.e. show where mixins is more readable, debugable and less stressful to the compiler) ? This kind of information is good for tuning stage later. My goal now is to finish the conversion and running of the header and the test code (https://github.com/attractivechaos/klib/blob/master/test/khash_test.c). @Ali: I noticed the -E option recently but haven't really used it. I now generated the pre-processed source and try to make use of it.
Re: Single exe vibe.d app
On Wednesday, 5 April 2017 at 12:13:38 UTC, Satoshi wrote: Hi, How can I build single exe application with vibe.d (windows)? now it require zlib.dll, libeay32.dll and ssleay32.dll But I need it as single app. you have to build those as static libraries first, compile vibe.d with that static libs provided to linker(you are most likely will be forced to x64 or m32mscoff depending on compilers used) and that *should* be enough. but there may arise some non obviuos issues such as licensing(some licenses prohibits even linking with some other licenced code) or linking issues, or full disability to do so if dynamic loading is used, or whatever i forgot to remember. sorry if it lacks details. thats just whole process in common.
Single exe vibe.d app
Hi, How can I build single exe application with vibe.d (windows)? now it require zlib.dll, libeay32.dll and ssleay32.dll But I need it as single app.
Re: pyd: implementing __hash__ and __str__ for PyD wrapped classes
On Wednesday, 5 April 2017 at 09:31:09 UTC, harfel wrote: Dear all, Relatively new to D in general and PyD in particular, I am trying to wrap some D classes I wrote for use in Python. Following the documentation and code examples, I got the basic functionality working. However, I am struggling with implementing the magic functions __str__ and __hash__ of the extension class. My current approach was to implement them as ordinary member functions: extern(C) void PydMain() { module_init(); // Reaction wrap_class!(PyReaction, PyName!"Reaction", Init!(MultiSet, MultiSet), Property!(PyReaction.reactants), Property!(PyReaction.products), Repr!(PyReaction.repr), Def!(PyReaction.py_str, PyName!"__str__"), // XXX needs slot Def!(PyReaction.py_hash, PyName!"__hash__"), // XXX needs slot )(); } but this does not work. In Python: Python 2.7.12+ (default, Sep 17 2016, 12:08:02) [GCC 6.2.0 20160914] on linux2 Type "help", "copyright", "credits" or "license" for more information. from teest_module import * r=Reaction({'a':1, 'b':1}, {'ab':1}) r.__hash__ 0x7fc1c7f4a080> r.__hash__() 1430289695L hash(r) 8779391257096 According to related post for C++/SWIG (http://stackoverflow.com/questions/25199233/str-not-called-when-printing-c-class-wrapped-for-python-with-swig), the reason is that these magic methods need to be implemented as slots, rather than ordinary member functions. Is there a way to declare these slots in PyD? I noticed that Repr does this for __repr__ and the operator overloads do this of course for their respective slots, but I could not find anything for __hash__ and __str__. Any ideas? Thanks! I haven't chased the source but most likely __hash__ and __str__ will be "magically" generated from toHash() and toString() respectively (both methods of Object, see:https://dlang.org/phobos/object.html#.Object).
pyd: implementing __hash__ and __str__ for PyD wrapped classes
Dear all, Relatively new to D in general and PyD in particular, I am trying to wrap some D classes I wrote for use in Python. Following the documentation and code examples, I got the basic functionality working. However, I am struggling with implementing the magic functions __str__ and __hash__ of the extension class. My current approach was to implement them as ordinary member functions: extern(C) void PydMain() { module_init(); // Reaction wrap_class!(PyReaction, PyName!"Reaction", Init!(MultiSet, MultiSet), Property!(PyReaction.reactants), Property!(PyReaction.products), Repr!(PyReaction.repr), Def!(PyReaction.py_str, PyName!"__str__"), // XXX needs slot Def!(PyReaction.py_hash, PyName!"__hash__"), // XXX needs slot )(); } but this does not work. In Python: Python 2.7.12+ (default, Sep 17 2016, 12:08:02) [GCC 6.2.0 20160914] on linux2 Type "help", "copyright", "credits" or "license" for more information. from teest_module import * r=Reaction({'a':1, 'b':1}, {'ab':1}) r.__hash__ 0x7fc1c7f4a080> r.__hash__() 1430289695L hash(r) 8779391257096 According to related post for C++/SWIG (http://stackoverflow.com/questions/25199233/str-not-called-when-printing-c-class-wrapped-for-python-with-swig), the reason is that these magic methods need to be implemented as slots, rather than ordinary member functions. Is there a way to declare these slots in PyD? I noticed that Repr does this for __repr__ and the operator overloads do this of course for their respective slots, but I could not find anything for __hash__ and __str__. Any ideas? Thanks!