Jump to content

Recommended Posts

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?

Share this post


Link to post

You make thing to complex. Delphi strings are reference counted with copy-on-write.

Share this post


Link to post

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

Share this post


Link to post

Yes that looks correct but it's also a very odd thing to do. What version of Delphi are you using? 

Share this post


Link to post
Posted (edited)

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. :classic_smile:

Edited by AlexBelo

Share this post


Link to post

It looks a bit odd but because we don't know for sure what all of the types and objects are, and your extracted code has arguments that aren't used, I don't think it's easy to offer specific advice. However, it's hard to imagine a scenario where this code would be the best way to do anything.

Share this post


Link to post

Why not, AFAIU it's something like .Tag (custom data) for all cells in a grid. Now it's likely done by Interfaces, DIs, callbacks, generics, overrides altogether but in old times people were much simpler 🙂

Share this post


Link to post
1 hour ago, Fr0sT.Brutal said:

Why not, AFAIU it's something like .Tag (custom data) for all cells in a grid. Now it's likely done by Interfaces, DIs, callbacks, generics, overrides altogether but in old times people were much simpler 🙂

What is sublist and what is FHintCell. It's all just guesswork. But having pointer to pointer to character array feels odd to me.

Share this post


Link to post

The type of sublist is the plain Pointer-based TList, so it makes sense that these hoops have to be done manually to store strings in it, but it is really not optimal.  If the code were updated to use TStringList or TList<String> instead, then you wouldn't have to worry about manually managing the string memory at all.

Share this post


Link to post
35 minutes ago, Remy Lebeau said:

The type of sublist is the plain Pointer-based TList

That's clear from the code but we don't know what it's life time is.

 

On the face of it, exactly as you say, TList<string> or TStringList would be much more suitable.  But my reticence is that there are lots of unknowns.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×