Re: CMake and D
On Saturday, 6 August 2022 at 18:22:45 UTC, Jan Allersma wrote: I figured out a strategy to solve te problem: 1) Create a C++ function which will be called in D. 2) Build a static C++ library with CMake and add dependencies (In my case: SDL libraries) 3) Create a new project (`dub init`). 4) Add these lines to `dub.json`: ``` "dflags": ["-L-lstdc++"], "lflags": ["-Lbuild", "-lframework", "-lSDL2"], ``` - `-L-lstdc++` is needed to use standard C++ functions. - `-Lbuild` is to add the `build` directory a library path (this is the directory where my earlier compiled C++ library is in). - `-lframework` is used to link my earlier compiled C++ library `libframework.a`. - And finally `-lSDL2` because that is a dependency used by my C++ library. Now I can add dependencies for my D code as well using `dub add`! Thank you for posting the solution! And you were fast enough to find it yourself before anyone can arrive with the solution ;) Happy coding my friend!
How do I initialize a templated constructor?
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The type is: " ~ typeof(type).stringof);
}
}
```
I want to create it and be able to successfully initialize the
template parameters
of the constructor but until now, I wasn't able to find a way to
successfully do
that. Is there a way you guys know? I have tried the following:
```
void main() {
// Doesn't work
auto val = TestArray!(10, "int")(60);
// Doesn't work either
auto val = TestArray!(10).TestArray!("int")(60);
// Neither this works
auto val = TestArray!(10).this!("int")(60);
}
```
As with every question I make, the solution must be "betterC"
compatible so I can use it.
Thanks a lot!
Re: Verbosity in D
On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? In most cases this is a false statement. Just see examples on frontpage of dlang site. Or try write and compare concrete programs. Python have a good expressiveness, but up to 100 times slower.
Re: Main foreach loop fails when another foreach is added
On Monday, 8 August 2022 at 02:45:54 UTC, Steven Schveighoffer wrote: And now, you tried to read it again! Which means you are trying to read more data from an empty stream. You need to either a) reopen the file, or b) do both in the same loop. -Steve Steve! You are Legend! **Thank you**. It is obvious now the second `foreach` is reading from an empty stream! Regards, ikel
Re: Acess variable that was set by thread
On 8/7/22 9:36 PM, vc wrote: Hello, i have the following code, the flora contains a boolean zeus in the DerivedThread the boolean zeus was set to true; but when i'm trying to access it outside the thread in main it returns me false; any thoughts ? is zeus declared just as: ```d bool zeus; ``` Because if so, it is in *thread local storage*. This is different *per thread*. This means, each thread gets its own copy, and writing to the copy in one thread doesn't affect any other threads. Note that Emanuele is also right that you have a race condition in any case. So you likely have 2 problems going on. -Steve
Re: Main foreach loop fails when another foreach is added
On 8/7/22 10:11 PM, ikelaiah wrote:
Hi,
I'm writing a program that reads a text file and launch my work URLs in it.
It worked fine, and very happy.
Then I added another `foreach` loop to count total number of lines.
After this, the main `foreach` won't work.
Does anyone know as to why this happens?
I might have missed something very obvious.
Thank you.
```d
...
// Open input file for reading
size_t line_count = 0;
File input_file = File(input_filename);
Here you open the file
auto file_range = input_file.byLine(KeepTerminator.no,
std.ascii.newline);
And then wrap it in a byline range.
// if this foreach not commented out
// the last foreach won't run.
foreach (char[] line; file_range)
{
line_count += 1;
}
For this foreach loop, you read every line in the file, exhausting the
file (the input stream for the file is empty).
// the MAIN foreach loop
// -- won't run if above foreach is enabled
foreach (char[] line; file_range)
{
if (!line.empty)
{
writeln("Open URL: " ~ line);
Thread.sleep(dur!("seconds")(2));
browse(line);
}
}
And now, you tried to read it again! Which means you are trying to read
more data from an empty stream.
You need to either a) reopen the file, or b) do both in the same loop.
```
-Steve
Re: Acess variable that was set by thread
On Monday, 8 August 2022 at 01:36:45 UTC, vc wrote:
Hello, i have the following code, the flora contains a boolean
zeus
in the DerivedThread the boolean zeus was set to true; but when
i'm trying to access it
outside the thread in main it returns me false; any thoughts ?
import flora;
class DerivedThread : Thread
{
this()
{
super();
}
private:
void run()
{
// Derived thread running.
zeus = true;
while(true)
{
}
}
}
void main()
{
auto derived = new DerivedThread().start();
writeln(zeus);
}
When `writeln(zeus)` runs, `zeus = true` probably was not
evaluated yet.
Main foreach loop fails when another foreach is added
Hi,
I'm writing a program that reads a text file and launch my work
URLs in it.
It worked fine, and very happy.
Then I added another `foreach` loop to count total number of
lines.
After this, the main `foreach` won't work.
Does anyone know as to why this happens?
I might have missed something very obvious.
Thank you.
Regards,
ikel
```d
module openurls;
import std.stdio : writeln, File, KeepTerminator;
import std.file;
import std.range;
import std.ascii;
import std.getopt : getopt, GetoptResult, defaultGetoptPrinter;
import std.process : browse;
import core.thread.osthread;
import core.time;
void main(string[] args)
{
string input_filename = "";
// Get command line option
GetoptResult user_args = getopt(args,
"input|i", "A list of URLs separated by new lines.",
_filename);
// Does user need help?
if (user_args.helpWanted)
{
defaultGetoptPrinter("Command line options for Open
URLs.",
user_args.options);
}
// Is input file specified?
if (input_filename.length == 0)
{
writeln("Open URL: No file specified.\n");
defaultGetoptPrinter("Command line option for Open URLs.",
user_args.options);
return;
}
// Does the file exist?
if (!input_filename.exists)
{
writeln("Open URL: input file --" ~ input_filename ~ "--
does not exist.\n");
return;
}
else
{
writeln("Open URL: reading --" ~ input_filename ~ "--");
}
// Open input file for reading
size_t line_count = 0;
File input_file = File(input_filename);
auto file_range = input_file.byLine(KeepTerminator.no,
std.ascii.newline);
// if this foreach not commented out
// the last foreach won't run.
foreach (char[] line; file_range)
{
line_count += 1;
}
// the MAIN foreach loop
// -- won't run if above foreach is enabled
foreach (char[] line; file_range)
{
if (!line.empty)
{
writeln("Open URL: " ~ line);
Thread.sleep(dur!("seconds")(2));
browse(line);
}
}
writeln("Open URL: completed");
writeln("Closing " ~ input_filename);
input_file.close();
}
```
Acess variable that was set by thread
Hello, i have the following code, the flora contains a boolean
zeus
in the DerivedThread the boolean zeus was set to true; but when
i'm trying to access it
outside the thread in main it returns me false; any thoughts ?
import flora;
class DerivedThread : Thread
{
this()
{
super();
}
private:
void run()
{
// Derived thread running.
zeus = true;
while(true)
{
}
}
}
void main()
{
auto derived = new DerivedThread().start();
writeln(zeus);
}
Re: Verbosity in D
On Monday, 8 August 2022 at 00:40:11 UTC, TTK Ciar wrote: On the other hand, I've noticed that D's idiomatic brevity can be diluted by the extremely verbose function names used in the standard library. For long function names you can define short aliases, for syntax you can't. So having short and efficient language constructs is by far more important than short function names. Especially a standard-library is much better off having descriptive and unique names - which sort of requires them to be long.
Re: "chain" vs "~"
On Sunday, 7 August 2022 at 03:55:50 UTC, Emanuele Torre wrote: On Sunday, 7 August 2022 at 01:22:18 UTC, pascal111 wrote: [...] They are quite different: * `chain` gives you "range" (iterator) that starts from the first element of `x` and ends at the last element of `y` (like e.g. `zip` in other languages). * `~` creates a new `int[]` with elements from `x` and the elements from `y`. [...] In next program, I used "insertInPlace", not "~" nor "chain", should I use "~" or it's the same as "insertInPlace"? https://github.com/pascal111-fra/D/blob/main/coco.d
Re: Verbosity in D
On Monday, 8 August 2022 at 00:11:33 UTC, pascal111 wrote: I don't have specific code but it was a general notice. Take Python as in example, the same program in Python doesn't cost much code as D code, and of course by putting in accounts that that I assume that there are some special tasks D can do, while Python can't do. There is definitely a spectrum of programming language practical expressiveness (the opposite of verbosity), with the dynamic languages (python, perl, ruby) on the "most expressive" end, and static languages (C, C++, Java) on the "most verbose" end. D is somewhere in the middle of that spectrum, much more expressive than C but not as expressive as python. The trade-off is much better run-time performance and lower memory overhead compared to the dynamic languages. I've been writing C, Perl and Python for a living for a while, following the common practice of writing a solution in Perl or Python first, for shortest possible development time, and then rewriting performance-intensive bits in C when more performance is needed. The appeal of D, to me, is that it gives me something akin to the same approach with just one language. I can write very concise, expressive D when performance doesn't matter, and then write more verbose C-like D when I need C-like performance, all in the same source file, with the same language. Having a sane and useful threading model is an added bonus. Neither python nor perl nor nodejs have useful threads, whereas D gives us real, concurrent threads with a fraction of the boilerplate -- https://tour.dlang.org/tour/en/multithreading/synchronization-sharing On the other hand, I've noticed that D's idiomatic brevity can be diluted by the extremely verbose function names used in the standard library. Sure, foreach loops can be just as concise as python's -- foreach(i; arr) -- but then you end up getting carpal tunnel syndrome anyway from typing out "AllImplicitConversionTargets" or "filterBidirectional" or "levenshteinDistanceAndPath". My impression is that brevity is more important to the language developers than it is to the phobos developers.
Re: Verbosity in D
On Monday, 8 August 2022 at 00:18:12 UTC, Emanuele Torre wrote: On Monday, 8 August 2022 at 00:11:33 UTC, pascal111 wrote: [...] You are just sounding like a troll now... "troll" :) I like it! That makes no sense: "I assume that there are some special tasks D can do, while Python can't do" How? "Take Python as in example, the same program in Python doesn't cost much code as D code" What same program are you talking about? Why did you mention python as if you showed me an example I can see? What am I supposed to say if can't even explain or show an example of how D is more verbose? Maybe I'm wrong, your words sound that Python isn't verbose-less.
Re: Verbosity in D
On Monday, 8 August 2022 at 00:15:48 UTC, pascal111 wrote:
On Sunday, 7 August 2022 at 23:44:26 UTC, Emanuele Torre wrote:
On Sunday, 7 August 2022 at 23:31:45 UTC, pascal111 wrote:
On Sunday, 7 August 2022 at 22:16:55 UTC, Emanuele Torre
wrote:
[...]
It seems complex, I didn't get it yet, I wished I didn't ask
about it :)
It's really trivial.
`auto [x, y] = getpoint();` is equivalent to
```C++
auto _p = getpoint();
auto x = _p.x /* first element of the struct */;
auto y = _p.y /* second element of the struct */;`
```
Also works with arrays.
```C++
int[] arr = { 10, 12, 14 };
const auto [x, y, z] = arr;
/* x=10 y=12 z=14 */
```
A lot of programming languages have this.
Really, I'm not sure I'm understanding this syntax `auto [x, y]
= getpoint();`, if you have the name of term of it in D or an
explaining link.
D does not have it. You have already been told that when they
have been mentioned.
If you want more information about it in C++, you could read
https://en.cppreference.com/w/cpp/language/structured_binding or,
for javascript,
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment.
That was just meant to be a simple example to show what jfondren
meant with "destructing bindings".
Re: Supporting Arabic in GUI
On Monday, 8 August 2022 at 00:20:53 UTC, pascal111 wrote: On Monday, 8 August 2022 at 00:12:07 UTC, Emanuele Torre wrote: On Sunday, 7 August 2022 at 23:48:22 UTC, pascal111 wrote: [...] I am very confused by this question. That has nothing to do with the programming language: it has all to do with the GUI toolkit you use (lazarus in that case). If you used lazarus with D instead of Pascal (if it is possible), you would have the same limitations in D. If you use another GUI toolkit in D/Pascal (e.g. GTK3, Qt5, Tk, etc.), you will have the limitations of that toolkit, which may or may not support Arabic text. So, the reason is the toolkit. I guessed D has specific library for GUI, and with that I judged D as whole that if it supports Arabic or not. Also I don't understand you saying "it's not its time"; there are plenty of GUI programs written in D. :/ I mean "my own time" that I'm still studying D basics, so I'll study GUI programming at another time, but if there are available resources for GUI, I would like to take a look in 'em. EDIT: The last part of my previous post is lost. I'll retype it again with some changes. I mean with time "my own time" that I'm studying D basic now, but if there are resources for GUI in D, I would like to take a look in 'em.
Re: Supporting Arabic in GUI
On Monday, 8 August 2022 at 00:12:07 UTC, Emanuele Torre wrote: On Sunday, 7 August 2022 at 23:48:22 UTC, pascal111 wrote: I have no idea about GUI or Rad programming in D; it's not its time, but I'm curious to know if D is fine supporting for Arabic language in the GUI applications or we will have some issues like I met - in my experience - in Free Pascal. This is a topic where we trying to make a custom message box supporting Arabic as what's supposed to be, but we didn't reach although that the degree we want: https://forum.lazarus.freepascal.org/index.php/topic,59765.0.html I am very confused by this question. That has nothing to do with the programming language: it has all to do with the GUI toolkit you use (lazarus in that case). If you used lazarus with D instead of Pascal (if it is possible), you would have the same limitations in D. If you use another GUI toolkit in D/Pascal (e.g. GTK3, Qt5, Tk, etc.), you will have the limitations of that toolkit, which may or may not support Arabic text. So, the reason is the toolkit. I guessed D has specific library for GUI, and with that I judged D as whole that if it supports Arabic or not. Also I don't understand you saying "it's not its time"; there are plenty of GUI programs written in D. :/ I mean "my own time" that I'm still studying D basics, so I'll study GUI programming at another time, but if there are available resources for GUI, I would like to take a look in 'em.
Re: Verbosity in D
On Monday, 8 August 2022 at 00:11:33 UTC, pascal111 wrote: On Sunday, 7 August 2022 at 23:53:36 UTC, Emanuele Torre wrote: On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? Quote: "In terms of functionality, Pascal is pretty much exactly the same as C, except with some sanity-conserving restrictions on one hand, and more verbose syntax on the other. It was an okay language for the time when it was popular, and I would give it kudos just for having the common sense to make the assignment operator := instead of =, and not allowing it to be chained, but verbosity back then was still something to be avoided if possible, so C was naturally seen as superior." https://www.quora.com/Is-there-a-value-learning-Pascal-now-Are-there-actually-any-parts-where-Pascal-is-better-than-C-Is-this-language-worth-investing-time-into-What-would-the-added-value-be-if-I-learn-it Regaring this, I don't understand what you mean either. How is D unnecesarily verbose? Do you have any specific example? I don't have specific code but it was a general notice. Take Python as in example, the same program in Python doesn't cost much code as D code, and of course by putting in accounts that that I assume that there are some special tasks D can do, while Python can't do. You are just sounding like a troll now... That makes no sense: "I assume that there are some special tasks D can do, while Python can't do" How? "Take Python as in example, the same program in Python doesn't cost much code as D code" What same program are you talking about? Why did you mention python as if you showed me an example I can see? What am I supposed to say if can't even explain or show an example of how D is more verbose?
Re: Verbosity in D
On Sunday, 7 August 2022 at 23:44:26 UTC, Emanuele Torre wrote:
On Sunday, 7 August 2022 at 23:31:45 UTC, pascal111 wrote:
On Sunday, 7 August 2022 at 22:16:55 UTC, Emanuele Torre wrote:
[...]
It seems complex, I didn't get it yet, I wished I didn't ask
about it :)
It's really trivial.
`auto [x, y] = getpoint();` is equivalent to
```C++
auto _p = getpoint();
auto x = _p.x /* first element of the struct */;
auto y = _p.y /* second element of the struct */;`
```
Also works with arrays.
```C++
int[] arr = { 10, 12, 14 };
const auto [x, y, z] = arr;
/* x=10 y=12 z=14 */
```
A lot of programming languages have this.
Really, I'm not sure I'm understanding this syntax `auto [x, y] =
getpoint();`, if you have the name of term of it in D or an
explaining link.
Re: Supporting Arabic in GUI
On Sunday, 7 August 2022 at 23:48:22 UTC, pascal111 wrote: I have no idea about GUI or Rad programming in D; it's not its time, but I'm curious to know if D is fine supporting for Arabic language in the GUI applications or we will have some issues like I met - in my experience - in Free Pascal. This is a topic where we trying to make a custom message box supporting Arabic as what's supposed to be, but we didn't reach although that the degree we want: https://forum.lazarus.freepascal.org/index.php/topic,59765.0.html I am very confused by this question. That has nothing to do with the programming language: it has all to do with the GUI toolkit you use (lazarus in that case). If you used lazarus with D instead of Pascal (if it is possible), you would have the same limitations in D. If you use another GUI toolkit in D/Pascal (e.g. GTK3, Qt5, Tk, etc.), you will have the limitations of that toolkit, which may or may not support Arabic text. Also I don't understand you saying "it's not its time"; there are plenty of GUI programs written in D. :/
Re: Verbosity in D
On Sunday, 7 August 2022 at 23:53:36 UTC, Emanuele Torre wrote: On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? Quote: "In terms of functionality, Pascal is pretty much exactly the same as C, except with some sanity-conserving restrictions on one hand, and more verbose syntax on the other. It was an okay language for the time when it was popular, and I would give it kudos just for having the common sense to make the assignment operator := instead of =, and not allowing it to be chained, but verbosity back then was still something to be avoided if possible, so C was naturally seen as superior." https://www.quora.com/Is-there-a-value-learning-Pascal-now-Are-there-actually-any-parts-where-Pascal-is-better-than-C-Is-this-language-worth-investing-time-into-What-would-the-added-value-be-if-I-learn-it Regaring this, I don't understand what you mean either. How is D unnecesarily verbose? Do you have any specific example? I don't have specific code but it was a general notice. Take Python as in example, the same program in Python doesn't cost much code as D code, and of course by putting in accounts that that I assume that there are some special tasks D can do, while Python can't do.
Re: Verbosity in D
On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? Quote: "In terms of functionality, Pascal is pretty much exactly the same as C, except with some sanity-conserving restrictions on one hand, and more verbose syntax on the other. It was an okay language for the time when it was popular, and I would give it kudos just for having the common sense to make the assignment operator := instead of =, and not allowing it to be chained, but verbosity back then was still something to be avoided if possible, so C was naturally seen as superior." https://www.quora.com/Is-there-a-value-learning-Pascal-now-Are-there-actually-any-parts-where-Pascal-is-better-than-C-Is-this-language-worth-investing-time-into-What-would-the-added-value-be-if-I-learn-it Regaring this, I don't understand what you mean either. How is D unnecesarily verbose? Do you have any specific example?
Re: Verbosity in D
On Sunday, 7 August 2022 at 23:44:26 UTC, Emanuele Torre wrote:
int[] arr = { 10, 12, 14 };
Oops, this is C++, not D: `int arr[] = { 10, 12, 14 };` =)
Supporting Arabic in GUI
I have no idea about GUI or Rad programming in D; it's not its time, but I'm curious to know if D is fine supporting for Arabic language in the GUI applications or we will have some issues like I met - in my experience - in Free Pascal. This is a topic where we trying to make a custom message box supporting Arabic as what's supposed to be, but we didn't reach although that the degree we want: https://forum.lazarus.freepascal.org/index.php/topic,59765.0.html
Re: Verbosity in D
On Sunday, 7 August 2022 at 23:31:45 UTC, pascal111 wrote:
On Sunday, 7 August 2022 at 22:16:55 UTC, Emanuele Torre wrote:
On Sunday, 7 August 2022 at 20:15:05 UTC, pascal111 wrote:
What destructuring binds? I didn't hear about that before.
```C++
#include
struct Point {
int x, y;
};
Point add_points(const Point& a, const Point& b)
{
return { a.x + b.x, a.y + b.y };
}
int main()
{
const auto [x, y] = add_points({ 1, 10 }, { -60, 40 });
std::cout << "x is: " << x << '\n';
std::cout << "y is: " << y << '\n';
}
```
It seems complex, I didn't get it yet, I wished I didn't ask
about it :)
It's really trivial.
`auto [x, y] = getpoint();` is equivalent to
```C++
auto _p = getpoint();
auto x = _p.x /* first element of the struct */;
auto y = _p.y /* second element of the struct */;`
```
Also works with arrays.
```C++
int[] arr = { 10, 12, 14 };
const auto [x, y, z] = arr;
/* x=10 y=12 z=14 */
```
A lot of programming languages have this.
Re: Verbosity in D
On Sunday, 7 August 2022 at 22:16:55 UTC, Emanuele Torre wrote:
On Sunday, 7 August 2022 at 20:15:05 UTC, pascal111 wrote:
What destructuring binds? I didn't hear about that before.
```C++
#include
struct Point {
int x, y;
};
Point add_points(const Point& a, const Point& b)
{
return { a.x + b.x, a.y + b.y };
}
int main()
{
const auto [x, y] = add_points({ 1, 10 }, { -60, 40 });
std::cout << "x is: " << x << '\n';
std::cout << "y is: " << y << '\n';
}
```
It seems complex, I didn't get it yet, I wished I didn't ask
about it :)
Re: Ranges
On Sunday, 7 August 2022 at 21:57:50 UTC, Ali Çehreli wrote: On 8/7/22 08:34, pascal111 wrote: > but after that in advanced level in programming, we should > use pointers to do same tasks we were doing with slices (the easy way of > beginners). That is an old thought. Today, we see that no matter how experienced, every person needs and appreciates help to prevent bugs. There are many cases of bugs killing people, jeopardizing expensive projects, loss of personal information, etc. Ali I think you are right that this is an old thought, I didn't noticed that, maybe it's because I didn't study C++ and know only about C, so I applied C features on D.
Re: Verbosity in D
On Sunday, 7 August 2022 at 20:15:05 UTC, pascal111 wrote:
What destructuring binds? I didn't hear about that before.
```C++
#include
struct Point {
int x, y;
};
Point add_points(const Point& a, const Point& b)
{
return { a.x + b.x, a.y + b.y };
}
int main()
{
const auto [x, y] = add_points({ 1, 10 }, { -60, 40 });
std::cout << "x is: " << x << '\n';
std::cout << "y is: " << y << '\n';
}
```
Re: Ranges
On 8/6/22 22:58, Salih Dincer wrote: > Ranges are not like that, all they do is > generate. You may be right. I've never seen it that way. I've been under the following impression: - C++'s iterators are based on an existing concept: pointers. Pointers are iterators. - D's ranges are based on an existing concept: slices. Slices are ranges. However, I can't find where I read that. Ali
Re: Ranges
On 8/7/22 08:34, pascal111 wrote: > Everyone knows that slices are not pointers D's slices are "fat pointers": In D's case, that translates to a pointer plus length. > that pointers are real work, Agreed. Pointers are fundamental features of CPUs. > but slices are like a simple un-deep technique that is appropriate for > beginners, That is not correct. Slices are designed by a C expert to prevent horrible bugs caused by C experts. Most C experts use slices very happily. > but after that in advanced level in programming, we should > use pointers to do same tasks we were doing with slices (the easy way of > beginners). That is an old thought. Today, we see that no matter how experienced, every person needs and appreciates help to prevent bugs. There are many cases of bugs killing people, jeopardizing expensive projects, loss of personal information, etc. Ali
Re: Ranges
On Sunday, 7 August 2022 at 19:53:06 UTC, ag0aep6g wrote: On Sunday, 7 August 2022 at 15:34:19 UTC, pascal111 wrote: Everyone knows that slices are not pointers that pointers are real work, but slices are like a simple un-deep technique that is appropriate for beginners, but after that in advanced level in programming, we should use pointers to do same tasks we were doing with slices (the easy way of beginners). I can't tell if this is a joke or not. It's just an opinion.
Re: Verbosity in D
On Sunday, 7 August 2022 at 16:45:15 UTC, jfondren wrote: On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? That's not clear to me at all, and your Pascal example about a feature that C and D both have, that doesn't help either. Post some code that seems particularly verbose to you. I think 'library code' tends to grow attributes like mushrooms, and that D gets longer when you try to avoid the GC, but casual use of D isn't more verbose than scripting languages. With competitors like Rust and C++ Go and and Zig, D usually wins pretty significantly in this respect. The only consistently less verbose language in this space is Nim, IMO. Do consider Go and Rust languages in the same level of C++ to make this comparison? I didn't use these languages before but I think they are just new languages which has no real history like C++ to compare with!!! With that said, dmd previews =in and =shortenedMethods both allow shorter expressions in D. And there are some C++ (and even C) convenience features that D doesn't have, like destructuring binds, or doesn't like, like anonymous struct literals with named fields. What destructuring binds? I didn't hear about that before.
Re: Ranges
On Saturday, 6 August 2022 at 15:37:32 UTC, pascal111 wrote:
On Friday, 5 August 2022 at 04:05:08 UTC, Salih Dincer wrote:
On Thursday, 4 August 2022 at 22:54:42 UTC, pascal111 wrote:
I didn't notice that all what we needs to pop a range forward
is just a slice, yes, we don't need variable here.
Ranges and Slices are not the same thing. Slicing an array is
easy. This is a language possibility. For example, you need an
incrementing variable for the Fibonacci Series.
SDB@79
What!!! so where's ranges?! I thought slices of any array are
ranges, and understood it like that, and also there's no data
type called ranges, it's like if you are talking about Ghostly
data type!
A range is like an iterator in any other language (Java, C++,
python3, javascript, etc), it is how D implements (lazy)
generators https://en.wikipedia.org/wiki/Lazy_evaluation .
Ranges/Iterators don't necessarily have to be backed by memory,
they just have to implement the interface. In D, a `empty` bool
function that tells you whether you are at the end of the range
or not; a `front` function to get the current value if the range
is not `empty`; and a void function named `popFront` to advance
to the next value if the range is not `empty`.
Once you have implemented this interface, you can use your
"range" object with any function that accept a range; with
`foreach`; etc.
Example of a range that is not backed by memory is a range with
all the integer numbers.
```D
struct Integers {
private int z = 0;
/* or make it a bool attribute that starts as false, and you
set to
* true when popFront is called while z is equal to int.min */
public bool empty() { return false; }
public int front() { return this.z; }
public void popFront()
{
/* if (this.z == int.min) { this.empty = false; return; } */
this.z *= -1;
if (this.z <= 0)
--this.z;
}
}
void main()
{
import std.stdio : writeln;
/* foreach is syntax sugar for
* for (auto r = Integers(); !r.empty(); r.popFront()) {
* auto z = r.front(); /+ or const z = r.front(); or ...
+/
* ...
* }
* that is why it only works with ranges.
*/
foreach (const z; Integers()) {
writeln(z);
if (z == 5)
break;
}
}
```
output:
```
0
-1
1
-2
2
-3
3
-4
4
-5
5
```
This will iterate all the integers, and the integers are of
course, not
all in memory, and don't remain in memory after they are used,
since
that would require infinite memory. (in the case of a range of
integers,
not infinite, because they are constrained by being int.sizeof
bytes,
but you could use a bignum implemenation that is not constrained
by
that and they would actually be infinite.)
---
The equivalent in Java is the Iterable/Iterator interface.
```java
import java.util.Iterator;
public class Integers
implements Iterable
{
public class IntegersIterator
implements Iterator
{
private int z = 0;
private boolean first = true;
public IntegersIterator(Integer z)
{
this.z = z;
}
@Override
public boolean hasNext() { return true; }
@Override
public Integer next()
{
if (this.first) {
this.first = false;
return this.z;
}
this.z *= -1;
if (this.z <= 0)
--this.z;
return this.z;
}
}
@Override
public IntegersIterator iterator() { return new
IntegersIterator(0); }
public static void main(String[] args)
{
/* syntax sugar for
* {
* final var it = newIntegers.iterator();
* while (it.hasNext()) {
* final int z = it.next();
* ...
* }
* }
*/
for (final int z : new Integers()) {
System.out.println(z);
if (z == 5)
break;
}
}
}
```
The equivalent in python is a generator function:
```python
def integers():
z = 0
yield z
while True:
z *= -1
if z <= 0:
z -= 1
yield z
for z in integers():
print(z)
if z == 5:
break
```
etc
Re: Ranges
On Sunday, 7 August 2022 at 15:34:19 UTC, pascal111 wrote: Everyone knows that slices are not pointers that pointers are real work, but slices are like a simple un-deep technique that is appropriate for beginners, but after that in advanced level in programming, we should use pointers to do same tasks we were doing with slices (the easy way of beginners). I can't tell if this is a joke or not.
Re: Ranges
On Sunday, 7 August 2022 at 15:34:19 UTC, pascal111 wrote: Everyone knows that slices are not pointers that pointers are real work, but slices are like a simple un-deep technique that is appropriate for beginners, but after that in advanced level in programming, we should use pointers to do same tasks we were doing with slices (the easy way of beginners). The following information about slices may be helpful: Slices are objects from type T[] for any given type T. Slices provide a view on a subset of an array of T values - or just point to the whole array. Slices and dynamic arrays are the same. A slice consists of two members - a pointer to the starting element and the length of the slice: ```d T* ptr; size_t length; // unsigned 32 bit on 32bit, unsigned 64 bit on 64bit ``` [...] **Source:** https://tour.dlang.org/tour/en/basics/slices SDB@79
Re: Verbosity in D
On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? That's not clear to me at all, and your Pascal example about a feature that C and D both have, that doesn't help either. Post some code that seems particularly verbose to you. I think 'library code' tends to grow attributes like mushrooms, and that D gets longer when you try to avoid the GC, but casual use of D isn't more verbose than scripting languages. With competitors like Rust and C++ Go and and Zig, D usually wins pretty significantly in this respect. The only consistently less verbose language in this space is Nim, IMO. With that said, dmd previews =in and =shortenedMethods both allow shorter expressions in D. And there are some C++ (and even C) convenience features that D doesn't have, like destructuring binds, or doesn't like, like anonymous struct literals with named fields.
Verbosity in D
It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? Quote: "In terms of functionality, Pascal is pretty much exactly the same as C, except with some sanity-conserving restrictions on one hand, and more verbose syntax on the other. It was an okay language for the time when it was popular, and I would give it kudos just for having the common sense to make the assignment operator := instead of =, and not allowing it to be chained, but verbosity back then was still something to be avoided if possible, so C was naturally seen as superior." https://www.quora.com/Is-there-a-value-learning-Pascal-now-Are-there-actually-any-parts-where-Pascal-is-better-than-C-Is-this-language-worth-investing-time-into-What-would-the-added-value-be-if-I-learn-it
Re: Ranges
On Sunday, 7 August 2022 at 05:12:38 UTC, Ali Çehreli wrote: On 8/6/22 14:10, pascal111 wrote: > a powerful point in the account of C. I missed how you made that connection. Everyone knows that slices are not pointers that pointers are real work, but slices are like a simple un-deep technique that is appropriate for beginners, but after that in advanced level in programming, we should use pointers to do same tasks we were doing with slices (the easy way of beginners).
Re: "chain" vs "~"
On Sunday, 7 August 2022 at 03:55:50 UTC, Emanuele Torre wrote: On Sunday, 7 August 2022 at 01:22:18 UTC, pascal111 wrote: [...] They are quite different: * `chain` gives you "range" (iterator) that starts from the first element of `x` and ends at the last element of `y` (like e.g. `zip` in other languages). * `~` creates a new `int[]` with elements from `x` and the elements from `y`. [...] I was wondering why they in D repeating ways for the same function, but I know now I'm wrong, "chain" isn't like "~".
Re: Ranges
On Saturday, 6 August 2022 at 17:29:30 UTC, Ali Çehreli wrote: On 8/6/22 09:33, Salih Dincer wrote: > the slices feel like ranges, don't they? Yes because they are ranges. :) (Maybe you meant they don't have range member functions, which is true.) Slices use pointers. Do I need to tell you what the pointers do! Each of them points to a data. Ranges are not like that, all they do is generate. Ok, you use a slice just as if it were a range. But they are not ranges. SDB@79
