Anders Melander

If either of the operands in a boolean expression is a variant then both operands are converted to variants. This is documented. Expressions on variants are evaluated using intrinsic functions implemented in system.variants.pas (_VarOr, _VarAnd, _VarAdd, etc. etc.). Because of the result of an expression isn't known until these functions has been called the compiler can't do short circuit evaluation on the expression. Look at the asm generated and it will all make sense No offense taken, but don't cry wolf just because the dog meows.

Who says it need fixing? Do you realize how much code it would break if the behavior was changed now? Also, maybe find out why it works the way it does before calling it a bug.

https://www.google.com/search?q=free+resource+editor+res http://melander.dk/reseditor (I'm the author)

You should ask @pyscripter about that. My guess is that the original SynEdit is used in a lot more applications and probably maintained more. You can check the commit logs yourself.

Nonsense. Evaluation is always left to right. Period. No. That will suffer from boolean short circuit which is the whole point of this thread. Actually at this point it seems that the point of the thread has become for everyone to have a different opinion. I wonder why the simplest questions, with the simplest answer, always gets the most attention.

If you use {$BOOLEVAL ON} and {$BOOLEVAL OFF} instead it will be a bit clearer what's going on. There's no point in passing Result along as a parameter. You're just doing an logical OR on the values in the list anyway. - and I do think you're being too clever. It's not a solution I would allow.

Okay then. There's none that I can think of that doesn't fall into the "too clever" category so I would choose the solution that is the most human readable.

Your first two solutions are fine. Why try to be "clever"?

https://github.com/SynEdit/SynEdit

Yes

No. I claimed that they would exhibit the same symptoms. I.e. incorrect result due to accumulation of rounding errors. That's not twisting anything. The degree of imprecision will be the same for the same data type regardless of the compiler since we're dealing with a native data type implemented on the CPU. The exact error might differ, but that doesn't make any difference. I'll take your word for that. It's all GrΣΣk to me

Yes they both suffer from floating point rounding errors. The fact that the exact error values differ doesn't make any difference. All compilers will suffer from this as the imprecision is inherent in the nature of floating point precision. Higher precision will make the error smaller but there will still be errors. As David points out the only way to avoid that is to use another algorithm. If that isn't practical then one might try to implement with an arbitrary precision library.

Why would that make a difference? If the problem is caused by rounding errors then FP will exhibit the exact same symptoms.

So... SO is better than a forum?

stackoverflow

Can't you use middle click to close the file?

I know. Hence the

[Alt]+V = View menu E = New Edit window [Alt]+[Space] = Top level Windows menu X = Maximize

[Alt]+V E [Alt]+[Space] X

Famous last words. I hear the NSA is very fond of hardware firewalls. The firmware is often very old.

Maybe you shouldn't have let that guy with the strange English accent from "Microsoft Support" help you with you "PC problem" Speaking of sleeping right at night; This thread was actually the topic on my dreams (yes, it was a nightmare) last night: I watched in horror as all my systems were being encrypted before my eyes. Somehow the hacker had so much control over my system that it kept on running even after I pulled the plug. Completely unrelated , but the first thing I did this morning was to run a compete scan on my system.

In this example, no, since the only design-time functionality being used is RegisterComponents() which is implemented in the RTL in a runtime package, not a design-time package. So this example can exist in a single runtime+designtime package. What I meant was that it's good practice to separate all run- and design-time code regardless of the fact that I didn't need to in this case. Thus my use of should instead of must. So far we have just your word for that and I contest it. The Delphi Developer's Guide has 14 pages on the topic of creating run- and design-time packages yet nothing that supports your claim. However it does mention one little detail that I had completely forgotten about: The DCLUSR default package. Guess what; It's a design-time only package. Do I need to elaborate on what that implies?

That depends on how you setup your projects. For example I never use the global library search path for anything other than the standard VCL/RTL. All project specific libraries goes into the project search path. Since I also place these libraries in sub folders under the project root all the search path entries can be made relative to the root. This has the benefit that the projects can built anywhere by just pulling the source. All projects are self contained.

That's fine if you only work with projects where only one version of the components are ever used at the same time across projects or branches. If you have to maintain multiple versions or branches of a project then you will potentially have to recompile the packages every time you change the branch you work on. It's a significant effort to have to babysit every commit made by unaware developers because they save forms with component properties that doesn't exist in the version of the components the application will be built with. Compiles and runs fine on their system but breaks at run time when built on the build server. If Embarcadero dog-fooded Delphi on something other that Delphi itself then I'm pretty sure they would have solved this problem a long time ago.

I think you just proved my point there. I'm not saying that you can't get out of trouble. I'm saying it's rather easy to get into trouble. The challenge is figuring out how to do that. https://ohshitgit.com/