Stefan Glienke

And then after you spent quite some time implementing this without defects that it would not be any faster than all the ready-to-use collection types or the actual performance improvement would be completely negligible.

@Remy Lebeau Selective perception? If a compiler is not a critical product function I don't know what is.

I think at least in Germany the court would say otherwise - keyword: Nachbesserung und Gewährleistung

pcg32 should be easy enough to implement from the c code.

That's what QA said before 10.4.2 released

Or he just wants to see the correct values when inspecting them while debugging?

No need to assume or guess anything - the base addresses are in the map file.

What type of collections do you have in mind? Not all types of collections can be implemented completely lock-free in an efficient way or they are hilariously complex to implement. Depending on the implementation some operations might not have the same characteristics of a regular thread-unsafe implementation.

No, we are not - some individuals who also happen to be MVP are.

https://xkcd.com/221/

LSP has nothing to do with that but the filter in the suggestion box. There were several plugins that could do that for ages.

Because what percentage of overall C++ development is being done in Visual Studio again?

https://choosealicense.com/ is also a good help to decide which one to pick.

Nuget is for .Net, not for C++. C++ has a bunch of package managers but none of them is considered the de facto standard that almost everyone uses.

This: This means it will be basically useless for commercial projects.

That dialog there is definitely not from the debugger. Make sure you did not accidentally disable breaking on exceptions.

Opinions on regex differ - however for this case using a regex is like using a bucket-wheel excavator to plant a pansy.

Just skip any spaces and then check if it's '(' or not: function IsFunctionInString(const aFunction, aStr: string): boolean; var vPos: Integer; p: PChar; begin vPos := Pos(aFunction, aStr); if vPos > 0 then begin p := @aStr[vPos + aFunction.Length]; while p^ = ' ' do Inc(p); Result := p^ = '('; end else Result := False; end;

But what if I would not answer there 😉 Seriously - I understand people getting their area here if they don't have their own place already - Spring4D already has its own place.

https://groups.google.com/g/spring4d as I get an email notification - but I also watch SO and this forum.

That's what the madCompileBugReport tool is for - you use madExcept with minimal debug info then the bugreport the application produces does not contain function names and such but using the tool turns it back into that - you need to have archived the map files for your released binaries though.

While it certainly looks impressive and pas2js has come a long way it is still far from being able to just take your existing code (non VCL dependant of course) and compile/run that.

Fair point - I've seen some glitches with unloaded DLL in the past - fortunately, we don't explicitly unload our own DLLs that were loaded with LoadLibrary. It's not a big issue, don't spend your valuable time on that - since we have a madExcept license anyway I will try out fulldebugmode.dll using that.

That work only needs to be done when the report is being generated and I think that is not a point where raw speed matters that much but accuracy - on collecting the stack trace I agree that should be as fast as possible. I think I have seen a Jcl function that returns the address of the call instruction which then could be used to correct the displayed one to match the call instruction. Anyhow if you are not able to correct this we still have the option to use madExcept for the FullDebugMode dll which I will consider using 🤷‍♂️

@Pierre le Riche It might work many times but when I saw this mentioned I remembered cases where I had seen leak reports with some weird looking call stacks in them which were kinda confusing as they were impossible (like in this case). I think simply walking up the stack and taking all addresses as a potential return address is the issue. This is the callstack when the code arrives in FastMM_DebugGetMem (10.3.3): and this is how the stack looks like: Looking at 00406E08 will find this: which is why LStrFromPWCharLen is being reported. So you are right - there should be a check if that potential return address is a valid one. Another thing I just noticed with the addresses in your vs the addresses reported from madExcept: madExcept reports the address of the call - you report the return address. IMO reporting the address of the call instruction is the better option - what do you think?