Having to split and match seems slow(50%). Surely the regex
splitter and matcher can be combined? Sometimes we just need to
extract out and remove information simultaneously.
I propose a new function called extractor that returns the
matchAll and splitter's results but is optimized.
Consider
void foo(string A = "")(string B = "")
{
static if (A != "")
do(A);
else
do(B);
}
foo!("x");
foo("x");
This is necessary because D's templating and meta programming
system is frail.
While CTFE should take care of such things, it does not, consider
On Monday, 17 June 2019 at 00:22:23 UTC, Samir wrote:
On Sunday, 16 June 2019 at 23:55:41 UTC, lithium iodate wrote:
There is *very* likely to be a terminating new-line at the end
of the file (many editors add one without asking!). If that
the case, the last line seen by the loop will be empty
On Sunday, 16 June 2019 at 23:55:41 UTC, lithium iodate wrote:
There is *very* likely to be a terminating new-line at the end
of the file (many editors add one without asking!). If that the
case, the last line seen by the loop will be empty and you must
not attempt to access any elements.
On
On Sunday, 16 June 2019 at 23:44:49 UTC, Samir wrote:
On Sunday, 16 June 2019 at 23:03:04 UTC, aliak wrote:
stripping the last line could result in an empty line if it
just has strippable characters?
The last line of the file is just text but without a newline
(\n) character or any other
On Sunday, 16 June 2019 at 23:44:49 UTC, Samir wrote:
On Sunday, 16 June 2019 at 23:03:04 UTC, aliak wrote:
stripping the last line could result in an empty line if it
just has strippable characters?
The last line of the file is just text but without a newline
(\n) character or any other
On Sunday, 16 June 2019 at 23:03:04 UTC, aliak wrote:
stripping the last line could result in an empty line if it
just has strippable characters?
The last line of the file is just text but without a newline (\n)
character or any other whitespace character at the end. I get
the same error
On Sunday, 16 June 2019 at 23:03:04 UTC, aliak wrote:
stripping the last line could result in an empty line if it
just has strippable characters?
The last line is just the text of the last line. There is no
newline character at the end. I also get the same error if I
remove the strip
On Sunday, 16 June 2019 at 22:47:14 UTC, Samir wrote:
I am trying to read from a text file using the following code:
import std.stdio;
import std.string;
void main() {
File file = File("test.txt");
string line;
while (!file.eof()) {
line = strip(file.readln());
if
I am trying to read from a text file using the following code:
import std.stdio;
import std.string;
void main() {
File file = File("test.txt");
string line;
while (!file.eof()) {
line = strip(file.readln());
if (line[0] == '>') { // line 10
On Sunday, June 16, 2019 5:53:30 AM MDT BoQsc via Digitalmars-d-learn wrote:
> On Sunday, 16 June 2019 at 11:38:27 UTC, rikki cattermole wrote:
> > The style guide has an opinion about this (you don't have to
> > follow it).
> >
> > https://dlang.org/dstyle.html#naming_keywords
>
> So if I follow
How does the observerObject Template and function work? I'm struggling
because both use the same name and how is the template parameter R
deduced/where is it coming from? Looks like it's somehow implicitly
deduced.
class ObserverObject(R, E...){...}
template observerObject(E)
{
On 17/06/2019 3:11 AM, Robert M. Münch wrote:
How does the observerObject Template and function work? I'm struggling
because both use the same name and how is the template parameter R
deduced/where is it coming from? Looks like it's somehow implicitly
deduced.
class ObserverObject(R,
On Sunday, 16 June 2019 at 01:36:38 UTC, Timon Gehr wrote:
It's a bug. It's memory corruption. Different objects with
overlapping
lifetimes use the same memory location.
Okay. Seen that way, it is clear to me why it's a bug.
...
No, it's not the same. Python has no sensible notion of
On Sunday, 16 June 2019 at 11:38:27 UTC, rikki cattermole wrote:
The style guide has an opinion about this (you don't have to
follow it).
https://dlang.org/dstyle.html#naming_keywords
So if I follow dstyle guidelines on keywords, this would be a
correct non-conflicting result:
module
The style guide has an opinion about this (you don't have to follow it).
https://dlang.org/dstyle.html#naming_keywords
Do not ask why I want to do that, you can however suggest
alternative variations.
As you all might know,
2. The Identifiers preceding the rightmost are the Packages
that the module is in. The packages correspond to directory
names in the source file path. Package and module names cannot
be
17 matches
Mail list logo
