Introduction: experts, intermediates, and beginners
If you are an expert, you should read this article so that you stop teaching kids magic. If you are a beginner or even intermediate, you should read this article to see why you can waste a lot of time trying to understand someone else's magic.
Selfish experts
Pchars are not intuitive if you are reading an expert's code who's selfishly casted away without source commenting. Pchars are not intuitive if you are used to higher level programming, such as PHP, Python, or general Freepascal/Delphi programming (where strings are handled for you automatically).
To assume is human nature
You may be used to just casting a pchar, such as pchar(mystring). This is a magic short cut, and sometimes works when you are sending in a read only parameter. Casting, however, won't work (actually it will work sometimes by luck, and this is the problem) in situations where the pchar is being filled or modified by the DLL.
If the pchar is not being modified in the DLL/DSO, and it is just being passed in as read only, then you can generally get away with casting an ansistring to a pchar.. however, when a newbie sees this cast, he can assume many things. The newbie then tries casting when it is not safe - and it even works, by luck - then he assumes more things. Assuming, is human nature. Repeat this after me, experts: Assuming, is human nature.
Quite often the newbie has been convinced into thinking that casting should work in all situations - because the compiler is so smart. Dear experts, this is why source code commenting all casts is recommended! Don't encourage the newbie or even intermediate to believe in magic! That's what casting does.
If I know, he must know - we are all equal
Rubbish. Many experts make the mistake of thinking that since THEY know the pchar cast is only safe in certain situations, that all newbies will know this too. How can they, if they are just newbies? Show a little respect. Be a teacher, not a selfish know-it-all expert. Write source comments on your casts, or don't cast at all.
Pchar casts are evil, and from hell. Many experts will disagree with me and they will continue to cast away like there is no tomorrow - because they've read the 400 fine manuals on Pchars and they know exactly what a pchar cast does at what time. Bad for them. Bad for their students: the folks reading their code. All students are newbies, and all programmers are students. Show some respect.
Don't just cast away like there is no tomorrow. Cast, and comment what is happening. It will help you, and future programmers that read your source. Selfish folks don't comment their pchar casts in source code. If one gets in the habit of casting pchar(string) without commenting on why it is safe in that particular situation, then eventually you or someone else may end up programming a buggy software program. Casts can encourage one to assume that strongly typed compilers are magical things that figure out everything. Casta can encourage one to assume that pchars are strings, and strings are pchars - that there is very little difference between the two.
Read The Fine Manual (all 400 of them)
Purists and experts will argue that newbies should know exactly what the cast does and where the memory is. Purists and experts will also argue that newbies should have RTFM. Actually, reading the fine manual usually won't help - reading 400 fine manuals might help, if the newbie has time. But then, why would a newbie be using a language with convenient ansistrings if it requires learning C anyway?
So hey, hold on a minute there expert, since when were we programming in C? Programming in higher level languages is supposed to be easier, not harder. Many newbies who use a language with ansistrings don't have time to become super ultra memory experts that understand every cast and every memory trick going on behind the scenes.
Humans assume things, whether experts like it or not. Experts will argue that humans shouldn't assume things - but assuming, is human nature! Must I repeat this? So if you are an expert, please don't argue that one should RTFM and stop assuming things about casts and memory management. Sorry, but that isn't human nature. If a string can be cast into a pchar and a pchar can be cast into a string, surely this means the compiler will take care of everything and we don't have to deal with any memory management. This is what a newbie assumes, whether you like it or not, experts!
I believe my compiler can create rabbits from hats
When a newbie or even an intermediate programmer coming from another language first sees a pchar cast, it shows him magic. He beleives in the magic. It will work elsewhere, is what he thinks. Not all newbies have 300 hours on hand and 400 fine manuals on hand so that they can study what the magic works and what magic doesn't. Not every newbie or intermediate has the time or patience the knowledge to open up step debugging and assembly windows.
Don't be a hoser, comment your casts
So if you aren't selfish, you will cater to newbies and you will comment your pchar casts. The other option is to skip the pchar casting all together and show in your code a real pchar being allocated - so that people don't see a cast - they see what really is happening.
Many experts assume newbies are experts, and that only experts read experts' source code, and that the people reading the source code have already read the 400 Fine Manuals. Obviously this is wrong.
Don't assume that those reading your code will know that a pchar cast is something special only to be used in certain situations. This is the big mistake Delphi and FPC programmers make - they assume that since they know exactly what goes on when a pchar cast occurs, and since they know exactly when a pchar cast is okay and when it is not okay, other newbies and intermediates MUST know this too!
Since when are newbies experts who spend 16 hours each day studying pchar casts and *char's in C? Experts who program in Delphi and FPC have C-like knowledge, while newbies coming into FPC and Delphi have no C-like knowledge. How is a newbie supposed to get into good habits, when newbies generally read expert's code, which have all the these magical casts all over the place? (especially when intefacing into C api's, which is unfortunately a lot of the code out there.).
What you can pass to a DLL
Pchars
If the DLL is going to modify or fill up a pchar's, the pchar must be manually memory managed. Do not simply cast a string to a pchar.
If the DLL is not going to modify or fill up a pchar's contents, then the pchar can be sent in as a casted one. For example, if a function in the DLL uses your data as information - i.e. read only data, but not to modify or write to - then a cast is safe. However you must make source comments beside your cast if you expect newbies and intermediates to understand your magic.
Ansistrings
Only pass ansistrings to a DLL if you are using a shared memory manager. A shared memory manager does not have to be a separate DLL such as borland's sharemem. One can share memory by reading up on how to use the GetMemoryManger and SetMemoryManager trick that is used in the PWU library, for example. However, even if you share memory, ansistrings may not be used in combination with obsolete languages like C or C++ that do not support the ansistring reference counting mechanism which FPC/Delphi uses. Some C++ compilers may support an ansistring, but not the same ansistring reference counting mechanism. Other compilers like Borland C++ supports the same ansistring that Delphi and FPC suport.
Shortstrings
You can send shortstrings across a DLL/SO without managing them. If you are sending strings which you know are generally of a certain fixed length, you may just want to use shortstrings. Example: you are always sending strings 1-90 characters long - or pahts under 250 characters - using a shortstring can be easier and faster.
See the points made in: Clearing Up PChar and DLL Confusion
See also: MD5Hash Example
Subject: Pass a PChar, Passing PChars, Using PChars in DLL's, Using PChars in DLLs, Using a PChar in a DLL, Using PChar's in a DLL's, SO, Shared Object Library, Dynamic Link Library, Dynamic Link Libraries, Shared Object File, pointers, memory management.
|
