views:

150

answers:

3

I am converting a low level C library to Delphi.

  1. I find a lot of casts. I think it is normal in C World. I think I am safe in throwing them out. Integer is 32 bit only here. What do you think?

  2. What could be the overhead of OOP if I convert it to objects etc?

  3. Similarly I want to know the cost of try .. finally and exceptions.

Give me any tip that you think would be useful.

A: 

Moving from a procedural language to OOP is a big leap. There are many advantages of using OOP. OOPs are easier to code and maintain. Choosing Delphi PL is a good choice because it can also access at low level by inserting assembly codes. Try-catch is used to prevent program crashes at run time because of exceptions.

rajeem_cariazo
OOPs are not always easier to code *or* maintain.
Mick
@Mick, 100% agree with you. OOP CAN BE easier to code and maintain but it isn't automatic. OOP is a tool for managing complexity but like all tools, if used improperly you can end up with one craptastic mess. Just ask all the procedural programmers over the past 3 decades who made the leap to OO but never fully grasped the paradigm. I'm sure the same can be said about OO programmers moving to functional languages. Different tools have different strengths and weaknesses.
codeelegance
+3  A: 

3 Similarly I want to know the cost of try .. finally and exceptions.

The cost of a try ... finally is negligable except in tight loops (put them around and not in the loop). Use them liberally to protect all your resources by balancing all instantiations / opens / allocations with free's / closes / de-allocations.

<code-to-open-a-file>
try
  ...
finally
  <code-to-close-the-file>
end;

The cost of a try ... except is noticeably higher. Use them to respond to exceptions occuring, but only when you can actually take some meaningful action like counter acting the reason for the exception, logging some specific information that would be lost at a higher level in your app, etc. Otherwise let the exception propagate to the caller of your code so it can (eventually) be caught at a more general level.

Never let exceptions escape your application or library or any thread within it.

Never "eat" exceptions by having an empty except block:

try
  ...
except
end;

There really is only one type of situation where this makes sense: catching exceptions in code that logs exceptions... And then always add a comment to say why you are eating the exception.

Marjan Venema
+1 for "always add a comment to say why you are eating the exception".
François
+1  A: 

You may find some helpful suggestions in the answers to this question on SO: Best resources for converting C/C++ dll headers to Delphi?

You may also want to take a look at the C-To-Pas project which aims to automate much of the conversion from C to Delphi.

Mick
I've seen C-To-Pas, and found it to be pretty worthless. All it is is basically a bunch of search-and-replace routines that can have some very strange side effects because there's no real parser involved.
Mason Wheeler