Delphi String functions vs .Net String class methods

Thread View: borland.public.delphi.language.delphi.dotnet

8 messages

[T] Back to Threads [V] Tree View [G] Group Articles

8 total messages Started by Stephen Boyd Tue, 10 Jun 2008 15:58

Author: Stephen Boyd
Date: Tue, 10 Jun 2008 15:58

18 lines
1929 bytes

I am just getting started with Delphi.Net and I am having a hard time 
trying to decide whether I should stick with the legacy Delphi string 
functions (Copy, Pos, Trim, etc) or whether I should switch to the .Net 
String class methods (SubString, IndexOf, Trim, etc).

On the one hand, using the String class methods would make the Delphi 
programs look more like .Net (a la C# and VB).  On the other hand, the 
Delphi functions sometimes behave more sensibly.  For instance, suppose 
you have a string, '12345' and you use the Delphi Copy function like 
this, Copy(string, 6, 1).  This returns an empty string which makes 
sense.  If however you use string.SubString(6, 1) it throws an exception.

Intermingling the different string functions would be too confusing 
because of the 1 relative Delphi functions and the zero relative .Net 
methods.

Is either one considered the 'best' or 'proper' way?  Or is it just a 
matter of personal preference?  Any opinions?

Re: Delphi String functions vs .Net String class methods

Author: Troy Wolbrink
Date: Tue, 10 Jun 2008 16:29

18 lines
1870 bytes

>I am just getting started with Delphi.Net and I am having a hard time 
>trying to decide whether I should stick with the legacy Delphi string 
>functions (Copy, Pos, Trim, etc) or whether I should switch to the .Net 
>String class methods (SubString, IndexOf, Trim, etc).

I think the best thing for you to do is whatever makes you more productive, 
and this should be the main factor in your decision.  That being said, I 
think there are a few things to consider:

1.  If you continue to use the Delphi string functions, your code will be 
better able to cross compile to Win32 or .NET.
2.  If you continue to use the Delphi string functions, your code will rely 
on SysUtils and/or other RTL units.
3.  The .NET string class methods like .ToUpper, .Trim and others (that 
don't deal with character indexes) are really nice to use.  I wish there 
were a way to do this in the Win32 side as well!

--Troy

Re: Delphi String functions vs .Net String class methods

Author: Stephen Boyd
Date: Tue, 10 Jun 2008 18:08

19 lines
1984 bytes

> 2.  If you continue to use the Delphi string functions, your code will rely 
> on SysUtils and/or other RTL units.

I don't really see that as an issue, since if I am doing anything with 
VCL.Net, which you pretty much have to in order to have a program that 
does anything, you have to distribute all of that stuff anyway.

There doesn't seem to be an option to include all run time packages in 
the executable like there was for Delphi 5.  Is this correct?

> 3.  The .NET string class methods like .ToUpper, .Trim and others (that 
> don't deal with character indexes) are really nice to use.  I wish there 
> were a way to do this in the Win32 side as well!
> 

I do like the convenience of those functions too, but I seem to have 
problems when using them with empty strings.  I get 'object not 
instantiated' errors.  Possibly because in Delphi an empty string is a 
nil pointer??

Re: Delphi String functions vs .Net String class methods

Author: John Moshakis
Date: Tue, 10 Jun 2008 19:33

40 lines
2475 bytes

Stephen Boyd wrote:

> > 2.  If you continue to use the Delphi string functions, your code
> > will rely  on SysUtils and/or other RTL units.
> 
> I don't really see that as an issue, since if I am doing anything
> with VCL.Net, which you pretty much have to in order to have a
> program that does anything, you have to distribute all of that stuff
> anyway.
> 
> There doesn't seem to be an option to include all run time packages
> in the executable like there was for Delphi 5.  Is this correct?
> 
> > 3.  The .NET string class methods like .ToUpper, .Trim and others
> > (that  don't deal with character indexes) are really nice to use.
> > I wish there  were a way to do this in the Win32 side as well!
> > 
> 
> I do like the convenience of those functions too, but I seem to have
> problems when using them with empty strings.  I get 'object not
> instantiated' errors.  Possibly because in Delphi an empty string is
> a nil pointer??

Hi Stephen,

The dotnet framework has 2 classes string and stringbuilder because of
the performance issues when doing concatenations. You can read about
the issues here under "Performance Considerations"

http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx

If your wanting to share source and your doing lots of concatenations I
would use StringBuilder in dotnet. I think the jvcl has a win32 version
of StringBuilder for your win32 code.

Cheers,
John

-- 
Blog: http://blog.moshine.com/

Re: Delphi String functions vs .Net String class methods

#10

Author: Troy Wolbrink
Date: Tue, 10 Jun 2008 20:16

31 lines
2267 bytes

>> 2.  If you continue to use the Delphi string functions, your code will 
>> rely on SysUtils and/or other RTL units.
>
> I don't really see that as an issue, since if I am doing anything with 
> VCL.Net,

Yes, if you're using VCL.NET then you're definitely already sitting on top 
of SysUtils.

>which you pretty much have to in order to have a program that does 
>anything, you have to distribute all of that stuff anyway.
>
> There doesn't seem to be an option to include all run time packages in the 
> executable like there was for Delphi 5.  Is this correct?

Yes, it's correct that you can link in Delphi units.

>> 3.  The .NET string class methods like .ToUpper, .Trim and others (that 
>> don't deal with character indexes) are really nice to use.  I wish there 
>> were a way to do this in the Win32 side as well!
>>
>
> I do like the convenience of those functions too, but I seem to have 
> problems when using them with empty strings.  I get 'object not 
> instantiated' errors.  Possibly because in Delphi an empty string is a nil 
> pointer??

This is definitely something new to get used to.  I'm using 
String.IsEmptyOrNull() more often.

--Troy

Re: Delphi String functions vs .Net String class methods

#15

Author: Stephen Boyd
Date: Wed, 11 Jun 2008 12:38

6 lines
1272 bytes

Troy Wolbrink wrote:
> 
> Yes, it's correct that you can link in Delphi units.
> 

How?  I don't seem to be able to find the option.

Re: Delphi String functions vs .Net String class methods

#18

Author: Troy Wolbrink
Date: Wed, 11 Jun 2008 14:36

8 lines
1345 bytes

>> Yes, it's correct that you can link in Delphi units.
>
> How?  I don't seem to be able to find the option.

In the project manager, under "References" you can right-click on any 
Borland/Delphi assembly and "Link in Units".

--Troy

Re: Delphi String functions vs .Net String class methods

#20

Author: Stephen Boyd
Date: Wed, 11 Jun 2008 19:00

9 lines
1455 bytes

Troy Wolbrink wrote:
>>> Yes, it's correct that you can link in Delphi units.
>> How?  I don't seem to be able to find the option.
> 
> In the project manager, under "References" you can right-click on any 
> Borland/Delphi assembly and "Link in Units".
> 

I would have been a long time looking for that.  Thank you.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads