| wyniijj@gmail.com: May 02 11:06PM -0700 Richard於 2019年5月1日星期三 UTC+8上午6時49分56秒寫道： > of node packages out there, nor is Python suffering from the number of > python packages, nor is Perl suffering from the size of CPAN, etc. > It's just a silly argument. When people complained C++ is complicated or heavy, they do not refer to C++'s various libraries. > There is no one right tool for EVERY job. A software craftsman has > more than one tool in their toolbox and understands their relative > productivity for different tasks. There must be at least one tool. > The days of the one language programmer are long gone, if they were > ever even here in the first place. I prefer using C++ only (the core part), but I don't use standard library. All are fine for me except using or maintaining other people's codes all of them tends to be unnecessarily complex(lots names and rules and create new kind of misuse). E.g. pointers are just pointers to me. I don't use smart pointer or iterator. The problem of memory leak and misuse are none issue to me. |
| "Öö Tiib" <ootiib@hot.ee>: May 03 12:59AM -0700 On Thursday, 2 May 2019 23:13:03 UTC+3, Vir Campestris wrote: > They're both byte code languages after all. > I also think that the ease of use of Java will have it around for a long > time. It's harder to leak resources accidentally in Java. Myth. In actual practice Java (and C# that is kind of "better" Java from Microsoft) programs leak every precious resource there is: sockets, file descriptors, threads, mutexes and memory. Fortunately there is often plenty of that stuff but sometimes it is concrete resource for what I need to compete and that they leaked. It is especially annoying under Windows where some of that myriad of dumb Java or C# tools sneaking in background forgot to close a file so I have to kill these using task manager or even reboot the whole system for to get the file descriptor released. Only then I can for example delete the file or the like. |
| Ian Collins <ian-news@hotmail.com>: May 03 08:13PM +1200 > new kind of misuse). > E.g. pointers are just pointers to me. I don't use smart pointer or iterator. > The problem of memory leak and misuse are none issue to me. I guess that makes you unique.. -- Ian. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 03 07:57AM -0400 On 5/3/19 2:06 AM, wyniijj@gmail.com wrote: ... > I prefer using C++ only (the core part), but I don't use standard library. How do you do input or output? |
| scott@slp53.sl.home (Scott Lurndal): May 03 01:04PM >> E.g. pointers are just pointers to me. I don't use smart pointer or iterator. >> The problem of memory leak and misuse are none issue to me. >I guess that makes you unique.. There's a large amount of perfectly functional C++ code in the wild that doesn't use smart pointers or iterators. |
| scott@slp53.sl.home (Scott Lurndal): May 03 01:06PM >... >> I prefer using C++ only (the core part), but I don't use standard library. >How do you do input or output? Using operating system API's (e.g. POSIX pread/pwrite/mmap), for example. In several of my past C++ projects (hypervisors, operating systems), I/O was done the old fashioned way, by poking registers. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 03 02:24PM +0100 On 03/05/2019 14:04, Scott Lurndal wrote: >> I guess that makes you unique.. > There's a large amount of perfectly functional C++ code in the wild > that doesn't use smart pointers or iterators. No, Ian is correct and you are not. C++'s iterator model, for example, is near perfect (and realizing that pointers can also be iterators is part of that). As far as C++ is concerned (and modern C++ in particular) YOU ARE DOING IT WRONG (tm). /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| wyniijj@gmail.com: May 03 07:27AM -0700 James Kuyper於 2019年5月3日星期五 UTC+8下午7時58分07秒寫道： > ... > > I prefer using C++ only (the core part), but I don't use standard library. > How do you do input or output? --------------- Hierarchy of system file class: +-> My__Std (Internal, for standard devices) | +-> My::RegFile | My::SysFile -+-> My::ByteFlow --+-> My::ChrFile . | . +-> My::SockFile . | . +-> My::FifoFile . .--- ?? N.A.?? --+-> My::DirFile . .--- ?? N.A.?? --+-> MyBlkFile(not implemented) ------------- Demo. Example ----------- #include <My.stdio.h> // for cin/cout/cerr #include <My.unistd.h> // for My::RdBuf (the whole file system in general) using namespace My; // for clearity int main() try { Errno r; String str; size_t n_wr; // number of data read or written cin >> str; // Read characters from STDIN_FILENO to str cout << str << MY_ENDL; // Write str to STDOUT_FILENO // Reset cout to "fpath" associated device (could be regular file, // character special file, socket file, or FIFO file) // Note: This is a simple demo. // if((r=cout.reset("fpath",O_RDWR))!=Ok) { MY_THROW( Reply(r) ); // Reply wraps class Errno for throwing purpose only // MY_THROW registers __FILE__, __LINE__ info. // before throw. } if((r=cout.write(str,n_wr))!=Ok) { MY_THROW( Reply(r) ); } if((r=cout.read(str.begin(),str._capacity(),n_wr))!=Ok) { MY_THROW( Reply(r) ); } str._setsize(n_wr); // The behavior of reading is very dependent on the device, so data // reading is normally done through class RdBuf. // RdBuf generalizes sequential data reading from various ByteFlow // devices, and for recovering packet message from read data stream. // RdBuf strm; // Read till a character is in CharGrp (simplified explanation). // if((r=strm.read(cin,CharGrp,str))!=OK) { MY_THROW( Reply(r) ); } // Read request for exactly 1024 characters. // if((r=strm.read(cin,str,1024))!=OK) { MY_THROW( Reply(r) ); } return 0; } catch(Errno e) { cerr << wrd(e) << MY_ENDL; return e.c_errno(); } catch(...) { cerr << "Unknow throw type" MY_ENDL; throw; }; |
| scott@slp53.sl.home (Scott Lurndal): May 03 05:22PM >pointers can also be iterators is part of that). >As far as C++ is concerned (and modern C++ in particular) YOU ARE DOING IT >WRONG (tm). While you are certainly entitled to your opinion, it's not universally shared. |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 03 06:09PM >>WRONG (tm). > While you are certainly entitled to your opinion, it's not universally > shared. How do you solve leaks without sart pointers? -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 03 07:46PM On Fri, 2019-05-03, Melzzzzz wrote: >> While you are certainly entitled to your opinion, it's not universally >> shared. > How do you solve leaks without sart pointers? YMMV, but I put my objects in containers, as part of other objects, or as locals in functions. Code with is sprinkled with smart pointers makes me suspicious -- IMO they should be used rarely. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: May 02 11:54PM -0700 On Thursday, 2 May 2019 12:18:14 UTC+3, Juha Nieminen wrote: > it might just as well be too long. Functions spanning several pages > (by whichever editor size you are using) are probably hard to read > anyway, and might benefit from a bit of refactoring. When the naming and namespace usage rules are set then that extra clarity does not help. For example: void foo::fancyFunction() { int n = bar(); // ... } It is already telling clearly that bar is from foo namespace. It is because of when bar is from other namespace then it must be written: int n = other::bar(); The "other" there may be other namespace in global namespace or nested namespace of foo or alias of some namespace in foo. Its name must make clear enough for reader what it is. When bar is from global namespace then it must be written: int n = ::bar(); When bar is file-local static name (can be in anonymous namespace or in foo or in anonymous namespace in foo or in global namespace it does not matter) then it must have some special naming difference like: int n = bar_(); IOW the rules can be set so that it is always clear enough from what namespace a name comes and then there is no need to stutter about "foo" within "foo". |
| Bart <bc@freeuk.com>: May 03 12:48PM +0100 On 03/05/2019 07:54, Öö Tiib wrote: > int n = bar(); > // ... > } Maybe I ought to go and look it up but it's easier to just ask: what does the foo:: mean in this context? |
| "Öö Tiib" <ootiib@hot.ee>: May 03 06:40AM -0700 On Friday, 3 May 2019 14:48:34 UTC+3, Bart wrote: > > } > Maybe I ought to go and look it up but it's easier to just ask: what > does the foo:: mean in this context? The foo:: there says that the function definition is of fancyFunction of namespace foo. Other way of writing the (equivalent) definition is namespace foo { // ... void fancyFunction() { int n = bar(); // ... } // ... } |
| jameskuyper@alumni.caltech.edu: May 03 07:41AM -0700 On Friday, May 3, 2019 at 7:48:34 AM UTC-4, Bart wrote: > > } > Maybe I ought to go and look it up but it's easier to just ask: what > does the foo:: mean in this context? foo means the same thing here that it does in most contexts: it's an arbitrarily chosen identifier. You should assume that whatever it identifies is suitable for use in the context where it's being used; but it's characteristics are otherwise unspecified, being unimportant to the discussion. To put it another way: if you think there's something you need to know about foo that isn't implied by the way foo is being used, either you're wrong about needing to know it, or the OP was wrong to use "foo" for this purpose. Other popular identifiers used the same way include foobar, bar, and baz. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 03 03:15PM > about foo that isn't implied by the way foo is being used, either you're > wrong about needing to know it, or the OP was wrong to use "foo" for > this purpose. Here perhaps foo/bar were unfortunate names, since naming is about meaningfulness. How about e.g. void bike::wheel() { int n = frame(); // ...: } Which hints that we're talking about a bike's frame rather than frames per second, or being framed, or ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bart <bc@freeuk.com>: May 03 07:51PM +0100 >> does the foo:: mean in this context? > foo means the same thing here that it does in most contexts: it's an > arbitrarily chosen identifier. In other contexts, there foo::abc tells you it is referring to the 'abc' identifier that belongs within namespace 'foo'. But since 'abc' is actually being defined here, it is confusing: * Is this whole definition itself inside 'foo'? (If so, then why have foo::?) * Is this definition, despite being inside it its own namespace, defining a function belonging to another? (And if so, why? Why can't it be defined inside foo:: ?) * Or does foo:: here mean that every unresolved identifier inside the function should be searched for inside foo? |
| "Öö Tiib" <ootiib@hot.ee>: May 02 10:53PM -0700 On Thursday, 2 May 2019 17:56:15 UTC+3, David Brown wrote: > which may be of interest to some people who happen to be in the group, > and the kind of pantomime nonsense perpetrated by you and Rick. Yes, > you are equally guilty. Perhaps you haven't put it clearly forward that you dislike Leigh's ways of "fighting" with religious spam even more than religious spam that you also dislike? |
| "Öö Tiib" <ootiib@hot.ee>: May 02 11:23PM -0700 On Thursday, 2 May 2019 17:58:23 UTC+3, peteolcott wrote: > > Why am I not surprised? Posters like you kill groups. > > If you ever get as far as working on a C++ implementation and want to discuss coding details, come back here. Until then, please stay out of irrelevant groups. > I only come here because the more relevant groups died. The groups die because of people who act like you. They post lot of posts and are impossible to discuss with. Then everybody will decide that they don't want to be in such sad places where such mentally ill behavior prevails. Go look at comp.programming and comp.programming.threads. These have became personal, insane blogs of "Amine Moulay Ramdane". He also dislikes that the groups are dead so he occasionally posts his crap to alive groups in comp.lang or alt.comp.lang or comp.arch. If he gets any responses from there then only insults. People are allergic to disrespectful behavior of madmen. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 03 01:37PM +0100 On 02/05/2019 15:56, David Brown wrote: > may be of interest to some people who happen to be in the group, and the > kind of pantomime nonsense perpetrated by you and Rick. Yes, you are > equally guilty. You need to have a serious word with yourself, m8. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| peteolcott <Here@Home>: May 03 09:33AM -0500 On 5/2/2019 2:00 AM, Öö Tiib wrote: > No, each kook deviates from average people in unique manner. > Their background and reasons of going crazy in that background > are rather different. :) My system of reasoning has finally been vetted. Now we have: [Deductively Sound Formal Proofs] -- True(x) ↔ (⊢x) True Premises Necessarily derive a True Consequence: ◻(True(P) ⊢ True(C)) This refutes Tarski and Gödel. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| peteolcott <Here@Home>: May 03 09:35AM -0500 > On Wednesday, 1 May 2019 22:44:22 UTC+1, peteolcott wrote: >> I used to talk about this on comp.theory and then comp.theory died: > There's a serious hole in your logic system if it failed to infer the latter from the former. Now we have: [Deductively Sound Formal Proofs] -- True(x) ↔ (⊢x) True Premises Necessarily derive a True Consequence: ◻(True(P) ⊢ True(C)) Within [Deductively Sound Formal Proofs] expressions of language that are not decided to be True are decided to be ¬True, thus undecidable sentences cannot be expressed. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| peteolcott <Here@Home>: May 03 09:36AM -0500 On 5/2/2019 9:56 AM, David Brown wrote: > I am sorry, but I think you have got people mixed up. I have never approved of spam - religious or otherwise. Nor do I like continuous junk posts (which are not spam - there is a difference) - that includes certain pointlessly repetitive religious posts, > and it includes your own pointlessly repetitive posts. > There is a difference between an /occasional/ off-topic discussion, which may be of interest to some people who happen to be in the group, and the kind of pantomime nonsense perpetrated by you and Rick. Yes, you are equally guilty. Now we have: [Deductively Sound Formal Proofs] -- True(x) ↔ (⊢x) True Premises Necessarily derive a True Consequence: ◻(True(P) ⊢ True(C)) Within [Deductively Sound Formal Proofs] expressions of language that are not decided to be True are decided to be ¬True, thus undecidable sentences cannot be expressed. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| peteolcott <Here@Home>: May 03 09:37AM -0500 On 5/3/2019 1:23 AM, Öö Tiib wrote: >>> If you ever get as far as working on a C++ implementation and want to discuss coding details, come back here. Until then, please stay out of irrelevant groups. >> I only come here because the more relevant groups died. > The groups die because of people who act like you. I am correct and here is the proof: Now we have: [Deductively Sound Formal Proofs] -- True(x) ↔ (⊢x) True Premises Necessarily derive a True Consequence: ◻(True(P) ⊢ True(C)) Within [Deductively Sound Formal Proofs] expressions of language that are not decided to be True are decided to be ¬True, thus undecidable sentences cannot be expressed. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| peteolcott <Here@Home>: May 03 09:38AM -0500 On 5/3/2019 7:37 AM, Mr Flibble wrote: >> There is a difference between an /occasional/ off-topic discussion, which may be of interest to some people who happen to be in the group, and the kind of pantomime nonsense perpetrated by you and Rick. Yes, you are equally guilty. > You need to have a serious word with yourself, m8. > /Flibble Now we have: [Deductively Sound Formal Proofs] -- True(x) ↔ (⊢x) True Premises Necessarily derive a True Consequence: ◻(True(P) ⊢ True(C)) Within [Deductively Sound Formal Proofs] expressions of language that are not decided to be True are decided to be ¬True, thus undecidable sentences cannot be expressed. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| 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