On Thursday, 14 November 2024 at 13:24:47 UTC, Dom DiSc wrote:
No, no. My problem is: [...]
So it seems, that the intended problem was transposed into
some example, thereby oblittering that problem with some
coding errors.
I checked that the source array has at least one element.
Yes, but on
On Saturday, 9 November 2024 at 04:02:46 UTC, Jonathan M Davis
wrote:
[...]
b[0 .. a.length-1] = a[];
You'll get a RangeError being thrown when you run the code.
[...]
Therefore a fix might be to not deminish the length:
b[ 0 .. a.length]= a[];
-manfred
On Sunday, 17 April 2022 at 18:25:32 UTC, Bastiaan Veelo wrote:
The reason is in [17.1.5](https://dlang.org/spec/enum.html):
“EnumBaseType types cannot be implicitly cast to an enum type.”
Thy. That's the anchor in the specs preventing Enums to be
integral types.
In the specs(17) about enums the word "integral" has no match.
But because the default basetype is `int`, which is an integral
type, enums might be integral types whenever their basetype is an
integral type.
On the other hand the specs(7.6.5.3) about types say
| A bool value can be implicitly
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct
Header`
What is the semantic sense of a template having no parameters?
Although the documentation declares such a template to be
syntactically correct, not a single
On Monday, 22 June 2020 at 02:16:52 UTC, user1234 wrote:
[...]
Maybe that the spec is a bit vague as it doesn't mention that
[...]
A vague place in a spec is usually called "Dark Corner" and the
functionality then marked as "Implementation defined".
But this mark is missing here.
And restric
https://dlang.org/spec/module.html#name_lookup contains under
4.3.4 only two sentences.
While the first sentence explains, that the search ends
"as soon as a matching symbol is found",
the second sentence implies that the search may continue until it
is sure, that
no other symbol "with the
On Monday, 13 April 2020 at 05:54:52 UTC, evilrat wrote:
if (auto weapon = cast(Weapon) gi)
weapon.Attack();
Does the parlor (currently illegal in Dlang)
if (Weapon w := gi)
w.Attack();
look nicer or even (currently legal):
if (Weapon w ._= gi)
w.A
On Monday, 9 March 2020 at 16:44:55 UTC, Steven Schveighoffer
wrote:
You're not the first person to ask.
Accepted.
Having a function `f' overloaded for argument types `bool' and
`ulong', the specs guarantee, that for `f( 1uL)' the boolean
overload of `f' is called.
What is this good for?
On Thursday, 3 January 2019 at 18:11:43 UTC, Paul Backus wrote:
[...] functions [...] default to `%s`.
thx. I should have rtfm instead of looking for an example.
-manfred
According to this tutorial
https://wiki.dlang.org/Defining_custom_print_format_specifiers
it seems easy to change the format of the output for
`std.stdio.writef'.
But why is there no example for changing the output when there
are no format specifiers?
-manfred
Tim K. wrote:
> Stack!(int) x;
x is not initialized.
`auto x= new Stack!(int);'
will do.
-manfred
Timon Gehr wrote:
> template getDepth(T){
> static if(is(T==Set!S,S)) enum getDepth=1+getDepth!S;
> else enum getDepth=0;
> }
Thx. Seems that I have to relearn a lot.
-manfred
Matt Kline wrote:
> isn't making any use of the template argument T
Correct. I do not know how to use `T' to determine the recursion depth of
the template---and I want no further parameter.
-manfred
How can one determine the recursion depth for templated types?
Example code:
import std.stdio;
class Set(T){
override string toString(){
return "Set";
}
}
void main(){
auto s0= new Set!uint;
writeln( s0); // writes Set
auto s1= new Set!(Set!uint);
writeln( s1); // should write Se
Dennis Ritchie wrote:
> if (4 <= 5 <= 6):
> print ("OK")
> -
I would rather write:
if( isSorted![4,5,6])
-manfred
Adam D. Ruppe wrote:
> My first gut idea
Turns out: it is the usage of a variable
- not newed, and
- of a type declared in the file.
-manfred
Adam D. Ruppe wrote:
> assert inside a mixed in string.
None praesent:
private import star, stack;
class StackExtended( T): Stack!T{
Star!T stacked;
this(){ stacked= new Star!T;}
auto opOpAssign( string op, T)( T node){
stacked+= node;
return super+= node;
}
auto opUnary( strin
"core.exception.AssertError@stackext.d(0): Assertion failure"
how to handle this?
-manfred
Jonathan M Davis wrote:
> UFCS is only ever used with the . syntax
The docs say so. Thx.
-manfred
The following gives:
"Error: 'a += b' is not a scalar, it is a C"
although UFCS should engage.
-manfred
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
Steven Schveighoffer wrote:
> That seems like a bug.
https://issues.dlang.org/show_bug.cgi?id=14589
-manfred
> Deprecation: super is not an lvalue
1) How to know when this will indeed be deprecated?
2) What does it mean, when `super++' is signalled as depracation, but
`super+=' is not signalled?
-manfred
> std.process.ProcessException@std\process.d(560):
> Failed to spawn new process
This is the error-message from the D-script from
http://wiki.dlang.org/Building_DMD
-manfred
Jack Applegame wrote:
>> test(10); // error
One can "import" the declaration by using an alias:
class A {
void test(int) {}
}
class B : A {
alias test= super.test;
void test() {
super.test(1); // compiles
test(10); // compiles
}
}
-manfred
Dennis Ritchie wrote:
auto fact = function (int x) => x * { if (x) fact(x - 1); };
int fact (int x) { return x * ( x>1 ? fact(x - 1): 1); };
-manfred
On Tuesday, 5 May 2015 at 05:26:17 UTC, anonymous wrote:
because `c is c`
Thanks. One can see this documented in
http://dlang.org/operatoroverloading.html#equals
But
1: how can one override this behavior
2: what is the design reason for this
Especially: how can one implement side effects o
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
=?UTF-8?B?QWxpIMOHZWhyZWxp?= wrote:
> a virtual function like accept() can do the trick
This would require changes in the whole class hierarchy.
But because of
> The actual type of the object is implicitly stored in the
> vtbl of each type.
and in addition, because the statement
| writeln( getC.
> class C{}
> class C1:C{}
> // ...
> class Cn:C{}
>
> C getC(){ return new Cn;} // might be extern
> // and deliver some Ci
>
> void visit( C1 fp){}
> // ...
> void visit( Cn fp){}
> void main(){
> visit( getC); // dispatch?
> }
-manfred
Damien wrote:
> is not a D bug
I cannot reproduce your problem.
Giving 10^38 and 10 as parameters the "lol" is output correctly.
-manfred
Carl Sturtivant wrote:
> is supposed to transform one delegate into another
Then please declare the template parameters to be delegates:
U muddle( T, U)( T f) {
uint g( int fp){
return cast(uint)( 5* f( fp));
}
auto gP= &g;
return gP;
}
unittest {
Carl Sturtivant wrote:
> Writing muddle!(int,int)
[...]
> gives the same error message.
Not entirely true:
template muddle( T, U...){
alias T delegate( U) Dptr;
auto muddle1( T, U...)( Dptr f) {
return f; //or make another delegate in real code
}
alias muddle1!( T, U) muddle;
}
Carl Sturtivant wrote:
> How do I fix this?
maybe it is currently not fixable because of restrictions in the deduction
algorithm.
Obviously the deduction works if the instantion of the template is replaced
by a symbol by `alias T delegate( U) Dptr;' or similar.
-manfred
Carl Sturtivant wrote:
> No it isn't according to dmd.
dmd does not express this.
according to
> p1.d(15): Error: [...]
dmd "cannot deduce" that `Dptr!(T, U)' might be equal to
`int delegate(int)'
-manfred
Temtaime wrote:
> What i'm doing wrong?
Maybey nothing than thinking---that the adress is printed in the number of
bits, whereas it is printed in the number of bytes.
-manfred
michaelc37 wrote:
> WTF -> -1 is greater than 7
>From the docs:
It is an error to have one operand be signed and the other unsigned for a
<, <=, > or >= expression.
-manfred
Josh wrote:
> I'm having a rather weird error when things that should have no
> effect are changed.
Seems that inserting symbolic debug info is broken in such a way, that it
touches ram out of its bounds---and the code for comparing the string
covers that ram. Commenting out the code and the st
Jesse Phillips wrote:
> argument being passed was an object
I see now, that you came to "convert object" because you know about the
olution of the task given. Sooily the solution is unknown before hand!
Of course my `class' printed out "something" that I didn't want to see. But
I still do not s
Jesse Phillips wrote:
>> Writes its arguments in text format to the file.
> I'm not sure what results you are interest in when searching for
> "arguments in text format."
I expected a closer explanation for the broad explanation "arguments in
text format". If the explanation for `write' wou
http://dlang.org/phobos/std_stdio.html:
void write(S...)(S args);
Writes its arguments in text format to the file.
1)
Feeding "arguments in text format" into the search-function for the whole
site does not give a hint to `toString'.
What am I missing?
2)
"to the file" ... which file?
-man
On Tuesday, 16 July 2013 at 07:19:05 UTC, Jacob Carlborg wrote:
The docs say: "Any intervening finally clauses are executed,
This does not solve:
/begin{ code}
markA:
if( exp1) goto markB;
if( exp2) goto markC;
...
scope ...
...
markB:
if( exp3) goto markA;
if( exp4) goto markC;
...
scope ..
Jonathan M Davis wrote:
gotos in such a context seem like a bit
of a nightmare to me though.
I did realize this nightmare. Therefore the assurance in the docs
is probably true only in the absence within the scope of at least
gotos to targets within the scope.
-manfred
Jonathan M Davis wrote:
Under what circumstances would they not be the same thing?
http://dlang.org/statement.html#GotoStatement
At least the famous gots can make lexical ordering different to
executional ordering.
-manfred
From the docs:
"If there are multiple ScopeGuardStatements in a scope, they are
executed in the reverse lexical order in which they appear."
Is lexical or executional order meant?
-manfred
Maxim Fomin wrote:
> How this is related
I will be quiet on this, because non formal specifications tend
to have ambiguities and I believe that the ambiguity I see
escapes the intended scope; but I am not willing to check for
this---and it is fruitless to explain such cases.
-manfred
Timon Gehr wrote:
> The code given in the original post is valid D code.
Yes, it is. But I see an ambiguity in the specs for this valid D
code.
-manfred
Maxim Fomin wrote:
> related to the issue?
... I can see that the definition is ambiguous. And if the coder
didnt't realize the ambiguousness as you do ...
-manfred
Maxim Fomin wrote:
> solves compilation errors
>From the docs:
| If a template has exactly one member in it, and the name of
| that member is the same as the template name, that member
| is assumed to be referred to in a template instantiation
It seems that the problem is located in this definit
Raphaël Jakse wrote:
> Is compressing for performance reasons?
Hopefully. Because in the general case the distribution of the
keys is unknown, no function used for computing the hash value
can be guarenteed to indeed spread the hash values uniformly
over the hash interval.
Compressing would ha
=?UTF-8?B?QWxpIMOHZWhyZWxp?= wrote:
> but the hash buckets are probably singly-linked lists
They are unbalanced binary search trees, which indeed turn to
singly-linked lists on sorted input.
-manfred
Nick Sabalausky wrote:
> *but* "head" and "tail" are merely pointers to "node"
Thank you. I do recognize now, that my flow of thought stopped
at the same point at which the flow of control of the compiler
stopped.
-manfred
Jakse wrote:
> It would also be interesting to have ideas for the general
> case
Yes, ideas might be interesting. :-)
A root of "good" hashing is incorporated in algorithm2 of your
posting:
spread the values produced by the hash function uniformly over
the interval size_t.min .. size_t.max.
Timon Gehr wrote:
> But as this is an undecidable property in general
I do not see, that the compiler has to solve the general case---
at least when compiling monolithic code and the executable is
only allowed to use types which are initialized at compile time.
Upon using several modules the mo
Nick Sabalausky wrote:
> But the OP was never trying to do anything like that.
See digitalmars.D.learn:40991
-manfred
Rob T wrote:
> and the problem I'm experiencing is definitely a compiler bug
I do not see that. Please work on my messages digitalmars.D.learn:40990
and digitalmars.D.learn:40991.
-manfred
Nick Sabalausky wrote:
> I really don't see the relevance
Please look at the definition of R:
struct R
{
int value;
d_list!R Rlist;
}
If no recursion was wanted the OP should have written:
d_list!(R*) Rlist;
In digitalmars.D.learn:40990 I already asked for an explanation.
-manfred
Rob T wrote:
> I want to create a simple recursive data structure as follows:
>
> struct R
> {
> int value;
> d_list!R Rlist;
> }
I do not see any usage for the member `d_list!R Rlist'.
Please explain.
-manfred
Timon Gehr wrote:
> In theory yes, but
[...]
What a pity. Because in the code given only the types Elem!0 and Elem!1
must be indeed initialized.
The fact, that the specification of the template describes a family of
types with an infinite number of members should not force the front end
to ch
Timon Gehr wrote:
> The example definitely exposes a bug in DMD.
> The D front end I am developing can already handle it.
May I guess, that your front end is also able to handle this code:
struct Elem( size_t myNumber) {
Elem!( myNumber +1)* next;
}
void main(){
Elem!0 list;
list.next= new
Rob T wrote:
> What is happening however, is that the templates are not doing
> what would be expected if the type was introduced manually
The expectations might be wrong.
With Templates one is able to introduce recursive definitions of types
into the type system. As with recursive functions, t
Jack Applegame wrote:
> Ok. Then how to implement in D this С++ std::function feature?
>
> http://liveworkspace.org/code/01aa058901529f65cb9a3cc4ba605248
That feature is among others defined here:
http://en.cppreference.com/w/cpp/utility/functional/function
As one might see it is a template,
Jack Applegame wrote:
>dg.ptr = cast(void*)b;
This changes the environment only. It does not change the function
called on the``dg()'-request---and the function called does not depend
on the environment.
But including a dependence on the environment may not change the
output, because the
Nick Sabalausky wrote:
> So ok:
>
> s/There *IS NO RECURSION* here./There is no _IMPOSSIBLE_ recursion
> here./
That's one correection only. Several more are to come.
Sorrily no one seems to have recognized this sentence in
digitalmars.D.learn:40918:
> Because `R' can recurse infinitely over
Rob T wrote:
> The above template definitions define exactly the same structure
> as the original
No, they implement not _exactly_ the same structure, because they
supply more freedom than the original templates version. The original
version forced a recursion onto every implementation, wherea
Nick Sabalausky wrote:
> ALL 3 types have an exact, FINITE size.
> There *IS NO RECURSION* here.
This conclusion is wrong. Otherwise one can conclude that `s' is not
recursing on itself in this code:
struct S{ S* next;}
S s;
s.next= &s;
... because `s' has a fixed and finite size.
One way to
Rob T wrote:
> In fact, I can define the structure just fine provided that I do not
> use a template.
.. and if one uses a template one can get an infinite recursion,
because templates include recursion. This is the case in your code.
The code I gave elimates that infinite recursion. The code
Manfred Nowak wrote:
> or `T' itself must take the lead.
`T' was given as:
| struct R
| {
| int value;
| d_list!R Rlist;
| }
... and using the given changes as well as D-parlor `T' becomes:
| struct R {
| int value;
| Ancor!R list;
| }
Because `R' can
Rob T wrote:
| struct d_list( T )
| {
|struct node
|{
| T payload;
| node* pred;
| node* succ;
|}
|node* head;
|node* tail;
| }
This doesn't loo like a list. It looks like the ancor of a list. Let
me rewrite it and use D-parlor.
| struct Ancor( T){
|str
Rob T wrote:
> I want to be clear that I'm trying to define a recursive data
> structure
[...]
> so correct me if there's a reasonable way to get this job done
A recursive data structure needs a mooring ... and such a mooring is
missing in the code given.
-manfred
Maxim Fomin wrote:
> Why now you are complaining about this?
Because this is the learn group and I did not realize, that the
compiler does conform to the definition of "overload resolution" in
function.html#function-inheritance, i.e. my expectation is defined as a
bug.
- manfred
Maxim Fomin wrote:
> Then disable behavior by marking class or function as a final.
Do you really mean by this, that "aspect programming" is impossible in
D?
Or that marking `final' is enough?
> provide an example how you can do this.
I was in fear and posted an approach. But I was not sure. The
Maxim Fomin wrote:
>> b= d2;
> What is wrong here?
The slight change in behavior might be unexpected and not intended for
the owner of variable `Base b;'.
What is the price ( i.e. coding time, execution time, execution space)
the owner of that variable has to pay in the case that she/he wan
Justin Whear wrote:
> is used to create library shims
One might be able to see: this is one of the roots of aspect
programming.
As a system programming language, D should be able to support this
paradigm like aspectC++ shows for c++.
Therefore: the answer to the subject is: yes.
-manfred
Dan wrote:
> The following takes nearly three minutes to compile.
... and this returns immediately:
struct B {
const size_t SIZE = 1024*64;
int[SIZE] x= void; // !!!
}
void main() {
B[] barr;
barr ~= B();
}
---
- manfred
Chris Cain wrote:
> So, no, the implementation wouldn't be changed during runtime
> since it must be provided when linking.
Thats an expressed intent only. Reason: the linker does not know any
thing about the language; the linker would be satisfied if there
exists any function the linker can l
F i L wrote:
> You can't force new D programmers to follow a 'guidline'
By exposing a syntax error for every missed explicit initialization the
current guideline would be changed into an insurmountable barrier,
forcing every "new D programmers to follow" the 'guidline'.
-manfred
F i L wrote:
> It sounds like circular reasoning.
Several considerations pressed the design into the current form:
1) always changing output on unchanged input is hard to debug
2) GC needs to be saved from garbage, that looks like pointers
3) missed explicit initializations should not create synt
Xan wrote:
> But it's a messy limitation.
On the contrary: it requires work to implement limitations. Therefore
limitations are implemented only to shield users from mess.
Not having descovered any benefit of a limitation might point to
insufficient empirical knowledge.
-manfred
MattCodr wrote:
> I have a doubt about the best way to insert and move (not
> replace) some data on an array.
I have the vision, that a mapping from a dense range of integers to
some value type and wast (i.e. Theta( n)) changes of this mapping are a
severe hint for a maldesign.
-manfred
Stewart Gordon wrote:
> If there were such a thing as bool.nan
... it would be called not-a-boolean. Of course it may make sense to
compute something using such poisoned values. But if such values make
sense, D is not prepared to use them, especially there is no
"if_then_else_otherwise" state
Timon Gehr wrote:
> The error message says
[...]
> recursive expansion
I did not read that in the posts and on dmd 2.057/win32 only an out of
memory was thrown.
> I'll attempt to analyse
Good luck.
-manfred
Timon Gehr wrote:
> This would make it a Phobos bug.
Not necassarily. But it would be a Phobos bug if the allocation cycle
is completely located within Phobos and the possibilty of such a cycle
is not mentioned in the docs.
An analog argument holds for every templated "library", that uses
tem
Ellery Newcomer wrote:
> Can anyone confirm this behavior?
The behavior has nothing to do with fedora, because I can confirm it
for win32. It seems to be rooted in an infinite loop of memory
allocations.
Is this the first time of a report that an implementation attempt
stumbles into the holti
Ellery Newcomer wrote:
> So this behavior is new, but is it sensical?
It is a bug:
If a mixin has a MixinIdentifier, it can be used to disambiguate
[cited 11 Feb 2012 from
http://www.d-programming-language.org/template-mixin.html ]
Jonathan M Davis wrote:
> thanks to how unicode works
This does not mean, that the data structure representing a sequence of
"letters" has to follow exactly the "working" you cited above. That
data structure must only enable it efficiently. If a requirement for
sequences of letters is, that a
Goal: show some skill of D for implementing mathematics.
A definition:
Let T1, T2, T3 be sets. A problem P of type ( T1, T2, T3) is
interpretable as a function from the domain
cartesian product of T1 and powerset of T2
to the codomain
T3.
Objective: Present code, that is usefull for all
Today I got the nice message
Error: undefined identifier missing
from DMD2.057/win and was baffled for several minutes until I
recognized the meaning.
-manfred
H. S. Teoh wrote:
> If this was code generated by an external utility
I wasn't argumenting for using external utilities, but against the
argument, that separating code for separatable phases would obfuscate
the code.
>> for more than one _needed_ phase
> compile-time validation of generated cod
Timon Gehr wrote:
> You probably haven't made extensive use of the feature.
That is correct.
> - needed for a third compilation, needed for a fourth compilation,
> needed for a fifth compilation ...
Provide an example please and I will change my opinion.
> - better syntax, can do complex things
H. S. Teoh wrote:
> I don't think that should be grounds to get rid of CTFE,
> though.
In contrast to your remark, I do not see the benefits of reducing two
compiling phases to one. For me CTFE ist nothing else than running the
executables of a first compilation in order to get some values need
H. S. Teoh wrote:
> the ideal situation would be that CTFE can replace writing an
> arbitrarily complex helper program
Aebitrary complex helper programs may include viruses and other nice
surprises. Walter does not want that adminstrators have to worry about
a compilation step to torture the sy
RenatoL wrote:
> why in D we are not obligated
This depends on how the designer wants the coders to think about the
semantics of a .
If a _always_ is an _additional_ entry into an otherwise linear
sequence of commands, then fall-through as standard is the consequence.
If a _always_ breaks t
bearophile wrote:
> instead of SIMDs added
Most delevopers at the same time like to turf their old errors and are
keen to do something knew.
-manfred
dennis luehring wrote:
> so your FileDelete would not return an FileDoesNotExists-Error?
Correct.
> would it not help to better understand big code if the remove
> would be renamed to remove_existing or to add something like this?
Maybe.
You possibly know about the `rm'-command of *nix-like sys
dennis luehring wrote:
> why is there an exception/error neeeded if missing?
Exceptions or errors are not _needed_.
Their existence stems from the modell under which the user of the
operation _has_ to think about the operation, especially whether it
is
a:only the outcome of the operation or
Jonathan M Davis wrote:
> In this case, it's very much like dealing with C++ iterators
A relevant part of Andrei's thread on "associative arrays iteration":
http://www.digitalmars.com/d/archives/digitalmars/D/associative_arrays_
iteration_is_finally_here_99576.html#N99614
-manfred
simendsjo wrote:
> it doesn't state return value
Yes, I haven't read carefully enough.
-manfred
simendsjo wrote:
> Wouldn't it make sense to return a pointer to the item being
> removed/null?
According to the docs this is the intended behavior.
-manfred
1 - 100 of 106 matches
Mail list logo
