Re: Is removing elements of AA in foreach loop safe?

2019-08-30 Thread XavierAP via Digitalmars-d-learn

On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote:


Do you agree? Or is there a better way to achieve this?


An alternative would be to reassign the AAA to the output of 
std.algorithm.filter()... but assignment between AAs and Ranges 
isn't so type-direct.


Re: Is removing elements of AA in foreach loop safe?

2019-08-30 Thread XavierAP via Digitalmars-d-learn

On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote:
Iterating of some structure and removing elements thereby is 
always errorprone and should be avoided. But: In case of AA, 
I've got the feeling, that it might be safe:



foreach (k,v;ways)
if (v.empty)
ways.remove(k);


Do you agree? Or is there a better way to achieve this?


It compiles and it runs without throwing any RangeError... So it 
appears to be safe. Otherwise it'd be a bug that there's not 
error.


Re: How do I execute a sql-file inside D code

2019-08-22 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 20 August 2019 at 11:33:33 UTC, Anders S wrote:


Use this code to check
conn.exec("CREATE DATABASE IF NOT EXISTS boxweb;");

however haven't found a way to run the sql file that create the 
tables. The file is in the source folder


I understand you're using some API to some SQL implementation 
which allows you to run SQL commands from strings, but not from 
files which is what you want?


Just read the file into a string with the D std lib:

import std:file;
conn.exec( readText(fileName) );

https://dlang.org/phobos/std_file.html#.readText


Re: 1 new

2019-08-06 Thread XavierAP via Digitalmars-d-learn

On Friday, 2 August 2019 at 18:25:28 UTC, jmh530 wrote:
When I navigate to https://forum.dlang.org/ I have a message 
that says "1 new reply" to "your posts." Normally, I click on 
that "1 new reply" and find the post that's new, go to it, and 
the message disappears. However, it doesn't seem to go away 
anymore. I tried looking at many different old posts without 
luck. At one point it was up to "2 new replies," but I viewed 
that other post and it went back down to "1 new reply." Does 
anyone else have this?


For me everything seems to work OK.


Re: Is it possible to disallow import for certain functions?

2019-07-27 Thread XavierAP via Digitalmars-d-learn

On Saturday, 27 July 2019 at 11:54:09 UTC, BoQsc wrote:
I would like to make sure that function in module that I have 
won't be imported, is this possible to achieve?


In general, make the function private.

But indeed, on your case, it is a terrible idea to define a 
main() function in a module that you plan to import. Move it out 
into its own main module.


Re: Any easy way to check if an object have inherited an interface?

2019-07-23 Thread XavierAP via Digitalmars-d-learn

On Monday, 22 July 2019 at 21:34:18 UTC, solidstate1991 wrote:
It seems that I've to write my own function that searches in 
the given object's classinfo.interfaces since I couldn't find 
anything related in Phobos.


Do you mean...?

interface I {}
class C : I {}
void main()
{
C c1;
writeln(is(typeof(c1) : I));
}

No need for Phobos, core language:
https://dlang.org/spec/expression.html#IsExpression
https://dlang.org/spec/declaration.html#Typeof


Re: assert in unittest has access to private member?

2019-06-30 Thread XavierAP via Digitalmars-d-learn

On Sunday, 30 June 2019 at 17:24:03 UTC, Robert M. Münch wrote:
I have a case, with templates, where an assert in a unittest 
can access a private memember and I don't know how this can 
happen.


Modules are the units of encapsulation in D:

https://dlang.org/spec/attribute.html#visibility_attributes


Re: Options for unit testing in D?

2019-06-23 Thread XavierAP via Digitalmars-d-learn

On Sunday, 23 June 2019 at 01:26:29 UTC, Mike Brockus wrote:


I think we made a lot of progress, suddenly it's working and I 
don't need to include main. Is there a way to indicate based on 
console output that one executable is the tester and the other 
is the application?


unittest blocks are skipped completely by the compiler when the 
-unittest command line option is not passed. So you can leave 
unittest code embedded in between the rest (specially for proper 
unit tests of functions and classes) and there is no need to 
worry about file separation. Even when you write a separate file 
with tests, all its code inside unittest blocks can be skipped 
for the compiler.


In the case of dub, it has a dedicated option, "dub test" instead 
of "dub build" or "dub run"


https://dub.pm/commandline.html#test


Re: Options for unit testing in D?

2019-06-21 Thread XavierAP via Digitalmars-d-learn

On Friday, 21 June 2019 at 04:08:42 UTC, Mike Brockus wrote:


I am wondering as to what options are available for a Meson 
build user when unit testing?


Unit tests are part of the language in D:

https://dlang.org/spec/unittest.html

These are compiled when you (or whatever build system you use) 
pass the argument -unittest to the compiler.



If you never herd about Meson before:
樂. https://mesonbuild.com/


D has an "official" build manager, called dub. Of course you're 
free to use another one you prefer.


https://dub.pm/getting_started

PS also embedded documentation is part of the language (no need 
for e.g. doxygen):


https://dlang.org/spec/ddoc.html



Re: Where can find fix length array memory layout document

2019-06-20 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 18 June 2019 at 12:26:14 UTC, lili wrote:

Hi guys:
   Is the Dlang fix-length array alloc on stack?  when a test
writeln([1]).sizeof //16
writeln([2]).sizeof //16
Why, What is the fix-length array memory layout.


You are quite confused...

[...] is an array literal, not a static array. Those aren't the 
same thing.


When you pass a array literal anywhere in your code, it will in 
principle be referred as a slice variable. This will not 
reallocate the contents. However the slice reference is another 
variable that takes up two words of space (see code below).


This slice type is the same variable type that stores dynamic 
arrays -- be they allocated or null.


Array literals are not necessarily allocated. The compiler is 
free to embed them into the program machine code itself.


If you want a static array, you can just declare it directly e.g. 
int[n] arr. Of course you can also generate is out of an array 
literal with the staticArray std library function.


PS the layout of D arrays is of course linear and contiguous. 
Both static or dynamic, just like C/C++ static arrays or 
std::vectors respectively.


Hopefully this code makes things clear:

/*/
enum lenInts = int.sizeof;
static assert(lenInts == 4);

int[1] arrStatic;
static assert(lenInts == arrStatic.sizeof);

auto slice = arrStatic[];
alias sliceType = typeof(slice);
static assert(is(sliceType == int[]));

enum lenPointers = size_t.sizeof; // fyi (unsinged) pointers
static assert(ptrdiff_t.sizeof == lenPointers); // fyi signed 
pointer diff


static assert(sliceType.sizeof == 2 * lenPointers);
// because a D array reference remembers a pointer (like C) plus 
the length (stored in a word-length integer)




Re: DIP 1016 and const ref parameters

2019-06-19 Thread XavierAP via Digitalmars-d-learn

On Thursday, 20 June 2019 at 00:30:35 UTC, Jonathan M Davis wrote:


Ultimately, if you want a function to accept both rvalues and 
lvalues as efficiently as posible, just templatize it and use 
auto ref.


I'm aware of auto ref, and I've used it to solve this same 
problem when I had a template, but as you say it works with 
templates only, not plain non-templated functions.


Or another possible optimization: in case the function is 
declared with const parameters (not ref), lvalues can be 
accessed by ref as an optimization; and rvalues can use the 
same trick they do now. As a consequence, no unnecessary 
copies ever -- thanks to const. This is even better because I 
don't have to type so many ref, which were never part of the 
algorithm but baby instructions for the dumb compiler (const & 
everywhere is one of the ugliest and most annoying things in 
C++).


Either way, const has nothing to do with any of this. You're 
free to mark a ref or auto ref parameter as const, but it has 
nothing to do with whether rvalues are accepted, and it will 
never have anything to do with whether rvalues are accepted. 
D's const is far too restrictive for it to make any sense to 
base rvalue stuff on it like they do in C++. The DIP has 
nothing do with const and everything to do with ref.

[...]
Regardless, the refness of a parameter is part of its type, and 
I'd be very surprised if it were ever changed so that any 
parameter that was not marked with ref was ever ref.


I know. That's why I look to the general solution to bind ref 
rvalues as a solution to bind const ref in particular. By the way 
it looks to me that most of the demand in the D community to bind 
to ref is for chain return ref functions. I wonder why no one in 
D is bothered about not being able to use const ref parameters 
easily, while in C++ everyone is bothered to do it, and passing a 
read-only struct/class by value won't pass by the least alert 
reviewer. My guess is that in D it's very often ranges that get 
passed, and these are passed as slices, which are by nature refs 
that don't reallocate, and can also be decorated const. Still the 
const ref concern stays more or less. Rust has a solution too (&) 
of course.


My new idea about const only would be a compiler optimization, 
not part of the language/ABI. The same way as RVO, which under 
the hood (but not at the ABI level) is implemented as changing 
the function signature completely. This const optimization would 
not change the function's ABI either.


However I see a practical problem to implement this optimization 
idea. RVO changes the function signature under the hood, but in 
the same way for every occurrence/call. This const optimization 
would need to change the signature, but only in the occurrences 
where the function is called with lvalues instead,not rvalues. So 
in practice turning every function with const struct parameters 
as a template; but under the hood, maintaining a single plan 
signature in the ABI. I wonder if this is as easy or feasible as 
RVO.


Re: The problem with the conversion.

2019-06-19 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 19 June 2019 at 17:28:38 UTC, XavierAP wrote:


Also, the return type of SDL_LoadBMP is a pointer, SDL_Surface* 
not just SDL_Surface.


Or just use auto of course if you prefer:

void load (string path)
{
import std.string : toStringz;
auto ab = SDL_LoadBMP (path.toStringz);


Re: DIP 1016 and const ref parameters

2019-06-19 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 19 June 2019 at 21:06:48 UTC, XavierAP wrote:


Now with an rvalue returned from get, interesting, no copy. 
Still, I wonder what really happened. Again, moving between 
stacks would still be work. And a different optimization can 
explain this non copy, for example inlining.


My guess as to what may be happening (I've never used a 
disassembler and I wasn't planning on starting today yet) is 
simple. The rvalue returned by get() is possibly not popped out 
from the stack, but rather left in the same place as sum() is 
called on it. This is actually optimum, but hardly an 
optimization, rather it's the easiest and least effort for the 
compiler. Again this would mean no moving -- which is good, 
because moving is work.


And also, this doesn't work in the general case. If parameters 
are by value, everything works perfect when I pass rvalues (but 
we already knew that, not answering my question); however if I 
pass lvalues they will be copied every time.


So my question is open... what about const ref rvalue parameters?

Or another possible optimization: in case the function is 
declared with const parameters (not ref), lvalues can be accessed 
by ref as an optimization; and rvalues can use the same trick 
they do now. As a consequence, no unnecessary copies ever -- 
thanks to const. This is even better because I don't have to type 
so many ref, which were never part of the algorithm but baby 
instructions for the dumb compiler (const & everywhere is one of 
the ugliest and most annoying things in C++).


Re: Is it possible to escape a reserved keyword in Import/module?

2019-06-19 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 19 June 2019 at 18:56:57 UTC, BoQsc wrote:
I would like to make sure that my modules do not interfere with 
d lang. Is there any  way to escape reserved words?


The only reason C# allows this is for interop or code generation 
for other languages that use the same keyword. For example 
"class" is an HTML attribute.


There is no excuse to do this for any other reason -- and C# 
gurus would also agree.



I would like to make sure that my modules do not interfere


Then don't name them as keywords :)


Re: DIP 1016 and const ref parameters

2019-06-19 Thread XavierAP via Digitalmars-d-learn
Hmmm I know about move semantics, and C++11 etc. I just don't 
know how related all that is to my original question. :)


On Wednesday, 19 June 2019 at 19:25:59 UTC, Jonathan M Davis 
wrote:
though if I understand correctly with RVO, it may just place 
the return value outside of the function in the first place to 
avoid needing to move.


Indeed, unrelated:
https://dlang.org/glossary.html#nrvo


func(foo(), bar(42), baz("hello"));

assuming that none of these functions return by ref, func is 
taking temporaries from several functions, and the spec 
actually guarantees that they will not be copied.


Where does the spec say this?? (This case is actually my 
question.)


However, please understand that naive moving is not an answer for 
me. Moving is still work! It would still be more efficient if 
foo's parameters were references/pointers -- if D functions were 
able to bind rvalues as such.


Theoretically a compiler could optimize by realizing that if a 
value parameter is not modified by the function (and it doesn't 
fit in a register etc), it can be read at its original 
location/address in the caller's stack, i.e. by 
reference/pointer. Again, nothing to do with moving. But I really 
doubt the D compilers do this, first because C++ probably don't, 
or else all C++ programmers are wasting their fingers and screen 
real state typing const & zillions of times; and second because D 
would not be able to bind as ref in case the argument happened to 
be an rvalue.

__

OK so I try to experiment myself:

/**/
struct XY
{
int x, y;
~this() { writeln("Destroyed!"); }
}

int sum(XY p) { return p.x + p.y; }

void main()
{
XY p;
p.sum;
}
/**/

Destroyed!
Destroyed!

Note that the compiler didn't realize that p isn't needed after 
the last statement of main, as you thought.


/**/

XY get()
{
XY p;
return p;
}
void main()
{
get.sum;
}
/**/

Destroyed!

Now with an rvalue returned from get, interesting, no copy. 
Still, I wonder what really happened. Again, moving between 
stacks would still be work. And a different optimization can 
explain this non copy, for example inlining.

__

Again, does the spec really mention any of this moving or 
eliding? I have found nothing.


Re: DIP 1016 and const ref parameters

2019-06-19 Thread XavierAP via Digitalmars-d-learn
On Wednesday, 19 June 2019 at 12:55:09 UTC, Jonathan M Davis 
wrote:


Even in C++, using const ref is not as good a practice as it 
once was, because they added move constructors, finally making 
object moveable. The result is that in many cases, it's 
actually more efficient to just copy values in C++ rather than 
use const &, but which is better does depend on the code.


As for D, unless you're dealing with large objects, odds are 
that worrying about passing by value is pointless. D classes 
are reference types, and D structs have move semantics 
built-in. So, you don't get as many copies as you would in 
C++98, and the situation is probably better than newer versions 
of C++, since IIRC, C++ classes aren't moveable by default, 
whereas D structs are. In general, you're probably better off 
just passing by value unless you find that a particular piece 
of code is inefficient when benchmarking. Either way, you don't 
want to be slapping const on everything the way you would in 
C++, because D's const is far more restrictive. So, while it 
still can be quite useful, odds are that if you start using it 
heavily, you're going to run into problems fast - especially 
since casting away const and mutating an object is undefined 
behavior in D. D's const has no back doors. If something is 
const, then you can't mutate it unless you also have a mutable 
reference to the same data. And because const is transitive, 
you pretty much can't get mutable stuff from const stuff like 
you frequently can in C++ (e.g. in C++, it's possible to have a 
const container of mutable objects, wherein D, once part of 
something is const, everything within that part is const).


As for the DIP, I'd suggest watching Andrei's recent dconf talk 
on the subject:


https://www.youtube.com/watch?v=aRvu2JGGn6E=youtu.be

- Jonathan M Davis


I am not talking about cases that would be candidate for moving, 
or where const would be any problem. If you want an example for 
the sake of argument:


struct Matrix3D
{
Matrix3D opBinary(string op)(const ref Matrix3D rhs) const;
}
unittest
{
auto a = Matrix3D.random;
assert(a == a * Matrix3D.identity);
assert(a == a + Matrix3D.zeros);
}

I did watch Andrei's talk, actually this is where I started and 
learned about the DIP(s), then I was confused that 1016 had been 
rejected, and smelling that it may be "reopening" I was not sure 
where I can find the "index" of DIPs under discussion or 
whatever... :)


IIRC, C++ classes aren't moveable by default, whereas D structs 
are.


What do you mean that structs are movable? I know about RVO (in 
both D and C++, supposedly guaranteed by all compilers in 
practice, but not by language spec -- why not D?), but what about 
passing up the stack as here?


Re: The problem with the conversion.

2019-06-19 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 19 June 2019 at 14:58:44 UTC, drug wrote:

19.06.2019 17:52, Den_d_y пишет:

void load (const (char *) path)
{
     SDL_Surface ab = SDL_LoadBMP (path);
     a = SDL_CreateTextureFromSurface (ab);
     SDL_FreeSurface (ab);
}


try the following:
```
void load (string path)
{
import std.string : toStringz;
SDL_Surface ab = SDL_LoadBMP (path.toStringz); // toStringz 
converts string to null terminated char*

auto a = SDL_CreateTextureFromSurface (ab);
SDL_FreeSurface (ab);
}


Also, the return type of SDL_LoadBMP is a pointer, SDL_Surface* 
not just SDL_Surface.


Indeed, in your code do use the D string path, not char*, and use 
toStringz when passing to C APIs.


Also, in D const(char)* would not be the same as const(char*). 
But don't worry about this and use string.


DIP 1016 and const ref parameters

2019-06-19 Thread XavierAP via Digitalmars-d-learn
I often use a pattern of having const ref struct parameters (as 
in C++) but this doesn't work in the case of rvalues. The 
workaround of defining an overload that calls its own name is 
terrible. I understand there was a DIP 1016 by Manu asking for 
this case to work. As far as I can tell, this was rejected, but 
later reconsidered, and now Andrei is starting up a new one[1]? 
Apologies but I'm not sure where these discussions are 
centralized. But if anyone has any idea or guess how seriously 
and in what kind of time this could be expected, that would be my 
first side question.


My main learning question is whether the const ref parameter 
pattern is good in D? In C++ I see it everywhere, but are there 
better alternatives, in particular in D, or is there no point 
because some copy elision optimization may be guaranteed? In 
short am I right in writing const ref parameters, or am I doing 
something silly (and as important as this DIP may otherwise be, 
it wouldn't affect me as much as I think)??


As far as I can see, this DIP would be helpful for two use cases: 
const ref, and return ref with method chains. Are there others?

__
[1] 
https://forum.dlang.org/post/d90a7424-a986-66f1-e889-a9abd55e0...@erdani.org


Re: How does this template work?

2019-06-18 Thread XavierAP via Digitalmars-d-learn

On Sunday, 16 June 2019 at 15:11:29 UTC, 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.


Eponymous templates:
https://dlang.org/spec/template.html#implicit_template_properties

"Templated types" are actually particular cases of eponymous 
templates:

https://dlang.org/spec/template.html#StructTemplateDeclaration

   class ObserverObject(R, E...) {...}

is equivalent to

   tempalte ObserverObject(R, E...)
   {
  class ObserverObject(R, E...) {...}
   }

So this is I think how everything is made to work with the same 
compiler engine, both individual "templated types" and "eponymous 
templates".


It's considered idiomatic, but if you don't like it in your case, 
it's very easy for the author to avoid it: just make the names 
different in any way.


   template Observer(E)
   {
  ObserverObject!(R, E) Object(R)(R range)
  {
  return new ObserverObject!(R, E)(range);
  }
   }

   auto observer = Observer!int.Object(TestObserver());


Re: Proper desctructor for an class containing dynamic array of objects

2019-06-14 Thread XavierAP via Digitalmars-d-learn

On Friday, 14 June 2019 at 11:10:58 UTC, rumbu wrote:

On Friday, 14 June 2019 at 07:52:24 UTC, Marco de Wild wrote:

On Thursday, 13 June 2019 at 16:08:52 UTC, Mike wrote:
Opposed to Java, D's member variables are static initialised.


Is there any documentation about this? I find it unexpected.


https://dlang.org/spec/class.html#static-constructor

«All member initializations must be determinable by the compiler 
at compile time, hence there is no order-of-evaluation dependency 
for member initializations, and it is not possible to read a 
value that has not been initialized. Dynamic initialization is 
performed by a static constructor»


Re: Does slicing have an effect?

2019-05-27 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 21 May 2019 at 20:44:49 UTC, rikki cattermole wrote:

On 22/05/2019 8:31 AM, Dennis wrote:


Does slicing have an effect I'm not aware of, or is this a bug?


It could have an effect if a was a struct/class via operator 
overloads. But in this case it should probably be a bug.


It doesn't look right, even for custom types; because D (and in 
particular Walter) is against changing the meaning of operators 
when overloading (e.g. << in C++). At least unofficially, 
although I may recall it is enforced at a few places elsewhere.


Going back to the original question, it may be a bug (for 
arrays). And if so and if D wants to enforce consistent operator 
semantics when possible, it may be considered a bug for any type.


Re: alias parameters, what for?

2019-05-09 Thread XavierAP via Digitalmars-d-learn
Thanks, I get your points. I do think they make more sense for 
the standard library, than in every general case (packages for 
specific uses). Namely, alias parameters provide absolute 
genericity (instead of overloading every possible use case, or 
else constraining the API by design), and ultimate runtime 
performance (always at the expense of compile time).


alias parameters, what for?

2019-05-09 Thread XavierAP via Digitalmars-d-learn
What are the benefits of alias parameters, compared to specifying 
the template parameters fully?

https://dlang.org/spec/template.html#aliasparameters

In most examples, at places in Phobos, and in Andrei's and Ali’s 
books, alias parameters are used for functions (in the general 
sense). Why this instead of specifying and typing the parameter 
functions or delegates?


This brings another question, why is it so widespread in Phobos 
etc. to template these function parameters instead of declaring 
them as run-time parameters? Is this really always considered 
beneficial, why?


For one it looks like it saves a lot of typing and makes the 
whole declaration more readable (not to mention possible 
attribute soups); but the type-checking code just moves to 
additional template constraints.


And finally what’s the advantage of alias parameters in general, 
besides function/delegates? But I don’t see other uses in 
practice, although they’re possible.


Re: Subtyping of an enum

2019-04-15 Thread XavierAP via Digitalmars-d-learn

On Monday, 15 April 2019 at 12:38:59 UTC, XavierAP wrote:


More generally you insist on modules and namespaces to be 
different concepts, which they are (pointlessly) for C++, but 
not for D (purposely).


Here I should say packages instead of modules... but the general 
argument stays.


Anyway your design is up to you :) but sub-typing is not 
reflexive, in D or any language.


Re: Subtyping of an enum

2019-04-15 Thread XavierAP via Digitalmars-d-learn

On Monday, 15 April 2019 at 10:34:42 UTC, Anton Fediushin wrote:


The problem here is that I want to keep methods that are 
related to an enum inside of this enum for purely aesthetic and 
organizational purposes.

...
These global functions pollute global namespace.


If you have defined `x.toString` as a method, UFCS means of 
course you can also call `toString(x)`... So it's debatable what 
polluting means.


More generally you insist on modules and namespaces to be 
different concepts, which they are (pointlessly) for C++, but not 
for D (purposely).


Re: Subtyping of an enum

2019-04-15 Thread XavierAP via Digitalmars-d-learn

On Monday, 15 April 2019 at 10:34:42 UTC, Anton Fediushin wrote:

On Monday, 15 April 2019 at 10:06:30 UTC, XavierAP wrote:


You have defined your sub-typing the opposite way that you 
wanted it to work: every `Enum` is an `internal`, but the 
other way around an `internal` may not work as an `Enum`. Your 
`fun` would in principle work if it were defined with an 
`internal` but passed an `Enum`... Of course you have defined 
`internal` as nested private so no... But then how did you 
want anything to work if no one outside Enum knows the 
super-type?


Isn't this how subtyping works for integers and other types? 
For example, you have subtyped an integer and added some new 
methods to it?


Yes (leaving aside whether stuff is private or nested) but you 
are using the types' relationship the other way around. You have:


static assert(is(Enum : internal));

But you are defining and calling fun() as if it were the other 
way around (internal : Enum)




Re: Subtyping of an enum

2019-04-15 Thread XavierAP via Digitalmars-d-learn

On Monday, 15 April 2019 at 08:39:24 UTC, Anton Fediushin wrote:


Hello! I am currently trying to add a custom `toString` method


Several remarks... First of all, strings can be compared 
(alphabetically) as well as integers, e.g.

assert("foo" > "bar")
Perhaps not your use case, but worth noting.

You have defined your sub-typing the opposite way that you wanted 
it to work: every `Enum` is an `internal`, but the other way 
around an `internal` may not work as an `Enum`. Your `fun` would 
in principle work if it were defined with an `internal` but 
passed an `Enum`... Of course you have defined `internal` as 
nested private so no... But then how did you want anything to 
work if no one outside Enum knows the super-type?


You obviously need to re-think your problem and your design :)

Obvious solution is to wrap an enum in a structure and utilize 
'alias this' for subtyping like this:


Actually the obvious solution (not sure if it otherwise works for 
you) would be to take advantage of D's Uniform Function Call 
Syntax [1] and define toString as a global function that can be 
called as a method:


enum Fubar { foo, bar }

string toString(Fubar fb)
{
return "It works.";
}

void main()
{
import std.stdio;
writeln(Fubar.foo.toString);
}

_
[1] 
https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs


Re: Are static variables available to other static variables?

2019-04-12 Thread XavierAP via Digitalmars-d-learn

On Friday, 12 April 2019 at 10:56:32 UTC, Jamie wrote:

On Friday, 12 April 2019 at 10:49:19 UTC, Jamie wrote:
I was trying to declare a static variable dependent on another 
static variable, but it didn't work. Are static variables not 
known to other static variables at compile time?


void main()
{   
C c = new C();
}

class C
{
static size_t A = 2;
static size_t B = 2^^A; // A is not known at compile time
}


Ok I'm confused... why does that above not work but this does:

void main()
{   
C c = new C();
}
class C
{
static size_t A = 2;
static size_t B;
static this()
{
B = 2^^A;
}
}


It's not a bug. I finally found it in the spec:

https://dlang.org/spec/class.html#static-constructor

"All member initializations must be determinable by the compiler 
at compile time, hence there is no order-of-evaluation dependency 
for member initializations, and it is not possible to read a 
value that has not been initialized. Dynamic initialization is 
performed by a static constructor"


Re: Are static variables available to other static variables?

2019-04-12 Thread XavierAP via Digitalmars-d-learn

On Friday, 12 April 2019 at 10:56:32 UTC, Jamie wrote:

On Friday, 12 April 2019 at 10:49:19 UTC, Jamie wrote:
I was trying to declare a static variable dependent on another 
static variable, but it didn't work. Are static variables not 
known to other static variables at compile time?


void main()
{   
C c = new C();
}

class C
{
static size_t A = 2;
static size_t B = 2^^A; // A is not known at compile time
}


Ok I'm confused... why does that above not work but this does:

void main()
{   
C c = new C();
}
class C
{
static size_t A = 2;
static size_t B;
static this()
{
B = 2^^A;
}
}


May this be a bug? Static mutable is a theoretically valid use 
case.


It looks to me that D often optimizes by evaluating at compile 
time. But in this case what is a possible optimization breaks a 
valid program when the optimization is found not to be possible. 
Other languages e.g. C# would by spec run these static 
initializations at run-time during the first use of C.


Re: What Does @ Mean?

2019-04-08 Thread XavierAP via Digitalmars-d-learn

On Monday, 8 April 2019 at 11:58:49 UTC, Ron Tarrant wrote:


And while I'm asking, does an underscore have special meaning 
when used either at the beginning or end of a variable name?


In D, @ is used as Adam has explained as a prefix indicating 
attributes (either user-defined ones or, confusingly enough, some 
of the standard ones).


The only other example of language using @, in an almost but not 
quite completely different way, is C#. It's also a prefix that 
allows you to define names that would collide with reserved 
words, for example string @class = "menu"; Of course you should 
never do this unless you absolutely need for interop.


Underscore prefixes are used in some languages by pure user 
convention mainly for private members (fields), to avoid name 
clashing. For example in D you could have a public property 
length and a private member _length.


Python takes this a step further. Since it supports classes but 
no public/private visibility at all, users and IDEs have convened 
to use (one or two) underscore prefixes to signal members that 
aren't meant to be accessed publicly from outside the class, even 
if there's nothing stopping you (besides auto code completion not 
showing them).


For C and C++ the convention (recognized by the standards) is 
different: names prefixed by any number of underscores are all 
reserved; basically because the global namespace is so badly 
polluted already. In this case I've seen some other annoying 
conventions, for example private member variables being prefixed 
with m_


Re: Poor regex performance?

2019-04-04 Thread XavierAP via Digitalmars-d-learn

On Thursday, 4 April 2019 at 09:53:06 UTC, Julian wrote:


Relatedly, how can I add custom compiler flags to rdmd, in a D 
script?

For example, -L-lpcre


Configuration variable "DFLAGS". On Windows you can specify it in 
the sc.ini file. On Linux: https://dlang.org/dmd-linux.html


Re: Distinguish float and integer types from string

2019-03-11 Thread XavierAP via Digitalmars-d-learn

On Monday, 11 March 2019 at 15:03:39 UTC, XavierAP wrote:


What compiler version are you using? I on the other hand was 
surprised that I needed the try-catch above, after having 
already checked isNumeric. The documentation claims that the 
conversion to int or long would truncate, but my compiler 
(v2.084.0) throws instead.


Of course now I realize that using try-catch I no longer need to 
check isNumeric... My design didn't use try-catch but I had to 
add it because std.conv:to behaves differently from the 
documentation:


https://dlang.org/phobos/std_conv.html#to

Not sure if I need to update my DMD, or it's the documentation 
that's out of date, or something else is wrong.


Re: Distinguish float and integer types from string

2019-03-11 Thread XavierAP via Digitalmars-d-learn

On Saturday, 9 March 2019 at 18:11:09 UTC, Jacob Shtokolov wrote:


One of the task was to take a string from STDIN and detect its 
type.
There were a few options: Float, Integer, string and "something 
else" (which, I think, doesn't have any sense under the scope 
of the task).


Another std-based solution I came up with:

bool isInteger(string str)
{
if(str.isNumeric)
{
try { return str.to!long == str.to!real; }
catch(ConvException) { return false; }
}
else return false;
}

I tried to use std.conv.to and std.conv.parse, but found that 
they can't really do this. When I call `data.to!int`, the value 
of "123.45" will be converted to int!


What compiler version are you using? I on the other hand was 
surprised that I needed the try-catch above, after having already 
checked isNumeric. The documentation claims that the conversion 
to int or long would truncate, but my compiler (v2.084.0) throws 
instead.


Re: Best practices of using const

2019-02-13 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 13 February 2019 at 11:32:46 UTC, envoid wrote:


Is there an article that explains best practices of using const 
in D?


Chapter 8 of Andrei Alexandrescu's book The D Programming 
Language.


Re: static arrays at runtime with templates ?

2019-02-04 Thread XavierAP via Digitalmars-d-learn

On Monday, 4 February 2019 at 19:14:38 UTC, Emil wrote:


Can std.array.staticArray build static arrays with size known 
only at run time ? Now that I am not overcome with enthousiasm 
it looks like it too needs to know the size.


A static array's size must be known (or computed) at compile 
time, by definition... There can be no exception; staticArray() 
gets or infers the size from its template/compile-time arguments.


For one, the trivial example on dlang.org/phobos
auto a = [0, 1].staticArray;
static assert(is(typeof(a) == int[2]));
is equivalent to
int[2] a = [0, 1];
static assert(is(typeof(a) == int[2]));
Is it better? Depends on.? No it really isn't...

However one of the possibilities of D is the ability to generate 
and execute quite some code at compile time by means of 
meta-programming; and I guess here's where staticArray() may end 
up being useful enough to have merited introduction into the std 
library; not for trivial uses where a straightforward T[n] 
declaration is preferable, being possible...


If there is something you want to solve in a program of yours, 
there may be another way, as H.S. Teoh suggests. If you're just 
trying out stuff it's also fine, :) there's still more.


Re: static arrays at runtime with templates ?

2019-02-04 Thread XavierAP via Digitalmars-d-learn

On Sunday, 3 February 2019 at 16:33:48 UTC, Emil wrote:


Is this for real, static arrays at runtime without manually 
allocating memory ? Is this legitimate or should I expect 
problems ?


Static arrays are always allocated at run-time. It's the size of 
the array that must be known at compile-time (in this case via a 
template parameter).


What's the advantage (or the essential difference) of
auto data = static_array!(int, 5);
instead of
int[5] data;
? Just asking ;) but it's good to play.

What does not compile on my end are the run-time parameters (3) 
and (2)...?


Return Value Optimization: specification, requirements?

2019-02-02 Thread XavierAP via Digitalmars-d-learn
I've heard here and there that D guarantees RVO, or is even 
specified to do so...


Is it spelled out in the language specification or elsewhere? I 
haven't found it.


Do you know the exact requirements for RVO or NRVO to be possible 
in theory, and to be guaranteed in practice in D? Does it depend 
only on what is returned, or does it depend how it's constructed?


I know I can debug to find out case by case, but that's the kind 
of C++ stuff I want to avoid... I want to know the 
theory/norm/spec.


Thanks


Re: Doubt about this book: The D Programming Language

2018-12-19 Thread XavierAP via Digitalmars-d-learn

On Sunday, 16 December 2018 at 18:37:15 UTC, Marko wrote:
On Amazon The D Programming Language has good reviews but it's 
8 years old. So is this book still relevant today?


Yes, I would recommend it. It is meant to be comprehensive but 
introductory, so many language or library changes since are out 
of the scope anyway. It's then also quite different from a 
cookbook approach for example -- depends what you're looking for. 
You may perhaps compare it more closely with Ali's book, but 
unfortunately I haven't read this one.


Re: Nested template arguments

2018-08-22 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 22 August 2018 at 14:48:57 UTC, Alex wrote:


Because it could be meant as the argument to some templates to 
the left. Like

(foo!bar)!x

Sure, it would be a coincidence, if both will work. However, 
templates are not something where you can simply imply the 
associative property, I think.


Of course there isn't an associative property... But I was 
thinking that without brackets the parser could fall back to 
whatever default "left to right" precedence, as would happen with 
operators, which needn't be associative either.


Nested template arguments

2018-08-22 Thread XavierAP via Digitalmars-d-learn

Why

foo!bar!x

is not understood as

foo!(bar!x)

but instead gives an error "multiple ! arguments are not allowed"?
Precisely because multiple "!" can never belong to the same 
instantiation, why does the parser not understand without needing 
brackets that the rightmost template should be nested as the 
argument for the next one to the left?


Re: Templated operator overloading

2018-08-22 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 22 August 2018 at 12:36:39 UTC, Simen Kjærås wrote:


Since both your opOpAssigns match equally, the compiler throws 
up. The solution is to add some sort of restriction:


This doesn't happen apparently: the operator has a left and a 
right side, even if both types define the operator, only one of 
them is on the left at each call.


It works now after Ali corrected my stupid syntax :)


Re: Templated operator overloading

2018-08-22 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 22 August 2018 at 13:20:01 UTC, aliak wrote:


"void opOpAssign(string op, T)(ref Tthis, const ref T x)" looks 
like the wrong signature for opOpAssign.


Oh I'll put on my stupid hat now...

I realize I had copy-pasted the wrong syntax from the global 
function attempt, but I swear I thought I had re-typed and tested 
the right one...


It's working now :)


Templated operator overloading

2018-08-22 Thread XavierAP via Digitalmars-d-learn
I've been trying some things to template operator overloads. The 
reason is that I want very similar code for different types, but 
I can't use polymorphism, as they're structs rather than classes. 
Perhaps this choice is not as advantageous as I think, and I may 
change this design from structs to classes, or else the code 
duplication would be small and never subject to change. But now 
I'm just trying for the sake of learning to find out what works 
or not in terms of templated operator overloading, and whether 
the reason something doesn't work is by design and if mentioned 
in the specification, or just an arbitraty result of some 
unspecified parsing/lowering step order, or it depends on the 
compiler (I'm using dmd).


Since there are in my case two similar types (below just a 
minimal dumb proof of concept), I want the operator(s) to work 
within the same type, or also with the other. The following code 
actually works, including type parameter inferrence, and const 
ref to avoid struct copying:


//
import std.stdio;

struct S1
{
void opOpAssign(string op, T)(const ref T x)
{
writeln(this, op, x);
}
}
struct S2
{}

void main()
{   
S1 s1;
S2 s2;
s1 *= s2;
}
//

When I want to have the same operator overloading code in both 
types however, I can't make it work:


//
private mixin template operator(Tthis)
{
void opOpAssign(string op, T)(ref Tthis, const ref T x)
{
writeln(this, op, x);
}
}

struct S1
{
mixin operator!S1;
}
struct S2
{
mixin operator!S2;
}

void main()
{   
S1 s1;
S2 s2;
s1 *= s2; // Error: s1 *= s2 is not a scalar
	s1.opOpAssign!"*"(s2); // Error: template 
test.S1.operator!(S1).opOpAssign cannot deduce function

}
//

And a final try with a global templated function instead of a 
mixin template:


//
private void opOpAssign(string op, Tthis, T)(ref Tthis that, 
const ref T x)

{
writeln(that, op, x);
}

struct S1
{}
struct S2
{}

void main()
{   
S1 s1;
S2 s2;
s1 *= s2; // Error: s1 *= s2 is not a scalar
s1.opOpAssign!"*"(s2); // OK!
}
//


Re: Auto keyword and when to use it

2018-08-22 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 21 August 2018 at 21:37:00 UTC, QueenSvetlana wrote:


I had a misunderstanding about the keyword auto because I 
wrongfully believed that it made the code like Python


Exactly, you are thinking still like D is Python or also 
dynamically typed. :) You will get when compiling errors that 
Python wouldn't detect until run-time (or with your private 
methods).


- A declaration with auto needs to include an initialization.
- The code will be equivalent as if replacing "auto" with the 
inferred type. It is not left for later to check.


I'm not terribly bothered btw by "Type = new Type()" but often 
type names get too long or include namespaces... 
"mylib.numeric.squareObjectWithPointyCorners = new 
mylib.numeric.squareObjectWithPointyCorners()"


Re: Auto keyword and when to use it

2018-08-21 Thread XavierAP via Digitalmars-d-learn

On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:


So I can't declare class level variables with auto, correct? 
only local method variables?


One difference between D's auto and C#'s var or C++'s auto is 
that the latter languages allow automatically typed declarations 
only for local (method/function-scope) variables, and forbid them 
for class or struct member variables (aka fields); whereas D 
allows auto anywhere (even function/method return type! -- which 
C# and C++ allow as well but only case of anonymous 
methods/lambdas).


I'm in favor of the AAA ("Auto" Almost Always) paradigm, but as 
long as the type if obvious to a human reader. I don't favor them 
for numeric types for this reason (non obvious bitsize, 
signedness...) It's up to each programmer. Only if someone likes 
"Type x = new Type()" instead of "auto x = new Type()" I would 
say they're clearly wrong.


Re: New programming paradigm

2017-09-07 Thread XavierAP via Digitalmars-d-learn
On Wednesday, 6 September 2017 at 23:20:41 UTC, EntangledQuanta 
wrote:
So, no body thinks this is a useful idea or is it that no one 
understands what I'm talking about?


I think it may be a good use, although I haven't invested so much 
time looking into your particular application.


It looks like a normal, sane use of templates. This is what they 
are primarily intended for. And yes, combining them with mixins 
provide some great possibilities that are not available in many 
other languages.


Have you seen how D recommends avoiding duplicate code when 
overloading operators, also by means of mixins:

https://dlang.org/spec/operatoroverloading.html#binary

I thought you may come from C since you mention void pointers as 
an alternative. But that is not considered the normal way in D, 
your new way is far better, and more "normal".


It looks you may be mistaking what happens at "run-time", or it 
may be a way of speaking. In D, templates called with different 
types generate different code already at compile-time -- even if 
in the source code you write, it all looks and works so 
polymorphically. This is a similar approach as in C++ and it's 
why D generics are called "templates"; as opposed for example to 
C#, where generics are not compiled into static types and keep 
existing at run-time. Andrei discusses both approaches in his 
book, and why the first one was chosen for D.


Re: multi-dimensional array whole slicing

2017-04-25 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 25 April 2017 at 20:46:24 UTC, Ali Çehreli wrote:


I think it's still consistent because the element type is not 
int in the case of multi-dimensional arrays.

[...]
int[3][4] b;
b[] = [1, 1, 1];


It is consistent, I just miss the possibility to more easily 
initialize multi-dimensional arrays uniformly in the same way as 
uni-dimensional ones.


I do not mean it would be good to change the current behavior. I 
think the best solution would be for D to implement built-in 
truly multi-dimensional arrays like T[,] as well as the existing 
(jagged) arrays of arrays T[][]. That's what C# does. The former 
could maybe even be lowered into jagged arrays (together with 
their initializations and slicings).


But again most people probably don't miss T[,] built-in arrays, 
specially since we can implement such [,] indexing for custom 
types. So there's not a strong use case.


But actually where I'm using multi-dimensional built-in arrays 
right now is in the private storage of a custom multi-dimensional 
type. Then I have the choice of either use them and live with 
this, but forward indexing transparently; or use uni-dimensional 
as private storage and map from 2d to linear during indexing...


Re: function type parameter inference not working

2017-04-25 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 25 April 2017 at 19:57:30 UTC, Ali Çehreli wrote:


This is an intentional limitation of D. It's not possible to 
bind rvalues (temporaries) to reference parameters. The best 
option here is 'auto ref':


Aha I had forgotten about the ref (obviously, otherwise I 
wouldn't have passed a temporary even in the unit test -- I'm 
embarrassed). If that's the reason why it doesn't work I'm 
satisfied.


It would be helpful if the error message talked about the ref 
qualifier as the root cause instead of the consequent failure to 
infer template parameters.


Re: function type parameter inference not working

2017-04-25 Thread XavierAP via Digitalmars-d-learn

On Sunday, 23 April 2017 at 19:40:39 UTC, ag0aep6g wrote:


Please post self-contained code. When I fill the gaps you left, 
it works for me:


Found it! It stops working (DMD v2.073.0 for Windows) if it has 
to infer the type of a temporary local variable -- constructed in 
place of the argument:



struct Matrix(size_t nr, size_t nc) {}
struct Vector(size_t n) {}

void assembleMass1D(Mat, Vec)(ref Mat M, const ref Vec x)
{ /* ... */ }

Matrix!(2,2) M;
Vector!2 V;
assembleMass1D(M, V);  // OK
assembleMass1D(M, Vector!2()); // ERROR template cannot deduce 
function



Is this a bug?


Re: function type parameter inference not working

2017-04-23 Thread XavierAP via Digitalmars-d-learn

On Sunday, 23 April 2017 at 19:40:39 UTC, ag0aep6g wrote:


Please post self-contained code. When I fill the gaps you left, 
it works for me:


Interesting, thanks a lot. I'll test and narrow down what's in my 
code preventing this from working (I can't really think of 
anything) and I'll report back.


function type parameter inference not working

2017-04-23 Thread XavierAP via Digitalmars-d-learn
It's not working for my case, while I see no special reason why 
it couldn't. Also I can't find specific inference rules at 
http://dlang.org/spec/function.html#function-templates


Is it a problem that the types to be inferred are in turn also 
templated? Any workaround that can make inference work? Otherwise 
I would re-consider my design rather than having to specify types 
already available in the runtime arguments :(


void assembleMass1D(Mat, Vec)(ref Mat M, const ref Vec x)
{ /* ... */ }
Matrix!(2,2) M = /* ... */;
Vector!2 V = /* ... */;
assembleMass1D(M, V); // ERROR template cannot deduce function 
from argument types


Re: multi-dimensional array whole slicing

2017-04-23 Thread XavierAP via Digitalmars-d-learn

On Sunday, 23 April 2017 at 09:06:35 UTC, Ali Çehreli wrote:


It took me a while to convince myself that there is no bug 
here. The problem, as is obvious to others, ;) a whole slice of 
a whole slice is still the same slice.


Ha, you're right, I hadn't realized.

But I still have a problem. For both multi-dimensional and 
uni-dimensional arrays a[] and a[][] are the same. And yet, a[] 
has different type in both cases and a[]=1 compiles for 
uni-dimensional but not for multi-dimensional.


Re: multi-dimensional array whole slicing

2017-04-23 Thread XavierAP via Digitalmars-d-learn

On Saturday, 22 April 2017 at 22:25:58 UTC, kinke wrote:


int[3][4] arr = void;
(cast(int[]) arr)[] = 1;
assert(arr[3][2] == 1);


Thanks... I think I prefer to write two loops though :p I wish D 
built-in arrays supported [,] indexing notation like C# (or as 
you can do in D for custom types)


multi-dimensional array whole slicing

2017-04-22 Thread XavierAP via Digitalmars-d-learn

I can do:

int[3] arr = void;
arr[] = 1;

But apparently I can't do:

int[3][4] arr = void;
arr[][] = 1;

What is the best way? What am I missing?


Re: DMD requirements (VC runtime version) where?

2017-04-21 Thread XavierAP via Digitalmars-d-learn

On Friday, 21 April 2017 at 11:37:07 UTC, Mike Parker wrote:

sc.ini manually is the better option if you don't need or want 
the 2015 build tools.


Thanks!

Nevertheless I think it would be good that the supported version 
of VS is documented on the website of DMD, just like it is on 
VisualD's. When the installer is updated, this document/webpage 
can be updated as well.


I don't immediately know how to find VS paths/exes and how to 
insert manually into sc.ini... But the VS extension manager is 
giving me some weird error message, so I'll just switch to 2015, 
even uninstall 2017.


DMD requirements (VC runtime version) where?

2017-04-21 Thread XavierAP via Digitalmars-d-learn
Visual D has just added support for VS 2017 (kudos), whereas 
before I had to stick with 2015 at the latest. But DMD has an 
additional dependency on VS (for x64), and it is not documented, 
as far as I've been able to find, which versions.


So I just tried, and now the DMD Windows installer complains that 
it can't find any compatible versions of MSVC and the Windows 
SDK, after having installed 2017.


Is this documented somewhere that I've missed? Otherwise, would 
it be possible to add this information somewhere, namely which 
versions of what dependencies are required for what features?


Re: Can we disallow appending integer to string?

2017-04-21 Thread XavierAP via Digitalmars-d-learn
On Wednesday, 19 April 2017 at 14:50:38 UTC, Stanislav Blinov 
wrote:

On Wednesday, 19 April 2017 at 14:36:13 UTC, Nick Treleaven


Why is it legal to append an integer?


Because integrals implicitly convert to characters of same 
width (byte -> char, short -> wchar, int -> dchar).


Huh... I hadn't used but I'd been assuming probably biased from 
C# that

str ~ i
would be equivalent to
str ~ to!string(i)
instead of
str ~ cast(char) i

Now I see the problem too...


Re: Use of "T"

2017-04-12 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 12 April 2017 at 14:46:20 UTC, solidstate1991 wrote:


Yes, templates. I've looked this up a bit, and I found it. I 
want to use it to use the dictionaries for different things 
than string<->int conversion.


T is just the common name of a (type) parameter, mostly whenever 
the template is more generic that you can't think of a more 
informative (template) parameter name. Just like you could use 
"str" for a string or "i" for an int name. But in you case you 
could use a more informative name such as "keyType" since you are 
describing keyType -> valueType dictionaries, also called 
associative arrays.


Moreover these dictionaries are built-in basic types in D:
https://dlang.org/spec/hash-map.html

This should be the Dictionary(int), string<->string conversion 
should be done with Dictionary(string). Int<->string should be 
done as Dictionary(string,int) if possible.


So according to the spec linked above, those examples would be 
declared:


string[int] dict1;
string[string] dict2;
int[string] dict3;


Re: Why is this legal?

2017-03-30 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 29 March 2017 at 09:50:10 UTC, abad wrote:


Is this on purpose and what's the rationale?


In Andrei's book, chapter 6.9.1 "the non virtual interface (NVI) 
idiom" answers your question. It cites this article by Herb 
Sutter as the originator of the idea:


http://www.gotw.ca/publications/mill18.htm


Re: How to continue after the book?

2017-03-28 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 28 March 2017 at 07:27:31 UTC, I Lindström wrote:


I do have a need for which I've been trying out a few languages 
and D seems by far the best for me. Should I just start doing 
that project and learn as I go by googling and asking here, or 
are there some other things you did before starting your first 
"real" project.


If you have a project in mind and that's the reason why you've 
looked into D, just start it now. After reading a book and 
preferably before, doing is the way to learn programming.


Worst case, you'll decide later to re-design a lot of your code. 
But you will have used your time in learning much more, more 
relevant for your specific needs, than with any toy exercises.


Re: how to define my own traits

2017-03-27 Thread XavierAP via Digitalmars-d-learn

On Monday, 27 March 2017 at 16:28:13 UTC, Gary Willoughby wrote:


Even Andrei was baffled:

http://forum.dlang.org/thread/nepm2k$311l$1...@digitalmars.com


I see... And Walter went further and reported it as a DMD bug 
(still open clearly).


It's what I mean. This strange behavior is more typical of C++, 
in D this is a rare corner case, but I can sympathize if Andrei 
and Walter don't want to accumulate issues like this one in the 
language, and on top of that fill the standard library and user 
code with this kind of workarounds.


First the solution is a hack, but ideally it wouldn't be needed, 
the original code should have worked with inout ranges all the 
same. So ideally DMD should be fixed to make the hack 
unnecessary. Andrei's proposal of deprecating inout entirely is 
also consistent at the expense of losing a feature.


When I first read about inout as a device to obviate code 
duplication typical in C++ const ref overloads, I liked it but I 
assumed it was implemented by lowering it into the actual 
duplicate overloads. Though I'm not even sure right now if such 
overloading is allowed in D.


I haven't tried if this happens with other compilers than DMD...


Re: how to define my own traits

2017-03-27 Thread XavierAP via Digitalmars-d-learn

On Monday, 27 March 2017 at 00:49:14 UTC, Moritz Maxeiner wrote:


Have you tried it without the dummy parameter on the example 
given in the bug report [2]?


I see, thanks for finding it! Looks a bit hacky but I can live 
with it.


Indeed if I remove the argument from Phobos, Martin's example 
breaks again.


Incidentally, everything keeps working if I qualify the function 
literal as

(inout int = 0) pure


how to define my own traits

2017-03-26 Thread XavierAP via Digitalmars-d-learn
I've looked into Phobos to emulate it when defining my own trait 
template, and when I see this:


module std.range.primitives;
// ...
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {}   // can test for empty
r.popFront;   // can invoke popFront()
auto h = r.front; // can get the front of the range
}));

I wonder, why that unused parameter (inout int = 0)?
In my project () { /* ... */ } works the same for a custom trait.


Re: really why module declarations?

2017-03-26 Thread XavierAP via Digitalmars-d-learn

On Sunday, 26 March 2017 at 20:58:24 UTC, Adam D. Ruppe wrote:


Module declarations are only optional in the most trivial case 
that is rarely useful in real world code. I recommend you 
ALWAYS use them (and always put a ddoc comment on them!), and 
moreover that you avoid top name modules (use 
`myproject.modname` instead of `modname`) to avoid conflicts.


OK I was already doing it all this in the multi-file project. I 
was curious but I guess it's long to explain the different things 
that can go wrong if one doesn't declare module names.


Followup question: if I am inside module myproj.pack1.mod1 and 
want to import myproj.pack1.mod2... should I import 
myproj.pack1.mod2; or import mod2; ?


really why module declarations?

2017-03-26 Thread XavierAP via Digitalmars-d-learn
I've perused both the spec[1] and Andrei's book, and I the idea I 
get is that module declarations are optional, recommended only in 
case of file names not being valid D names. But in the community 
(and Phobos) I see it's strongly recommended and used throughout.


What's the reason? If the declaration overrides the path 
(provided the file is found) rather than enforcing path 
consistency by outputting a compile error, then what's the 
benefit of module declarations, if we have to be disciplined to 
keep it consistent with paths anyway?


I'm busy starting my first big multi file D project, thanks for 
any feedback!



[1] https://dlang.org/spec/module.html#ModuleDeclaration


Re: recommend Git GUI client for Linux?

2017-03-25 Thread XavierAP via Digitalmars-d-learn

On Thursday, 2 March 2017 at 06:16:09 UTC, Patrick Schluter wrote:


Here [1] is the official git page listing all GUI clients for 
different plartforms.
I use GitExtensions[2] and I like it a lot. It works very well 
and all the complicated stuff can be done from the GUI 
interface and also from command line.


Patrick thanks for the great recommendation! I'm using 
GitExtensions now on Windows. In comparison I wonder how GitHub's 
desktop client is even allowed on the Internet.


For Linux (Lubuntu) any recommendation among these?
https://git-scm.com/download/gui/linux


Re: GitHub detects .d source as Makefile?

2017-03-20 Thread XavierAP via Digitalmars-d-learn

On Sunday, 19 March 2017 at 21:53:17 UTC, Seb wrote:


FWIW this has been fixed by Martin last summer, but the people 
at GitHub aren't very responsive. The PR is still pending :/

More info:

https://trello.com/c/g9PB3ISG/233-improve-d-language-recognition-on-github
https://github.com/github/linguist/pull/3145


Thanks for the info. Whole thing looks beyond me, plus I'm new to 
GH so not sure what's polite, but I'll try to remember pinging 
after a while whenever no one does.


In the meantime my file is finally ok, after I added an override 
in the .gitattributes file,* it looks like there was a time delay 
from the language being re-classified by the GitHub Linguist 
until it was processed anew by the appropriate highlight parser. 
Even though the majority language stat for the repository had 
updated instantly.



* Fyi these are the lines I added to my .gitattributes file:

*.d  linguist-language=D
*.di linguist-language=D


Re: Error: out of memory

2017-03-19 Thread XavierAP via Digitalmars-d-learn

On Sunday, 19 March 2017 at 20:50:50 UTC, Gand Alf wrote:


just use DMD with the -m64 parameter ;)


then you should get a x64 DMD


No, at least afaik, then you tell DMD to make a x64 exe, but DMD 
itself (this particular Windows version) is still a 32-bit exe.


Re: Error: out of memory

2017-03-18 Thread XavierAP via Digitalmars-d-learn

On Saturday, 18 March 2017 at 20:39:20 UTC, StarGrazer wrote:


about 2GB before it quites. It also only uses about 12% of cpu.

I have 16 GB total memory and about that free. Surely dmd could 
do a better job? Any way to get it to do such a thing like set 
the maximum amount of memory it can use?


Any 32-bit process gets 2 GB of memory space, regardless of how 
much physical memory you have.


https://msdn.microsoft.com/library/aa366778.aspx

If you used a 64-bit version of dmd your problems should go 
away... If the binary for Windows isn't available from the 
downloads here, you can try compiling it from source yourself... 
But I'm sure someone somewhere has done it already. Or you can 
try another compiler such as GDC, which is available for Windows 
x64.


Also 12.5% probably means 100% of one of 8 cores in your CPU.


Re: GitHub detects .d source as Makefile?

2017-03-18 Thread XavierAP via Digitalmars-d-learn

On Saturday, 18 March 2017 at 10:52:31 UTC, XavierAP wrote:


Thanks! It seems I can also override the language detection in 
.gitattributes, and it is now fixed :)


The majority language assigned to the whole repository is fixed, 
but alas syntax highlighting in heatsim.d is still wrong. Looks 
like this is handled by code in a different repository[1] from 
linguist. I'll look at the issues on both...



[1] 
https://github.com/github/linguist/blob/master/vendor/README.md


Re: GitHub detects .d source as Makefile?

2017-03-18 Thread XavierAP via Digitalmars-d-learn

On Saturday, 18 March 2017 at 01:33:13 UTC, David Nadlinger wrote:


The code GitHub uses to infer source file languages is 
open-source, and – fittingly – available on GitHub: 
https://github.com/github/linguist


You should check the issues for reports of similar D-related 
problems, and if there are none, create a new one. Or, better 
yet, submit a pull request with an appropriate fix.


Thanks! It seems I can also override the language detection in 
.gitattributes, and it is now fixed :)


I'll take a look around and file an issue if it doesn't exist. 
Probably not PR myself as I don't know Ruby.


As a workaround, adding a "module …;" declaration to your file 
should help. You probably want to be doing that anyway.


I know about this and I've read the spec and Andrei's book yet 
I'm not entirely clear why it is such a mandatory practice. I'll 
ask in a new thread...



[1] 
https://github.com/github/linguist/blob/master/lib/linguist/documentation.yml


GitHub detects .d source as Makefile?

2017-03-17 Thread XavierAP via Digitalmars-d-learn
So I have put my first code even on GitHub (comments welcome :)) 
and GitHub seems to detect the wrong language, even if I'm not 
familiar with this GH feature.


https://github.com/XavierAP/etc/tree/master/heatsim

The repository itself ("etc") is flagged as been written in 
Makefile? Right now I have only two source files (and a couple of 
images and a pdf). If I look at syntax highlighting online, one 
of them main.d seems highlighted in D ok. But the other one 
heatsim.d is not correctly highlighted.


https://github.com/XavierAP/etc/blob/master/heatsim/src/heatsim.d
https://github.com/XavierAP/etc/blob/master/heatsim/src/main.d

Is this a known issue with D on GitHub? Should I report it I 
guess?
How smart is GH that it doesn't look at the file extension? What 
happened?


Re: first try

2017-03-17 Thread XavierAP via Digitalmars-d-learn

On Friday, 17 March 2017 at 00:35:32 UTC, Philip Miess wrote:


https://gitlab.com/pmiess/101gamesDlangComputerGames/blob/master/
aceyducy.d


You don't need string literals to be verbatim (r"") in order to 
insert newlines as in the code (without escape sequences). All 
string literals behave this way in D -- this is different from C# 
for example.


Re: Sorting Assosiative Arrays and Finding Largest Common Substring

2017-03-16 Thread XavierAP via Digitalmars-d-learn

On Thursday, 16 March 2017 at 16:02:13 UTC, helxi wrote:


1. .length is of type ulong


Either use auto or if needed size_t. As Thedeemon says this is an 
alias of ulong on 64-bit and uint on 32.


https://dlang.org/spec/hash-map.html


Re: Phobos function to check if files are identical?

2017-03-14 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 14 March 2017 at 18:26:52 UTC, flamencofantasy wrote:


  import std.mmfile;

  auto f1 = new MmFile("file1");
  auto f2 = new MmFile("file2");

  return f1[] == f2[];


Nice! I don't have experience with memory-mapped files. What are 
the pros and cons?


Re: Phobos function to check if files are identical?

2017-03-14 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 14 March 2017 at 08:12:16 UTC, Andrea Fontana wrote:


First I would check if the files have different size or if they 
are the same file (same path, symlink, etc).


Good idea. Good reason to have it in std.file. There might also 
be platform dependent shortcuts?


Re: Phobos function to check if files are identical?

2017-03-13 Thread XavierAP via Digitalmars-d-learn

On Monday, 13 March 2017 at 17:47:09 UTC, H. S. Teoh wrote:


Binary comparison is easy. Just read the files by fixed-sized 
chunks and compare them.


Follow up question... What is the best @safe way? Since 
File.byChunk() is @system. Just out of curiosity, I would rather 
use it and flag my code @trusted, although I guess there could be 
concurrency issues I have to take into account anyway... anything 
else?


Re: code folding

2017-03-13 Thread XavierAP via Digitalmars-d-learn
On Tuesday, 14 March 2017 at 00:38:12 UTC, Vladimir Panteleev 
wrote:


If you have enough declarations in one file that they call for 
code folding, it may be better to move them to a separate 
module. Public imports and aliases allow doing this without 
breaking any code.


[...]

Generally speaking, I would recommend to simply avoid code 
folding altogether:


https://blog.codinghorror.com/the-problem-with-code-folding/


Indeed good point:
http://stackoverflow.com/questions/475675/when-is-a-function-too-long


Re: Phobos function to check if files are identical?

2017-03-13 Thread XavierAP via Digitalmars-d-learn

On Monday, 13 March 2017 at 17:47:09 UTC, H. S. Teoh wrote:


Why it is not easy to do by hand?


Sorry typo, I had intended to type "I know it is easy"


Re: code folding

2017-03-13 Thread XavierAP via Digitalmars-d-learn

On Monday, 13 March 2017 at 17:29:41 UTC, Inquie wrote:


I have been using

static if(true)
{
... junk
}


Indeed #region is part of the C# specification, even if it has no 
effect on the code. (The specification does not say anything 
about folding/collapsing, just about "marking sections of code", 
although I guess most IDEs supporting it will follow the example 
of MS's reference implementation.)


Short answer, D does not have this, as far as I know.

I don't really think it's good substitute practice to insert 
meaningless static if(true)... Even if you're really used to that 
feature, and even if you're right that it does the job and 
doesn't change the generated code.


Unfortunately you can't get this folding easily (I'm sure some 
Vim wizard would come up with something). Instead if you want to 
mark regions of code, that's what comments are for. You can't get 
the folding you want unfortunately (outside of naturally existing 
bracket pairs) but you can use your editor to search forward and 
backward in the file for whatever text, e.g.


//region: foo//


Re: Declaring interfaces with a constructor

2017-03-13 Thread XavierAP via Digitalmars-d-learn

On Monday, 13 March 2017 at 02:15:21 UTC, David  Zhang wrote:
What it says on the tin. Is there a way to create interfaces 
with a constructor or must I use an abstract class.


What do you want to do in your constructor? I can't think of 
anything that wouldn't change some state, either of the class 
(but interfaces aren't allowed to have fields either, precisely 
because they may not have state), or the global state (worse...). 
Just curious.


Additionally, is there a way to force the linker to link a 
function in a class without an implementation with another that 
does have an implementation?


I'm not sure if you mean the same as generating "interface files"?
[1] https://dlang.org/dmd-windows.html#interface-files


Re: Can you fix this code to avoid using pointers?

2017-03-13 Thread XavierAP via Digitalmars-d-learn

On Monday, 13 March 2017 at 14:47:20 UTC, H. S. Teoh wrote:
On Sat, Mar 11, 2017 at 08:07:39PM +, XavierAP via 
Digitalmars-d-learn wrote: [...]

But I still like the version with pointers ;)


There's nothing wrong with using pointers in D.  The fact that 
D alleviates most cases of (explicit) pointers is a testament 
to just how awesome it is. ;-)  But that shouldn't deter anyone 
from using (explicit) pointers once in a while.  In fact, D 
makes it such that it's a lot safer using pointers than in 
C/C++, mainly because it alleviates most of the dangerous use 
cases for pointers so what's left is generally harmless stuff. 
Unless your code for whatever reason is involved in heavy 
pointer hackery (like OS writing), but that's not a typical use 
case.


I did it again ;)

enum params = [
"Radius of disk in m",
"Integration step size along radius",
"Total integration time in s",
"Integration step size along time",
"Time step size for output",
"Initial temperature in C",
"Edge temperature in C",
"Flow temperature in C",
"2D conductivity in W K^-1",
"2D diffusivity in m^2 s^-1",
"Convective coefficient in W m^-2 K^-1" ];

real*[params.length] vals = [
, , , , ,
, , ,
, ,  ];

import std.conv: to;

/* ... */

foreach(i, param; params)
{
/* ... */
*vals[i] = to!real(val);
}

I had the same requirement to make separate named scalars instead 
of an array; but also an array was handier to assign the values 
inside a loop; and I needed a readable  and simple way to map 
between them. An array of pointers is perfect I think.


And the only dangerous thing I could do with the pointers is 
arithmetic on them instead of the pointed values, but: "pointer 
arithmetic not allowed in @safe functions." So all is good :)


Phobos function to check if files are identical?

2017-03-13 Thread XavierAP via Digitalmars-d-learn
It's not easy to do by hand of course, but I was wondering if 
there was one simple function taking two file names and just 
returning a bool or something like that. I haven't found it in 
std.file.


If such a function doesn't exist in Phobos but there's a good 
implementation in some other library, I'm interested to know. 
Although this time it's for a unit test so I'd rather implement 
it in two lines than add a dependency.


And otherwise to write it by hand, how do you think is the best 
way? And in terms of performance? By chunks in case of a binary 
comparison? And what about the case of a text comparison?


Thanks


Re: Code style for property

2017-03-12 Thread XavierAP via Digitalmars-d-learn

On Sunday, 12 March 2017 at 11:15:04 UTC, Nicholas Wilson wrote:

On Sunday, 12 March 2017 at 10:47:35 UTC, Andrey wrote:
And I want make access to read x, y and bar. Probably I should 
add prefix for private members, that is a question: what 
prefix should I use? Now I use prefix p_ (from the word 
property), but maybe prefix m_ is better and you need to use 
it for all private members?


A single leading underscore is usually used to denote a private 
variable ( names prefixed with two leading underscores are 
reserved for use by the compiler).


If you need any prefix at all, a single underscore is enough, and 
it's also the tradition in other languages such as Python, C#... 
Whether a private member is exposed as property or in some other 
way, can be seen in the getter/setter, no need to classify it 
into the member declaration.


C++ kind or requires a letter on top such as m_ simply because 
any identifiers starting with an underscore are (mostly and 
certainly at the global scope) reserved (namespace pollution 
anyone?).


It's really up to you, we won't call the police ;)


Re: Best ways to declare associative arrays

2017-03-12 Thread XavierAP via Digitalmars-d-learn

On Sunday, 12 March 2017 at 07:58:40 UTC, helxi wrote:


string[string] change(ref string[string] arg_array){
//..
arg_array["first"] = strip(readln());
//..
arg_array["second"] = strip(readln());
//..
return def;
}


Nicholas clarified why your declaration was wrong, but there are 
several strange things in your code that you may want to 
re-think. Also it looks to me that an associative array is not 
the most appropriate type for what you want to do.


To call a function you just pass the names of the arguments, not 
their types. So simply change(test), NOT change(string[string] 
test)


arg_array is an in-out (ref) parameter, but change() returns 
another value of the same type, def, not defined in your code, 
and which you do not use in main(). I think you may be interested 
only in changing arg_array, so the signature could be instead: 
void change(ref ...)


What you seem to want from your associative array is to associate 
two strings, "first" and "second" with two values (strings from 
the user), and only two. An associate array is more flexible than 
that, which is bad, you want your code to restrict you away from 
errors. For example if you keep using an associative array you 
could at the end of change(): assert(arg_array.length == 2);


I wonder if it's not enough and better for you to use a plain 
array. Keys "first" and "second" are not more informative than 
numeric indices. You may also use the advantage that an array can 
be hard-typed as fixed-length if this is known at compile time 
(and if you don't declare it with new), so it restricts your code 
in the perfect way:


void change(ref string[2] arg_array) {
arg_array[0] = strip(readln());
arg_array[1] = strip(readln());
}
void main() {
string[2] test;
change(test);
}

Also another disadvantage of associative arrays is that they are 
not ordered, so if for example in main() you read through the 
values in test with a foreach loop, you may get the result in any 
order (second first, and first second is possible). A simple 
array will keep order 0, 1.


If you were so bummed about using 0-1 instead of "first"-"second" 
you could define:


enum lineKey :size_t {
first = 0,
second
}
void change(ref string[2] arg_array) {
arg_array[lineKey.first ] = strip(readln());
arg_array[lineKey.second] = strip(readln());
}

But at least to me it looks worse. As a programmer you already 
know that the first index is 0 and 1 comes next.


Re: Can you fix this code to avoid using pointers?

2017-03-11 Thread XavierAP via Digitalmars-d-learn

On Saturday, 11 March 2017 at 19:15:59 UTC, H. S. Teoh wrote:


What about just:

foreach (const ref p; [in1, in2, in3, in4])


I would think there will be already one copy from the local 
parameter variables to the in situ array. Then from that one into 
the for each element it's ref'd all right. But I'm afk and can't 
test.


Like the other copy I missed and Adam spotted when passing the 
arguments with missing ref qualifiers..


I realized that the code that sparked the question made no sense 
and should be done in a different way... As is always the case 
when these questions come up.

But I still like the version with pointers ;)


Re: Can you fix this code to avoid using pointers?

2017-03-11 Thread XavierAP via Digitalmars-d-learn

On Saturday, 11 March 2017 at 13:44:30 UTC, Satoshi wrote:


void calc(in double[] array...) {
foreach (x; array) { }
}


To do what I want it should be foreach(ref x; array) -- or const 
ref. But also I don't want to modify the function signature, 
certainly in this way. In another situation yes, but the 
arguments are very different magnitudes, for example 
temperatures, conductivity, heat power, etc. They should be 
separate arguments with self-documenting names. And it's not 
worth the bother to define a struct type for them as a set. 
Specially since this is an internal implementation "problem" that 
shouldn't affect the outer interface.


I know there's something in std.algorithm for this, but afaik it 
would be relatively bloated compared to this pointer solution. In 
C++ I would use a  instead of a *pointer, but I 
actually think C++ references are redundant with pointers, not 
much safer, and plain confusing.


I guess it's a not a common case because if a type is non trivial 
to copy it should probably be a class, which is already assigned 
by reference so I wouldn't need the pointer/ref.


Re: Can you fix this code to avoid using pointers?

2017-03-11 Thread XavierAP via Digitalmars-d-learn

On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote:
I do not really think it's a bad solution, to check several 
scalar arguments that must obey the same condition; just 
wondering if you have better ideas. Try to avoid modifying the 
function's signature and defining custom types, unless you have 
a really terrific idea.


void calc(double in1, double in2, double in3, double in4)
in {
   foreach(const p; [, , , ])
  enforce(*p > 0);
}
body { /* ... */ }


Please imagine double is a type that I wanted to avoid copying, 
just check by ref. Same question :p


Re: Can you fix this code to avoid using pointers?

2017-03-11 Thread XavierAP via Digitalmars-d-learn

Oh... please forget it
What a terrible example :p I forgot why I was using pointers at 
all... I must have had a reason to write this in the past ???


Can you fix this code to avoid using pointers?

2017-03-11 Thread XavierAP via Digitalmars-d-learn
I do not really think it's a bad solution, to check several 
scalar arguments that must obey the same condition; just 
wondering if you have better ideas. Try to avoid modifying the 
function's signature and defining custom types, unless you have a 
really terrific idea.


void calc(double in1, double in2, double in3, double in4)
in {
   foreach(const p; [, , , ])
  enforce(*p > 0);
}
body { /* ... */ }



Re: DMD default safety command line switch

2017-03-09 Thread XavierAP via Digitalmars-d-learn

On Friday, 10 March 2017 at 01:17:57 UTC, Jack Stouffer wrote:

On Friday, 10 March 2017 at 01:13:26 UTC, XavierAP wrote:

On Friday, 10 March 2017 at 00:48:39 UTC, Jack Stouffer wrote:
Don't know the history, but as recently as a week ago Andrei 
has argued against such behavior has balkanizing the 
community.


What behavior? Anyway my question is answered, thanks :)


Changing default behavior which results in incompatible code.


Aha of course I agree. No language wants to do this, it goes 
beyond what is referred as community. But yeah look what happened 
to Python 3.x




Re: DMD default safety command line switch

2017-03-09 Thread XavierAP via Digitalmars-d-learn

On Friday, 10 March 2017 at 01:13:26 UTC, XavierAP wrote:

What behavior? Anyway my question is answered, thanks :)


What behavior is a rhetorical question, meaning that I don't 
really want it to be answered 0;)


Re: DMD default safety command line switch

2017-03-09 Thread XavierAP via Digitalmars-d-learn

On Friday, 10 March 2017 at 00:48:39 UTC, Jack Stouffer wrote:
Don't know the history, but as recently as a week ago Andrei 
has argued against such behavior has balkanizing the community.


What behavior? Anyway my question is answered, thanks :)


Re: @safe console input?

2017-03-09 Thread XavierAP via Digitalmars-d-learn

On Thursday, 9 March 2017 at 23:55:35 UTC, Adam D. Ruppe wrote:

Just wrap it in a @trusted function.


I knew this answer already of course ;) but I take it as implying 
that there is no other way.


Actually I really wonder why std.stdio.readln() itself is not 
flagged @trusted. I wouldn't think such a function skips any 
buffer bounds checking, even in -release -- having to wait for 
user input anyway performance is no issue.


can I overload operators as extension methods?

2017-03-09 Thread XavierAP via Digitalmars-d-learn
The same way as T.foo() is lowered to foo(T) if no such member is 
defined inside the type. It would allow me to extend 3rd party 
types with operator notation without wrapping them.


After trying and reading the specification, looks like nuts, but 
just wanted to confirm. Thx


@safe console input?

2017-03-09 Thread XavierAP via Digitalmars-d-learn
I was surprised by a compiler message saying that 
std.stdio.readln() (and specifically the overload without 
arguments) is not safe but @system.


Actually I was using it only to pause execution until the user 
presses Enter. So how else could I do this within a @safe 
environment?


And more generally, is it possible to get user console input in a 
@safe way?


DMD default safety command line switch

2017-03-09 Thread XavierAP via Digitalmars-d-learn
Andrei's 2010 book states that the default safety level can be 
changed from @system to @safe by means of a -safe command line 
switch, in the case of the DMD compiler. Now I've tried it and 
it's not recognized.


Was this feature remove on purpose? I could imagine that.

The default safety keeps being @system, right?

PS I've found this old thread... I'm looking for a bit less long 
answer to read ;)

http://forum.dlang.org/thread/hcqb44$1nc9$1...@digitalmars.com


Re: DUB specify version identifier on command line?

2017-03-08 Thread XavierAP via Digitalmars-d-learn

On Wednesday, 8 March 2017 at 02:15:00 UTC, Nicholas Wilson wrote:
Setting version identifiers is done by the `-version=ident` 
command line flag (this is equivalent to `version = ident` at 
source level) .
This should therefore be settable by the "dflags" dub 
configuration setting.


The way I would do it would be to have a custom configuration 
that sets "dflags" : [ "other normal flags", "-version= 
MemoryDebug"]


and then build the MemoryDebug dub configuration.

Hope that makes sense.


Yes... Although I was looking for a command line parameter for 
dub, not dmd, but apparently it's impossible. So thanks for 
pointing to the DFLAGS possibility, it has worked. :) I still 
prefer this for building different versions rather than changing 
the dub.json file every time. Thanks!


Re: Best memory management D idioms

2017-03-07 Thread XavierAP via Digitalmars-d-learn

On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote:
To avoid this from the beginning, it may be better to use 
allocators. You can use "make" and "dispose" from 
std.experimental.allocator the same way as New/Delete.


OK I've been reading on std.experimental.allocator; it looks 
really powerful and general, more than I need. I see the 
potential but I don't really have the knowledge to tweak memory 
management, and the details of the "building blocks" are well 
beyond me.


But even if I don't go there, I guess it's a good thing that I 
can change my program's allocator by changing one single line or 
version assigning theAllocator, and benchmark the results among 
different possibilities.


I see the default allocator is the same GC heap used by 'new'. 
Just for my learning curiosity, does this mean that if I 
theAllocator.make() something and then forget to dispose() it, it 
will be garbage collected the same once no longer referenced? And 
so are these objects traversed by the GC?


I've also looked at mallocator, [2] can it be used in some way to 
provide an allocator instead of the default theAllocator? As far 
as I can tell mallocator is not enough to implement an 
IAllocator, is there a reason, or where's the rest, am I missing 
it?



[1] https://dlang.org/phobos/std_experimental_allocator.html
[2] 
https://dlang.org/phobos/std_experimental_allocator_mallocator.html


DUB specify version identifier on command line?

2017-03-07 Thread XavierAP via Digitalmars-d-learn
I'm talking about the conditional compilation keyword "version", 
not about version strings. I've looked in DUB's help and 
reference [1][2] but can't seem to find how to solve my problem. 
On the command line it seems to be possible to specify debug 
identifiers, but not version identifiers. [3]


It came up while trying to do something specific, so I'll explain 
this. I'm learning and trying things, and I was playing with 
dlib.core.memory. Before moving to the next thing I wanted to try 
printMemoryLog(). This outputs memory debugging info, only when 
compiled with version(MemoryDebug) [3].


I'm working with Visual D. However for 3rd party package 
dependencies it's simpler to compile them with dub, and have VS 
find the lib for my client project. Without the version 
identifier, my program works: compiles, links to dlib, and runs 
ok. Then I instruct VS to define version(MemoryDebug) for some 
configuration. No matter how I re-run dub to build dlib, I get 
linking errors from the additional functions defined in the 
imported dlib source which aren't found in the binary lib.


I guess it's also possible to specify this by adding to the 
dub.json file [2], but for me it's more flexible if I can leave 
it alone and compile different versions from the command line 
alone. But if the json is the only way please let me know. 
Otherwise what am I missing? Thanks in advance.



[1] http://code.dlang.org/docs/commandline#build
[2] http://code.dlang.org/package-format?lang=json#version-specs
[3] https://dlang.org/spec/version.html#DebugCondition
[4] 
https://github.com/gecko0307/dlib/blob/master/dlib/core/memory.d


  1   2   >