11–20 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.
You need a basic understanding of C.But C and C++ are different languages,period.
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.
Genuine question.
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
C: total heap usage: 1 allocs, 1 frees, 21 bytes allocated
C++: total heap usage: 4 allocs, 4 frees, 145 bytes allocated
[edit] Repeated using gcc 4.9.1 and clang 3.5.0 with -std=c++14. No difference.
[edit] Seems with Clang and libc++ it's better than the C implementation as it doesn't do any heap allocation:
clang++ -stdlib=libc++ -std=c++14 -Wall -Wextra -g test.cpp -o test
total heap usage: 0 allocs, 0 frees, 0 bytes allocated
"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,…
Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for short strings. Even 1 byte. This is for binary back-compat and will hopefully be fixed in GCC 5.0. For now try it with Clang and libc++. See[0] for more information and a comparison of current implementations.... the standard doesn't require SSO at all.
Thirdly, and getting to the deeper issue, once the heap is involved the C version is nearly (it needs length params) optimal and will still always be more efficient than the C++ code. Why? The C++ solution uses uses operator+ which is fundamentally performing a different and less general algorithm. For composition it will introduce some amount of repeated work which even the best link-time optimizing compilers probably won't remove, and may, depending on the length of the trailing string segments, and the growth strategy used under the covers, force two allocations. The standard doesn't give complexity guarantees for mutation on std::string at all, so the resulting performance could, on some platforms, be very bad. In all cases you will be able to construct an input that forces more than one allocation (exponentially growing segment sizes).
There's also another efficiency issue in the naive op+ approach... C++s allocator specification doesn't provide realloc() so a portable solution will always use more peak memory, on average, when it is forced to reallocate.
The C++ solution is just using the wrong algorithm for the job. You can write, and I have toyed with[1], a variadic strcat() function that will be optimal in the generic case. The standard library just lacks one. It's embarrassing, but fairly understandable given that variadic templates didn't come in to the standard until 2011. I'm hoping if they introduce one it'll be called scat() :-)
I'm a big C++ fan, but we shouldn't be deluding ourselves here. Fortunately, these things can be fixed within the framework of the current language.
[0] https://github.com/elliotgoodrich/SSO-23/blob/master/README....
"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,…
To be fair, he says "likely to be" and results may vary between compilers. He also makes reference to the speed penalty of calling strlen(), which isn't necessary with std:string because it stores the length. Even with more allocations, it's possible the C++ version runs faster. It should have a lower computational complexity, meaning it would be faster if the input strings were much longer than they are in this example.
Not showing up. Here's an archived version: https://archive.today/LoOe1
Thanks. Very short post though. What I have to say is, that C++11 and onwards had indeed made C++ much more approachable. I think Herb Sutter's talk on modern C++ is also worth a look. [0] [0] https://www.youtube.com/watch?v=TJHgp1ugKGM
"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…
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 course.
I started learning C and C++ together at the same time a few years ago. I prefer to code in C++, using the standard template library, but there's always this extremely annoying little voice in the back of my head saying, "you could do this more efficiently if you operated on character arrays instead of a std::string"
I'm getting so tired of the word myth and how it's used so incorrectly. These may be misconceptions, but they are not myths. In truth, some of these are factually accurate and you're framing them as a misconception to drive a narrative. I can't help but consider that link-bait, even though structured differently, this would be a good article.
Second, I don't find his use of "myth" objectionable, in much the same way I (as a scientist) don't find objectionable the use of "theory" to mean "guess" in non-scientific speech (attempting to impose "guess" as a meaning when discussing scientific theories is anathema). This use of "myth" here is fairly common, at least colloquially in America, as a rhetorical flourish in place of "misconception."
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.
Good luck trying to understand C++ without C look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one t…