Jump to content

David Heffernan

Members
 View Profile  See their activity

  • Content Count

    3513

  • Joined

  • Last visited

  • Days Won

    174

Posts posted by David Heffernan

  1. Posted

    1 hour ago, Lars Fosdal said:

    From what I read, the 32-bit version of Matlab has issues under W11ARM, while the 64-bit supposedly works.

    IMO - making a general statement that 32-bit and 64-bit intel apps doesn't work on ARM, is a far cry away from specifying some specific apps that don't work.

     

    32 bit version of MATLAB hasn't existed for at least 5 years

  2. Posted

    22 minutes ago, Juan C.Cilleruelo said:

    The only brand that has a product similar to Apple, after a very, very, very conscious comparison, is Microsoft. The Surface Laptop 5 with 32Gb RAM and 1Tb SSD is very similar to the Mac Book Air I first bought. With the discount, even the price was very similar. 

    I compared an XPS13 with Macbook Air 13 and the Macbook, 16GB RAM, 512Tb and the prices are £929 vs £1,649. Looking at 32/1Tb the comparison is £1,400 vs £2,000 and the Macbook only has 24Gb because there is no 32Gb option, at least where I am.

     

    Perhaps I'm missing something. Is this comparison flawed?

     

    Also worth noting that, unless I'm mistake, none of the Macbooks have touch screen displays. You can get a swanky touch screen on the XPS13 and still have a few hundred pounds of change compared to the price for the non touch Mac. 

     

    I must be missing something.

  9. Posted

    9 hours ago, Fred Ahrens said:

    Sorting units by name is dangerous.

    There are some units that need to be added at the end of the list, if they overwrite some behavior's of objects and functions of other units above in the list. There are other units that need to be placed on top of the list if they do some special initialization that needs to be done in the app as soon as possible, before any other parts of the app start to initialize.

    Although the real problem is the language design that makes this order affect the meaning of the program. 

    • Like 2

  16. Posted · Edited by David Heffernan

    Of course the other problem with packing a record that should be aligned is that gives it alignment of 1 so they can be misaligned. These days that doesn't usually matter for x86/x64 but it can be a issue for some SSE2 instructions and for arm processors. 

  19. Posted · Edited by David Heffernan

    1 hour ago, ertank said:

    Even if I make it identical C# enum with Delphi enum, There is still one byte difference in total struct vs record comparison. I check even the last item offset in C# struct matches to Delphi and this last item size also matches on both C# and Delphi. It must be that C# has one byte more at the very bottom of its struct.

     

    @FPiette advise to add it at the end of Delphi record as a dummy variable and I can do that.

     

    I wonder if I absolutely need it?

    If I do need it, I wonder if there is another way of handling that in newer Delphi versions like a compiler directive {$MINENUMSIZE 4}?

     

    Thanks.

    Hard to comment on this without seeing you actual code. This is all about the detail and we have none of it. For all I know you are using packed records and manually inserting padding. In which case, if that's what you've decided to do then you know how to fix it. 

  20. Posted

    48 minutes ago, FPiette said:

    My method works with ALL Delphi compilers.

    It would have been useful to say something like this, like you may need manual alignment if you need to use ancient compilers like Delphi 6. But even then, in most cases, aligned records work as expected. It's only in some very rare cases that this is not the case. Perhaps you have an example for us. Or has that knowledge been lost in the passage of time.

     

    For people that don't need to support 20 year old compilers, feel free to use the compiler to do the alignment.

  21. Posted

    10 minutes ago, FPiette said:

    My experience shows it is NOT always the case.

    Show us an example, with modern Delphi. For sure some ancient versions didn't get alignment correct. That's no longer the case.

     

    Compiler alignment always works for me, and I do a lot of it. And converting to 64 bit was trivial when I had to do that. 

  22. Posted

    57 minutes ago, ertank said:

    Tags is an enum and takes up 4 bytes in C# but 1 byte in Delphi.

    In your Delphi code you should be using {$MINENUMSIZE 4} at the point where you define the enums.

     

    An example from my own codebase:

      

    //Dragon4
{$MINENUMSIZE 4}
type
  TDragon4DigitMode = (DigitMode_Unique, DigitMode_Exact);
  TDragon4CutoffMode = (CutoffMode_TotalLength, CutoffMode_FractionLength);
{$MINENUMSIZE 1}

     

    I would however say that using offset methods to compare offsets is very good advice. But I definitely do not advise manual alignment. The compiler can do it perfectly well. You may as well get it to do that. Then, come the day you move to 64 bit, you won't have to change a thing.

    • Thanks 1

  23. Posted

    3 hours ago, FPiette said:

    To avoid that problem, I always use a packed record and insert dummy data between fields to align used fields the same way as in C++. I use offsetof macro in C/C++ to get the offset of each struct field and a similar Delphi function I wrote to get the offset of a record member.

    This is bad advice. If you are using aligned records in Delphi, then the compiler uses the same alignment rules as for aligned C++ structs, and for aligned C# structs.

×