Re: Wrong result with enum
On Thursday, 11 November 2021 at 14:52:45 UTC, Stanislav Blinov
wrote:
On Thursday, 11 November 2021 at 09:11:37 UTC, Salih Dincer
wrote:
Unless explicitly set, default type is int. 110 is
greater than int.max.
11
```d
enum w = 100_000;
size_t b = w * w;
// size_t b = 10 * 10; // ???
assert(b == 10_000_000_000); // Assert Failure
```
The w!(int) is not greater than the b!(size_t)...
That code is
```
size_t b = int(w) * int(w);
```
That is, `multiply two ints and assign result to a size_t`.
Multiplication of two ints is still an int though, and you
can't fit ten billion in an int, so that's overflow. It doesn't
matter that you declare `b` as `size_t` here. Overflow happens
before that assignment.
Thank you all :)
DMD still has to type inference...
I think the safest and most practical method is to explicitly use
double types:
```d
import std.stdio;
enum factors { n = 1e+9, n1 }
auto gauss (double a = factors.n,
double b = factors.n1)
{ return cast(size_t)(a * b)/2; }
void main()
{
gauss.writeln;
ulong.max.writeln;
}
```
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: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote: As for now, I know no compiler that can do that. GCC can do it. Somewhat notoriously, LTO can lead to bugs from underspecified asm constraints following cross-TU inlining.
Re: How to use dmd code coverage
On Thursday, 11 November 2021 at 22:35:21 UTC, forkit wrote: On Thursday, 11 November 2021 at 21:40:33 UTC, Ali Çehreli wrote: On 11/11/21 1:37 PM, forkit wrote: dmd test.d -cov ...but no .lst file anywhere to be found. Huh! I don't get it. Please run the program! :) Ali oh! that kinda makes sense, now that I think of it ;-) Actually, the reason I got soo confused is clear to me now. I have my own GUI IDE, which I wrote myself (winforms/C#) cause I got so fed up with creating/saving files everytime I just wanted to play with some code. I can use 10 different languages in it...so far. Basically, my IDE means I never need to create/save files manually, I can just write|compile|run (although it has save/open feature too ;-) Unfortunately, it redirecs output of the .exe > somefile.txt (and my IDE reads that file back into a textbox within my IDE to display the results). I never see or use a command prompt). This redirection meant no .lst file was ever created, hence I could not find it. I spent an hour on this! Was so confusing. I know of no solution to this. Basically means I can't use my IDE when I use -cov .. back to the command prompt :-(
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: How to use dmd code coverage
On Thursday, 11 November 2021 at 21:40:33 UTC, Ali Çehreli wrote: On 11/11/21 1:37 PM, forkit wrote: dmd test.d -cov ...but no .lst file anywhere to be found. Huh! I don't get it. Please run the program! :) Ali oh! that kinda makes sense, now that I think of it ;-)
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: How to use dmd code coverage
On 11/11/21 1:37 PM, forkit wrote: dmd test.d -cov ...but no .lst file anywhere to be found. Huh! I don't get it. Please run the program! :) Ali
How to use dmd code coverage
// --
module test;
import std.stdio;
void main()
{
writeln("Hello World!");
}
// ---
dmd test.d -cov
..but no .lst file anywhere to be found. Huh! I don't get it.
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: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 17:29:33 UTC, rempas wrote: On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote: Yes, this is still the case. A particularity of DMD inliner is that it does its job in the front-end, so inlining asm is totally impossible. Then, even if inlining was done in the backend inlining of asm would not be guaranteed because the byte code is generated at a very late stag, which causes problem with the registry allocator, the preservation of the stack, etc. For example ldc2 does not inline a trival asm func https://godbolt.org/z/1W6r693Tq. As for now, I know no compiler that can do that. What? Not even GCC or Clang? Someone said that LDC2 does it with two ways in the thread I linked There's an attribute to tell it the function is safe to inline.
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote: Yes, this is still the case. A particularity of DMD inliner is that it does its job in the front-end, so inlining asm is totally impossible. Then, even if inlining was done in the backend inlining of asm would not be guaranteed because the byte code is generated at a very late stag, which causes problem with the registry allocator, the preservation of the stack, etc. For example ldc2 does not inline a trival asm func https://godbolt.org/z/1W6r693Tq. As for now, I know no compiler that can do that. What? Not even GCC or Clang? Someone said that LDC2 does it with two ways in the thread I linked
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 12:05:14 UTC, Adam D Ruppe wrote: You really shouldn't expect dmd to inline *anything*. Or to optimize anything for that matter. That isn't its strength. Oh yeah! I just thought to ask anyway! Thanks a lot for your time!
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: Wrong result with enum
On Thursday, 11 November 2021 at 09:11:37 UTC, Salih Dincer wrote: Unless explicitly set, default type is int. 110 is greater than int.max. 11 ```d enum w = 100_000; size_t b = w * w; // size_t b = 10 * 10; // ??? assert(b == 10_000_000_000); // Assert Failure ``` The w!(int) is not greater than the b!(size_t)... That code is ``` size_t b = int(w) * int(w); ``` That is, `multiply two ints and assign result to a size_t`. Multiplication of two ints is still an int though, and you can't fit ten billion in an int, so that's overflow. It doesn't matter that you declare `b` as `size_t` here. Overflow happens before that assignment.
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 08:58:43 UTC, rempas wrote: I've seen from [this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case? Yes, this is still the case. A particularity of DMD inliner is that it does its job in the front-end, so inlining asm is totally impossible. Then, even if inlining was done in the backend inlining of asm would not be guaranteed because the byte code is generated at a very late stag, which causes problem with the registry allocator, the preservation of the stack, etc. For example ldc2 does not inline a trival asm func https://godbolt.org/z/1W6r693Tq. As for now, I know no compiler that can do that.
Re: Wrong result with enum
On Thursday, 11 November 2021 at 05:37:05 UTC, Salih Dincer wrote:
is this a issue, do you need to case?
```d
enum tLimit = 10_000; // (1) true result
enum wLimit = 100_000; // (2) wrong result
void main()
{
size_t subTest1 = tLimit;
assert(subTest1 == tLimit);/* no error */
size_t subTest2 = wLimit;
assert(subTest2 == wLimit);/* no error */
size_t gauss = (tLimit * (tLimit + 1)) / 2;
assert(gauss == 50_005_000); /* no error */
gauss = (wLimit * (wLimit + 1)) / 2;
assert(gauss == 5_000_050_000);/* failure
// Fleeting Solution:
enum size_t limit = 100_000;
gauss = (limit * (limit + 1)) / 2;
assert(gauss == 5_000_050_000); //* no error */
} /* Small Version:
void main(){
enum t = 10_000;
size_t a = t * t;
assert(a == 100_000_000);// No Error
enum w = 100_000;
size_t b = w * w;
assert(b == 10_000_000_000); // Assert Failure
}
*/
```
Integer overflow. By default an enum is defined as `int` which is
limited to 32 bit. `int.max` is 2_147_483_647 which is the
biggest number representable with an int.
You can declare the enum to be of a bigger type `enum : long { w
= 100_000 };`
or you can use `std.bigint` if you don't know the maximum you
work with or the library `std.experimental.checkedint` which
allows to set the behaviour one wants in case of overflow.
Re: Wrong result with enum
On Thursday, 11 November 2021 at 05:37:05 UTC, Salih Dincer wrote: is this a issue, do you need to case? ```d enum tLimit = 10_000; // (1) true result enum wLimit = 100_000; // (2) wrong result That's an `int` literal. Try enum wLimit = 100_000L; the L suffix makes a `long` literal.
Re: Wrong result with enum
On Thursday, 11 November 2021 at 12:05:19 UTC, Tejas wrote:
On Thursday, 11 November 2021 at 09:11:37 UTC, Salih Dincer
wrote:
On Thursday, 11 November 2021 at 06:34:16 UTC, Stanislav
Blinov wrote:
On Thursday, 11 November 2021 at 05:37:05 UTC, Salih Dincer
wrote:
is this a issue, do you need to case?
```d
enum tLimit = 10_000; // (1) true result
enum wLimit = 100_000; // (2) wrong result
```
https://dlang.org/spec/enum.html#named_enums
Unless explicitly set, default type is int. 110 is
greater than int.max.
11
```d
enum w = 100_000;
size_t b = w * w;
// size_t b = 10 * 10; // ???
assert(b == 10_000_000_000); // Assert Failure
```
The w!(int) is not greater than the b!(size_t)...
Are you on 32-bit OS? I believe `size_t` is 32 bits on 32 bit
OS and 64 on a 64-bit OS
That's not the issue with his code. The 32 bit overflow happens
already during the `w * w` mulitplication. The wrong result is
then assigned to the `size_t`.
`cast(size_t)w * w` or the declaration `enum : size_t { w =
100_000 };` would change that.
Re: Wrong result with enum
On Thursday, 11 November 2021 at 09:11:37 UTC, Salih Dincer wrote: On Thursday, 11 November 2021 at 06:34:16 UTC, Stanislav Blinov wrote: On Thursday, 11 November 2021 at 05:37:05 UTC, Salih Dincer wrote: is this a issue, do you need to case? ```d enum tLimit = 10_000; // (1) true result enum wLimit = 100_000; // (2) wrong result ``` https://dlang.org/spec/enum.html#named_enums Unless explicitly set, default type is int. 110 is greater than int.max. 11 ```d enum w = 100_000; size_t b = w * w; // size_t b = 10 * 10; // ??? assert(b == 10_000_000_000); // Assert Failure ``` The w!(int) is not greater than the b!(size_t)... Are you on 32-bit OS? I believe `size_t` is 32 bits on 32 bit OS and 64 on a 64-bit OS
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 08:58:43 UTC, rempas wrote: I've seen from [this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case? You really shouldn't expect dmd to inline *anything*. Or to optimize anything for that matter. That isn't its strength.
Re: Wrong result with enum
On Thursday, 11 November 2021 at 06:34:16 UTC, Stanislav Blinov wrote: On Thursday, 11 November 2021 at 05:37:05 UTC, Salih Dincer wrote: is this a issue, do you need to case? ```d enum tLimit = 10_000; // (1) true result enum wLimit = 100_000; // (2) wrong result ``` https://dlang.org/spec/enum.html#named_enums Unless explicitly set, default type is int. 110 is greater than int.max. 11 ```d enum w = 100_000; size_t b = w * w; // size_t b = 10 * 10; // ??? assert(b == 10_000_000_000); // Assert Failure ``` The w!(int) is not greater than the b!(size_t)...
Is DMD still not inlining "inline asm"?
I've seen from [this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case?
