Fr0sT.Brutal

As I said there, that answer deserves much more upvotes))

Git branches are powerful but they require some time to get used with, like every powerful but complicated technology. Good news is that you don't have to use this workflow unless you feel you're ready. When I was learning Git, I've had single-branch repos for about a year (I'm single developer). Then I started learning tags, branches, merging etc. Now I'm aware of Git ideal workflow but still mostly use single main branch and just eventually start a new one for a new feature.

Better to replace them with conditional like {$IFDEF WITH_INLINES} inline; {$ENDIF} - this change could be merged into upstream so you won't have to do it with every update

No I meant redefining an env var https://stackoverflow.com/a/38003499/1497831

Just disable all features that will be working for licensed users only. Check out lower answer in that SO topic Btw, if you won't encrypt your code and use some sly tricks, it would be quite easy to detect all these `if customerA` places and make the app fully functional

Well, if compiler supported standardized set of capability checks it would be enough in most cases. But let's face the truth - Emba/Idera's purpose is to make people move to recent versions. They unlikely will support any framework helping to stick to older versions

The experiment isn't clean. You have whole process of reading from HDD included which is very variable because of OS file cache mechanism. You also add search action that is not relevant to memory allocations.

rsvars.bat && msbuild.exe /t:build /nologo %ProjFile% beat it with call to dcc32 😜

Any exception has it address pointing to a place in app's code. Why not look at that place? Moreover you can retrieve full call stack when an exception is thrown

Yep, I always wondered why so many people use concrete version defines that make the whole code unusable when a new version arrives. I personally prefer minimizing usage of version defines replacing them with defines that declare the very feature. F.ex., RAD_2010 => GENERICS_OK (non-buggy generics). It's like using logically named identifiers instead of i1, jj3 etc

Yes, it CAN use any lib but currently only OpenSSL is supported 😜

From my experience on building with C objs. Converting from COFF is not needed, XE2+ can handle COFF. VC: * build with platform toolset = SDK * config > C/C++ > Code gen > Runtime = /MD * config > C/C++ > Code gen > buffer security check = No * if __RTC_* are required: 'Basic Runtime Checks' are used; to disable them, you can go on the project properties, and set the Configuration Properties>C/C++>Code gen>Basic Runtime Checks option to 'Default'. https://stackoverflow.com/questions/10158013/unresolved-external-symbols-rtc-in-windows-programming-tutorial * if __aullshr is required: turn off "/O1" optimization Configuration Properties>C/C++>Optimization https://stackoverflow.com/questions/54719855/unresolved-external-symbol-aullshr-when-optimization-is-turned-off + Configuration Properties>C/C++>debug info format C7 (/Z7) * if chkstk is required Configuration Properties > C/C++ > Command Line > Additional Options, add /Gs1000000 Delphi: * use Windows, ctrl * you can declare names as strings if they're mangled function CheckStream(Data: Pointer; Size: NativeUInt): Byte; cdecl; external name '?CheckStream@@YA_NPBEI@Z'; {$L ZDecoder.obj} Also: [VC] names are mangled in С++ build mode, try to build in С mode that only adds "_" The main issue I hadn't solved is a specific order of linking obj's when they have wide dependencies on each other. Probably "ld -relocatable .\ReleaseDLL\SomeDir\*.obj -o OneObj.o" would help

If only Delphi support true complex constants (arrays, records), typed constants would lose their sense. It's a shame Delphi still can't declare stupid constant array of strings. Btw, for typing simple constants you can use typecasting instead: const clBlack = TColor(0); const rbsCRLF = RawByteString(#13#10);

Nice to know! I guess they're more or less recent addition These rules are results of personal experience. I've seen an app that required changing decimal separator from default comma to dot in system settings to work, otherwise it crashed constantly. So here comes Rule #3 (the general one) Rule #3. Remember the world is much more complex than you may think. - There are different locales - There are different languages - There are different timezones - There are characters beyond A..Z - There are Right-to-left scripts etc

Side note: having a choice, I'd stay away from such a software unless there would be REALLY strong benefits in using it. Then I'd use it but curse its developer regularily

Rule #1. Always use standardized format for string representation. For dates it could be ISO 8601 or something custom but explicitly forced! F.ex. with FormatDateTime(dt, CommonFormat). The same with floats. Rule #2. Use *ToStr functions without FormatSettings parameter only for displaying purposes. User has his locale settings so he expects data in a defined format. Don't force him to see another one (imagine if some app would force you to use 12-hour time or American MM/DD/YYYY format that makes Europeans crazy).

Don't forget '%%d' (meant to produce '%d' after formatting) and '%s%s' cases

It could be not so much up to date but I keep adding stuff from time to time. Luckily not much things change at language level. Anybody is always welcomed to do pull request or fill an issue; I'll try to update the list to 10.4 in the near future

$1000 for a toy PC? You could get 5 NUCs for this price

Not a surprise on initially German forum ;)))

THTTPClient uses high-level OS facilities and libs, TIDHTTP is based on low-level sockets and OpenSSL libs that must be provided for TLS to work. My guess is that Id is more feature rich but if you just need to poll some URL from time to time, THTTPClient is good choice

Poor man's solution: Project group with all your 100 projects -> open in RAD -> build all -> go make yourself some tea

This repo is very outdated. I forked and did lots of updates from original C project but this tech has disadvantages: - antiviruses are likely be nervous when your app would use such memory loading - there's no workaround if a library is doing something important in DLLMain

United types are a headache in JS/TS... you must always check whether that 'foo' is number, or string, or maybe string object, or undefined, or null... Overloaded methods rule. Compiler takes care of correct branching so you can't forget some type check and ruin your app. One addition I'd add to generics is "is" operator for simple types. Nevertheless, "de-generising" a type is a bad practice that should be avoided so I doubt is would be added to language

I gathered most valuable ones of them in https://github.com/Fr0sT-Brutal/Delphi_Compilers (intended for library devs that have to support many compiler versions)