Jump to content

Vandrovnik

Members
 View Profile  See their activity

  • Content Count

    523

  • Joined

  • Last visited

  • Days Won

    6

Posts posted by Vandrovnik

  1. Posted

    11 minutes ago, Uwe Raabe said:

    If we can gather some more votes for that issue I will be happy to point the product management to it. As it seems to be some low hanging fruit (looks like a missing MoveViewToCursor call), we might have this being included in 10.4.1.

    I have voted... And I am curious whether it will be fixed before the report is 5 years old 🙂

    • Like 1

  2. Posted

    4 hours ago, PeterPanettone said:

    Have you tried to DOCK the Search for Usages result list? Maybe the IDE freezes because it's not docked?

    I have not, because no result list was displayed, just cursor indicating that I should wait... After 3 minutes I killed it.

  4. Posted

    1 hour ago, Mike Torrettinni said:

    I envy you. I don't have the same experience as you do, renaming across multiple units regularly fails on my Delphi 10.2.3, unfortunately.

    It's probably my project design contributing to the issue, but still, the IDE should be managing this better or alert on complex unit design if it bothers it.

     

    In 10.3.3, it is better, usually rename finds all places, but sometimes it does not and finds for example just 10 of 30.

  6. Posted

    From my point of view, typed constants are just initialized variables, not true constants. (Even when I do not change their values in runtime.)

    When used in code, regular (untyped) constants may produce faster code:

      

    const XTyped : integer = 3;
      xUntyped = 3;

var a: integer;

begin
a:=5*XTyped;
if a>20 then exit;
a:=5*XUntyped;
if a>20 then exit;

     

     

    c2.thumb.png.4e5b8d137a4d973b04c38e0b888c3e88.png

  7. Posted

    27 minutes ago, Kas Ob. said:

    .. David and Vandrovnik asked question instead answering or provide an opinion,...

    I have asked, what you think is a bug. You have answered and I wrote you, how compiler probably decides the value and that I do not see a bug there.

     

    When you want to decide, whether Delphi is wrong with something, first you need a specifiaction saying, what is right. Then you can compare actual result with it. And do testing with current version of Delphi, because even if you find an error in old version, it will probably never be fixed.

  9. Posted · Edited by Vandrovnik

    47 minutes ago, Kas Ob. said:

    C and L on 64bit

    They should be the same value with M, M is the right here.

     

    If breaking perfect logical math calculation one line of code into two lines change then value then yes, the compiler is wrong and faulty, the way L and M calculated is identical why should the result be different.

     

    All in all, even it is faulty i prefer consistency, so they should have the same value on all platform and bitness accordingly, don't you think ? 

     

    I will not go with all the combination, i believe you can, if you want change those types with other simple types, some will compile and some will not, and here -1 is fool the compiler to accept it with $R+, but in fact it should not be needed to start with, the compiler refuse to compile this "C : UInt64 = 1 shl 63" while has no problem with "C = UInt64(-1)", is it right to refuse compilation with error ? 

     

    will this example with NativeInt and NativeUInt , change you mind? 

    
{$R+}
const
  C: UInt64 = UInt32(-1) shl 63;
var
  L: UInt64;
  M: UInt64;
begin
  L := UInt32(-1) shl 63;
  M := UInt32(-1);
  M := M shl 63;
  Writeln('C = ' + IntToHex(C, 16));
  Writeln('L = ' + IntToHex(L, 16));
  Writeln('M = ' + IntToHex(M, 16));
  if (M = 1 shl 63) then
    Writeln('True')  else
    Writeln('False');
  if (M = L) then
    Writeln('True')  else
    Writeln('False');
  if (M = C) then
    Writeln('True')  else
    Writeln('False');
  Readln;
end.

    Still wrong

    C = 0000000080000000
    L = 0000000080000000
    M = 8000000000000000
    False
    False
    False

     

    You don't see it as a bug, which is completely fine, each of us has opinion, may be this is a feature and should be documented, so the document should clearly explain and document each and every situation with each type.

     

    C :   UInt64 = UInt32(-1) shl 63;

    I suppose it is calculated in unsigned 32 bits (because you used UInt32) as $FFFFFFFF shl 31 (63 is masked by width of the left side operand), which is $80000000. This number is expanded to unsigned 64bit, so $0000000080000000 is expected result.

     

    The same for L.

     

    Sorry, I do not see a bug here.

     

  13. Posted

    2 minutes ago, David Heffernan said:

    The inability to control the type of a floating point literal is the only real issue here. 

     

    Everything else mentioned above can be readily worked around. But the fact that you can't control the type of a floating point literal presents problems that have no workaround. 

     

    I want to write

     

    const

      s = 0.1s;

      d = 0.1d;

     

    And have two literals with different values. 

     

    You have: 

     const
  F1 = 0.2;
  F2 = Single(0.2);

   writeln(F1);
   writeln(F2);

 2.00000000000000E-0001
 2.00000002980232E-0001

     

  16. Posted

    55 minutes ago, Lars Fosdal said:

    @Kas Ob.

     

    As for D, NativeUInt = 32-bit.  Shifting a 1 63 places to the left in a 32-bit variable, should yield 0.

     

    Delphi's "Shifting a 1 63 places to the left in a 32-bit variable" is the same as "Shifting a 1 31 places to the left in a 32-bit variable", so you will get $80000000.

    In the example above, shifting is done in 64bit variable and the result $8000000000000000 is assigned to 32bit typed constant - lower 32bits are used (0) and a warning is generated.

    • Like 1

  17. Posted

    Also note this in help:

    The operations x shl y and x shr y shift the value of x to the left or right by y bits, which (if x is an unsigned integer) is equivalent to multiplying or dividing x by 2^y; the result is of the same type as x. For example, if N stores the value 01101 (decimal 13), then N shl 1 returns 11010 (decimal 26). Note that the value of y is interpreted modulo the size of the type of x. Thus for example, if x is an integer, x shl 40 is interpreted as x shl 8 because an integer is 32 bits and 40 mod 32 is 8.

     

    So we have: 

    const  P: UInt32 = UInt32(1) shl 63;   // contains 2147483648

     

  18. Posted

    In help, they write: "If constantExpression is a real, its type is Extended."

    I believe F1 and F2 are both extended.

     

    const
      F1 = 0.2;
      F2 = Single(0.2);

     

       writeln(F1);
       writeln(F2);

     

     2.00000000000000E-0001
     2.00000002980232E-0001

     

    If F1 was comp, it could save only integer values.

  24. Posted

    7 minutes ago, Ian Branch said:

    OK.  I'll have another try.

    I have had a look at the article above and am trying to integrate the ShutdownBlockReason.... functions.

    Where are the declared/defined?

    Did you read, what Cristian Peța linked?

      

    function ShutdownBlockReasonCreate(hWnd: HWND; Reason: LPCWSTR): Bool; stdcall; external user32;
function ShutdownBlockReasonDestroy(hWnd: HWND): Bool; stdcall; external user32;

     

  25. Posted

    12 minutes ago, David Heffernan said:

    If what you say were true, then class forward references would not exist.

    I believe Anders is right.

    Class reference is just a pointer - its size is known. When you use this class as a member of another class (fChild: tChild, where tChild is a class), you cannot reference its members in properties (property x: integer read fChild.x). If fChild is a record (fChild: tChild, where tChild is a record), you can reference its members in properties, like in Anders' example (property x: integer read fChild.x).

×