- Awsomeness - 1 Update
- template madness - 5 Updates
- Undefined Behaviour - 2 Updates
| queequeg@trust.no1 (Queequeg): Sep 06 01:15PM > https://www.youtube.com/watch?v=qs0biWHy5WU Cool. But what does it have to do with C++? -- https://www.youtube.com/watch?v=9lSzL1DqQn0 |
| Juha Nieminen <nospam@thanks.invalid>: Sep 06 08:46AM >> just cannot work). > 1) Don't use FILE; use C++ wrappers of FILE (std::fstream et al). > 2) Don't use assert as it is considered harmful; throw an exception instead. Way to completely miss my point. Anyway, if we are going to that tangent, unfortunately the C file functions are still faster than the C++ ones (even though the gap has gotten smaller over the decades). If you want the absolutely fastest file reading speed in your program, you'll probably have to use the C file handling functions (especially std::fread). And yes, there are many situations where you really want or even need the fastest possible file reading and writing. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 06 08:55AM > While an assertion may be user unfriendly, crashing the system with a > stack-trace and core dump is very developer friendly. Throwing an > exception looses the forensic trail to the crash. In general, use assert() for situations that indicate such a serious bug in the program that there is no recovery possible and the only viable and sane thing to do is to just terminate the program there, because it can't possibly work correctly anymore. Most useful at the development stage, of course. (Whether the assertions should be left in the final published product is another complex question.) Throw an exception for situations that are fatal errors, but can be ostensibly recovered from. In some cases it may be the handiest way for a library to indicate to the calling code that something went horribly wrong and the requested thing cannot be done. (This may happen in a situation where it's just not feasible to simply return some kind of error code from the library.) A memory allocation error, which the standard library containers throw when it happens, might be the quintessential example: The container has fatally failed to perform the requested operation, and cannot possibly continue to work as it should, but this should cause the program to simply crash. Instead, the calling code is given the choice to recover from this situation. Since there's a myriad of places where this error may happen, many of which cannot possibly just return an error code (such as a copy constructor, for instance), throwing an exception is the most viable strategy. If the calling code wants to deal with this situation gracefully, it can. |
| David Brown <david.brown@hesbynett.no>: Sep 06 12:08PM +0200 On 06/09/18 10:46, Juha Nieminen wrote: > to use the C file handling functions (especially std::fread). > And yes, there are many situations where you really want or even > need the fastest possible file reading and writing. I would expect that the fastest way to access files is going to vary by OS, by access type, and even by filesystem type. mmap() is often going to be faster than any file read or write function for random access - but perhaps for compressed or COW filesystems you are better reading the file in as one lump and writing a new copy, rather than modifying the file. And for files on a disk (even an SSD), I would expect the difference in processor time between the C functions (which will be thin wrappers over the OS API calls) and the C++ functions (which might be thicker wrappers) will be negligible. |
| jameskuyper@alumni.caltech.edu: Sep 06 05:54AM -0700 On Thursday, September 6, 2018 at 4:55:10 AM UTC-4, Juha Nieminen wrote: > because it can't possibly work correctly anymore. Most useful at the > development stage, of course. (Whether the assertions should be left > in the final published product is another complex question.) One of the key features of assert() is the ability to turn it off by #defining NDEBUG. If you have no intention of ever using that feature, you should define your own assert-like macro that doesn't have that feature. My biggest problem with assert() is that I can't imagine any context in which what assert() does is what I would want my program to do, starting with the fact that the date isn't in ISO 8601 format. I generally prefer that, no matter how bad the problem, my program doesn't exit without first sending a message somewhere that contains information about the run-time context in which it failed. For instance, if assert(a<b) would be triggered, I'd want information about the current values of a and b. And I almost always want it to perform needed clean-up. |
| scott@slp53.sl.home (Scott Lurndal): Sep 06 12:55PM >has gotten smaller over the decades). If you want the absolutely >fastest file reading speed in your program, you'll probably have >to use the C file handling functions (especially std::fread). Or the POSIX functions, esp. mmap. |
| Sam <sam@email-scan.com>: Sep 06 07:15AM -0400 > before MIME support came along... Oh , I know! But sadly you don't. Why not > go > look it up you mouth breather. That's "Mr. Mouth Breather" to you. And it didn't. Everything depended on pot luck that someone's client used the same character set as you did. Until MIME came along and standardized everything, welcoming the 21st century with open arms. But, for some peculiar reasons, some people stubbornly prefer to live in the past, trying to suffer the modern world using obsolete technoogy. Why? Beats me, I have no idea. > >And that would be a darn shame. > Perhaps being able to speak 4 words of French is impressive in the US, not > so much over here in Europe. So, what exactly impresses you folks, over there? You know you're arguing against self-interest, you know. Without the internationalization brought on by MIME you wouldn't be able to use all your funny-looking characters in your messages. > A bit complex for you? Posting binaries to usenet (how did they do it > without MIME... its a mystery) was big back in the late 80s and early 90s. > Figure out the rest youself. We're not talking about binaries, but plain text messages. Try to keep up. > >date of the formal specification for PGP-signed MIME content? Why would =20 > >someone want to misrepresent the publication date? Enlighten us, please. > Fuck knows what you're on about there, off in your own little world. I'm sorry to have disturbed you with reality. > >> That would be hard work. Writing ones own parser isn't. > >Who said it was hard? > Well you needed help. No, I do not believe I ever asked for any help. I was looking for some free entertainment, which you helpfully provided. |
| Sam <sam@email-scan.com>: Sep 06 07:21AM -0400 > >> I'm sure that made sense to someone. > >It sure did. > I can't say I'm surprised you find his piss poor grammar intelligable. You must've meant to write ".. that you find ..". Just trying to help you on your quest to improve the usage of King's English on the intertubes. Before you get your panties in a wad about someone else's grammar and spelling, you should make sure that yours is up to par. Looks pretty bad, otherwise. I wouldn't necessarily complain about an occasional typo, or a missed preposition, myself. I make mistakes too. But whining about typos or grammatical errors typically indicates a feeble and immature mind. > Now, please excuse me, I must use tools like compiler to doing code! "like .. a .. compiler", or perhaps "like compilers". "to .. to .. code", or better, "to write code". May the force be with you. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment