AlexBelo

Hmm... But how I use such a component for more then 15 years?.. 

OK, most likely because I always compile monolithic executables. 🙂

But AFAIUI it was not obligatory. Now it's "must" for more-than-Win32 components.

Thank you.

Googling "separate packages for runtime and design" returns old but still relevant detailed article:

Creating Packages

https://delphi.fandom.com/wiki/Creating_Packages

Hi all.

I recompile my old 32-bit codebase to use it in Win64 projects.

At moment I need to recompile a component with ide designer part (it lives in separate unit).

Question: how to configue my package to avoid compilation of this unit?

Hi all.

Win64 platform, small console test project.

After some days with 11.1.5 I permanenetly get the following message:

Debugger fatal error: debug kernel not responding.

Cleaning of project, rebooting IDE and Windows do not help.

Any advice?

---

Upd: it looks like something is wrong in project itself. I can run and debug another test project. Anyway I still need advice what to search/fix in project ...

Thank you for additional information.

__fastcall for overlapped virtual destructor of Delphi-based class in CLANG32 compiler

https://quality.embarcadero.com/browse/RSP-38783

HI all.

RAD 11.1.5

Consider the following code:

class dExc : public TObject
{
 public:
  static int Counter;
  dExc() { Counter++; printf(" dExc\n"); }
  /* __fastcall */ ~dExc() { Counter--; printf("~dExc\n"); }
};

int dExc::Counter=0;

If I compile this in "classic" mode without __fastcall I get:

[bcc32 Error] Main.cpp(19): E2113 Virtual function '~dExc::dExc()' conflicts with base class 'TObject'

CLANG-32 compiler shows "Success", but program crashes in destructor of ~dExc.

Adding __fastcall produces workable exe in both cases.

(CLANG-64 version works with and without __fastcall because 64-bit uses its own call convention AFAIK)

Is this a bug in CLANG-32 compiler?

Sources are very old and not mine. All compiles fine in 2007 (last ansi version) but now I'm preparing a codebase for unicode and 64 bits.

Thanks all for help.

BTW I see nothing too strange in code: function SetItemCell operates with pointers on different types (some structures and strings as special case). Nothing nonlegitimate or obscure. 

Is this correct

  New(v);
  v^:=value;

  Dispose(v);
 

Umm...

procedure TStringAlignGrid.SetHintCell(ACol,ARow: longint; const Value: string);

var   v: PString;

begin

 // v:=NewStr(Value);  // <--- new AnsiString instance on heap

 v:=New(Value);

[DCC Error] E2008 Incompatible types

Hi all.

I'm c-builder programmer and I need some Delphi help.

In old pas file which I'm trying to compile I see (simplified):

function SetItemCell(ACol,ARow: longint; List:TList; value: Pointer): pointer;
var
  t: pointer;
  sublist:TList;
begin
  t:=NIL;
  ...
  t:=sublist.items[ARow];
  sublist.Items[ARow]:=value;
  ...
  SetItemCell:=t; // give back the pointer to the previously stored element to let the caller dispose it
end;

OK, this code puts new pointer into list and returns old contents.

Now usage with pointer to string:

procedure TStringAlignGrid.SetHintCell(ACol,ARow: longint; const Value: string);
var
  v: PString;
begin
  v:=NewStr(Value);  // <--- new AnsiString instance on heap
  v:=SetItemCell(ACol,ARow, FHintCell, v);
  if v<>NIL then
    DisposeStr(v);     // <--- delete old string
end;

No problem in "old Ansi" Delphi versions but now compiler scolds NewStr and DisposeStr as incompatible with Unicode.

So a question is: how to create string on heap?

Thank you for tip.

According docs it supports all types of applications (including 64 bit BCB).

But at moment I have problems: 64 bit app does not start at all, 32 bit app does not show any results ...

I'll try asking EL support.

Yes, it was missed libs (*.a). But unfortunately even successfully linked madExcept does not work in my test 64-bit CB exe (nor "mad" exception handling, nor leaks detection) ...

Hi all.

I'm new in 64-bit RAD development. At moment I'm trying to find out how to search memory leaks.

According to docs FastMM's ReportMemoryLeaksOnShutdown does not work in C++ projects at all.

madExcept does not work with 64-bit projects ...

Do you know any tool for 64 bits?

Here is info from Mathias (aka madshi)

Quote

 

Some years ago I tried to add support for BCB64, and although it more or less worked ok, I did not find a way to make the BCB64 linker happy, in a way that would work with the madExcept installer. No matter what I did, the BCB64 linker always complained about one thing or another. So after a lot of trying and failing, I finally gave up.

 

I'm not sure, maybe the problem has been solved by Embarcadero in newer BCB builds, I don't really know, but the demand for BCB64 has not been very high, to be honest, so I'm not very motivated to work on that atm. However, you could try copying the various madBasic, madDisAsm and madExcept pas files into your project folder and try to compile it that way. Maybe it works, I can't say for sure. It's certainly not "supported", so if it doesn't work, I don't really have a quick way to help you.

 

So CB64 is simply out of official support.

https://quality.embarcadero.com/browse/RSP-38717?jql=

Testing your cases in last version, Win32 build:

ACCESS VIOLATION DURING STACK UNWIND

No AV but a lot of memory leaks.

Not Firing Destructors When It Should

Destructors are on place but memory leaks.

TRY/CATCH LEAK

This very basic case is really fixed.

Fire Destructors Twice

No double destruction but memory leaks.

AFAIUI all memory leaks are unproperly handled exception objects.

Hi all.

I'm on CB2007 for many years. After last special BCB "quality release" I've eventually decided to try a modern version.

void __fastcall TfrmMain::btnHelloClick(TObject *Sender)
{
 ShowMessage(L"Hello, World!");
 for(int i=0; i<10000000; ++i, ++t)
 {
  try {
   try { throw Exception(L"Message Message Message Message Message Message Message Message Message Message Message "); }
   catch(const Exception& e) { throw; }
  } catch(const Exception& e) { }
 }

 ShowMessage(L"Good bye, World!");
}

CLANG compiler, static linkage.

Memory Initial     Final          (data from Task Manager)

Win64    17680K  18328K      Some leak?..

Win32     5080K   1734332K  !!!!!!!!!!!!!!!!!!

madExcept reports memory leak on every rethrowing in catch (tested without loop, of course) in Win32.

Unfortunately I can't test it in details in Win64 version (because it looks like madExcept still doesn't support bcb64) but subtle hint on memory leak is also visible in test results.

Before posting QP report I would like to see your comments/results.

> all the options

I've done it before posting here - except definitely useless in this context "Colors" clause.

😄

> creator normally answers

OK, I'll try there.

Hi all.

I'm investigating memory leak in new builder "quality" release using madExcept's resource leak feature.

Everything goes fine in win32 compilation but in win64 I see:

[ilink64 Error] Fatal: Unable to open file 'MADEXCEPT.O'

No such file in madExcept installation. All paths in IDE to madExcept binaries looks valid.

Any advice?

Also what can I use to see memory leaks in win64 version?

Yes, thank you.

(Why they placed it in "Colors" section? I see no reason for this...)

> 3rd party tools

No, fresh installation without any additions.

Hi all.

I'm trying "modern" IDE (I still use 2007 version) in "C-Builder mode" (if this matters).

I see vertical lines at the left side which marks blocks of code (from '{' to '}' ).

Is this possible to hide them?.. (Can't find anything in Tools->Options).

FreeAndNil() - The Great Delphi Developer Debate

https://s608.t.en25.com/e/es?s=608&amp;e=5507850&amp;elqTrackId=65d0dc3c5cdd4756be52277591b686f0&amp;elq=bbc2a556cfa141cc926d04a00819b81d&amp;elqaid=44034&amp;elqat=1

OMG. What? Again? Unbelievable! :-)

The following MVPs have shared their opinion on the topic. Register now to see what they have to say! Allen Bauer, Dalija Prasnikar, Frank Lauter, Uwe Raabe, Paul TOTH, Radek Cervinka, Olaf Monien, Dr. Holger Flick, Patrick Prémartin, Boian Mitov, Matthew Vesperman, Vinicius Sanchez, Darian Miller, Juliomar Marchetti, Erik van Bilsen, and Nick Hodges

Thank you, it works.