Re: is char[] faster than string?

2017-04-05 Thread H. S. Teoh via Digitalmars-d-learn
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?

2017-04-05 Thread Adam D. Ruppe via Digitalmars-d-learn

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?

2017-04-05 Thread Inquie via Digitalmars-d-learn
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

2017-04-05 Thread timvol via Digitalmars-d-learn

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

2017-04-05 Thread Inquie via Digitalmars-d-learn

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

2017-04-05 Thread Nicholas Wilson via Digitalmars-d-learn

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

2017-04-05 Thread evilrat via Digitalmars-d-learn

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

2017-04-05 Thread Nicholas Wilson via Digitalmars-d-learn

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

2017-04-05 Thread harfel via Digitalmars-d-learn

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

2017-04-05 Thread biocyberman via Digitalmars-d-learn

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

2017-04-05 Thread evilrat via Digitalmars-d-learn

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

2017-04-05 Thread Satoshi via Digitalmars-d-learn

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

2017-04-05 Thread Nicholas Wilson via Digitalmars-d-learn

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

2017-04-05 Thread harfel via Digitalmars-d-learn

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!