On 10/15/2014 09:35 PM, MachineCode wrote:
Is there one function in the Phobos library to check if give an array is
equal to first elements in another array? e.g, f(a, b) the entire b
array must match to first elements in a and then return true otherwise
false, ie:
a[0 .. b.length] == b
proba
On Thursday, 16 October 2014 at 04:35:13 UTC, MachineCode wrote:
Is there one function in the Phobos library to check if give an
array is equal to first elements in another array?
auto n = min(a.length, b.length);
if (a[0..n] == b[0..n]) ...
Is there one function in the Phobos library to check if give an
array is equal to first elements in another array? e.g, f(a, b)
the entire b array must match to first elements in a and then
return true otherwise false, ie:
a[0 .. b.length] == b
probably there's no such a function (but I wou
Since I've added this call, my program will sometimes but not
always either generate a core dump or a seg fault. It seems that
the issue is with the const char * parameter.
I don't have a good grasp of the difference between the way D and
C work for char * types. The call to loadTexture uses a
On 2014-10-15 19:47, Etienne Cimon wrote:
The D syntax for inline assembly is Intel style, whereas the GCC syntax
is AT&T style. This guide seems to show exactly how to translate from
C++ to D.
I'm posting this research for anyone searching the forums for a solution.
I found a better guide to
Even better would be if phobos provided it out of the box:
---
import std.stdio;
import std.algorithm;
import std.array;
import std.string;
import std.conv;
void stripStringArrayInPlace(T)(T[] ar){for(long i=0,
len=ar.length; i < len; ++i) ar[i] = ar[i].strip;}
T[] stripStringArray
Thanks so much it's a bit more bloated than I was expecting but
it works.
---
void main() {
import std.stdio;
import std.algorithm;
import std.array;
import std.string;
import std.conv;
auto ar = [" dad ", " blue "];
ar.writeln;
auto arStriped = ar.map!strip.a
On 10/15/2014 04:26 PM, Domingo wrote:
Ideally I want to use something like this:
import std.stdio;
import std.string;
import std.algorithm;
import std.conv;
void main()
{
string[] ar = [" dad ", " blue "];
writeln(typeid(ar));
// a) foreach for purely side-effect expressions:
Domingo:
Ideally I want to use something like this:
-
import std.stdio;
import std.string;
import std.algorithm;
import std.conv;
void main()
{
string[] ar = [" dad ", " blue "];
writeln(typeid(ar));
//ar.each(writeln);
//ar.map!writeln;
On 2014-10-15 09:48, Etienne wrote:
I currently only need to translate these commented statements. If anyone
I found the most useful information here in case anyone is wondering:
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
The D syntax for inline assembly is Intel style, w
On Wednesday, October 15, 2014 12:11:22 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 10/15/14 4:59 AM, Rei Roldan wrote:
> > I don't see how passing all required files to the compiler could
> > possible raise an issue with module discoverability. Unless I'm missing
> > something? In re
Ideally I want to use something like this:
-
import std.stdio;
import std.string;
import std.algorithm;
import std.conv;
void main()
{
string[] ar = [" dad ", " blue "];
writeln(typeid(ar));
//ar.each(writeln);
//ar.map!writeln;
//ar.apply!
On Wednesday 15 October 2014 22:13, John Colvin wrote:
> On Wednesday, 15 October 2014 at 19:29:27 UTC, Jack Applegame
> wrote:
>> I don't understand why this code doesn't compile:
>>
>> http://dpaste.dzfl.pl/dfd8df7f80ad
>
> that should be immutable(ubyte)[] not immutable ubyte[] which is
> equi
On Wednesday 15 October 2014 21:29, Jack Applegame wrote:
> I don't understand why this code doesn't compile:
>
> http://dpaste.dzfl.pl/dfd8df7f80ad
Immutability issues with unions ring a bell for me. This may be related to
issue 12885 [1] which is the result of dmd pull #2665 [2] which even
m
On Tuesday, 14 October 2014 at 16:08:31 UTC, Robert burner
Schadek wrote:
On Tuesday, 14 October 2014 at 12:51:29 UTC, Nordlöw wrote:
Could you please give me a code example? I'm not skilled
enough in D to follow this description.
struct Range(T) {
Array!S array;
T opIndex(size_t i) {
On Wednesday, 15 October 2014 at 08:23:29 UTC, Marc Schütz wrote:
Someone else already reported the same problem. I'll add a link
to your post.
Where, I didn't found any Bugzilla issue, so I opened one.
https://issues.dlang.org/show_bug.cgi?id=13621
On Wednesday, 15 October 2014 at 19:29:27 UTC, Jack Applegame
wrote:
I don't understand why this code doesn't compile:
http://dpaste.dzfl.pl/dfd8df7f80ad
that should be immutable(ubyte)[] not immutable ubyte[] which is
equivalent to immutable(ubyte[]). You can't overwrite immutable
data, hen
I don't understand why this code doesn't compile:
http://dpaste.dzfl.pl/dfd8df7f80ad
On 10/15/2014 09:48 AM, Laeeth Isharc wrote:
> struct RetStruct
> {
> double[] a;
> double[] b;
> }
>
> RetStruct myfunction(double x)
That's my preference. Tuples would work as well but they have two minor
issues for me:
- Unlike a struct, the members are anonymous. (Yes, tuples me
On Wednesday, 15 October 2014 at 16:48:24 UTC, Laeeth Isharc
wrote:
Hi.
I have to write a bunch of functions that operate on input
arrays to return multiple output arrays.
In case helpful the inputs are price bars or economic data
points (datetime, ohlc) and the outputs are nx1 arrays (I won
Here is byref:
import std.typecons;
import std.stdio;
void myfunction(double x, ref double[] a, ref double[] b)
{
a~=x+1.0;
a~=x+9.0;
b~=x+2.0;
b~=x+11.0;
return;
}
void main()
{
double[] a;
double[] b;
myfunction(99.0,a,b);
Hi.
I have to write a bunch of functions that operate on input arrays
to return multiple output arrays.
In case helpful the inputs are price bars or economic data points
(datetime, ohlc) and the outputs are nx1 arrays (I won't say
vectors) of doubles or structs.
What is the best way to ret
On 10/15/14 4:59 AM, Rei Roldan wrote:
I don't see how passing all required files to the compiler could
possible raise an issue with module discoverability. Unless I'm missing
something? In regards to pains if "folder|file names / package|module
names" don't match, imho, physical organization of
I'm translating some library from C++ and I'd need some help with
assembler translations. I've read the guides on D inline assembler but
it's fairly thin. I don't understand what "=r", "=a", "%0", "%1" should
be in D. Is this some sort of register?
https://github.com/etcimon/botan/blob/master/
I don't see how passing all required files to the compiler could
possible raise an issue with module discoverability. Unless I'm
missing something? In regards to pains if "folder|file names /
package|module names" don't match, imho, physical organization of
files should never (ever) be of any c
On Wednesday, 15 October 2014 at 04:36:27 UTC, Domingo Alvarez
Duarte wrote:
With dmd trunk trying to compile vibed after fixing several
array declarations from C style to D style I'm getting this
error that I do not understand:
---
Building vibe-d 0.7.21-rc.2 configuration "libevent",
26 matches
Mail list logo