Re: How to allow +=, -=, etc operators and keep encapsulation?
On Monday, 12 April 2021 at 18:16:14 UTC, Jack wrote:
Give this class:
```d
class A
{
int X() { return x; }
int X(int v) { return x = v;}
private int x;
}
```
I'd like to allow use ```+=```, ```-=``` operators on ```X()```
and keep encapsulation. What's a somehow elegant way to do that?
I assume you know what you are doing, right?
In this specific case I would say you can probably stick with it
as is since you can have value checks in getter/setter, you can
validate and correct values before it mess up the internal state,
and calculate X without exposing internal state (today it may be
int x, tomorrow you change it to be stored as string, who
knows...).
But this example doesn't really tell if it's acceptable in what
you are trying to achieve.
Otherwise:
What you need is called abstraction, you provide high level
interface to your problem without exposing internal state which
is implementation detail, which gives you freedom to modify
internal logic without breaking everyone's code that consume your
interface.
Assuming A is some special scalar type you just implement all
operations in a way that makes it only relevant as a whole.
Otherwise if you still need to peek on its private members you
have leaky abstractions (it is called feature envy).
Allocated memory escapes a reference to parameter variable
I recently updated my compiler from 2.091.1 to 2.096.0. After doing so, I started getting deprecations that I think may be related to the DIP25 change mentioned in the release notes here: https://dlang.org/changelog/2.092.0.html#dip25. Here's an example of the code that is generating the deprecation notices: https://run.dlang.io/is/MRFG1u I found this issue that seems to be very similar to what I am running into: https://issues.dlang.org/show_bug.cgi?id=21525. Can someone help me understand whether the deprecation notices are spurious (as in the issue above) and if not, what I need to do to fix the deprecations? Thanks!
Re: GC memory fragmentation
On Monday, 12 April 2021 at 20:50:49 UTC, Per Nordlöw wrote: more aggressive collections when nearing it. What is a more aggressive collection compared to a normal collection? Unfortunately we still have no move support in D's GC because of its impreciseness.
Re: GC memory fragmentation
On Monday, 12 April 2021 at 20:50:49 UTC, Per Nordlöw wrote: I'm surprised there is no such functionality available. It doesn't sound to me like it's that difficult to implement. Afaict, we're looking for a way to call `GC.collect()` when `GC.Status.usedSize` [1] reaches a certain threshold. I wonder how other GC-backed languages handle this. [1] https://dlang.org/phobos/core_memory.html#.GC.Stats.usedSize
Re: GC memory fragmentation
On Monday, 12 April 2021 at 07:03:02 UTC, Sebastiaan Koppe wrote: On side-note, it would also be good if the GC can be aware of the max memory it is allotted so that it knows it needs to do more aggressive collections when nearing it. I'm surprised there is no such functionality available. It doesn't sound to me like it's that difficult to implement.
Re: Range Error
On Monday, 12 April 2021 at 19:19:12 UTC, kdevel wrote: On Monday, 12 April 2021 at 18:13:38 UTC, Imperatorn wrote: [...] [...] D can be so much fun! ```d import std.stdio; [...] Of course :D
Re: Range Error
On Monday, 12 April 2021 at 18:13:38 UTC, Imperatorn wrote:
[...]
Yup
D can be so much fun!
```d
import std.stdio;
enum Color {none = " n ", red = " r ", black = " b "};
enum sColor {black= " b ", white= " w "};
class Square {
public:
this(Color color, sColor Scolor) {
this.color = color;
this.Scolor = Scolor;
}
Color color;
sColor Scolor;
}
void Printboard (alias Q) (Square[8][8] square) {
foreach (int i, ref v; square)
{
foreach(int j, ref w; v)
{
string s = Q (w);
write (s);
}
writeln;
}
writeln;
}
bool isEven(int a)
{
return a&1;
}
void main()
{
Square[8][8] square;
foreach (int i, ref v; square)
foreach(int j, ref w; v)
{
auto color = (i + j).isEven
? sColor.black
: sColor.white;
w = new Square(Color.none, color);
}
foreach (int i, ref v; square)
{
if (i > 2)
continue;
foreach (int j, ref w; v)
w.color = (i + j).isEven
? Color.red
: w.color;
}
Printboard!(w => w.color) (square);
Printboard!(w => w.Scolor) (square);
}
```
Re: "this" as default parameter for a constructor.
On Sunday, 11 April 2021 at 20:38:10 UTC, Pierre wrote:
Hi,
I have a class with a reference to the parent object and a
constructor that has the parent as parameter
class foo {
this ( foo p /* , other params */ ) {
parent = p;
}
foo parent;
}
Of cause, the parent is almost always the object that creates
the new intance. So
auto f = new foo(this);
I'd like to set "this" ( the creator ) as default argument if
the constructor :
this ( foo p = this ) {...}
I can't. But however, the function, the argument and the
current object in body of the constructor are 3 different
things and the compiler can distinguish each one.
Is there a way to pass the reference of the caller to the
creator as default argument ?
it isn't supported as far i know so use a default construtor like
@Kagamin has show
How to allow +=, -=, etc operators and keep encapsulation?
Give this class:
```d
class A
{
int X() { return x; }
int X(int v) { return x = v;}
private int x;
}
```
I'd like to allow use ```+=```, ```-=``` operators on ```X()```
and keep encapsulation. What's a somehow elegant way to do that?
Re: Range Error
On Monday, 12 April 2021 at 18:01:02 UTC, kdevel wrote:
On Sunday, 11 April 2021 at 20:41:35 UTC, Bastiaan Veelo wrote:
[...]
[...]
Yes, there is a `7` where there should be an `i` on this line:
```d
for(int i=7;7>=0;i--)
```
This will go on forever, so you get a range error as soon as
`i < 0`.
Can't these kinds of errors be eliminated by using foreach
loops?:
```d
Square[8][8] square;
foreach (int i, ref v; square)
{
foreach(int j, ref w; v)
{
if((isEven(i)&&isEven(j))^(!isEven(i)&&!isEven(j)))
w = new Square(Color.none, sColor.white);
else
if((!isEven(i)&&isEven(j))^(isEven(i)&&!isEven(j)))
w = new Square(Color.none,sColor.black);
else
assert(false);
}
}
```
Yup
Re: Range Error
On Sunday, 11 April 2021 at 20:41:35 UTC, Bastiaan Veelo wrote:
[...]
What am I doing wrong here? Is it the 'for' loop?
Yes, there is a `7` where there should be an `i` on this line:
```d
for(int i=7;7>=0;i--)
```
This will go on forever, so you get a range error as soon as `i
< 0`.
Can't these kinds of errors be eliminated by using foreach loops?:
```d
Square[8][8] square;
foreach (int i, ref v; square)
{
foreach(int j, ref w; v)
{
if((isEven(i)&&isEven(j))^(!isEven(i)&&!isEven(j)))
w = new Square(Color.none, sColor.white);
else
if((!isEven(i)&&isEven(j))^(isEven(i)&&!isEven(j)))
w = new Square(Color.none,sColor.black);
else
assert(false);
}
}
```
Re: How to use a shared library created in cython?
On Sunday, 11 April 2021 at 20:08:15 UTC, affonso elias ferreira junior wrote: Hi everyone, I'm trying to use a shared library created in Cython. example. [...] I am on my mobile phone, and cannot reproduce. But i see that this cast(int function()) should be cast(int function(int)). Try correcting function signatures throughout the code. And extern (c) int test() is irrelevant here because you are loading it via a different mechanism.
Re: "this" as default parameter for a constructor.
class foo {
this ( foo p /* , other params */ ) {
parent = p;
}
foo create() {
return new foo(this);
}
void use() {
foo f = create();
}
foo parent;
}
Re: Range Error
On Monday, 12 April 2021 at 01:22:12 UTC, Steven Schveighoffer wrote: On 4/11/21 4:41 PM, Bastiaan Veelo wrote: On Sunday, 11 April 2021 at 19:45:30 UTC, Ruby The Roobster wrote: What am I doing wrong here? Is it the 'for' loop? Yes, there is a `7` where there should be an `i` on this line: ```d for(int i=7;7>=0;i--) ``` This will go on forever, so you get a range error as soon as `i < 0`. ... I fixed the code now. It works. Thanks for your help.
Re: Range Error
On Sunday, 11 April 2021 at 20:41:35 UTC, Bastiaan Veelo wrote: On Sunday, 11 April 2021 at 19:45:30 UTC, Ruby The Roobster wrote: What am I doing wrong here? Is it the 'for' loop? Yes, there is a `7` where there should be an `i` on this line: ```d for(int i=7;7>=0;i--) ``` This will go on forever, so you get a range error as soon as `i < 0`. —Bastiaan. I have fixed this.
Re: GC memory fragmentation
On Sunday, 11 April 2021 at 09:10:22 UTC, tchaloupka wrote: Hi, we're using vibe-d (on Linux) for a long running REST API server and have problem with constantly growing memory until system kills it with OOM killer. [...] Looks like the GC needs some love
Re: GC memory fragmentation
On Sunday, 11 April 2021 at 09:10:22 UTC, tchaloupka wrote: Hi, we're using vibe-d (on Linux) for a long running REST API server and have problem with constantly growing memory until system kills it with OOM killer. [...] But this is very bad for performance so we've prolonged the interval for example to 30 seconds and now memory still goes up (not that dramatically but still). [...] So it wastes a lot of free space which it can't return back to OS for some reason. Can these numbers be caused by memory fragmentation? There is probably a lot of small allocations (postgresql query, result processing and REST API json serialization). We have similar problems, we see memory usage alternate between plateauing and then slowly growing. Until it hits the configured maximum memory for that job and the orchestrator kills it (we run multiple instances and have good failover). I have reduced the problem by refactoring some of our gc usage, but the problem still persists. On side-note, it would also be good if the GC can be aware of the max memory it is allotted so that it knows it needs to do more aggressive collections when nearing it.
