On 11/20/2012 09:37 AM, Mark Woodward wrote: > On 11/20/2012 09:21 AM, Jerry Feldman wrote: >> On 11/20/2012 06:12 AM, Mark Woodward wrote: >>> On 11/20/2012 01:55 AM, David Kramer wrote: >>>> You probably want sprintf, which is like printf except it outputs a >>>> string instead of writing the output to stdout. >>>> >>>> http://www.cplusplus.com/reference/clibrary/cstdio/sprintf/ >>> You never, ever, really never, want to use sprintf in any program. >>> Each and every occurrence of "sprintf" should be replaced by snprintf >>> as soon as possible. The sprintf call is unbounded is a stability risk >>> as well as a potential security hole. >> C++ native strings are identical to C language strings using all the C >> library functions, but there is a very rich C++ string class that is >> part of the STL (standard template Library)(std::string). >> http://www.cplusplus.com/reference/string/string/ >> >> IMHO, as a long time contractor I always recommend coding in the same >> style that is prevalent in the companies that I have worked in. When >> coding in C++ I rarely use the C language strings or printfs. Again, >> from a purist standpoint, in C++ you should generally use the cout set >> of input/output operators. > > This is a pet peeve of mine. What is a C++ "purist?" C++ is a very > broad language with a lot of capabilities. The "cout" object is merely > one of those to be used or not based on need. > > For some reason, "purists" want to ignore that C++ is for all > practical purposes a set of extensions to C. Furthermore, that, for > some reason, programs must be coded entirely differently than you > would C code. I reject this mentality as something akin to "java-envy" > or something. > > There is nothing wrong with the various incarnations of printf. There > is no reason not to use malloc if you want. There is no reason not to > use "char *" for strings. Templates need not be used. > > C++ code is that which compiles using a C++ compiler, not some > ideological construct that must be adhered too. > Mark, There are reasons why you should avoid both mixing stdio (cstdio) iostream as well as the C Malloc(3) and the C++ new allocator. In the case of I/O, you can get some interleaves because iostream and stdio use different buffers. Not a major issue, and sometimes using the printf (safe ones) library calls in C++ is useful.
In the case of malloc vs the C++ operators, such as new, there could be some serious problems. First let me give you some of my background. I worked on a small team to port Purify to Tru64. This required instrumenting both malloc, new, brk, sbrk, et. al. The issue is that the new operator and malloc would be working with different pools. Both use either sbrk or mmap or both. So, mixing malloc and new could cause the application to use more heap than using just new. In some cases, the new operator is actually layered on malloc. All C++ guides say not to mix the two. Remember that by using new, you have a certain amount of cleanup using a destructor where in malloc you do not. Remember, when malloc is called for the first time, it requests a large amount of memory for the pool.. Same with new. There are some cases where your application could run out of memory even though there is plenty available. One of the test cases I wrote was to force an application to run out of memory in this case, but at the same time I knew exactly how malloc and new were implemented. If I remember correctly, at that time malloc used a combination of sbrk and mmap. So, while it is not a good thing to mix cstdio and iostream and malloc and new, there are some valid reasons to do so, but use them with care. And from my purist standpoint, while C++ was built on top of C originally, when coding in C++ code in C++ not in C. -- Jerry Feldman <[email protected]> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
