Re: array setting : Whats going in here?

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Oct 07, 2023 at 12:00:48AM +, claptrap via Digitalmars-d-learn 
wrote:
> 
> char[] foo;
> foo.length = 4;
> foo[] = 'a'; // ok sets all elements
> foo[] = "a"; // range error at runtime?
> foo[] = "ab"; // range error at runtime?
> 
> So I meant to init with a char literal but accidently used double
> quotes.  Should that even compile? Shouldn't the compiler at least
> complain when trying to init with "ab"?

If you want initialization, don't slice the target array. For example:

char[] foo = "a";

Or:

char[] foo;
...
foo = "a";

When you write `foo[]` you're taking a slice of the array, and in that
case if the lengths of both sides of the assignment don't match, you'll
get a runtime error.


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com

Re: Straight Forward Arrays

[dhs via Digitalmars-d-learn]

On Thursday, 5 October 2023 at 16:57:00 UTC, Jesse Phillips wrote:

On Wednesday, 4 October 2023 at 10:51:46 UTC, dhs wrote:


D and Go slices have advantages but can be confusing. I don't 
have a solution, but if anyone is interested, the relevant 
discussions about slice confusion in the Go community apply to 
D slices as well.


I don't believe slice confusion in D is the same as God.

https://he-the-great.livejournal.com/48672.html

D manages to avoid stomping, while Go provides no clear 
ownership when slices are at play.



And here is the slices explained
https://dlang.org/articles/d-array-article.html


Thanks for the link. It actually demonstrates my point: he gets 
the same results from D and Go until he appends elements to the 
slice. It is then that things get confusing.


Obviously, the implementations are not exactly the same: for 
example, in Go 'capacity' is a field whereas in D it is a 
calculated property. But they are *similar*.


Here are some quotes from Go users:

"the issue of Go's slices is that they act as both a dynamic 
array and a slice viewing a portion of one. The two uses conflict 
with one another, and the interactions are full of traps. "


https://news.ycombinator.com/item?id=28344938

"the behaviour is logical based on how Go works. The criticism is 
instead that it works this way in the first place. The reason 
it's like this is that slices were attempting to address two 
separate use cases — growable arrays and subarrays"


https://www.reddit.com/r/golang/comments/6qizjq/fucking_go_slices/

Quote: "Welcome to go! This is one of the language quirks."

https://www.reddit.com/r/golang/comments/10b4ofx/confused_about_array_and_slices/

Others pointed out that slices work well. My points is: if you're 
thinking about a change it's worth reading the Go discussions, 
because their slices are similar in concept.

Need help with 128bit integer ucent boolfilter

[d007 via Digitalmars-d-learn]

I am search for a fast 128bit integer ucent boolfilter, used for 
server side duplicate request filter.



I can seed there is https://github.com/MartinNowak/bloom, only 
accept size_t as key.



Is there some library support 128bit integer boolfilter ? C or 
C++ or rust is ok for me.



Is 128bit boolfilter a doable thing? or it will not work or will 
be much more slow compare to 64 bit solution?