Leaderboard

Giving an error is *always* better than assuming an "instead of" value for invalid data. You can potentially ruin the entire system by doing that. The strategy of giving the error is up to the developer - the "it simply crashes and refuses to do anything with the entire data" is fine. It depends on the data itself if let's say all valid entries can be imported and only the invalid ones can be left out and possibly reported back so the customer can fix them and then import those.

So, some input is invalid. What would you put instead of that corrupt value? Are the data line by line? Is there a sequence among those lines that gives interdependency (f.x. main/detail, header/line, etc)? Can you skip a line without corrupting the import? I agree that the specification should contain instructions on handling empty or invalid fields. If it doesn't - letting it crash and burn and returning that fact to the client is appropriate.

Plenty, this is my current gui of choice - https://git-fork.com/

I would approach this from the point of view that all data provided by the client is bad until proven otherwise - seriously, expect bad data, when it' encountered report that and exit/stop gracefully (with an error message that enables the client to fix the data).

As a programmer, you are aware of the issues around invalid data, missing data, etc. The client who provides the specification is often less aware of these issues, and their consequences. In terms of ethics, I would say that as a programmer it is your responsibility to raise the issue with the client. That's part of being a good professional. How the client responds to that is down to them. If they insist on ignoring invalid data, then that is their choice. But you should strongly advise them against that, and if they do insist, then document that this was their choice. In your case it sounds like the ultimate client is not being advised of this, and the culture in your organisation is to do what the client asks without questioning it. That's a slightly different problem. If the decision takers in your organisation are not receptive to best professional practise then there's only so much you can do.

Fossil would be a weird choice. Regardless of how good it is, it's not widespread. git is everywhere, and has so much tooling and resources available. Very hard to see past it.

You also can use 'absolute'

Another +1 for throwing an error. You can't tell whether it's OK to replace some value from "foo" to "0" and will take responsibility for this replacement f.ex., if someone's bank balance would become zero when a corrupted input is given to you app 🙂 In the area you described specs are your Bible, your weapon and defense. Don't do anything more or less

If you mean you only want to accept LAN connections on port 80 or something, you can can do as you suggest, but this is irrelevant to SSL/TLS. It is quite normal nowadays to respond with a redirection to the correct HTTPS URL. Angus

https://delphi.fandom.com/wiki/Compile_from_Commandline It doesn't explicitly mention anything newer than Delphi 2007, but since the process has not changed, why should it?

From what I see it's fixed like this: var p : PWord;

Best solution would probably to change the type of segment_ptr but then probably the E2010 pops up somewhere else. Anyhow a simple hardcast will do what it did before they tightened the assignment rule in 10.2: p := TWordArray(segment_ptr); Also shouldn't FastReports have fixed that code some while ago given they support 10.2 and higher?

Branch prediction can do wonders in some micro-benchmarks, but they always have a cost, until the CPU logic actually "warmed up". No branch is always better, since the real problem is branch misprediction. Using the asm generated by a recent GCC with tuned optimization flags as a reference is a good hint of what is likely to be more efficient. Intel and AMD are major GCC contributors. And a wall clock of a realistic process (not micro benchmark) is the ultimate reference. We use some part of our automated tests as performance benchmark, running some close-to-the reality scenarios.

Indeed. This is why I use the "if x then repeat until not x" explicit pattern in time-critical loops of my framework - e.g. when processing JSON. As a nice side effect, the variables uses in "x" are more likely to be assigned to registers, since they will be used more often. Sometimes an explicit temporary local variable is needed. Or use of the 'result' variable if it is a PChar. Both Delphi and FPC require this, unless "x" is a single simple test, where I have seen FPC able to optimize it IIRC.

I would think that especially with external data, you can never be 100% sure that all works fine. You made a contract to the data known at that certain time, but you cannot predict the future. Maybe your customer changes the contract without noticing you. I think also that the programmer should handle that as careful as possible, but in reality you will always see unexpected data and behaviour. UnitTests might help a lot, also to identify known "wrong data", but who can predict the unkown ? In some cases the system can handle the unexpected gracefully, in some systems you will find hard crashs. To throw an exception in these cases at least may help to prevent further damage. To cover everything in try - finally, and to ignore exceptions is maybe not the best choice to ensure a good data quality. That way nobody gets aware of such (hopefully rare) cases.

I get more Delphi-specific help online than I get from work colleagues. Have for years. That's the trouble in this business. I get hired because I'm supposedly a "Delphi expert" and they assign me to work with someone who teaches me how to use the crap process they have not changed in 10+ years because "the new guy doesn't know what he's doing yet". I make suggestions, and after a while someone pulls me aside and says I really need to "get with the program" and stop coming up with ideas about how to improve things and start learning the way the system works today ... because it's WORKING. Yup ... mostly ... except for the random errors and the blue-screens and the high-frequency of customer-generated errors that make our apps blow up ... My boss told me recently that I need to not be so afraid to debug stuff, that I need to roll up my sleeves and spend however many hours it takes working with the debugger to find input errors in an import parser. Our customers send us data files with a hundreds of thousands of de-normalized database records in CSV format, and sometimes they leave a new field name off the end of the header; or their system decides to render fields that are not usually zero as <empty>, as in xxx,,yyy,zzz... -- see it there between xxx and yyy? It just jumps right out atcha, don't it? This is the "New and Improved 2020 Digital Millennium Edition of Where's Waldo?" Waldo is hiding between those double-commas! Our code is fairly brittle and we get lots of error reports daily saying the Delphi apps crashed. The problem is that there are a ton of places in the import routines that call things like StrToInt(...) that throw exceptions when an input token is empty or not a numeric value. None of the fields are validated before we try the conversions, and our code doesn't have ANY Try...Except fencing around it anywhere. So all the exceptions get raised to the outermost layer of our framework that just re-raises them. My boss wanted me to get on a screen-share session with another developer to "see how it's done". The other guy said it took him about 90 minutes to track down the problem. Thankfully, I was busy on something else that had higher priority. When I was done with my work, I fired up Delphi, enabled madExcept, ran the same import routine and data, and found the errant line in less than 90 seconds. I made a short video of it with SnagIt and posted it for them. A company license for madExcept is less than it costs us to track down four or five of these import bugs, and we get one or two of them every week from clients. I'm trying to be helpful and show them how to waste less time, but of course they see it like I'm spitting in their faces. People are so effing weird... So don't think you're missing anything by working alone. Most of the folks in this forum can answer questions nobody else can. They get tired of me asking what must seem like dumb or repetitive questions, but that's another matter. It's better than asking colleagues who don't even understand what I'm asking or insist I forget all of that "expertise" they hired me for so I don't make them all look so ignorant. Anyway, I can't tell if what I posted was helpful since you went off on a meta-discussion... As for this comment ... I think you're missing the point entirely. TMyClass = class . . . end; This is a class. It has nothing whatever to do with frames. TMyForm = class(TForm) . . . end; This is also a class. It also has nothing whatever to do with frames. As far as "flexibility" goes ... they're CLASSES ... you can make them do ANYTHING you want! Frames are also classes. So what? So are TStringLists. You're confusing language constructs with magic pixie dust that the IDE provides you in a few random cases. I've seen Frames implemented without help from the IDE and they are butt-ugly and not half as useful. I'm talking about CLASSES... some of which are derived from TForm. The way you interact with TMyForm should be no different than how you interact with TMyClass. That's all I'm saying. People nod their head as if they agree. But they don't. Not really. Most Delphi devs will happily go on and on about the proper ways of interacting with classes (in general), and then proceed to throw most of that lecture out the window when it comes to interacting with Forms. Go figure...

Hi... Even if you are the only developer, you should have a ticket system. You can use it to create small "building blocks" for the project. Think of it as a "to-do" list, where you document which changes have been made for the one ticket. A small one is Mantis. https://www.mantisbt.org/

Yes

@pyscripter Yes this is correct. and it has a lazy form too : const __imp_VirtualAlloc: Pointer = @VirtualAlloc; __imp_VirtualFree: Pointer = @VirtualFree; Now to your linking issue. your best choice is to use a dll. If that is not an option, you can compile your c code for x86 using bcc32c and link the output with delphi. I did this several time and it works. EMB offers c/c++ compiler tool chain at no cost (only for x86). https://www.embarcadero.com/free-tools/ccompiler/ Use MSVC to compile for x64 and link (probably it already worked for you). If bcc32c is not an option, you can manually edit the generated object output(which I don't recommend) : use a hex editor and replace all imported function of your object file : // Replace '@' by '_' or better by a char that is not widely used. And make sure that the new name is not used elsewhere. // you are a scripter man ... you can write a script that do the work for you. __imp__VirtualAlloc@16 => __imp__VirtualAlloc_16 __imp__VirtualFree@12 => __imp__VirtualFree_12 // ---------------- delphi -------------- const __imp__VirtualAlloc_16: Pointer = @VirtualAlloc; __imp__VirtualFree_12: Pointer = @VirtualFree;