Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 24 Jun 2003 14:16:59 -0400 kclark at CetaceanNetworks.com (Kevin D. Clark) wrote: > It is possible to write portable C++ code that uses malloc() and > friends -- all without knowing what the underlying implementation > does. If you follow the rules, your code will be completely > portable. I would submit that it's not even that difficult to do > this. > > malloc() and free() and new and delete etc. all do what the standards > say they should do. As long as you use these things as they are > intended, your code will be fine. If you religiously follow the standards, your code should be reasonably portable. Too many programmers make assumptions, like long == 32 bits (WRONG), endian == little (WRONG). Malloc(3) et. all should be ok in C++ when use in the proper context. Alloca(3) is nice to use, but is not portable. Some implementations do not support alloca(3). Some support it properly (eg. allocation on the stack), and some actually call malloc(3) leading to potential memory leaks. In any case, I think most of us replying here already have the expertise. Also, when I mention portability I'm generally talking about portability within the Unix paradigm. So, the code should be portable across Linux, FreeBSD, and commercial Unix platforms. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20030624/cc8c30e0/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |