char[4096] buf;
writeln(GC.stats.usedSize);
foreach (i; 0 .. 10) {
sformat(buf, "%f", 1.234f);
writeln(GC.stats.usedSize);
}
Output with DMD32 D Compiler v2.089.1-dirty (Win10 x64):
16
16
16
...
Output with DMD32 D Compiler
On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven
Schveighoffer wrote:
I'm pretty sure std.concurrency uses Variant to pass message
data, which boxes when it gets over a certain size. You are
probably crossing that threshold.
The allocations should level out eventually when the GC starts
On 1/30/20 4:51 PM, Ben Jones wrote:
The following result doesn't make sense to me... how does isInstanceOf
return false?
```
import std.traits;
import std.stdio;
import std.typecons;
auto f(T)(T t){
return Nullable!T(t);
}
void main(){
auto f3 = f(3);
On Friday, 31 January 2020 at 00:51:45 UTC, Ben Jones wrote:
writeln(typeof(f3).stringof);
writeln(isInstanceOf!(Nullable, f3));
In the first one, you check typeof, but not in the second one.
writeln(isInstanceOf!(Nullable, typeof(f3))); // true
The template argument there was T
From one noob to another: Not much of a difference, but levenshteinDistance seems to be a good fit
here. About as fast as your solution, slightly lower memory usage. byCodeUnit/byChar might shave off
a few more ms.
For small scripts like these I'm usually not even bothering with const
The following result doesn't make sense to me... how does
isInstanceOf return false?
```
import std.traits;
import std.stdio;
import std.typecons;
auto f(T)(T t){
return Nullable!T(t);
}
void main(){
auto f3 = f(3);
writeln(typeof(f3).stringof);
On Thursday, 30 January 2020 at 20:42:02 UTC, Paul Backus wrote:
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
[..]
would make the language grammatically ambiguous...
OK, understood. Thank you.
On Thursday, 30 January 2020 at 20:00:05 UTC, MoonlightSentinel
wrote:
On Thursday, 30 January 2020 at 17:00:08 UTC, ShadoLight wrote:
[..]
...your proposed change it would be ambigous ...
Ok, that makes sense - I did not consider the impact of the
optional empty braces. Thank you.
On Wednesday, 29 January 2020 at 08:56:26 UTC, rumbu wrote:
On Wednesday, 29 January 2020 at 08:40:48 UTC, p.shkadzko wrote:
Has anyone read "d programming language tutorial: A Step By
Step Appoach: Learn d programming language Fast"?
On Thu, Jan 30, 2020 at 09:37:40AM +, Michael via Digitalmars-d-learn wrote:
[...]
> auto elements = buf.to!string.strip.split(" ").filter!(a => a != "");
>
> That line strips white space from buf, splits it, removes empty
> elements and returns an array of strings. At least I thought so.
If
On Thursday, 30 January 2020 at 21:09:41 UTC, Simon wrote:
How do I revert my variable to the init state?
null is the initial state for those.
On Thursday, 30 January 2020 at 21:09:41 UTC, Simon wrote:
Hi dlang community,
I'm trying to implement a "reset" functionality which should
revert all variables to the program start initial state.
Example:
import Graph;
protected Edge[string] m_string2edge;
int main()
{
// adding some
Hi dlang community,
I'm trying to implement a "reset" functionality which should
revert all variables to the program start initial state.
Example:
import Graph;
protected Edge[string] m_string2edge;
int main()
{
// adding some elements
// not important how it works
//
On Thursday, 30 January 2020 at 18:20:47 UTC, uranuz wrote:
2. Where in the documentation is mentioned that when I create
alias to name that is a function or method that has overloads
then this alias is actually an alias not only for the first or
second or randomly selected overload in
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
Is there a technical reason for this limitation? Why are the
'classical' invocation style not allowed for eponymous
templates as well?
The 'classical' invocation style is not allowed because it would
make the language
On Thursday, 30 January 2020 at 17:00:08 UTC, ShadoLight wrote:
Agreed. My question though is should the 'shorthand' notation
_replace_ the 'longhand' notation, or be available _in
addition_ to the 'longhand' notation in the eponymous case (so
the eponymous notation is just 'syntax sugar' if
On Thu, Jan 30, 2020 at 06:20:47PM +, uranuz via Digitalmars-d-learn wrote:
[...]
> 1. Why API for __traits(getOverloads) is so strange. Why I need to
> find parent for symbol myself and pass actual symbol name as string,
> but not actually pass a symbol itself? It is very strange to me...
I apologise that I need to revive this discussion again. But
still I got answer to only one of my questions. I know that it is
a common practice in programmers society that when someone asks
more than 1 question. Then people who answer them usually choose
only one of these questions that is
On Thursday, 30 January 2020 at 16:16:48 UTC, MoonlightSentinel
wrote:
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
[...]
From my POV is
void foo(T)() { ... }
just a shorthand notation for...
Agreed. My question though is should the 'shorthand' notation
_replace_ the
On Thursday, 30 January 2020 at 16:23:54 UTC, Michael wrote:
Is there a way to detect unused imports?
It happened to me that I used imports which I did not need in
the end. So, I'd like to remove them easily.
https://issues.dlang.org/show_bug.cgi?id=20442
TL;DR
This has come up in the past
Is there a way to detect unused imports?
It happened to me that I used imports which I did not need in the
end. So, I'd like to remove them easily.
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
Is there a technical reason for this limitation? Why are the
'classical' invocation style not allowed for eponymous
templates as well?
It seems somewhat arbitrary - note that inner/outer functions
does not have this limitation -
On Thursday, 30 January 2020 at 14:22:11 UTC, Paul Backus wrote:
On Thursday, 30 January 2020 at 14:10:38 UTC, ShadoLight wrote:
...but in the 'classical' default template style, so I would
have thought the
template_name!(compile_time_args).function_name(run_time_args)
style would still work,
On Thursday, 30 January 2020 at 14:10:38 UTC, ShadoLight wrote:
...but in the 'classical' default template style, so I would
have thought the
template_name!(compile_time_args).function_name(run_time_args)
style would still work, even if the template and function names
are identical.
If this
On Thursday, 30 January 2020 at 14:10:38 UTC, ShadoLight wrote:
Taking this example from documentation page on 'Template
Sequence Parameters' [1]:
[...]
Tested on https://run.dlang.io
Taking this example from documentation page on 'Template Sequence
Parameters' [1]:
import std.stdio;
template print(args...)
{
void print()
{
writeln("args are ", args); // args is a ValueSeq
}
}
template write(Args...)
{
void write(Args args) // Args is a TypeSeq
On Thursday, 30 January 2020 at 13:05:05 UTC, drug wrote:
That's probably triggered by some constraints. I had the issue
like this with Nullable:
https://github.com/dlang/phobos/pull/7324
The core problem here stems from the fact that templates are
always instantiated in the scope of the
On Thursday, 30 January 2020 at 13:23:17 UTC, Adam D. Ruppe wrote:
On Thursday, 30 January 2020 at 06:12:32 UTC, Michael wrote:
I did exactly just what you proposed.
yeah i often just leave my random filenames in there, in this
case rl was one of them. (if you don't put `.d` at the end of a
(I'll answer here anyway just in case someone lands here via a
web search.)
On Thursday, 30 January 2020 at 10:31:08 UTC, mark wrote:
Why is this a *copy*? (For a copy (in C++) I'd have expected
return *this.)
In C++, `this` is a pointer, but in D, it is a reference. So
assignment follows
On Thursday, 30 January 2020 at 06:12:32 UTC, Michael wrote:
I did exactly just what you proposed.
yeah i often just leave my random filenames in there, in this
case rl was one of them. (if you don't put `.d` at the end of a
filename, dmd will add it automatically). Generally a "module X
is
On 1/30/20 2:50 PM, Martin Tschierschke wrote:
When building my small vibe.d app I am getting this messages twice:
/usr/include/dmd/phobos/std/range/primitives.d(174,38): Deprecation:
alias byKeyValue this is deprecated - Iterate over .byKeyValue instead.
Below is a program that produces a wordladder.
The algorithm is probably suboptimal, but I don't care since I've
implemented the same one in Python, Rust, Go, Java, and Nim, so I
find it useful for language comparison purposes.
What I'd like some feedback on is how to improve the code
When building my small vibe.d app I am getting this messages
twice:
/usr/include/dmd/phobos/std/range/primitives.d(174,38):
Deprecation: alias byKeyValue this is deprecated - Iterate over
.byKeyValue instead.
/usr/include/dmd/phobos/std/range/primitives.d(176,27):
Deprecation: alias
In the D Cookbook it has as part of the FibonacciRange example:
@property FibonacciRange save() { return this; }
And in the description it says:
"...save, which returns a new range that is a copy of the current
range and can be advanced independently..."
Why is this a *copy*? (For a copy
On Thursday, 30 January 2020 at 10:31:08 UTC, mark wrote:
In the D Cookbook it has as part of the FibonacciRange example:
@property FibonacciRange save() { return this; }
And in the description it says:
"...save, which returns a new range that is a copy of the
current range and can be
On Thursday, January 30, 2020 2:37:40 AM MST Michael via Digitalmars-d-learn
wrote:
> auto is surely a nice feature. Nonetheless I'd prefer to use
> explicit types. So when reading a code and I see the auto keyword
> I also have to find out what kind of type is meant.
>
> I have a line of code
auto is surely a nice feature. Nonetheless I'd prefer to use
explicit types. So when reading a code and I see the auto keyword
I also have to find out what kind of type is meant.
I have a line of code that looks like this:
auto elements = buf.to!string.strip.split(" ").filter!(a => a !=
"");
On Thursday, 30 January 2020 at 08:13:16 UTC, Mike Parker wrote:
That means any arguments you pass on the command line after the
source file name will be passed to your program. Compiler
options need to go before the source file name.
rdmd -L-lreadline mysource.d
That works, thanks Mike
On Thursday, 30 January 2020 at 06:27:36 UTC, Michael wrote:
On Thursday, 30 January 2020 at 06:15:54 UTC, Mike Parker wrote:
Is your source file named rl.d? And are you running dmd in the
source file's directory?
No, I did not. Changed it now and it works with dmd. Great!
Tried the same
39 matches
Mail list logo
