- Undefined Behaviour - 4 Updates
- template madness - 6 Updates
- Awsomeness - 1 Update
| boltar@cylonHQ.com: Sep 07 12:02PM On Thu, 06 Sep 2018 07:15:36 -0400 >> 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 Look up uuencode you pillock. If you can't even manage that then nothing else you say is worth a damn. >> 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. FFS utf8 is 8 bit, thats binary as far as usenet is concerned. There are some ignorant idiots on here, but you definately win this months prize. |
| boltar@cylonHQ.com: Sep 07 12:03PM On Thu, 06 Sep 2018 07:21:04 -0400 >"like .. a .. compiler", or perhaps "like compilers". >"to .. to .. code", or better, "to write code". >May the force be with you. Congratulations, you can't spot irony either. But then you're a yank so that will come as a surprise to precisely no one. |
| Sam <sam@email-scan.com>: Sep 07 06:20PM -0400 > >And it didn't. Everything depended on pot luck that someone's client used > Look up uuencode you pillock. If you can't even manage that then nothing > else you say is worth a damn. And how exactly did uuencoded content specify its character set, and type, Einstein? > >> Figure out the rest youself. > >We're not talking about binaries, but plain text messages. Try to keep up. > FFS utf8 is 8 bit, thats binary as far as usenet is concerned. No, utf8 is not binary. Try again. > There are some ignorant idiots on here, but you definately win this months > prize. What prize do I get? |
| Sam <sam@email-scan.com>: Sep 07 06:23PM -0400 > >"to .. to .. code", or better, "to write code". > >May the force be with you. > Congratulations, you can't spot irony either. So, your claim of being an uberhacker, and the 2nd coming of Kevin Mitnick, is irony? > But then you're a yank so that > will come as a surprise to precisely no one. Indeed. You french are world-famous for your sense of humor. You even think that Jerry Lewis is funny. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 07 06:17AM >>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. If you are making a closed program for a limited number of platforms, you can of course do that. However, if you want to write portable code, then that's not an option. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 07 12:02PM > #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. Why? I don't define my own std::printf() just because I never use the %g format specifier. More seriously, shipping with assert() enabled may be something you dislike, but it doesn't violate the semantics of assert() itself. Unlike many other common assert usage patterns. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Sep 07 12:58PM >>>to use the C file handling functions (especially std::fread). >> Or the POSIX functions, esp. mmap. >If you are making a closed program for a limited number of platforms, *snort* mmap is portable to a very large number of platforms - there is only one that it is not directly portable to (but could be shimmed on windows). >you can of course do that. However, if you want to write portable >code, then that's not an option. Sure it is. Abstract it in a class (we have a class called c_osdep) which is dependent upon the OS. Use the windows mapping functions in the windows version of the class, and the posix functions in the posix version of the class. The remaining code is then portable. Nothing useful can be done with just the facilities provided by the C or C++ standards in my line of work. |
| jameskuyper@alumni.caltech.edu: Sep 07 06:16AM -0700 On Friday, September 7, 2018 at 8:02:21 AM UTC-4, Jorgen Grahn wrote: > On Thu, 2018-09-06, jameskuyper@alumni.caltech.edu wrote: > > On Thursday, September 6, 2018 at 4:55:10 AM UTC-4, Juha Nieminen wrote: ... > > feature. > Why? I don't define my own std::printf() just because I never use the > %g format specifier. I consider the fact that it can be turned off by #defining NDEBUG to be a very significant part of what assert() is; %g is a comparatively minor detail about how printf() works. This is obviously a judgement call, but objectively you can see that defining the NDEBUG feature takes up almost all of 7.2p1, which is a large fraction of the size of 7.2.1, which describes how assert() behaves when NDEBUG isn't #defined. As a purely practical matter, if you have a good reason for not wanting to turn off an assert(), it's going to be a problem if someone else who's working with your code compiles it using -DNDEBUG, because of their own asserts. I don't thing your printf("%g") analogy covers that issue. I consider it implied by your use of assert() that turning it off that way is acceptable. The issue is clear communications - not to the compiler, but to other people maintaining the code. If it is in fact not acceptable, I'm going to blame your use of assert() for being misleading, not their use of -DNDEBUG. |
| Richard Damon <Richard@Damon-Family.org>: Sep 07 02:10PM -0400 > 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. I find having a debugger break-point in abort() or having an abort that makes an appropriate core dump that can be loaded into a debugger a useful feature. This is of course mostly useful in the debugging environment, where such things are available and useful. In production code, yes, you likely want to catch the error earlier and perform cleanup. The one key feature about assert being able to be turned off is that the assert call must not have any needed side effects, as when you turn off the asserts in production, those side effects go away. |
| Ian Collins <ian-news@hotmail.com>: Sep 08 07:28AM +1200 On 08/09/18 06:10, Richard Damon wrote: > The one key feature about assert being able to be turned off is that the > assert call must not have any needed side effects, as when you turn off > the asserts in production, those side effects go away. I once placed a bunch of initialisation code in asserts, worked well in testing but not so well in the target build... Pesky side effects :) -- Ian. |
| woodbrian77@gmail.com: Sep 06 09:30PM -0700 On Thursday, September 6, 2018 at 8:15:37 AM UTC-5, Queequeg wrote: > Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote: > > https://www.youtube.com/watch?v=qs0biWHy5WU > Cool. But what does it have to do with C++? Here's some increasingly robust, middleware related code: https://github.com/Ebenezer-group/onwards One of the strengths of my approach is portability. The main thing I need to do to support a new platform is make sure my front tier: https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc builds and runs on that platform. I have 3 tiers: back, middle and front. The front tier is less than 50 lines and runs on FreeBSD, Linux and Windows. The smallness of the front tier helps make it highly portable. Brian Ebenezer Enterprises - Enjoying programming again. http://webEbenezer.net |
| 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