Re: Completing C code with D style
On Sunday, 14 November 2021 at 04:29:53 UTC, forkit wrote: On Saturday, 13 November 2021 at 23:02:15 UTC, pascal111 wrote: I touch that D is big language, it's not small like standard C. This will cost me much studying, so I think I need slow down and learn it step by step. Yes. C is so much smaller, and thus simpler (till you wanna do something complex) But C also makes it 'simpler' to shoot yourself in the foot ;-) Even with your simple C code, which is so easily tranposed to D, you already benefit from: - variables being always initialised before use (i.e no need to initalise i in your for loop, in D) - array indices being automatically checked for out-of-bounds (i.e. i < 10 ... in D.. it becomes.. numbers.length ) so you can make your simple code, even 'simpler' in D ;-) Thanks! I won't hide my real intention. Learning C to learning D is like the case of doctor Jekyll and Mr. Hyde, if I'm in the place of Jekyll, I treat Hyde as a son and I want to teach him programming, and we can't do that with C because it belongs to vertical thinking, while D belongs to Hyde or the horizontal thinking.
Re: Completing C code with D style
On Saturday, 13 November 2021 at 23:02:15 UTC, pascal111 wrote: I touch that D is big language, it's not small like standard C. This will cost me much studying, so I think I need slow down and learn it step by step. Yes. C is so much smaller, and thus simpler (till you wanna do something complex) But C also makes it 'simpler' to shoot yourself in the foot ;-) Even with your simple C code, which is so easily tranposed to D, you already benefit from: - variables being always initialised before use (i.e no need to initalise i in your for loop, in D) - array indices being automatically checked for out-of-bounds (i.e. i < 10 ... in D.. it becomes.. numbers.length ) so you can make your simple code, even 'simpler' in D ;-)
Re: Completing C code with D style
On Thursday, 11 November 2021 at 22:30:12 UTC, forkit wrote: On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote: [...] ok.. for a more on topic response.. First: Please name your variables sensibly: char negativity, even; // grrr!!! char answer1, answer2; // makes so much more sense [...] I touch that D is big language, it's not small like standard C. This will cost me much studying, so I think I need slow down and learn it step by step.
Re: Completing C code with D style
On Thursday, 11 November 2021 at 19:34:42 UTC, Stanislav Blinov wrote: Original C code from the first post can only fail on I/O, which is arguably out of your control. And the meat of it amounts to 10 conditional stores. Your implementations, in both C and D, are a very, very far distance away from that. Like I mentioned before, the whole algorithm can already complete even before a single `malloc` call starts executing. Not caring about *that* is just bad engineering. Actually, that's an interesting comment, as it clearly indicates where we differ in perspective when we read that initial code. The 'meat' of it, from my perspective, is 'there's someone using this code'. So why is there no code to verify that input, and handle incorrect input in a user friendly manner. The rest of the coding is kinda automatic reflex.. use a for loop.. or a switch..use an array or a vector..separate concerns into functions...I really don't care what or how you do that part (as long as it's not code I need to understand or maintain). But don't give me a program that says enter a, b or c, but ultimately doesn't give a shi# what I enter. Hence the 'addition's I made ;-) I think your perspective, and mine (and others) are ALL valid.
Re: Completing C code with D style
On Friday, 12 November 2021 at 01:05:15 UTC, Stanislav Blinov wrote: On Thursday, 11 November 2021 at 22:10:04 UTC, forkit wrote: It's called 'staged learning'. Staged learning is the only way for humans to learn, due to the limitations of the human cognitive system. Specifically, the way short-term memory and long-term memory facilitate learning. Those who lack this understanding of how humans learn, tend to throw too much at novices. Like making a simple program do a bunch of extra work for literally no reason? Also, this apparent drive towards requiring novices to understand the implications of their code, in terms of optimising the assembly that gets produced, is just nonsense. They'll never get pass the for loop! This has nothing to do with "optimising the assembly". also, I think it's important not to conflate, code that doesn't perform well, with code that is not optimal. it doesn't take very long as a developer, before you realise nobodys likes slow software ;-) so performance will ALWAYS be front of mind, once you reach that point. We don't need people telling us your code needs to written so that it performs well. But even fast software is not necessarily optimised, and likely far from it in many scenarios... and getting worse it seems... which is ok, as long as faster devices keep rolling out I guess.. most people are developers (incl me), not programmers per se, and don't have the time to understand the ins and outs of how code executes on hardware, and how one library finction interacts with another.etc... and so are not really in a position to optimise it. They are more interested in ensuring the solution they give to their users is not slow. That's what matters to them, and their users. An app that use 3GB of your memory, when (if optimised) really could reduce that to 1GB, sounds great, in principle. But what effect will that optimised code have in terms of bugs and maintainance? So there are tradeoffs that do genuiely need to be considered, and circumstances differ. btw. None of the solutions in this thread are slow..not by any means... and its certainly likely that none are optimal. Hopefully the compiler and library are doing their very best to make it optimal ;-)
Re: Completing C code with D style
On Friday, 12 November 2021 at 01:05:15 UTC, Stanislav Blinov wrote: On Thursday, 11 November 2021 at 22:10:04 UTC, forkit wrote: It's called 'staged learning'. Staged learning is the only way for humans to learn, due to the limitations of the human cognitive system. Specifically, the way short-term memory and long-term memory facilitate learning. Those who lack this understanding of how humans learn, tend to throw too much at novices. Like making a simple program do a bunch of extra work for literally no reason? I think what you're missing here, is that this thread was about how to bring some C code into D, and do it some kinda 'D style'. But this thread clearly demonstrates, there is no 'D style'. Stop being so combative ;-) let people be creative first, performance oriented second (or third.. or .). If we all wrote code the same way, we'd likely all be thinking the same way... and that would not be good. If people want code that looks the same as everyone elses, and forces you to think in the same way as everyone else, they can go use Go ;-)
Re: Completing C code with D style
On Thursday, 11 November 2021 at 22:10:04 UTC, forkit wrote: It's called 'staged learning'. Staged learning is the only way for humans to learn, due to the limitations of the human cognitive system. Specifically, the way short-term memory and long-term memory facilitate learning. Those who lack this understanding of how humans learn, tend to throw too much at novices. Like making a simple program do a bunch of extra work for literally no reason? Also, this apparent drive towards requiring novices to understand the implications of their code, in terms of optimising the assembly that gets produced, is just nonsense. They'll never get pass the for loop! This has nothing to do with "optimising the assembly".
Re: Completing C code with D style
On Thursday, 11 November 2021 at 23:41:48 UTC, kdevel wrote: On Thursday, 11 November 2021 at 22:30:12 UTC, forkit wrote: [...] for(int i = 0; i < sizeof(numbers) / sizeof(int); ++i) // is so much safer - in C style I made it even safer: for (int i = 0; i < sizeof numbers / sizeof *numbers; ++i) (void*)*numbers = NULL; ..don't you just love C ;-)
Re: Completing C code with D style
On Thursday, 11 November 2021 at 21:56:19 UTC, Ali Çehreli wrote:
On 11/11/21 11:34 AM, Stanislav Blinov wrote:
> Pessimization, though, is laughably easy, and
> should be avoided at all costs.
I am not passionate about this topic at all and I am here
mostly because I have fun in this forum. So, I am fine in
general.
However, I don't agree that pessimization should be avoided at
all costs. I like D because it allows me to be as sloppy as I
want to fix my code later on when it really matters.
And when is that? And why is it not now? You mean prototyping?
You can do that in any language, not sure what's special about D
here. Sure, prototype away. No one gets everything right in a
single keystroke.
> Not caring about *that* is just bad engineering.
There wasn't a problem statement with the original code. So, we
understood and valued it according to our past experiences. For
example, most of us assumed the program was about 10 integers
but I am pretty sure that array was just an example and the
program was meant to deal with larger number of arrays.
What difference does that make? You still don't want to do any
unnecessary work, whether you're dealing with one puny array or a
million of them.
Another example is, you seem to value performance over
maintainability because you chose to separate the selection
letters without getting any programmatic help from any tool:
I didn't "choose" that. That's Siarhei Siamashka's version, fixed
up to use `each` instead of `map!text.join`, because latter
serves no useful purpose.
That is a weird comparison anyway. Performance OVER
maintainability? There's nothing "more performant" or "less
maintainable" in the input handling code, as it's the same as
original.
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", );
if ((negativity == 'b') && (even == 'b'))
For example, the 'b's in that last line may be left behind
unmodified if someone changes the help text alone.
Let me see if I get this straight now... are you seriously
talking about protecting against this program being altered by a
goldfish? Because in that case, I'd best not write any code
altogether. Someone someday may put an extra semicolon somewhere,
the thing would stop compiling, and I'll be totally ruined.
...Perhaps let's actually stay on this planet?
Someone may find that kind of coding "bad engineering" that
shoul be avoided at all cost.
Sure. Someone definitely may. It'd certainly be nice to decouple
input from logic. That doesn't take 14 times more code and AAs to
do though. Just sayin' ;)
(Not to defend myself but my associative array was exactly
because I could not bring myself to separate those selection
letters from the help text. I simply could not show
unmaintainable code to a beginner.)
The original UI code is four lines. Four. Not fool-proof, input's
not even validated. But four lines. Yours is fifty five, just to
construct and present the UI and read input. Consequently,
original program is about 14 times easier to maintain than yours.
What did I miss?
Re: Completing C code with D style
On Thursday, 11 November 2021 at 22:30:12 UTC, forkit wrote:
[...]
for(int i = 0; i < sizeof(numbers) / sizeof(int); ++i) //
is so much safer - in C style
I made it even safer:
for (int i = 0; i < sizeof numbers / sizeof *numbers; ++i)
Maybe the type of numbers is changed in the future. sizeof is an
operator which needs parentheses around its argument only for
types. sizeof (non-type-arg) alleges a binding that does not
exist:
#include
struct bar {
long l1;
long l2;
};
#define S(a) #a, (long unsigned) a
int main ()
{
struct bar *b;
printf ("%25s = %lu\n", S(sizeof(*b)));
printf ("%25s = %lu\n", S(sizeof(*b).l1));
printf ("%25s = %lu\n", S(sizeof(b)->l1));
return 0;
}
compiles (!) and gives:
sizeof(*b) = 16
sizeof(*b).l1 = 8
sizeof(b)->l1 = 8
Re: Completing C code with D style
On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote: Next code originally was a classic C code I've written, it's pure vertical thinking, now, I converted it successfully to D code, but I think I made no much changes to make it has more horizontal thinking style that it seems D programmers care in horizontal thinking style. Is there any additions I can make in the code to make it suitable with D style or it's fine? ok.. for a more on topic response.. First: Please name your variables sensibly: char negativity, even; // grrr!!! char answer1, answer2; // makes so much more sense Second: You need to use D-style syntax in your array declaration int numbers[10] = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26]; // C style int[10] numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26]; // D style Third: you're asking for trouble in your for loop declaration. for(int i = 0; i < 10; ++i) // grrr!! What if you counted up your elements incorrectly? for(int i = 0; i < sizeof(numbers) / sizeof(int); ++i) // is so much safer - in C style for(int i = 0; i < numbers.length; ++i) // is so much safer - in D style Finally, D is multi paradigm. That's probably the first (and most important) thing you should know about D. Yes, you can write C style easy, and in many cases, that's just fine. You can also write in other styles. But sometimes it is worthwhile rewriting code differently, to see what advantages, if any, comes about. D is a language where you can actually do just that. Above is a good (although very basic) example - i.e. change the way you define a for loop, so that it's safer, simpler, and more maintainable. Also, use of lambdas, UCFS, etc.. (which is probably what you meant by 'horizontal' code), if used sensibly, can remarkably reduce and simplify code, as well as contributing to the maintainability of that code. Thankfully, D is multiparadigm (which is its best and worst feature), and so it lets you can experiment with different styles. Try doing this in C, Go, Rust...
Re: Completing C code with D style
On Thursday, 11 November 2021 at 21:13:03 UTC, Stanislav Blinov wrote: On Thursday, 11 November 2021 at 00:11:07 UTC, H. S. Teoh wrote: It depends on what you're doing. In the OP's example, yeah worrying about allocations is totally blowing things out of proportions. But that's the thing. How would one ever learn to know where that dividing line is if all the learning material they see teaches them the opposite - to not know or care? It's called 'staged learning'. Staged learning is the only way for humans to learn, due to the limitations of the human cognitive system. Specifically, the way short-term memory and long-term memory facilitate learning. Those who lack this understanding of how humans learn, tend to throw too much at novices. Also, this apparent drive towards requiring novices to understand the implications of their code, in terms of optimising the assembly that gets produced, is just nonsense. They'll never get pass the for loop!
Re: Completing C code with D style
On 11/11/21 11:34 AM, Stanislav Blinov wrote:
> Pessimization, though, is laughably easy, and
> should be avoided at all costs.
I am not passionate about this topic at all and I am here mostly because
I have fun in this forum. So, I am fine in general.
However, I don't agree that pessimization should be avoided at all
costs. I like D because it allows me to be as sloppy as I want to fix my
code later on when it really matters.
> Not caring about *that* is just bad engineering.
There wasn't a problem statement with the original code. So, we
understood and valued it according to our past experiences. For example,
most of us assumed the program was about 10 integers but I am pretty
sure that array was just an example and the program was meant to deal
with larger number of arrays.
Another example is, you seem to value performance over maintainability
because you chose to separate the selection letters without getting any
programmatic help from any tool:
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", );
if ((negativity == 'b') && (even == 'b'))
For example, the 'b's in that last line may be left behind unmodified if
someone changes the help text alone. Someone may find that kind of
coding "bad engineering" that shoul be avoided at all cost. (Not to
defend myself but my associative array was exactly because I could not
bring myself to separate those selection letters from the help text. I
simply could not show unmaintainable code to a beginner.)
I don't think there is much more to see here: A simple C program,
liberties taken for fun in D, pessimization is bad, unmaintainability is
bad, yes.
Ali
Re: Completing C code with D style
On Thursday, 11 November 2021 at 00:11:07 UTC, H. S. Teoh wrote: It depends on what you're doing. In the OP's example, yeah worrying about allocations is totally blowing things out of proportions. But that's the thing. How would one ever learn to know where that dividing line is if all the learning material they see teaches them the opposite - to not know or care? 'Twas a simple task: traverse an array and print numbers out of it based on a predicate. That is all the original program did. How does doing (LOTS) more than that make any of it easier to understand, let alone equivalent to execute? forkit says: "if I was writing millions of processes across 1000s of servers..." No. Just... no. If I've only ever written "convenient" pessimized code, I won't magically start lighting up those wasted transistors just because I got a new job. I'll just be writing the same "convenient" pessimized code, only it would now span 1000s of servers. Which is the exact effing situation that we're in already!
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 23:15:09 UTC, forkit wrote: On Wednesday, 10 November 2021 at 22:17:48 UTC, russhy wrote: On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote: btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. So I really don't give a damn about allocations .. not one little bit ;-) Having the right mindset helps not make these mistakes in the future Changing habits is hard, make sure to train yourself to pick the right one, early if possible Umm.. you kinda missed the last part of my post... ..where I said..'Now if I were running a million processes across 1000's of servers, I probably would give a damn.' Your CPU executes code speculatively, and in parallel. That's just the way it is, it's how the machine works. Therefore, you simply cannot afford to NOT think about that. You're just wasting your machine time if you're not caring about that. Consequently, you're wasting your time, someone else's time, and, well, money. No, it's not a million processes across 1000s of servers, it's at least two processes across n cores, each of which has m ALUs. (At least two because the OS is involved). But it's two processes from you, two processes from me, four from the other guy, and pretty soon you have a monster that struggles to utilize even a tenth of your machine. All because "I'll care about it tomorrow". C'mon... nothing in my code was 'unacceptable' in terms of speed or efficiency. Making code transformations to improve speed and efficieny are important, but secondary. A newcomer cannot improve code that they do not understand ;-) Yes, optimization is hard. Pessimization, though, is laughably easy, and should be avoided at all costs. "I don't care" is the number 1 reason for the atrocious situation with software that we're in right now. And people tend to come up with all sorts of ridiculous excuses, but most of them, distilled, do amount to "I don't care". My phone is a thousand times faster, and has two million times more memory, than the thing that guided Apollo 11 to the Moon. And yet it sometimes takes longer to react to my keystrokes than roundtrip for a radio signal to the Moon *and* back. My desktop is two times faster, and has eight times more memory, than my phone. But it consistently takes THREE TIMES the roundtrip of a radio signal to the Moon and back to start Visual Studio. Heck, it will take longer than the roundtrip of a radio signal to the Moon and back to post this message after I hit "Send". And I'm reasonably certain this news server is not on the Moon. This all is, plainly, ridiculous. Picking understandable code first, IS right. No. "Understability" is subjective. Show me some code in Scala or Fortran, I won't make heads or tails of it, even though it may be perfectly obvious to the next guy who also never saw either language. What's "right" is writing code that doesn't perform, or cause, any unnecessary work. It may not be fast, but at least it won't be slow for no reason. In any case, I say again, this thread is not about writing performance code per se, but about presenting code to new-comers, that they can make some sense of. And how does invoking extra work help with that? Coupled with not even explaining what that extra work is and why it is there? Taking some C code, and writing/presenting it in D (or vica-versa) in such a way that you can longer make any sense of it, is kinda futile. Original C code from the first post can only fail on I/O, which is arguably out of your control. And the meat of it amounts to 10 conditional stores. Your implementations, in both C and D, are a very, very far distance away from that. Like I mentioned before, the whole algorithm can already complete even before a single `malloc` call starts executing. Not caring about *that* is just bad engineering. If you're writing C, or D, you're not writing pulp fiction for the masses. There are other languages for that.
Re: Completing C code with D style
On Thu, Nov 11, 2021 at 01:09:26AM +, forkit via Digitalmars-d-learn wrote: > On Thursday, 11 November 2021 at 00:11:07 UTC, H. S. Teoh wrote: > > On Wed, Nov 10, 2021 at 11:39:40PM +, forkit via Digitalmars-d-learn > > wrote: [...] > > > I still remember compiling code on my 286x86 ... talk about low > > > memory..whoaaah. > > > > ... > > But if you're in a time-constrained inner loop, you do *not* want to > > be allocating memory without a second thought, lest you provoke the > > ire of the GC and get a stop-the-world pause in the wrong moment. > > E.g., when your radiotherapy dosage controller is just about to shut > > off the radiation beam, and the extra pause can mean death from > > overdose. :-P .. > > > Silly me.. if only I had used v2.098.0 ... I might still be alive. > > https://dlang.org/changelog/2.098.0.html#forkgc T -- I am not young enough to know everything. -- Oscar Wilde
Re: Completing C code with D style
On Thursday, 11 November 2021 at 00:11:07 UTC, H. S. Teoh wrote: On Wed, Nov 10, 2021 at 11:39:40PM +, forkit via Digitalmars-d-learn wrote: [...] I still remember compiling code on my 286x86 ... talk about low memory..whoaaah. ... But if you're in a time-constrained inner loop, you do *not* want to be allocating memory without a second thought, lest you provoke the ire of the GC and get a stop-the-world pause in the wrong moment. E.g., when your radiotherapy dosage controller is just about to shut off the radiation beam, and the extra pause can mean death from overdose. :-P .. Silly me.. if only I had used v2.098.0 ... I might still be alive. https://dlang.org/changelog/2.098.0.html#forkgc
Re: Completing C code with D style
On Wed, Nov 10, 2021 at 11:39:40PM +, forkit via Digitalmars-d-learn wrote: [...] > I still remember compiling code on my 286x86 ... talk about low > memory..whoaaah. That's nothing! ;-) When I was a kid, I programmed a computer that had only 48K of RAM (that's 48 *kilo*bytes, not megabytes!). The address space was 64K (16-bit), but beyond the 48K boundary was occupied by ROM which cannot be modified. > These days, I have a 4GB ramdisk, put all the dmd/phobos..etc source > code into that, and everything is read/compiled completely in memory, > in seconds. The slowest part is copying the compilation back to disk, > but even that happens so fast I don't even see it happen. In all likelihood, it isn't actually copying everything back to disk in that instant, but rather sitting in the HD cache while the controller slowly writes it to disk in the background. :-D (Well, before that, in the OS cache.) > Worrying about an extra allocation here or there seems kinds trivial > over here ;-) It depends on what you're doing. In the OP's example, yeah worrying about allocations is totally blowing things out of proportions. But if you're in a time-constrained inner loop, you do *not* want to be allocating memory without a second thought, lest you provoke the ire of the GC and get a stop-the-world pause in the wrong moment. E.g., when your radiotherapy dosage controller is just about to shut off the radiation beam, and the extra pause can mean death from overdose. :-P Or y'know, the more important thing these days -- hundreds of your gamers will complain about jerkiness or lower framerates in their totally-important 60fps GPU-raytraced game. ;-) Or, on a more serious note, if you're trying to solve a mathematically hard problem, needless allocations can mean the difference between getting the answer next week vs. the next century. Sometimes these things *do* add up. T -- MSDOS = MicroSoft's Denial Of Service
Re: Completing C code with D style
On Wed, Nov 10, 2021 at 03:13:08PM -0800, Ali Çehreli via Digitalmars-d-learn wrote: > On 11/10/21 3:05 PM, H. S. Teoh wrote: > > > I cannot compile even simple programs on a low-memory system because > > the compiler runs out of memory > > Did the -lowmem switch help in some cases? On my (high-mem) home PC, it does help to reduce the memory footprint somewhat. But unfortunately, not enough to make compilation work on the low-mem systems on all except the most trivial of programs. So still no-go. > Is -betterC any better? ;) [...] Have not tried. Maybe I'll give it a shot when I have some time. I'm not a fan, though. Using -betterC loses some of the key advantages D offers over C, and would probably not be incentive enough for my colleagues to consider adopting D. (We had tried C++ before and given up on it, so whatever is going to displace C in this space better offer a LOT more than C++ ever did. Simply being yet another variant of C isn't going to cut it.) T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 23:05:06 UTC, H. S. Teoh wrote: On Wed, Nov 10, 2021 at 10:17:48PM +, russhy via Digitalmars-d-learn wrote: On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote: > btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. > So I really don't give a damn about allocations .. not one > little bit ;-) It's not a good mindset to have Give room for the unexpected, don't burn all of your options right now Having good foundation helps one to grow and scale faster than others [...] +1. Ironically, dmd itself is pretty care-free about allocating memory (in the name of compile speed -- after all, everybody has GBs of RAM to spare, but nobody wants to wait, right?). As a result, I cannot compile even simple programs on a low-memory system because the compiler runs out of memory and crashes before it can finish compiling. What good is a super-fast compiler that cannot finish compiling before it uses too much memory? Because of this, I have not dared to introduce D to my colleagues -- if they see what dmd does on the kind of low-memory embedded systems that we work on, they'd get such a bad impression of D they'll never ever want to hear about it again. :-/ T I still remember compiling code on my 286x86 ... talk about low memory..whoaaah. These days, I have a 4GB ramdisk, put all the dmd/phobos..etc source code into that, and everything is read/compiled completely in memory, in seconds. The slowest part is copying the compilation back to disk, but even that happens so fast I don't even see it happen. Worrying about an extra allocation here or there seems kinds trivial over here ;-)
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 22:17:48 UTC, russhy wrote: On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote: btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. So I really don't give a damn about allocations .. not one little bit ;-) Having the right mindset helps not make these mistakes in the future Changing habits is hard, make sure to train yourself to pick the right one, early if possible Umm.. you kinda missed the last part of my post... ..where I said..'Now if I were running a million processes across 1000's of servers, I probably would give a damn.' C'mon... nothing in my code was 'unacceptable' in terms of speed or efficiency. Making code transformations to improve speed and efficieny are important, but secondary. A newcomer cannot improve code that they do not understand ;-) Picking understandable code first, IS right. In any case, I say again, this thread is not about writing performance code per se, but about presenting code to new-comers, that they can make some sense of. Taking some C code, and writing/presenting it in D (or vica-versa) in such a way that you can longer make any sense of it, is kinda futile. I doubt the original op will ever come back to D, after seeing some of those examples that were provided ;-)
Re: Completing C code with D style
On 11/10/21 3:05 PM, H. S. Teoh wrote: > I cannot compile > even simple programs on a low-memory system because the compiler runs > out of memory Did the -lowmem switch help in some cases? Is -betterC any better? ;) Ali
Re: Completing C code with D style
On Wed, Nov 10, 2021 at 10:17:48PM +, russhy via Digitalmars-d-learn wrote: > On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote: > > btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. So I > > really don't give a damn about allocations .. not one little bit ;-) > > It's not a good mindset to have > > Give room for the unexpected, don't burn all of your options right now > > Having good foundation helps one to grow and scale faster than others [...] +1. Ironically, dmd itself is pretty care-free about allocating memory (in the name of compile speed -- after all, everybody has GBs of RAM to spare, but nobody wants to wait, right?). As a result, I cannot compile even simple programs on a low-memory system because the compiler runs out of memory and crashes before it can finish compiling. What good is a super-fast compiler that cannot finish compiling before it uses too much memory? Because of this, I have not dared to introduce D to my colleagues -- if they see what dmd does on the kind of low-memory embedded systems that we work on, they'd get such a bad impression of D they'll never ever want to hear about it again. :-/ T -- Verbing weirds language. -- Calvin (& Hobbes)
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote: btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. So I really don't give a damn about allocations .. not one little bit ;-) It's not a good mindset to have Give room for the unexpected, don't burn all of your options right now Having good foundation helps one to grow and scale faster than others Often i seen gamedevs write shitty code, "it's fine" they said, only to realize their game runs at 10FPS when they decide it's time to port it to the Switch (portable console) or when one decide to play on a laptop Or your server can no longer fit in the 128mb VPS instance, and you forced to pay the more expensive one, only because "it was fine" Having the right mindset helps not make these mistakes in the future Changing habits is hard, make sure to train yourself to pick the right one, early if possible
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 06:47:32 UTC, forkit wrote: btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. So I really don't give a damn about allocations .. not one little bit ;-) That's not the point. The point is the program is doing unnecessary non-trivial work while introducing additional failure paths. It certainly has ways to go to reach Ali's AA solution, but still... To put things in perspective, the algorithm can easily complete before malloc even returns (heck, before it even starts executing). There's what, 11 cmovs at most? It would take several dozen instructions, a couple of loops and a few other branches just to find malloc when you first call it. Not to mention it itself making that syscall and setting up its bins... And I'm not even talking about optimization. Just, uh, non-pessimization.
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 04:54:58 UTC, Stanislav Blinov wrote: On Tuesday, 9 November 2021 at 11:03:09 UTC, forkit wrote: They both produce exactly the same output. But do vastly different things. But I tell ya.. the cognitive load .. well.. it increased dramatically ;-) Of course it did. Cuz you overthunk it. Dramatically. Your D version allocates memory, for no good reason. I mean, to store results, but you already have storage for them, so kinda pointless. Your C version, OTOH, stores results on stack (so again, why did you allocate for them in D?..), but allocates some "string builder" for... what, exactly? The program is filter, or sort + partition. Requires 0 allocations in C or D. And.. in any case, the take away from this thread should not be about nonallocating coding, but rather the interesting comment from the originl op.. "Wow! your code seem so nice, I like it although I don't know how exactly it works."
Re: Completing C code with D style
On Wednesday, 10 November 2021 at 04:54:58 UTC, Stanislav Blinov wrote: On Tuesday, 9 November 2021 at 11:03:09 UTC, forkit wrote: They both produce exactly the same output. But do vastly different things. But I tell ya.. the cognitive load .. well.. it increased dramatically ;-) Of course it did. Cuz you overthunk it. Dramatically. Your D version allocates memory, for no good reason. I mean, to store results, but you already have storage for them, so kinda pointless. Your C version, OTOH, stores results on stack (so again, why did you allocate for them in D?..), but allocates some "string builder" for... what, exactly? The program is filter, or sort + partition. Requires 0 allocations in C or D. Thanks for your feedback. This was not production code. It took a few minutes to do it on my pc, just for a little fun. So I doubt that I 'overthunk it' in such a small amount of time ;-) Also, my thought process began from the basis that the number data was immutable, and that the final data need to be stored, so that it could be manipulated etc... at will. I also wanted the use to a message, as to what they chose (hence the manipulation of memory for a message that could not be know in advance of the user making those choices). btw. My pc has 24GB of main memory, and my CPU 8MB L3 cache. So I really don't give a damn about allocations .. not one little bit ;-) Now if I were running a million processes across 1000's of servers, I probably would give a damn.
Re: Completing C code with D style
On Tuesday, 9 November 2021 at 11:03:09 UTC, forkit wrote: They both produce exactly the same output. But do vastly different things. But I tell ya.. the cognitive load .. well.. it increased dramatically ;-) Of course it did. Cuz you overthunk it. Dramatically. Your D version allocates memory, for no good reason. I mean, to store results, but you already have storage for them, so kinda pointless. Your C version, OTOH, stores results on stack (so again, why did you allocate for them in D?..), but allocates some "string builder" for... what, exactly? The program is filter, or sort + partition. Requires 0 allocations in C or D.
Re: Completing C code with D style
On Monday, 8 November 2021 at 12:04:26 UTC, forkit wrote:
On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote:
Next code originally was a classic C code I've written, it's
pure vertical thinking, now, I converted it successfully to D
code, but I think I made no much changes to make it has more
horizontal thinking style that it seems D programmers care in
horizontal thinking style. Is there any additions I can make
in the code to make it suitable with D style or it's fine?
Oh man! some of those answers... whoohah
Here's mine, with a little of that horizontal thinking ;-)
And just had a little fun transposing my D code back into C.
They both produce exactly the same output.
But I tell ya.. the cognitive load .. well.. it increased
dramatically ;-)
increased cognitive load bad!
// ==
#include
#include
#include
#include
#include
void displayResults(const char answer1, const char answer2);
int main(void)
{
char answer1, answer2;
while (true)
{
printf("Would you like in list (n=negatives, p=positives,
b=both)? ");
scanf_s(" %c", , 1);
if (answer1 == 'n' || answer1 == 'p' || answer1 == 'b')
{
break;
}
printf("%c is not a valid answer. Try again.\n", answer1);
}
while (true)
{
printf("Would you like in list (e=evens, o=odds, b=both)?
");
scanf_s(" %c", , 1);
if (answer2 == 'e' || answer2 == 'o' || answer2 == 'b')
{
break;
}
printf("%c is not a valid answer. Try again.\n", answer2);
}
displayResults(answer1, answer2);
putchar('\n');
return EXIT_SUCCESS;
}
void displayResults(const char answer1, const char answer2)
{
// NOTE: 0 is neither positive or negative, but is considered
to be even
int numbers[11] = {-3, 14, 47, -49, -30, 15, 4, -82, 99, 26,
0};
// an array to store results from answer1
int result1[sizeof(numbers) / sizeof(numbers[0])];
// the final array that consolidates the results from answer1
and answer2
// must be at least this size in case it stores all elements
from numbers.
int finalResult[sizeof(numbers) / sizeof(numbers[0])];
int result1Count = 0; // to keep count of number of elements
aquired in answer1
int result2Count = 0; // to keep count of number of elements
aquired in answer2
// my version of a string builder ;-)
const int msgSize = 50; // should be large enough to hold the
entire message.
char *const resultMsg = (char *)malloc(msgSize);
if (resultMsg == NULL)
{
exit(EXIT_FAILURE); // not enough memory!! really??!!
}
strcpy_s(resultMsg, 15, "\nHere are all ");
switch (answer1)
{
case 'n':
for (size_t i = 0; i < sizeof(numbers) / sizeof(int);
i++)
{
if (numbers[i] < 0)
result1[result1Count++] = numbers[i];
}
memcpy((char *)resultMsg + 14, "[negative] \0", 12);
break;
case 'p':
for (size_t i = 0; i < sizeof(numbers) / sizeof(int);
i++)
{
if (numbers[i] > 0)
result1[result1Count++] = numbers[i];
}
memcpy((char *)resultMsg + 14, "[positive] \0", 12);
break;
case 'b':
for (size_t i = 0; i < sizeof(numbers) / sizeof(int);
i++)
{
result1[result1Count++] = numbers[i];
}
break;
default:
// how could it ever get here??
printf("Bad input!!\n%c is not a valid answer.",
answer1);
assert(0); // don't waste my time!
}
// debug
/*
{
printf("\n[ result1Count after processing answer1 is: %d
]\n ", result1Count);
for (int i = 0; i < result1Count; i++)
{
printf("%d ", result1[i]);
}
putchar('\n');
}
*/
switch (answer2)
{
case 'e':
for (int i = 0; i < result1Count; i++)
{
if ((result1[i] % 2) == 0)
finalResult[result2Count++] = result1[i];
}
if (answer1 == 'b')
{
memcpy((char *)resultMsg + 14, "[even]\0", 7);
}
else
{
memcpy((char *)resultMsg + 25, "[even]\0", 7);
}
break;
case 'o':
for (int i = 0; i < result1Count; i++)
{
if ((result1[i] % 2) != 0)
finalResult[result2Count++] = result1[i];
}
if (answer1 == 'b')
{
memcpy((char *)resultMsg + 14, "[odd]\0", 6);
}
else
{
memcpy((char *)resultMsg + 25, "[odd]\0", 6);
}
break;
case 'b':
for (int
Re: Completing C code with D style
On Monday, 8 November 2021 at 12:04:26 UTC, forkit wrote: case 'o' : result = result.filter!(a => (a % 2 == 1)).array; oops. case 'o' : result = result.filter!(a => (a % 2 != 0)).array;
Re: Completing C code with D style
On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote:
Next code originally was a classic C code I've written, it's
pure vertical thinking, now, I converted it successfully to D
code, but I think I made no much changes to make it has more
horizontal thinking style that it seems D programmers care in
horizontal thinking style. Is there any additions I can make in
the code to make it suitable with D style or it's fine?
Oh man! some of those answers... whoohah
Here's mine, with a little of that horizontal thinking ;-)
// =
module test;
import std.stdio : write, writeln, writefln, readf;
import std.algorithm : filter, sort;
import std.array: array;
void main()
{
// NOTE: 0 is neither positive or negative, but is considered
to be even
int[] numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26, 0];
int[] result;
char answer1;
write("Would you like in list (n=negatives, p=positives,
b=both)? ");
readf(" %c", answer1);
debug { writeln("You selected ", answer1); }
switch(answer1)
{
case 'n' :
result = numbers.filter!(a => (a < 0)).array;
break;
case 'p' :
result = numbers.filter!(a => (a > 0)).array;
break;
case 'b' :
result = numbers;
break;
default :
writefln("Invalid answer." );
throw new Exception("Bad input!!"); // don't waste my
time!
}
char answer2;
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", answer2);
debug { writeln("You selected ", answer2); }
switch(answer2)
{
case 'e' :
result = result.filter!(a => (a % 2 == 0)).array;
break;
case 'o' :
result = result.filter!(a => (a % 2 == 1)).array;
break;
case 'b' :
break;
default :
writefln("Invalid answer." );
throw new Exception("Bad input!!"); // don't waste my
time!
}
writeln(result.sort());
}
// =
Re: Completing C code with D style
On Saturday, 6 November 2021 at 13:48:59 UTC, jfondren wrote: On Saturday, 6 November 2021 at 13:27:55 UTC, kdevel wrote: On Thursday, 4 November 2021 at 00:53:11 UTC, jfondren wrote: On Wednesday, 3 November 2021 at 20:36:08 UTC, russhy wrote: Keeping things simple helps debugging! As simple as possible, but not simpler! [...] What about the number 0 (zero)? Not treating it as positive is a bug that I introduced in a rewrite. Mathematically a whole number (integer) is positive iff it is greater than 0. Since 0 is not greater than 0 0 is not positive. The vocabulary of the program shall be changed such that the term "positive" is replaced with "non-negative". Or one introduces one (0) or two (-0, +0) new signs ...
Re: Completing C code with D style
On Saturday, 6 November 2021 at 13:27:55 UTC, kdevel wrote:
On Thursday, 4 November 2021 at 00:53:11 UTC, jfondren wrote:
On Wednesday, 3 November 2021 at 20:36:08 UTC, russhy wrote:
Keeping things simple helps debugging!
I'd still have to run your program to be sure of its simple
logic, though. The real star d feature that would help with
debugging is unittest:
What about the number 0 (zero)?
Not treating it as positive is a bug that I introduced in a
rewrite.
If 0 is considered to be excluded from the domain how would one
define in D a type which cannot represent 0 in the first place?
Follow-up question: Are there language facilities such that one
could initialize an array of these non-zero-ints like?:
```
nzint [] numbers = [ -2, -1, 1, 2 ];
```
In general, you use a constructor that tests for non-zero and you
take care to maintain the invariant. D has some tools (like
invariant) to help with that, but it's not a dependent-typed
language.
For this specific example, you can sort of do that with
std.typecons.Nullable
```d
unittest {
import std.typecons : Nullable, nullable;
import std.algorithm : map;
import std.array : array;
alias NonZero(T) = Nullable!(T, 0);
NonZero!int[] numbers = [-2, -1, 0, 1, 2].map!(i =>
NonZero!int(i)).array;
int sum;
int invalids;
foreach (n; numbers) {
if (n.isNull) invalids++;
else sum += n.get;
}
assert(sum == 0);
assert(invalids == 1);
}
```
Re: Completing C code with D style
On Thursday, 4 November 2021 at 00:53:11 UTC, jfondren wrote:
On Wednesday, 3 November 2021 at 20:36:08 UTC, russhy wrote:
Keeping things simple helps debugging!
I'd still have to run your program to be sure of its simple
logic, though. The real star d feature that would help with
debugging is unittest:
What about the number 0 (zero)? If 0 is considered to be excluded
from the domain how would one define in D a type which cannot
represent 0 in the first place? Follow-up question: Are there
language facilities such that one could initialize an array of
these non-zero-ints like?:
```
nzint [] numbers = [ -2, -1, 1, 2 ];
```
If 0 is included in the domain the classification of the values
into negative and positive ones is not complete since 0 is
neither.
```
enum sign { negatives = 'n', positives = 'p', both = 'b' }
enum parity { evens = 'e', odds = 'o', both = 'b' }
bool simple(int n, sign s, parity p) {
if (n < 0 && s == sign.positives) return false;
if (n > 0 && s == sign.negatives) return false;
if (n & 1) {
if (p == parity.evens) return false;
} else {
if (p == parity.odds) return false;
}
return true;
}
unittest {
import std.algorithm : filter, equal;
version (have_zero) {
auto numbers = [-2, -1, 0, 1, 2];
}
else {
auto numbers = [-2, -1, 1, 2];
}
alias match = (ns, s, p) => ns.equal(numbers.filter!(n =>
simple(n, s, p)));
assert(match(numbers, sign.both, parity.both));
assert(match([-1], sign.negatives, parity.odds));
assert(match([-2], sign.negatives, parity.evens)); // fails
when we have_zero
assert(match([2], sign.positives, parity.evens));
assert(match([1], sign.positives, parity.odds));
assert(match([-2, -1], sign.negatives, parity.both));
assert(match([-2, 2], sign.both, parity.evens));
}
```
```shell
$ dmd -version=have_zero -checkaction=context -unittest -main
-run a.d
a.d(27): [unittest] false != true
1/1 modules FAILED unittests
```
Re: Completing C code with D style
On Wednesday, 3 November 2021 at 20:36:08 UTC, russhy wrote:
Keeping things simple helps debugging!
I'd still have to run your program to be sure of its simple
logic, though. The real star d feature that would help with
debugging is unittest:
```d
enum sign { negatives = 'n', positives = 'p', both = 'b' }
enum parity { evens = 'e', odds = 'o', both = 'b' }
bool simple(int n, sign s, parity p) {
if (n < 0 && s == sign.positives) return false;
if (n > 0 && s == sign.negatives) return false;
if (n & 1) {
if (p == parity.evens) return false;
} else {
if (p == parity.odds) return false;
}
return true;
}
unittest {
import std.algorithm : filter, equal;
auto numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
alias match = (ns, s, p) => ns.equal(numbers.filter!(n =>
simple(n, s, p)));
assert(match(numbers, sign.both, parity.both));
assert(match([-3, -49], sign.negatives, parity.odds));
assert(match([-30, -82], sign.negatives, parity.evens));
assert(match([14, 4, 26], sign.positives, parity.evens));
assert(match([47, 15, 99], sign.positives, parity.odds));
assert(match([-3, -49, -30, -82], sign.negatives,
parity.both));
assert(match([14, -30, 4, -82, 26], sign.both, parity.evens));
}
```
Re: Completing C code with D style
On 11/3/21 11:41 AM, Stanislav Blinov wrote: > And Ali... associative arrays? For this? What are you trying to teach > the good beginner here? :D Obviously, we're all enjoying this thread but once the OP made it clear that they wanted a C-like solution, I took some liberty with alternative solutions. :) I think even in production code I would implement something similar at least to keep selection characters like 'n' together with their long forms like "negative". I might use linear searching instead of an assoiative array (or store the assoiative arrays for later use, which I did think about before posting it). But, considering they are generated when interacting with stdin, likely fed by a human, the time loss there is zero. :) Ali
Re: Completing C code with D style
On Wednesday, 3 November 2021 at 20:36:08 UTC, russhy wrote:
I don't understand why you guys offer OP such
complicate/bloated examples, it'll only make things confusing
and slow down compilation time with templates and imports, this
is not needed at all
I don't like complicated things either. Additional facilities are
interminable in D :)
For example:
```d
import std.stdio, std.algorithm, std.array;
int main() {
auto numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
char negativity, even;
Start:
bool error;
enum sign { negatives = 'n', positives = 'p', both = 'b' }
write("Would you like in list (n=negatives, p=positives,
b=both)? ");
readf(" %c", );
switch (negativity) with(sign) {
case negatives:
numbers = filter!("a < 0")(numbers).array;
break;
case positives:
numbers = filter!("a > 0")(numbers).array;
break;
case both:
break;
default:
error = true;
goto Error;
}
enum type { evens = 'e', odds = 'o', both = 'b' }
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", );
switch (even) with(type) {
case evens:
numbers = filter!("!(a % 2)")(numbers).array;
break;
case odds:
numbers = filter!("a & 1")(numbers).array;
break;
case both:
break;
default:
error = true;
}
Error:
if(error) {
"Error...".writeln;
goto Start;
} else writef("%(%s\n%)", numbers);
return 0;
}
```
Please try to use auto...
Re: Completing C code with D style
The code "as is" is perfectly fine
I don't understand why you guys offer OP such complicate/bloated
examples, it'll only make things confusing and slow down
compilation time with templates and imports, this is not needed
at all
One change, use .length property instead of the hardcoded value
Keeping things simple helps debugging!
```D
int main() {
int numbers[10] = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
char negativity, even;
write("Would you like in list (n=negatives, p=positives,
b=both)? ");
readf(" %c", & negativity);
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", & even);
// you can access .length property of
slices/arrays/static_arrays in D
for (int i = 0; i < numbers.length; ++i) {
if (negativity == 'n') {
if (numbers[i] > 0)
continue;
} else {
if (negativity == 'p')
if (numbers[i] < 0)
continue;
}
if (even == 'e') {
if (numbers[i] % 2)
continue;
} else {
if (even == 'o')
if (!(numbers[i] % 2))
continue;
}
writefln("%d", numbers[i]);
}
return 0;
}
```
Re: Completing C code with D style
On Wednesday, 3 November 2021 at 00:50:51 UTC, Siarhei Siamashka
wrote:
!text.join("\n").writeln;
Ahem... You've turned a program that does not allocate to a
program that allocates who knows how much memory?
And Ali... associative arrays? For this? What are you trying to
teach the good beginner here? :D
```d
import std.stdio, std.algorithm;
void main()
{
auto numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
char negativity, even;
write("Would you like in list (n=negatives, p=positives,
b=both)? ");
readf(" %c", );
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", );
if ((negativity == 'b') && (even == 'b'))
{
// don't do any unnecessary work
numbers.each!writeln;
}
else
{
numbers.filter!(x => !((negativity == 'n' && x > 0) ||
(negativity == 'p' && x < 0)))
.filter!(x => !((even == 'e' && (x % 2)) ||
(even == 'o' && !(x % 2
.each!writeln;
}
}
```
Re: Completing C code with D style
On Wednesday, 3 November 2021 at 00:57:38 UTC, Ali Çehreli wrote: On 11/2/21 5:50 PM, Siarhei Siamashka wrote: Your code can be changed to something like this: And I over-engineered it. :) import std.stdio; import std.algorithm; import std.range; import std.exception; import std.format; . . . Ali I think I costed you much efforts. Thank you, it's a great version.
Re: Completing C code with D style
On Wednesday, 3 November 2021 at 00:50:51 UTC, Siarhei Siamashka wrote: On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote: By "vertical" vs. "horizontal" thinking, do you mean imperative vs. functional style? https://en.wikipedia.org/wiki/Functional_programming#Imperative_vs._functional_programming Maybe you are right, I think that, but I don't know the exact English terms.
Re: Completing C code with D style
On 11/2/21 5:50 PM, Siarhei Siamashka wrote:
Your code can be changed to
something like this:
And I over-engineered it. :)
import std.stdio;
import std.algorithm;
import std.range;
import std.exception;
import std.format;
// A readable name; corresponds to C's typedef
alias FilterFunction = bool function(int);
// These are our filters; they will be initialized not right
// where they are defined but in a following 'shared static
// this()'. (This is a current D implementation issue.)
immutable FilterFunction[string] negativityFilters;
immutable FilterFunction[string] evennessFilters;
// 'shared static this()' blocks are executed before main()
// is executed.
shared static this() {
const matchAll = (int _) { return true; };
negativityFilters = [
"negatives" : (int i) { return i <= 0; },
"positives" : (int i) { return i >= 0; },
"both" : matchAll,
];
evennessFilters = [
"evens" : (int i) { return (i % 2) == 0; },
"odds" : (int i) { return (i % 2) == 1; },
"both" : matchAll,
];
}
// Picks the filter that corresponds to user input
FilterFunction pickFilter(const(FilterFunction[string]) filters) {
// The full names of filters e.g. [ "evens", "odds", "both" ]
auto fulls = filters.byKey.array.sort;
// The first letters of the names e.g. [ 'b', 'e', 'o' ]
auto shorts = fulls.map!(key => key.front);
// A mapping from short to full name e.g. 'b' -> "both"
auto shortToFull = assocArray(shorts, fulls);
// Prompt the user by combining the short and full names
writef!"Would you like in list (%-(%s, %))? "(
zip(shorts, fulls).map!(z => format!"%s=%s"(z[0], z[1])));
char c;
readf(" %c", );
enforce(c in shortToFull, format!"'%s' is not a valid option"(c));
const full = shortToFull[c];
return filters[full];
}
// Picks filters according to user input
FilterFunction[] pickFilters() {
return [ negativityFilters, evennessFilters ].map!pickFilter.array;
}
// The main logic of the program
void run() {
auto numbers = [ -3, 14, 47, -49, -30, 15, 4, -82, 99, 26 ];
auto filters = pickFilters();
auto selection = numbers.filter!(n => filters.all!(f => f(n)));
writefln!"%-(%s\n%)"(selection);
}
int main() {
try {
run();
return 0;
} catch (Exception e) {
stderr.writefln!"ERROR: %s"(e.msg);
return 1;
}
}
Ali
Re: Completing C code with D style
On Wednesday, 3 November 2021 at 00:50:51 UTC, Siarhei Siamashka
wrote:
On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote:
It's supported in many modern programming languages and it's
not a unique feature of the D language alone. Your code can be
changed to something like this:
import std.stdio, std.algorithm, std.conv, std.string;
void main()
{
auto numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
char negativity, even;
write("Would you like in list (n=negatives, p=positives,
b=both)? ");
readf(" %c", );
write("Would you like in list (e=evens, o=odds, b=both)?
");
readf(" %c", );
numbers.filter!(x => !((negativity == 'n' && x > 0) ||
(negativity == 'p' && x < 0)))
.filter!(x => !((even == 'e' && (x % 2)) ||
(even == 'o' && !(x % 2
.map!text.join("\n").writeln;
}
Wow! your code seem so nice, I like it although I don't know how
exactly it works. For now I'll keep learning traditional
imperative programming style then after that I'll look in the
functional one, it's new to me.
Re: Completing C code with D style
On Tuesday, 2 November 2021 at 23:45:39 UTC, pascal111 wrote:
Next code originally was a classic C code I've written, it's
pure vertical thinking, now, I converted it successfully to D
code, but I think I made no much changes to make it has more
horizontal thinking style that it seems D programmers care in
horizontal thinking style. Is there any additions I can make in
the code to make it suitable with D style or it's fine?
By "vertical" vs. "horizontal" thinking, do you mean imperative
vs. functional style?
https://en.wikipedia.org/wiki/Functional_programming#Imperative_vs._functional_programming
It's supported in many modern programming languages and it's not
a unique feature of the D language alone. Your code can be
changed to something like this:
import std.stdio, std.algorithm, std.conv, std.string;
void main()
{
auto numbers = [-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
char negativity, even;
write("Would you like in list (n=negatives, p=positives,
b=both)? ");
readf(" %c", );
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", );
numbers.filter!(x => !((negativity == 'n' && x > 0) ||
(negativity == 'p' && x < 0)))
.filter!(x => !((even == 'e' && (x % 2)) ||
(even == 'o' && !(x % 2
.map!text.join("\n").writeln;
}
Completing C code with D style
Next code originally was a classic C code I've written, it's pure
vertical thinking, now, I converted it successfully to D code,
but I think I made no much changes to make it has more horizontal
thinking style that it seems D programmers care in horizontal
thinking style. Is there any additions I can make in the code to
make it suitable with D style or it's fine?
// D programming language
import std.stdio;
int main()
{
int numbers[10]=[-3, 14, 47, -49, -30, 15, 4, -82, 99, 26];
char negativity,
even;
write("Would you like in list (n=negatives, p=positives, b=both)?
");
readf(" %c", );
write("Would you like in list (e=evens, o=odds, b=both)? ");
readf(" %c", );
for(int i=0; i<10; ++i)
{
if(negativity=='n')
{
if(numbers[i]>0)
continue;
}
else{
if(negativity=='p')
if(numbers[i]<0)
continue;
}
if(even=='e')
{
if(numbers[i]%2)
continue;
}
else{
if(even=='o')
if(!(numbers[i]%2))
continue;
}
writefln("%d",numbers[i]);
}
return 0;
}
