21–30 of 144 posts
Good luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you. BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.
What exactly do you need to know about C, that is not part of C++, to understand C++? Genuine question.
"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings." I just compiled the C code and the C++ code using: gcc -std=c99 -Wall -Wextra test.c -o test g++ -std=c++11 -Wall -Wextra test.cpp -o test According to valgrind: C: total heap usage: 1 allocs, 1 frees,…
Try it with -stdlib=libc++, since that's what will control the behavior of std::string.
total heap usage: 0 allocs, 0 frees, 0 bytes allocatedGood luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you. BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.
What exactly do you need to know about C, that is not part of C++, to understand C++? Genuine question.
What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import . And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.
Drives me batty to see articles where malloc() is happily assumed to always succeed.
Earlier quoted context omitted.
The articles promise is actually terribly dubious. Firstly, in the real world, name+'@'+domain is likely to exceed the capacity for any SSO anyway. Even the example composition, which is 21 chars, may resort to heap allocation under some implementations. It's a bad solution to depend on it for performance. Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for sh…
That's the good thing about C. With C++, you don't know what is being allocated, where. With C, it is explicit. You know what's happening if you call malloc. And this compose function could easily be written in C to take the "addr" as an argument to be filled, rather than provide it as a return value. Then it can be entirely stack allocated. The caller would need to make sure that the "addr" array was large enough of…
"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings." I just compiled the C code and the C++ code using: gcc -std=c99 -Wall -Wextra test.c -o test g++ -std=c++11 -Wall -Wextra test.cpp -o test According to valgrind: C: total heap usage: 1 allocs, 1 frees,…
"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings." I just compiled the C code and the C++ code using: gcc -std=c99 -Wall -Wextra test.c -o test g++ -std=c++11 -Wall -Wextra test.cpp -o test According to valgrind: C: total heap usage: 1 allocs, 1 frees,…
The articles promise is actually terribly dubious. Firstly, in the real world, name+'@'+domain is likely to exceed the capacity for any SSO anyway. Even the example composition, which is 21 chars, may resort to heap allocation under some implementations. It's a bad solution to depend on it for performance. Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for sh…
What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import . And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.
What sort of C programmer wouldn't test for malloc() failing. Drives me batty to see articles where malloc() is happily assumed to always succeed.
... as in Linux.