On Monday, 16 November 2015 at 22:39:17 UTC, Dan wrote:
I have been lurking on this site over the past few weeks trying
to decide when (and if) to make the transition. Can anyone here
who has already made that transition tell me how smoothly it
went? Any major unexpected problems? Advice?
On Tuesday, 17 November 2015 at 02:40:14 UTC, Domain wrote:
How to use readText to read utf16 file? Or other encoding file.
Here's a helpful resource when working with text files in D.
http://nomad.so/2015/09/working-with-files-in-the-d-programming-language/
On Tuesday, 17 November 2015 at 11:58:22 UTC, Chris wrote:
Sorry that should be:
@property void popFront()
{
r = r[1..$];
cnt++;
}
On Tuesday, 17 November 2015 at 12:41:45 UTC, Chris wrote:
On Tuesday, 17 November 2015 at 12:22:22 UTC, Marc Schütz wrote:
In any case, I'd suggest you fix your opIndex(), except if
there's a really good reason it is as it is.
I see. Thanks for the explanation. What would be the easiest
fix
On Tuesday, 17 November 2015 at 00:33:44 UTC, Chris Wright wrote:
This might change, but that's a gamble, and not one I'd take.
For projects where you need specific libraries to exist
already, D probably won't serve your needs. (It's definitely
easier with C++ interop, but you'd still have to
I've checked several options now and it doesn't work.
Here (http://dlang.org/statement.html#foreach-with-ranges) it is
stated that it suffices to have range primitives, if opApply
doesn't exist. My code worked up to 2.068.0, with the
introduction of 2.068.1 it failed. I wonder why that is.
On Monday, 16 November 2015 at 18:18:51 UTC, Chris wrote:
On Monday, 16 November 2015 at 17:57:53 UTC, opla wrote:
On Monday, 16 November 2015 at 16:55:29 UTC, Chris wrote:
On Monday, 16 November 2015 at 16:49:19 UTC, Marc Schütz
wrote:
On Monday, 16 November 2015 at 16:44:27 UTC, Chris
On Tuesday, 17 November 2015 at 11:58:22 UTC, Chris wrote:
I did just that and I could find the culprit. It's opIndex().
It works up until 2.068.0, with 2.068.1 I already get this
error:
"primitives.d(7): Error: invalid foreach aggregate
doSomething(items).opIndex()"
@property size_t
On Tuesday, 17 November 2015 at 12:22:22 UTC, Marc Schütz wrote:
Ok, that's a strange implementation of opIndex(). Usually, a
parameter-less opIndex() is supposed to return a slice into the
full range, but yours returns a size_t, which of course can't
be iterated over.
The change that made
On 17.11.2015 15:32, maik klein wrote:
template tupIndexToRange(alias Tup, Indices...){
[snip]
I don't quite understand how that code is supposed to work. Maybe
there's just some detail missing, but it could also be that your
approach can't work.
This is roughly what I want to achieve
On Tuesday, 17 November 2015 at 05:37:55 UTC, Domain wrote:
Thank you! Now another question: how to handle endianness?
If your file follow a file format:
the endianness should be defined there.
else it's a random text file:
either it will have a BOM with endianness,
or you will
Thanks everyone for taking the time to respond!
@Lobo,
Start using D now. It's not all or nothing so you don't have to
give up on C++. I have several projects that contain both C++
and D intermixed.
Using both does seem like a good way to transition. I could
combine the strengths of D
The question is also posted on
https://stackoverflow.com/questions/33757981/filtering-a-tuple-of-containers-with-indicies
template tupIndexToRange(alias Tup, Indices...){
import std.meta;
static if(Indicies.length == 0){
alias tupIndexToRange = AliasSeq!();
}
else{
alias
I looked through the dataframe code and a couple of comments...
I had thought perhaps an app could read in the header info and
type info from hdf5, and generate D struct definitions with
column headers as symbol names. That would enable faster
processing than with the associative arrays, as
On Tuesday, 17 November 2015 at 14:21:27 UTC, Dan wrote:
Personally, I don't think there is a reason to transition.
Instead, you should learn D and then use it when you are ready.
That is troubling, but reasons to transition must exist or the
language would not exist, right? I find that if I
On Tuesday, 17 November 2015 at 11:26:19 UTC, Marc Schütz wrote:
That really depends on the details, that's why I asked. It
could be a regression, or it could be that the compiler now
does stricter checking than before, and your implementation
wasn't completely correct, or it could be a bug
On Tue, 17 Nov 2015 10:53:04 +, bachmeier wrote:
> On Tuesday, 17 November 2015 at 00:33:44 UTC, Chris Wright wrote:
>> This might change, but that's a gamble, and not one I'd take.
>> For projects where you need specific libraries to exist already, D
>> probably won't serve your needs. (It's
On Tuesday, 17 November 2015 at 22:47:17 UTC, Jon D wrote:
I'd like to chain several ranges and operate on them. However,
if the chains are different lengths, the data type is
different. This makes it hard to use in a general way. There is
likely an alternate way to do this that I'm missing.
I'd like to chain several ranges and operate on them. However, if
the chains are different lengths, the data type is different.
This makes it hard to use in a general way. There is likely an
alternate way to do this that I'm missing.
A short example:
$ cat chain.d
import std.stdio;
import
On Tuesday, 17 November 2015 at 15:48:10 UTC, anonymous wrote:
On 17.11.2015 15:32, maik klein wrote:
[...]
[snip]
I don't quite understand how that code is supposed to work.
Maybe there's just some detail missing, but it could also be
that your approach can't work.
[...]
Thanks but I
On 17.11.2015 20:46, maik klein wrote:
.selectFromTuple!(0, 1).expand
Does this result in a copy? I avoided doing it like this because I was
worried that I would copy every array. But I also don't fully understand
when D will copy.
Yes and no. It copies the Array structs, but it does not copy
On 11/17/15 3:25 PM, user123ABCabc wrote:
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
if (typeid(a) == typeid(b)) return a.opEquals(b);
Wow this is terrible to compare two objects in D. The line I quoted
means that two TypeInfoClass are likely to be allocated, right ?
On 11/17/2015 12:40 AM, MichaelZ wrote:
> In http://dlang.org/operatoroverloading.html#eqcmp it is stated that
>
> "If opEquals is not specified, the compiler provides a default version
> that does member-wise comparison."
>
> However, doesn't this only apply to structs, and not objects?
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
if (typeid(a) == typeid(b)) return a.opEquals(b);
Wow this is terrible to compare two objects in D. The line I
quoted means that two TypeInfoClass are likely to be allocated,
right ?
But usually when comparing objects one
On Tuesday, 17 November 2015 at 23:22:58 UTC, Brad Anderson wrote:
One solution:
[snip]
Thanks for the quick response. Extending your example, here's
another style that works and may be nicer in some cases.
import std.stdio;
import std.range;
import std.algorithm;
void main(string[]
In http://dlang.org/operatoroverloading.html#eqcmp it is stated
that
"If opEquals is not specified, the compiler provides a default
version that does member-wise comparison."
However, doesn't this only apply to structs, and not objects?
The default behaviour of opEquals for objects seems
On Mon, 2015-11-16 at 22:39 +, Dan via Digitalmars-d-learn wrote:
>
[…]
> My platform of choice is 64-bit Fedora using Code::Blocks (yes, I
> use an IDE as a crutch). It seems that D supports this combo.
Last time I looked at Code::Blocks it couldn't do a dark theme, and the
D support was
27 matches
Mail list logo
