- Undefined Behaviour - 17 Updates
- explicit initializer clauses - 1 Update
- copy_backward - 1 Update
- The Rapture (Reprise ad infinitum) - 5 Updates
- Data-Oriented Design and Avoiding the C++ Object-Oriented Programming Zimmer Frame - 1 Update
| boltar@cylonHQ.com: Aug 31 08:31AM On Thu, 30 Aug 2018 22:14:02 +0200 >You could equally well say that if it is valid C++11, then a C11 >compiler should handle it in C since the compiler can already handle it >in C++. That would be nonsense just the same. The superset should handle the subset, not vice verca. >C is not a subset of C++. It is /close/ to a subset, but not an exact one. Its close enough as makes no difference and that is how its used. Actual use cases should trump academic opinion. >> any more. >If people had really wanted this particular form of VLAs in their C++ >code, I am sure the gcc team would have allowed it as an extension. If Having used gcc for MANY years I think its fair to say the gcc team include and exclude what they feel like, not necessarily what their users want. Which given the compiler is free and a lot of them do it for no money is entirely reasonable. But one shouldn't assume the users are at the head of their list when it comes to wish fulfillment. >modes of gcc, then the way forward is to file a bug in gcc asking for >the missing feature. If other people agree with you, and it is as >simple to support as you think, then maybe it will get added. It is Its already supported. I very much doubt the C++ and C sections of the compiler use different parsers and lexical analysers, its almost certainly the same ones with various feature flags switched on and off depending on the language. |
| Ian Collins <ian-news@hotmail.com>: Aug 31 09:50PM +1200 >> compiler should handle it in C since the compiler can already handle it >> in C++. That would be nonsense just the same. > The superset should handle the subset, not vice verca. Which doesn't include VLAs. -- Ian |
| boltar@cylonHQ.com: Aug 31 09:56AM On Fri, 31 Aug 2018 21:50:31 +1200 >>> in C++. That would be nonsense just the same. >> The superset should handle the subset, not vice verca. >Which doesn't include VLAs. It seems to me idiotic to switch off a feature which is already built into the compiler simply because its not part of an official standard. |
| Ian Collins <ian-news@hotmail.com>: Aug 31 10:03PM +1200 >> Which doesn't include VLAs. > It seems to me idiotic to switch off a feature which is already built into the > compiler simply because its not part of an official standard. One problem with VLAs and C++ is constructs that are regular arrays in C++ have to be VLAs in C. For example const size_t s = 42; int n[s]; -- Ian. |
| David Brown <david.brown@hesbynett.no>: Aug 31 12:38PM +0200 >> compiler should handle it in C since the compiler can already handle it >> in C++. That would be nonsense just the same. > The superset should handle the subset, not vice verca. Obviously - /if/ C++ were a superset of C. It isn't - it is only approximately, and so C++ can only handle most of C code instead of all of it. I think what you are trying to say is that you would prefer C++ to be a full superset of C. That would not work (though it could, reasonably, be slightly closer than it is today). >> C is not a subset of C++. It is /close/ to a subset, but not an exact one. > Its close enough as makes no difference and that is how its used. Actual use > cases should trump academic opinion. No, that's wrong - on both accounts. It is not hard to write code that is compatible with both languages - and that is the practical solution that people use if they have to mix the languages. There are a few fiddly bits, but mostly it's fine. There are, I think, three main cases for such mixes. One is header files that should be usable by both C and C++. There you see a fine example of incompatibility - a declaration of an external function is incompatible between C and C++. It has an easy solution for headers, but it is still needed. A second case is for people programming C on Windows with MSVC, because the compiler is crap for C. So they write code that is C (or at least is intended to be C), but compiled as C++. A final case is for mixed development groups where code is originally in C but is migrated to C++. However, C written to be compatible with C++ has some restrictions. You are likely to get some non-idiomatic coding, like casting the result of malloc (some C programmers have very strong opinions against that). There are lots of other things where C++ is stricter than C, leading to code that is fine in C being a failure in C++ (some types of casts, mixing enums and ints, having multiple tentative declarations of the same variable in a file). Some of these - such as K&R function declarations and definitions - most C programmers are happy to see gone. Then there are features that can be very useful in C that don't exist in C++. Designated initialisers are, I think, the biggest in this class. (C++ plans to adopt them in C++20.) VLAs and complex numbers are others that are somewhat less used. _Generic is a new one in C11. There are things that exist in both languages, but have different details - such as the type of 'a' or file-scope "const" data. And clearly keywords in C++ that don't exist in C can be identifiers in normal C code. So no, C++ is not a proper superset of C, and never can be. It could be closer, of course. VLA's were not supported in C++ because there was a hope of introducing a better alternative, but that initiative failed because no one could figure out how to implement it with the desired syntax and semantics. So some compilers (like gcc) have partial support for VLAs in C++. And no, "actual use cases" should not trump the standards. Compilers and standards committees should work together (as they do) - sometimes one will be ahead of the other, but we don't want compiler implementers having a free-for-all, even for copying features from C. That leads to incompatibilities and restrictions in later versions of the language. > given the compiler is free and a lot of them do it for no money is entirely > reasonable. But one shouldn't assume the users are at the head of their list > when it comes to wish fulfillment. You are mixing up "users in general" with individual users. gcc developers are interested in hearing the ideas and opinions of individuals, but will usually not implement something unless it seems useful to a wide range of users (or the individual writes the implementation themselves). So if someone says they want VLAs with sizes from file-scope variables passed to functions, it is not likely to come high up on their to-do lists. It would be a lot of work for little gain. If several people ask, and show how that coding style is used in a lot of C programs and is better than alternative constructs, and if the gcc C++ experts can see that it will not conflict with other things in C++ present or expected future, /then/ they would give it some priority. > Its already supported. I very much doubt the C++ and C sections of the compiler > use different parsers and lexical analysers, its almost certainly the same ones > with various feature flags switched on and off depending on the language. They use different parsers and different lexical analysis, AFAIUI. The C++ front-end was split off from the C front-end long ago as it became too complex to maintain as a "C with extras" parser. It would be possible, I suppose, to use the C++ parser to handle C as a sort of "C++ with lots of limits and a few extra bits". But I don't expect that to happen - the result would be a good deal less efficient for C, and probably lose many of the useful gcc C extensions. clang has a different development history, and different models for their front-end handling. Where gcc started with C and gradually added C++ as the language developed, clang started when C++ was a well-established language. AFAIK, it /does/ handle C and C++ in the same parser, and so is much more likely to support C constructs in C++. |
| boltar@cylonHQ.com: Aug 31 11:02AM On Fri, 31 Aug 2018 22:03:43 +1200 >C++ have to be VLAs in C. For example >const size_t s = 42; >int n[s]; And the problem is...? |
| Sam <sam@email-scan.com>: Aug 31 07:02AM -0400 > It seems to me idiotic to switch off a feature which is already built into > the > compiler simply because its not part of an official standard. Feel free to write your own C++ compiler, to show everyone how it should be done. |
| boltar@cylonHQ.com: Aug 31 11:14AM On Fri, 31 Aug 2018 12:38:40 +0200 >Then there are features that can be very useful in C that don't exist in >C++. Designated initialisers are, I think, the biggest in this class. I don't remember seeing them ever used in code whereas I've seen VLAs a number of times. >And clearly keywords in C++ that don't exist in C can be identifiers in >normal C code. That is pretty much the only real issue preventing C++ being a proper superset of C. >And no, "actual use cases" should not trump the standards. Compilers I disagree. A programming language and its compiler is a tool to get a job done, its not a purely academic exercise. You can see this with objective C++ compilers - a hideous mash up of languages which unfortunately is required because of Apple sticking with Objective-C for its APIs long after it should have been taken out back and shot. >is better than alternative constructs, and if the gcc C++ experts can >see that it will not conflict with other things in C++ present or >expected future, /then/ they would give it some priority. I imagine most programmers have neither the time nor inclination to get into in depth argumenst over compiler features with compiler writers, they're too busy doing their job. The only people who will are those involved in compilers or students who have lots of free time. Neither of which will probably be using the compilers in a "get it done by yesterday" business enviroment. >They use different parsers and different lexical analysis, AFAIUI. The >C++ front-end was split off from the C front-end long ago as it became >too complex to maintain as a "C with extras" parser. It would be Well thats odd because very often with gcc you get a "use flag -xyz to use this language feature" type of error. Though perhaps its only within a particular language, not between them. |
| boltar@cylonHQ.com: Aug 31 11:23AM On Fri, 31 Aug 2018 07:02:47 -0400 >This is a MIME GnuPG-signed message. If you see this text, it means that >your E-mail or Usenet software does not support MIME signed messages. Indeed it doesn't, I don't need any attachment shite with usenet. >> compiler simply because its not part of an official standard. >Feel free to write your own C++ compiler, to show everyone how it should >be done. I should have known the utterly moronic "If you don't like something do it yourself" argument would pop up from some muppet eventually. Sorry sonny, I have a job to do. When you get one you might realise that free time can be scarce (he says writing a usenet post, but hey ;). But FWIW I wrote a (subset of) C interpreter about 10 years ago so I do have some skin in the game. |
| David Brown <david.brown@hesbynett.no>: Aug 31 01:42PM +0200 >> C++. Designated initialisers are, I think, the biggest in this class. > I don't remember seeing them ever used in code whereas I've seen VLAs a number > of times. People write code in different ways. I have seen and used designated initialisers more often than VLAs - but equally I have no reason to doubt your experience. In discussions of "what does C have that C++ does not", I find designated initialisers coming up more often than VLAs. Perhaps it is because there is no equivalent in C++, while C++ programmers have various alternatives to use in situations where a VLA might be of interest in C. VLA's in C have (unfairly, IMHO) an image of being "dangerous" - designated initialisers are considered either harmless convenient syntax, or directly useful for safer more legible coding. >> normal C code. > That is pretty much the only real issue preventing C++ being a proper superset > of C. No, it is not - that's why I gave other issues. But the keyword one here is certainly a big and insurmountable issue. > compilers - a hideous mash up of languages which unfortunately is required > because of Apple sticking with Objective-C for its APIs long after it should > have been taken out back and shot. I agree about Objective-C++. But that goes against your case - it is an example of a language created in compilers for actual use, rather than one that was planned or defined by academics or committees. > busy doing their job. The only people who will are those involved in compilers > or students who have lots of free time. Neither of which will probably be > using the compilers in a "get it done by yesterday" business enviroment. I'm lost here. You are blaming the language for being run by "academics" rather than real compilers (forgetting that the standards committee consists mainly of major language users and compiler developers, with only a few academics). You blame the compiler writers for making things up for their own interest instead of listening to users. You blame the users for being too busy working to tell compiler developers what they want. Everyone, it seems, is to blame for not solving your impossible request for making C++ a full superset of C. > Well thats odd because very often with gcc you get a "use flag -xyz to use > this language feature" type of error. Though perhaps its only within a > particular language, not between them. There are few features that are controlled by flags in gcc (other than the obvious ones that are controlled by the choice of language standards). But there are certainly a large number of extensions to C that are not available in C++ in gcc - usually because doing so would mean duplicating effort, or at least adding significant effort, for a feature deemed of little worth. |
| Bo Persson <bop@gmb.dk>: Aug 31 03:46PM +0200 >> const size_t s = 42; >> int n[s]; > And the problem is...? The problem is with C where this is a VLA, which are optional in C11. So C99 only? In C++ this is a fixed size array (s is a constant), so just works. Bo Persson |
| boltar@cylonHQ.com: Aug 31 01:47PM On Fri, 31 Aug 2018 13:42:11 +0200 >because there is no equivalent in C++, while C++ programmers have >various alternatives to use in situations where a VLA might be of >interest in C. To me designated initialisers is one of those features that looks like it would be very useful but rarely is. But as you say, each to their own. >I agree about Objective-C++. But that goes against your case - it is an >example of a language created in compilers for actual use, rather than >one that was planned or defined by academics or committees. Well not really, what it shows is that when there's a will there's a way and if the gcc and clang teams can merge the hideous syntax of Obj-C with C++ then C99 should be a doddle. >I'm lost here. You are blaming the language for being run by >"academics" rather than real compilers (forgetting that the standards >committee consists mainly of major language users and compiler I'm not sure what you mean by "major language users". Corporations will inveitably try and skew things there own way to suit their own compiler implementations and needs which don't necessarily intersect with coders at large. >for making things up for their own interest instead of listening to >users. You blame the users for being too busy working to tell compiler >developers what they want. You said it yourself - when solitary users do make a point it generally gets lost in the noise. >Everyone, it seems, is to blame for not solving your impossible request >for making C++ a full superset of C. I never said a full superset, I simply said it should support the syntax of NINETEEN year old C99. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 06:46PM +0300 > I never said a full superset, I simply said it should support the syntax of > NINETEEN year old C99. I'm curious - how do the C programmers protect themselves against stack overflow with VLA-s? A VLA takes an unknown amount of space in the stack, and the stack size is typically very limited (in order of some MB-s). Also, running out of stack is UB, there is no error recovery. In my little test I could only call 5 nested functions each having a VLA of meager 50,000 doubles, until getting a segfault. Max stack depth 5 seems too small even for C, not to speak about C++ where I routinely see stack backtraces of depth 100 or more. |
| David Brown <david.brown@hesbynett.no>: Aug 31 05:57PM +0200 On 31/08/18 17:46, Paavo Helde wrote: > overflow with VLA-s? A VLA takes an unknown amount of space in the > stack, and the stack size is typically very limited (in order of some > MB-s). Also, running out of stack is UB, there is no error recovery. C programmers (good ones, anyway!) make sure they don't allocate too big VLAs - they check the sizes or get the size from a known source. They don't ask web site users to give them a number and use that as the size of the array! It is exactly the same as for any other allocation. You don't pre-allocate a std::vector with a size that is unreasonable. Yes, overrunning your stack space is UB. For most real programs, so is overrunning your heap. On some OS's (like Linux, with typical configurations) the OS will happily accept memory requests for much more space than it can give you, and crash your application (or a different program) when the space gets used. Even when OS's are more conservative, you can happily allocate so much space that other programs get moved out to swap and everything slows to a fraction of its normal speed. The C or C++ code may have defined behaviour in such cases, but the user certainly doesn't! And if you have an OS is clever enough to refuse the allocation, programs are rarely smart enough to deal with the situation well. Exiting due to an unhandled exception, or simply failing to do the job expected of the program, is not much better than crashing from a stack overflow. > of meager 50,000 doubles, until getting a segfault. Max stack depth 5 > seems too small even for C, not to speak about C++ where I routinely see > stack backtraces of depth 100 or more. Use VLAs - or any other stack data - in a way that makes sense for the target. There is nothing special about VLAs here - the same would happen if you made a std::array of 50,000 doubles local to the function. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 07:32PM +0300 On 31.08.2018 18:57, David Brown wrote: > situation well. Exiting due to an unhandled exception, or simply > failing to do the job expected of the program, is not much better than > crashing from a stack overflow. That's right. Relying on the bad_alloc exception is not wise because at that point the computer has already become unusably slow anyway and there is also a good chance the OS will kill your program before it gets bad_alloc. Also, the memory reported as free is often actually not unused. The OS is using it for disk file caching, for example. If the programs will grab it to themselves, the system performance will go down. Decent memory-demanding software should actually monitor the available free memory and reduce the number of parallel threads or refuse to start new tasks if there is too little of it. OTOH, being nice will often just mean that other programs can grab more. When I get a notice from my program "avoiding parallelization because of low memory", I already know this is because Firefox has eaten up 12 GB again. |
| David Brown <david.brown@hesbynett.no>: Aug 31 06:44PM +0200 On 31/08/18 18:32, Paavo Helde wrote: > that point the computer has already become unusably slow anyway and > there is also a good chance the OS will kill your program before it gets > bad_alloc. Use the same attitude - thinking sensibly and realistically - when using VLAs, and you will be equally successful at using them as with any other kind of resource. Take a cavalier attitude of allocating resources without a care, and you'll get trouble regardless of whether it is stack space, heap space, threads, processor time, or any other resource. VLAs are not different or more dangerous than anything else in programming. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 31 08:29PM +0100 On Fri, 31 Aug 2018 18:44:05 +0200 David Brown <david.brown@hesbynett.no> wrote: [snip] > you'll get trouble regardless of whether it is stack space, heap space, > threads, processor time, or any other resource. > VLAs are not different or more dangerous than anything else in programming. I know that you know this, and moving back to the original proposition, it is worth mentioning that VLAs are also by no means the main part of the things in C99 that do not form part of valid C++. The proposition of your respondent that "[VLAs] is pretty much the only real issue preventing C++ being a proper superset of C" is weird. C++ has numerous incompatibilities with C99, and even more with C11. For example there are a number of C99 types, macros and operators beginning with an underscore and followed by a capital letter which are and always will be represented differently in C++ (_Bool, _Complex, _Imaginery, _Pragma), and more in C11 (_Alignas, _Alignof, _Atomic, _Noreturn, _Static_assert, _Thread_local). Aside from that, off the top of my head, C99 has compound literals, designated initializers and the restrict qualifier which are not in C++, C's unions behave differently and its character literals are of different size. I am sure there are lots of other incompatibilities as well. I don't know anyone who writes code other than headers which is deliberately designed to be both valid C and valid C++. Headers are different. Many C libraries aim to be usable in C++ and their headers are in the common subset between C89/90 and C++. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 31 06:23PM (The subject is not intended to be taken literally, more like dropping relevant keywords.) This is a transcript of a recent gcc: main.cpp #include <iostream> #include <ostream> #include <string> #include <list> using namespace ::std::literals; struct ex { explicit ex( int ){} }; int main() { ::std::list< ex >ex{ { 1 } }; } transcript main.cpp: In function 'int main()': main.cpp:11:30: error: converting to 'ex' from initializer list would use explicit constructor 'ex::ex(int)' { ::std::list< ex >ex{ { 1 } }; ^ This sounds as if there was a rule that requires a non-explicit constructor here. I searched in n4762 »9.3.4 List-initialization [dcl.init.list]«, but I was not able to find this rule. |
| Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 31 03:31PM +0100 On 30/08/2018 15:45, Fraser Ross wrote: > so I disagree. The wording is done identically to that for copy where > they correctly use the C++ end iterator convention. > Fraser. I think you are correct. I was confused by comparing the incorrect descriptions of copy and move. If you look at for_each the description there is correct saying: "... starting from first and proceeding to last - 1." Fraser. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 06:45PM -0700 On Thursday, August 30, 2018 at 6:38:41 PM UTC-4, Chris M. Thomasson wrote: > What happens in the rapture? Will you just drop dead, or disappear? The Bible describes it: Jesus describes how it will be a worldwide event: https://www.biblegateway.com/passage/?search=Matthew+24%3A34-42&version=KJV 34 Verily I say unto you, This generation shall not pass, till all these things be fulfilled. 35 Heaven and earth shall pass away, but my words shall not pass away. 36 But of that day and hour knoweth no man, no, not the angels of heaven, but my Father only. 37 But as the days of Noah were, so shall also the coming of the Son of man be. 38 For as in the days that were before the flood they were eating and drinking, marrying and giving in marriage, until the day that Noe entered into the ark, 39 And knew not until the flood came, and took them all away; so shall also the coming of the Son of man be. ==> 40 Then shall two be in the field; the one shall be taken, and the other left. ==> 41 Two women shall be grinding at the mill; the one shall be taken, and the other left. 42 Watch therefore: for ye know not what hour your Lord doth come. https://www.biblegateway.com/passage/?search=Luke+17%3A34-36&version=KJV ==> 34 I tell you, in that night there shall be two men in one bed; the one shall be taken, and the other shall be left. 35 Two women shall be grinding together; the one shall be taken, and the other left. 36 Two men shall be in the field; the one shall be taken, and the other left. Luke 17:34 suggests it will be in the evening in Jerusalem. But, no one knows for sure. Paul goes further, describes how quickly it will occur. People will just wink out of existe in immediacy, probably with no visible flash or audio sound. https://www.biblegateway.com/passage/?search=1+Corinthians+15%3A51-52%2C1+Thessalonians+4%3A13-18&version=KJV 1 Corinthians 15:51-52 51 Behold, I shew you a mystery; We shall not all sleep, but we shall all be changed, 52 In a moment, in the twinkling of an eye, at the last trump: for the trumpet shall sound, and the dead shall be raised incorruptible, and we shall be changed. 1 Thessalonians 4:13-18 13 But I would not have you to be ignorant, brethren, concerning them which are asleep, that ye sorrow not, even as others which have no hope. 14 For if we believe that Jesus died and rose again, even so them also which sleep in Jesus will God bring with him. 15 For this we say unto you by the word of the Lord, that we which are alive and remain unto the coming of the Lord shall not prevent them which are asleep. 16 For the Lord himself shall descend from heaven with a shout, with the voice of the archangel, and with the trump of God: and the dead in Christ shall rise first: 17 Then we which are alive and remain shall be caught up together with them in the clouds, to meet the Lord in the air: and so shall we ever be with the Lord. 18 Wherefore comfort one another with these words. Study these things. Faith comes by hearing, and hearing by the word of God (the Bible). Some verse by verse, concept by concept, explanation: https://www.youtube.com/watch?v=5te0v0zCOjc -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 06:46PM -0700 On Thursday, August 30, 2018 at 6:40:51 PM UTC-4, Chris M. Thomasson wrote: > >> group. > > I didn't write the posts on this thread. Look at the headers. > Rick C. Hodgin Enterprises? Giganews. I post from Google Groups or Eternal September. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 30 09:12PM -0700 On 8/30/2018 6:46 PM, Rick C. Hodgin wrote: >>> I didn't write the posts on this thread. Look at the headers. >> Rick C. Hodgin Enterprises? > Giganews. I post from Google Groups or Eternal September. I see Giganews here: ___________________ eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!z10-v6no1138729qtb.0!news-out.google.com!i36-v6ni658qti.0!nntp.google.com!z10-v6no1138728qtb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail ___________________ |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 09:18PM -0700 On Friday, August 31, 2018 at 12:12:15 AM UTC-4, Chris M. Thomasson wrote: > ___________________ > eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!z10-v6no1138729qtb.0!news-out.google.com!i36-v6ni658qti.0!nntp.google.com!z10-v6no1138728qtb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail > ___________________ https://groups.google.com/forum/?nomobile=true#!original/comp.lang.c++/eF0aM6K1Ki0/dCwkEobAEAAJ NNTP-Posting-Date: Thu, 23 Aug 2018 11:31:23 -0500 Newsgroups: comp.lang.c++ ===> X-Mozilla-News-Host: news://news.giganews.com:119 From: "Rick C. Hodgin" <rick.c...@gmail.com> Subject: The Rapture (Reprise ad infinitum) ===> Organization: Rick C. Hodgin Enterprises Date: Thu, 23 Aug 2018 17:31:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Message-ID: <jOydnXk6ubDGfOPGnZ2dnUU7-RGdnZ2d@giganews.com> Lines: 6 ===> X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-W1ehWKd9taIIJtfziaTYlIsjiukIWaJgEnE8h5OpJ0MlkkUOD4gNKNsZdw81Zcv/1KnE4jf/F9PmLq1!Rsx1aOHhNWNei/XVXhMLXbwjM68xbfVm/429hLqpj1KYYfJfXjhTaSppItAYVssGDikotoruAFRr ===> X-Complaints-To: ab...@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 1289 Content-Type: text/plain; charset=utf-8; format=flowed ===> Content-Language: en-GB Content-Transfer-Encoding: 7bit The ===> highlighted lines show his signature. Compare these to my headers. -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Aug 31 08:22AM +0200 On 31/08/18 06:12, Chris M. Thomasson wrote: > ___________________ > eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!z10-v6no1138729qtb.0!news-out.google.com!i36-v6ni658qti.0!nntp.google.com!z10-v6no1138728qtb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail > ___________________ News posts pass through various servers, and the headers you see will include the originating server, the server you use, and any servers along the way. Giganews is one of the biggies in the business - a great deal of Usenet posts pass through one of their systems along the way. Usually it is quite obvious when a post is one of the real Rick's annoying sermons, or one of the fake Rick's equally annoying so-called "satires". And if Poe's law applies, then it really doesn't matter who made the post. |
| David Brown <david.brown@hesbynett.no>: Aug 31 08:16AM +0200 On 30/08/18 22:37, Vir Campestris wrote: > time was ~1MHz.. > Sorry. Next time I'll look it up, not rely on decades old memory. > (Except my manuals are in store until next month.) For most of us, the Spectrum and the Z80A was a /long/ time ago. The brain remembers many pointless and useless details, but rarely the ones we actually want for such "I'm a bigger nerd than you" competitions. (And wasn't it 3.5 MHz, or perhaps 3.75 MHz, rather than 4 MHZ ? Will that show I remember better than you - or will I have egg on my face? It's a race to Wikipedia!) But I think we can all agree that a modern x86 cpu is orders of magnitude faster than a Z80A :-) |
| 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