> This does not make sense to me. When you return a string (from a > function in a DLL or anywhere else), this string will have a > reference count of at least 1 and thus will not be cleaned up by anyone. > > The only problem I can see that can occur is in case the program and > the DLL indeed use different memory managers, in which case you can > have a situation where memory allocated by the dll's memory manager > is freed "to" the program's memory manager, and that will probably > confuse the hell out of it (even if they are essentially the same > memory manager, just using different data structures). > >
I apologize, I should have said that you'd not have exactly the same problems with returning a string - they are different problems but the basic point and idea remains the same: no matter what you do, strings will cause problems. What I should have said was there would still be all sorts of problems with returning a string - not necessarily the reference count problem, but other issues that cause similar havoc, such as two memory managers not communicating with each other. There are so many problems to consider, that a programmer once again spends more time thinking about the possible problems instead of programming a solution that works reliably. When it comes time to maintain your application in the future, or modify your DLL, and if you did some how manage to get strings working by using setlength's in the right place, and not returning a string as a result, you may not remember why these workarounds were in place and what workarounds must be left in the code if you change the code. If you go in and modify a DLL one day in the future, with a string that is just barely working as is with workarounds, the application might go BOOM when you make one little change to the DLL. In other words, even if you can get a string working as a parameter being sent, received, and allocated properly (but not as a function result), it may be a dangerous bomb waiting to tick off in the future when you try and maintain or upgrade your DLL. You must spend minutes/hours going through every possible problem that could happen with the modifications you make, every time you upgrade your DLL. If I change this code in my DLL, does that mess up the work around's that kept the bomb from going off? If I change this other code in my DLL, is the string still safe? There are just too many issues to think about. Unless, of course, there is a sharemem unit for FPC. And with a sharemem unit, since I've never used one in Delphi or FPC, I'm not sure how reliable they are. i.e are there bugs in the sharemem units that cause problems in Delphi, anyone know? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
