Re: Can't make inout work.
On 17/03/2019 18:34, Kagamin via Digitalmars-d-learn wrote: On Saturday, 16 March 2019 at 14:57:35 UTC, Paul Backus wrote: This code fails to compile if you change `auto s2` to `const s2`--in other words, it has the same problem as the original example. Maybe there's not much need for qualifiers anyway. This is what I meant as well. diniz
Re: Block statements and memory management
On 16/03/2019 11:19, Dennis via Digitalmars-d-learn wrote:
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as in
{int a = 10;}
it disappears complete from the memory when the scope finishes? Or does it
remain in some part of the memory? I am thinking of using scopes to make
optimized programs that consume less memory.
In general, you want variables to have no larger scope than needed, so in large
functions reducing the scope may be useful. When it comes to efficiency however,
doing that is neither necessary nor sufficient for the compiler to re-use
registers / stack space. I looked at the assembly output of DMD for this:
```
void func(int a);
void main()
{
{
int a = 2;
func(a);
}
{
int b = 3;
func(b);
}
}
```
Without optimizations (the -O flag), it stores a and b on different places in
the stack.
With optimizations, the values of a and b (2 and 3) are simply loaded in the EDI
register before the call.
Removing the braces doesn't change anything about that.
The compiler does live variable analysis [1] as well as data-flow analysis [2]
to figure out that it's only needed to load the values 2 and 3 just before the
function call. This is just a trivial example, but the same applies to larger
functions.
In any case, for better memory efficiency I'd consider looking at reducing
dynamic allocations such as new or malloc. Memory on the stack is basically free
compared to that, so even if adding lots of braces to your code reduces stack
memory, chances are it's a low leverage point.
[1] https://en.wikipedia.org/wiki/Live_variable_analysis
[2] https://en.wikipedia.org/wiki/Data-flow_analysis
Just to add a bit on what has been said:
* Register allocation (see wikipedia) is a well-researched area.
* By coding that way, you force the compiler to optimise *a certain way* which
may prevent it to perform other, more relevant optimisations.
* You cannot beat the knowledge in that domain, it is simply too big and
complex, just be confident.
diniz
Re: Can't make inout work.
PS: the chapter of Ali Çehreli's book on func args is great: http://ddili.org/ders/d.en/function_parameters.html diniz
Re: Can't make inout work.
On 16/03/2019 04:49, Paul Backus via Digitalmars-d-learn wrote:
On Friday, 15 March 2019 at 23:57:15 UTC, aliak wrote:
Anyone knows how to make this work?
You need an explicit `inout` on the return value of `make`:
auto ref make(T)(inout auto ref T value) {
return inout(S!T)(value);
}
I think (but may be wrong) that you don't need inout here, since a plain 'ref'
will (and does) work. This is accepted by me (I added vars to make the code
clearer to myself):
struct S(T) {
T value = T.init;
}
auto ref make(T)(ref T value) {
return S!T(value);
}
auto ref f(T)(ref S!T s) {
return make(s.value);
}
void main() {
class C {}
C c ;
auto s1 = S!C(c) ;
auto s2 = make!C(c) ;
auto s3 = f!C(s2) ;
}
Re: local class instance (at module-level)
On 15/03/2019 00:45, ag0aep6g via Digitalmars-d-learn wrote:
On 14.03.19 20:43, Jacob Carlborg wrote:
class C {
uint i ;
this (uint i) {
this.i = i ;
}
this (uint i) shared {
this.i = i ;
}
this (uint i) immutable {
this.i = i ;
}
}
__gshared c0 = new C(0);
shared c1 = new shared C(1);
immutable c2 = new immutable C(2);
You only need one of the constructors depending on if you want a __gshared,
shared or immutable variable.
If you make it `pure`, you can use the same constructor in all cases:
class C {
uint i ;
this (uint i) pure {
this.i = i ;
}
}
__gshared c0 = new C(0);
shared c1 = new shared C(1);
immutable c2 = new immutable C(2);
all right, thank you!
Re: bug in doc?
On 14/03/2019 15:52, H. S. Teoh via Digitalmars-d-learn wrote:
On Thu, Mar 14, 2019 at 03:22:52PM +0100, spir via Digitalmars-d-learn wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
==> Error: non-constant expression `["foo":5L, "bar":10L, "baz":2000L]`
Also: I don't understand the error message:
* What is non-constant in the *expression*?
* And why should it be constant at all?
(Removing "immutable" does not help...)
[...]
It's a well-known limitation. The workaround is:
immutable long[string] aa;
static this() {
aa = [
"foo" : 5,
...
];
}
All right! No language has to be perfect... (I'm joking). But the doc (the
language ref for the matter) should definitely say what you just explained
above, shouldn't they? I actually think clearly stating limitations is a +++.
(Like an industry company that does not make perfect product but has great
client support.)
diniz
Re: local class instance (at module-level)
On 14/03/2019 12:16, H. S. Teoh via Digitalmars-d-learn wrote:
On Thu, Mar 14, 2019 at 12:05:22PM +0100, spir via Digitalmars-d-learn wrote:
I desperately try to declare/define/initialise a simple class instance
at module-level. This is a special (conceptually static and immutable)
instance used as a "marker", that just should exist and be accessible
by methods of this class and/or other classes defined in the same
module. (Thus I don't care if TLS.) I use it as a remplacement for
null, to avoid semantic confusion and unhelpful segfaults in case of
bug.
Does this work?
class C { ... }
immutable C c0;
static this() {
c0 = new C(...);
}
T
Oh yes, that was it ! Thank you very much.
diniz
bug in doc?
https://dlang.org/spec/hash-map.html#static_initialization: immutable long[string] aa = [ "foo": 5, "bar": 10, "baz": 2000 ]; ==> Error: non-constant expression `["foo":5L, "bar":10L, "baz":2000L]` Also: I don't understand the error message: * What is non-constant in the *expression*? * And why should it be constant at all? (Removing "immutable" does not help...) diniz
local class instance (at module-level)
I desperately try to declare/define/initialise a simple class instance at
module-level. This is a special (conceptually static and immutable) instance
used as a "marker", that just should exist and be accessible by methods of this
class and/or other classes defined in the same module. (Thus I don't care if
TLS.) I use it as a remplacement for null, to avoid semantic confusion and
unhelpful segfaults in case of bug.
I have tried a number of options and never manage to do it, including:
* [C/auto/static immutable c0] = new C(0) ;
* C c0 ; c0.i = 0 ;
* defining a static this()
* more...
The most confusing error is:
Error: variable `_base.c0` is a thread-local class and cannot have a static
initializer. Use `static this()` to initialize instead.
I also could not find any information --for a while, repeatedly, since I can go
on developing in the meantime, using null instead. I'm bluffed and confused,
since there is nothing weird in that, is there? (the compiler can just allocate
it in static mem and take the address)
Reduced test case:
===
class C {
uint i ;
this (uint i) {
this.i = i ;
}
}
// error
auto c0 = new C(0) ;
void main () {
// ok
auto c0 = new C(0) ;
}
===
I would enjoy an explanation (or a pointer to) in addition to a solution.
Thank you,
diniz
PS: I take the opportnity to ask if I can count on the compiler to intern
literal strings (which my code may use in several places, including loops), esp.
"", or should I declare and use (for instance):
static immutable s0 = "" ;
Re: Why does D language do not support BigDecimal type?
On 12/03/2019 10:31, Boqsc via Digitalmars-d-learn wrote: Please attach quick working examples for every sentence you write or it's just a waste of time. People want to see the results and direct actions first before anything else, it's more efficient communication. We are in the subforum of Dlang learn, after all. Do not write "For Example". Then you may help people helping you by giving examples of your own use cases, first. I'm interested in writing a simple game prototype and I imagine that I would like to include some item parts in decimal. (100.00) To keep everything simple I would like to make my code as clean and simple as possible. From this single example, you don't need "fractal" (decimal or binary) numbers at all, just plain ints. Look up "fixed point arithmetics" on wikipedia, the article is rather good. It's easy and clean in comparison, at least if you only need simple operations. (That's how, by the way, monetary/financial software is or at least used to be implemented.) diniz
Re: Distinguish float and integer types from string
On 09/03/2019 19:11, Jacob Shtokolov via Digitalmars-d-learn wrote: The thing is that in PHP, for example, I would do The thing is php needs to be able to "lexify" raw input data at runtime, while in D this is done at compile-time. The ompiler has the lexer to do that. But I agree that, for user input, it would be cool to have such a feature available. However, this would quickly become complex because of (the reciprocal of) localisation, or even personalisation. Eg I like to write decimals like: -1'234'457,098 diniz
Re: this is null
On 09/03/2019 21:10, ANtlord via Digitalmars-d-learn wrote: On Saturday, 9 March 2019 at 20:04:53 UTC, Paul Backus wrote: You can end up with a null `this` reference if you dereference a null pointer to a struct and then call a method on the result. For example: I can but my reference is not null before calling. Take a look at the line of code [0]. There is a check before the line. https://github.com/ANtlord/deadmemory/blob/master/src/deadmemory/mem.d#L20 [0] There is a typo in this instruction: T* ptr = this.list.getFisrtFreeOrAdd(memViewLen).getPtr!T(); ^^ rs (may this explain your null? the compiler should complain) diniz
Re: 2 class issues -- PS
from [https://dlang.org/spec/attribute.html#abstract] : --- abstract Attribute An abstract member function must be overridden by a derived class. Only virtual member functions may be declared abstract; non-virtual member functions and free-standing functions cannot be declared abstract. Classes become abstract if any of its virtual member functions are declared abstract or if they are defined within an abstract attribute. Note that an abstract class may also contain non-virtual member functions. Classes defined within an abstract attribute or with abstract member functions cannot be instantiated directly. They can only be instantiated as a base class of another, non-abstract, class. Member functions declared as abstract can still have function bodies. This is so that even though they must be overridden, they can still provide ‘base class functionality’, e.g. through super.foo() in a derived class. Note that the class is still abstract and cannot be instantiated directly. --- Is there thus another way to enforce overriding of given methods? I wish to instantiate superclasses for special instances, as shown in previous mail. It is not a big deal (I can live without this enforcement, and my clients as well since if they wish to implement their own subclasses, they will have to override) but I still wish to know that for further cases. Thank you, diniz
2 class issues
Hello, First, I am not very experimented with the combination of static lang (alloc & typing) and OO (class-based). I'm implementing a library for lexical analysis (lexing), with 2 minor issues: -1- How to enforce that subclasses implement given methods without using "abstract", which seems to make the whole class abstract? (no info found in doc, actually, the page on classes [1] does not seem to even mention abstract classes) -2- How to have "constant" (predefined) class instances at the module-level? The compiler requires a "static this ()". What does this actually mean (for a constructor)? What are the consequences, for either my code or client code? (The doc on the topic [2] is rather obscure for me, and I could not find better elsewhere.) I'm also bluffed by "Static constructors have empty parameter lists." Does this mean I should manually fill the fields? (not a big deal, but why???) This may give: // Predefined pseudo-pattern "End-of-Text": auto EoT = new Pattern() ; // ??? EoT.name = "EoT" ; // Unique lexeme "end-of-text": auto eot = new Lexeme() ; // ??? eot.patname = "EoT" ; eot.slice = null ; eot.index = uint.max ; Then, why have a constructor at all? This would also prevent me from making classes immutable, while conceptually all are immutable... (no reason for a pattern or a lexeme to change) Thank you, diniz [1] https://dlang.org/spec/class.html [2] https://dlang.org/spec/class.html#static-constructor
Re: Beginner ?. Why does D suggest to learn java
On 17/10/14 07:38, maarten van damme via Digitalmars-d-learn wrote: While d can be complex, there's nothing preventing you from starting out simple and not using all features at first. I don't understand why it's not suitable for a beginner if you use this approach... For some reasons, in my view: A beginner has to learn programming in addition to a first lang. A beginner has to learn a first lang in addition to programming. We learn languages by understanding valid, meaningful input, ie here reading code. All static langs introduce tons of complication only due to their staticity. D is rather big complex, in the field of static langs. Most code will use more than a theoretical minimal set of features. And this minimal set is far more in size, difficulty, complication than in langs partly designed for ease of learning (Lua, Python, Scheme...). Even plain C is far more difficult than say, Lua. d
Re: Beginner ?. Why does D suggest to learn java
On 17/10/14 03:05, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 00:52:14 + MachineCode via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I don't understand. If at least it were C but java? why not D itself? C is *awful* as beginner's language. never ever let people start with C if you don't hate 'em. as for D... current version of D can be used, but with some precautions. we now have excellent book by Ali. (it's great, really! i believe that it must be featured on the front dlang.org page!) but java has alot more books and tutorials. not that D is bad for beginners, it's just has a smaller userbase. and all that things with classes are reference types and structs are not, empty array is not empty array but is empty array and so on D may be confusing a little. it's good to have some CS background to understood that things. What you say here applies, I guess, to many other points. I applaud Ali for writing a tutorial like his but... Check it (just the first pages is enough) for literally the dozens of notions one must know and master for being able to understand, not only the features of D introduced, but even the tutorial itself. If I am not a programmer, and one who knows other static langs, and better of the mainstream procedural paradigm, if not D itself, then I do not understand more than few isolated words here and there. We are blind to the huge pile of concepts we know, I guess, because we know them, thus take them for granted... d
Re: String created from buffer has wrong length and strip() result is incorrect
On 17/10/14 09:29, thedeemon via Digitalmars-d-learn wrote:
On Friday, 17 October 2014 at 06:29:24 UTC, Lucas Burson wrote:
// This is where things breaks
{
ubyte[] buff = new ubyte[16];
buff[0..ATA_STR.length] = cast(ubyte[])(ATA_STR);
// read the string back from the buffer, stripping whitespace
string stringFromBuffer = strip(cast(string)(buff[0..16]));
// this shows strip() doesn't remove all whitespace
writefln(StrFromBuff is '%s'; length %d, stringFromBuffer,
stringFromBuffer.length);
// !! FAILS. stringFromBuffer is length 15, not 3.
assert(stringFromBuffer.length == strip(ATA_STR).length);
Unlike C, strings in D are not zero-terminated by default, they are just arrays,
i.e. a pair of pointer and size. You create an array of 16 bytes and cast it to
string, now you have a 16-chars string. You fill first few chars with data from
ATA_STR but the rest 10 bytes of the array are still part of the string, not
initialized with data, so having zeroes. Since this tail of zeroes is not
whitespace (tabs or spaces etc.) 'strip' doesn't remove it.
Side-note: since your string has those zeroes at the end, strip only removes the
space at start (thus, final size=15), instead of at both ends.
d
Re: How to check i
On 16/10/14 20:46, Uranuz via Digitalmars-d-learn wrote: I have some string *str* of unicode characters. The question is how to check if I have valid unicode code point starting at code unit *index*? [...] You cannot do that without decoding. Cheking whether utf-x is valid and decoding are the very same process. IIRC, D has a validation func which is more or less just an alias for the decoding func ;-). Moreover, you also need to distinguish word-character code points from others (punctuation, spacing, etc) which requires unicode code points (Unicode the consortium provide tables for such tasks). Thus, I would recommand you to just abandon the illusion of working at the level of code units for such tasks, and simply operate on strings of code points. (Why do you think D has them builtin?) denis
