> The usage of strings in the samples was just to verify which code was > executed and where things went wrong. I wasen't aware of the fact that > that alone could cause problems. In the actual application mainly > objects are passed to functions as regular and out parameters and a > boolean is returned to indicate success or failure.
What kind of objects.. most objects cannot be passed without taking precaution or using sharemem. If any of the objects use ansistrings, dynamic arrays, there will be problems (also called "automated types", since the memory that the "type" uses is so to say "automated" for you, i.e. reference counted). > I don't think the sharemem unit is used anywhere in the origial code. I > could be wrong, though. I don't have the code here at home. I'll have a > look on Monday. > > The application is still under development, so it's not actually been > used/tested on a large scale. For as far as i know, the application, > compiled with Delphi, doesn't show any of the problems I get when the > app is compiled with FPC. But that could just as well be dumb luck. > > > The general safe rule is to never return a string into a function > > result when passing it to a DLL without shared memory. > > I'm not sure what you ment by that. Did you mean it's unsafe to return > an ansistring from a function exported by a dll per say? Or did you mean > passing an ansistring to a function imported from a dll, manipulating > that string and returning it? Both cases are cause for concern. I meant that sending a string as a paramater can be dangerous, and that returning a string as a function result can be dangerious too. Sometimes sending a string paramater can be done, but only if you take extra precaution. The DLL does not know what your EXE memory is doing. So by the time the string gets to the DLL it may be cleaned up and gone, kind of like a garbage collector. Same thing with returning a string.. if the string gets returned as the result of a function, it may have already been cleaned up and gone by the time you catch it on the exe side. Some times you can use setlength calls and other tricks to get around this, but I've found you spend too much time trying to trick the reference counter (like a garbage collector) - and its better to just allocate a pchar and KNOW what you are doing. This is the real advantage of KNOWING your memory, and why C programmers think they are king (but in every day applications that don't use DLL's, knowing your memory is a waste of time - compilers, dlls, operating systems is an exception where knowing your memory is more of a good thing and not a waste of time). I'm not sure if FPC has a sharing memory unit available - I've not looked into this, because most of the stuff I'm interested in creating, I want other programmers to be able to use too - gotta popularize the Pascal language by making DLL's available to other programmers than just our selfish selves. With a sharemem system I don't think you can share your DLL's with other programmers in other languages - but in your case maybe you are just using DLLs in your local application and would benefit from sharing memory. Again I don't know if FPC has this available - anyone know? This is a confusing topic though, and no problem being confused about it all, even for weeks or months after researching it. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
