David Heffernan

Why would this be useful? It's invariably best to let the system schedule threads. If you are going to do it manually then you probably need to schedule all compute threads manually. Forcing one thread to a specific processor without taking care of other threads in the system will just lead to contention.

Mobile, and Linux (I think) use LLVM. Windows and Mac 32 bit use classic. Not sure about Mac 64 but I'd guess LLVM. Then there's the emulators.... But yeah, it's a mix.

No. I mean what is aDatabase, the variable in your code. What is that? What type.

Just to be clear, what is aDatabase. I suppose the answer could depend on that information.

I just keep a document with every change I make, and then on a new release go and reply them one by one if they are still needed. A few hours work.

Well, we were talking about compiler changes

Slightly smaller executable files, binary literals, literal separators, support for new asm instructions. I think "care" feels a little strong.

I should have been clearer. I'm talking about the new code they added for themed apps. I agree it is necessary for old pre comctl32 v6 apps. I still do that. For comctl32 v6 I can't understand why they don't use PARGB32 images.

It has always been a mistake for Embarcadero to owner draw menus when they have images. I modify the rtl to avoid this and let the system drawn the menus, using PARGB32 images. After about 4 or 5 delphi releases they got their owner draw code to mostly work as well as letting the system draw it, although I think there were still DPI scaling issues. But it was inevitable that a new version of Windows would mean that owner draw code needed updating. And any applications out in the field would be stuck with this owner draw code that hasn't been tweaked for the new Windows version. It makes no sense to me that they did this. Surely the entire point of the system theme is that the system draws it.

Perfect for making images contain partial faces!

For 32 bit it's just Get8087CW and Set8087CW, but your real problem is still identifying the specific point in the code where it is changed.

This isn't to do with project settings. These settings are owned by the thread and something is changing them. By the sounds of it that something is an external DLL. If so you need to save the fp control word before you call the dll and restore that saved value when the dll call returns.

It has been demonstrated this is only possible using include files. I'm not sure what you can expect to find in a book that can add to this knowledge, and I doubt very much that ALL CAPS is going to unlock any blockage. Perhaps more likely is that what you are remembering was how to split something other than interface and implementation parts of a unit.

I'm sure you can do this easily enough with tools like obs

Attempts to build multiple projects in a group lead to out of memory errors on my XE7 Delphi. I guess things are somewhat better in later releases.

I don't think it should be either or, why can't we have both? Instead if often seems that we have neither.

Clearly there is a problem but you'd need to provide information on what the data is and precisely how you are processing it before you can get specific help. One thing I can probably say with confidence is that you are falling into the well know Delphi memory stream anti pattern.

Why do you want Embarcadero C++? What in particular are you looking for that is specific to Embarcadero tools rather than standard C++?

I bet Peter hasn't even written to Embarcadero!!

As I demonstrated in my previous comment what you are looking for is impossible so clearly you must have misremembered.

There's no other way. The interface and implementation sections of a unit must be in a single translation unit and the only way to have multiple files in a single translation unit is with include files.

Previous comments from Andy

I have the feeling that Andy is quite happy not to have to keep chasing updates.....

Even this can happen if the developer is splitting time between two different projects.

Merge conflicts happen whether or not the team is using branches or all developing on a single branch. If there are never any conflicts then it doesn't make much difference if you use branches or not. If there are conflicts then they can be a massive problem on long lived branches. But if there are no branches then they are also a massive problem. Often developments are in flux. Devs try something. Realise it was the wrong idea. Try something else, and so on. If this happens without branches then everyone has to deal with the conflicts over and over again. That's more work. Well managed branches make this easier. There never are magic bullet solutions for tough problems like this. You have to keep an open mind and do what works best for their teams.