For example, Boost's crc [boost.org] is a bloated 2,305 Lines of Code just to implement a CRC that could be written in a mere ~25 lines of C code.
Because the last time you actually needed to parameterize CRC to have CRC64 was NEVER. If you need stronger hashing you'll be using FNV or SHA variants. But's let use Template Metaprogramming to solve a "solution" in search of a problem./s
While C++ has it share of problems, (cue that old C++ joke: C++ has 2 problems: 1. Its design, and 2. Its implementation),
People don't use 64-bit CRC, but they do use 8- and 12- and 16- and 24-bit CRCs. They use CRCs with different initial shift register values, and that differ in whether you shift bits from the MSB or LSB of the next byte into the CRC register (big- or little-endian bytes).
The C++ code in Boost gets you support for all those variants plus more, efficiently implemented at runtime. Your 25 lines of C don't even get you an efficient, portable implementation, unless (and this would push the 25 line bound) you f
I bet you're wrong. According to sloccount, there are 816 lines of compiled code in boost's crc.hpp, out of 2307 total lines on my system -- most of the rest are comments, some are blanks.
The features to implement are:
Arbitrary number of bits up to the compiler's largest native unsigned integer type (such as "unsigned long long")
Arbitrary generator polynomial
Arbitrary initial value for the remainder register
Arbitrary bit-mask to XOR into the final result
Selection of big- versus little-endian input bytes
It seems so silly. I'm hearing two sides, only one of which is defensible. You say, "look at the greatness of my bloated monstrosity! Look how general it is! See all of the great features!" Everyone else is saying "Dude, just use a 10 line function specific to your application. It'll be smaller and faster."
Are you the author or something? Why do you care so much about this?
One person said 25 lines, but that they assumed they don't need most of the functionality that Boost gives you because they assumed a program only needs a single CRC algorithm. Some protocols use four or five different CRCs in different places.
Another person said 10 lines, but that code will be slower than Boost. (Go ahead, try it. Be sure to measure how long it takes you to make the code implement a CRC correctly without copying from someone else's code.)
Let's see... 4 or 5 times 25 is.... less than 2307 lines.
Again, why do you care? It's just a bloated library for doing CRC, for goodness sake! You have to either be the author or the biggest boost fanboy on the planet.
I'm not a fan of boost by any means (some of it really feels like wankery) but this seems a bit of a stretch.
The question is, why do you care? Sure you could write and debug your own 25 line function, or you make a single 1 line call into boost and have at it. Libraries are almost always a lot larger than code you'd write yourself because libraries tend to be written for more than just your specific usecase.
That bunch of lines will do every CRC up to 64 bits under the sun. Would you be every bit as critical
Because then you might as well just use boost::crc. You're still using someone else's reference implementation, just quibbling over which libraries are acceptable. If the argument is that each application should use its own CRC implementation, take that argument to its conclusion.
But you could just copy the part you need and optimize it for your platform. And by lowering the amount of code, security analyzing will be much easier.
"Our reruns are better than theirs."
-- Nick at Nite
Spot on... (Score:5, Insightful)
"C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language"
Linus is truly a treasure for succinctly sum things up. I would have left of the "crap language" because that will trigger the faithful.
Re: (Score:4, Informative)
Or just Crap++.
For example, Boost's crc [boost.org] is a bloated 2,305 Lines of Code just to implement a CRC that could be written in a mere ~25 lines of C code.
Because the last time you actually needed to parameterize CRC to have CRC64 was NEVER. If you need stronger hashing you'll be using FNV or SHA variants. But's let use Template Metaprogramming to solve a "solution" in search of a problem. /s
While C++ has it share of problems, (cue that old C++ joke: C++ has 2 problems: 1. Its design, and 2. Its implementation),
Re: (Score:5, Insightful)
People don't use 64-bit CRC, but they do use 8- and 12- and 16- and 24-bit CRCs. They use CRCs with different initial shift register values, and that differ in whether you shift bits from the MSB or LSB of the next byte into the CRC register (big- or little-endian bytes).
The C++ code in Boost gets you support for all those variants plus more, efficiently implemented at runtime. Your 25 lines of C don't even get you an efficient, portable implementation, unless (and this would push the 25 line bound) you f
Re: (Score:2)
I'll bet the average developer could still easily beat 2305 LOC.
Re: (Score:5, Informative)
I bet you're wrong. According to sloccount, there are 816 lines of compiled code in boost's crc.hpp, out of 2307 total lines on my system -- most of the rest are comments, some are blanks.
The features to implement are:
Re:Spot on... (Score:3)
It seems so silly. I'm hearing two sides, only one of which is defensible. You say, "look at the greatness of my bloated monstrosity! Look how general it is! See all of the great features!" Everyone else is saying "Dude, just use a 10 line function specific to your application. It'll be smaller and faster."
Are you the author or something? Why do you care so much about this?
Re: (Score:2)
One person said 25 lines, but that they assumed they don't need most of the functionality that Boost gives you because they assumed a program only needs a single CRC algorithm. Some protocols use four or five different CRCs in different places.
Another person said 10 lines, but that code will be slower than Boost. (Go ahead, try it. Be sure to measure how long it takes you to make the code implement a CRC correctly without copying from someone else's code.)
In both cases, you end up writing more code it ta
Re: (Score:2)
Let's see ... 4 or 5 times 25 is .... less than 2307 lines.
Again, why do you care? It's just a bloated library for doing CRC, for goodness sake! You have to either be the author or the biggest boost fanboy on the planet.
Re: (Score:2)
I'm not a fan of boost by any means (some of it really feels like wankery) but this seems a bit of a stretch.
The question is, why do you care? Sure you could write and debug your own 25 line function, or you make a single 1 line call into boost and have at it. Libraries are almost always a lot larger than code you'd write yourself because libraries tend to be written for more than just your specific usecase.
That bunch of lines will do every CRC up to 64 bits under the sun. Would you be every bit as critical
Re: (Score:2)
Why is copying forbidden in this case? Aren't we talking about open source?
Re: (Score:2)
Because then you might as well just use boost::crc. You're still using someone else's reference implementation, just quibbling over which libraries are acceptable. If the argument is that each application should use its own CRC implementation, take that argument to its conclusion.
Re: (Score:2)
But you could just copy the part you need and optimize it for your platform. And by lowering the amount of code, security analyzing will be much easier.