- template madness - 9 Updates
- Best books for: C++ 11, C++14, and C++17 - 1 Update
- Awsomeness - 1 Update
- Undefined Behaviour - 2 Updates
- Idea for allowing "using namespace" in headers - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Sep 05 05:02PM > intermediate maintainers confusing themselves for a hour or couple > because of hiding those with a more local name. So at least "::" > prefix should be used and then it is only "std" that remains. It doesn't exactly help that the C standard library doesn't use a consistent naming convention. For example, FILE is not a macro (and thus "std::FILE" is fine). On the other hand, assert() is a macro (and thus "std::assert" just cannot work). |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 05 06:33PM +0100 On 05/09/2018 18:02, Juha Nieminen wrote: > For example, FILE is not a macro (and thus "std::FILE" is fine). > On the other hand, assert() is a macro (and thus "std::assert" > 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. /Flibble -- "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." |
| "Öö Tiib" <ootiib@hot.ee>: Sep 05 11:19AM -0700 On Wednesday, 5 September 2018 20:33:37 UTC+3, Mr Flibble wrote: > 2) Don't use assert as it is considered harmful; throw an exception instead. Throwing exception is even worse than assert. Exception reports nothing and when there happens to be some catch(...) {cleanse();throw;} on the way out then it spoils the crash dump as well. Proper way of handling programming errors run time is to report (or log) the error and to kill the program. That can't be done in centralized manner and so has to be implemented into every program anew. Reporting just can not be for example injected into std::terminate since that does not accept any arguments. |
| Ian Collins <ian-news@hotmail.com>: Sep 06 07:28AM +1200 On 06/09/18 05:33, Mr Flibble wrote: > 2) Don't use assert as it is considered harmful; throw an exception instead. Considered harmful by whom? -- Ian |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 05 08:11PM On Tue, 2018-09-04, Öö Tiib wrote: ... > and about taste it is easy to fight but impossible to argue. > Most of C library names are utter Klingon recognizable from afar > without any "std::" needed. I think that's a key point. The C names tend to be recognizable and odd, or at least well-known like "free" and the other ones Tiib mentioned. C++ standard library names are in a namespace. So if you shave off the namespace all that's left is often a common name (find, copy, read, ...) which you want to use for things in your own code. At least /I/ want to use them: I prefer to read short names without superfluous information, and I don't use CamelCase for functions, so my names tend to be similar to the standard library's. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 05 08:21PM On Mon, 2018-09-03, Chris Vine wrote: > really going to include cstring to capture also, say, strcpy() in the > same code? > This is not wholly rhetorical. What do other people do? If I use POSIX functions, I use the POSIX headers which are documented to pull them in. Using your example, if I used strdup() and strerror() in some source file, I'd pretend both as merely POSIX functions, and pull them in using <string.h>. This is rarely or never a problem for me, and I still get to use the <cfoo> headers a lot. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Sep 05 08:23PM >On 06/09/18 05:33, Mr Flibble wrote: >> 2) Don't use assert as it is considered harmful; throw an exception instead. >Considered harmful by whom? While I disgree with the 'throw an exception instead', I don't like to see assert() used in production code - it is very user unfriendly and doesn't provide sufficient information for a user to create a defect report from. Use it for development testing, but build the production software with -DNDEBUG. Most places where an assert is used, the proper recovery code could be added with a modicum of extra effort. |
| Ian Collins <ian-news@hotmail.com>: Sep 06 08:31AM +1200 On 06/09/18 08:23, Scott Lurndal wrote: > production software with -DNDEBUG. > Most places where an assert is used, the proper recovery code could > be added with a modicum of extra effort. Most but not all; sometimes we need to protect against the impossible! 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. -- Ian. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 06 12:07AM +0200 On 05.09.2018 22:23, Scott Lurndal wrote: > and doesn't provide sufficient information for a user to create a > defect report from. Use it for development testing, but build the > production software with -DNDEBUG. If that refers to use of `assert`on its own, it means that where otherwise an assertion would fire, the user just gets wrong but perhaps not obviously wrong results (Murphy's law would skew reality in the direction of the not obviously wrong results, and mostly where they harm the most). Maybe later also a crash or hang. IMO that's a very bad idea, but maybe you're talking about a double-whammy assert + something, where the something might be a "hard" exception or termination with logging or termination with optional restart and logging. > Most places where an assert is used, the proper recovery code could > be added with a modicum of extra effort. A failed assertion usually means that at least one critical assumption did not hold. AFAIK local recovery from incorrect critical assumptions, is usually not practically possible. Cheers! - Alf |
| Manfred <noname@add.invalid>: Sep 05 11:06PM +0200 On 9/2/2018 2:48 AM, 😉 Good Guy 😉 wrote: >> For a tutorial, what are the best and easiest books to read on C++ 11, C++ 14, and C++ 17? >> Thank you, >> Mike You may also look at: https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 05 08:56PM +0100 https://www.youtube.com/watch?v=qs0biWHy5WU Message ends. /Flibble -- "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." |
| boltar@cylonHQ.com: Sep 05 06:39PM On Mon, 03 Sep 2018 21:27:51 -0400 >ou =20 >that "vous =C3=AAtes un cr=C3=A9tin", without MIME it wouldn't be possibl= >e. Wouldn't it? I wonder how usenet coped with 8 bit data and character sets before MIME support came along... Oh , I know! But sadly you don't. Why not go look it up you mouth breather. >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. >> No, you'd have to go back further than that for you to fit in. >Can you translate that into English? You're not making sense. The =20 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. >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. >> >write this message. I'm impressed. >> That would be hard work. Writing ones own parser isn't. >Who said it was hard? Well you needed help. >And I feel obligated to return the favor, and I tell you that I have no =20 >doubts at all, not any, whatsoever, as to whether you know or don't know =20 >what you're doing. Not much of a mystery, there. When you can demonstrate you have the basic ability to find out simple facts about usenet then feel free to criticise others. >> short trousers. >I'll keep your very profound advice in mind, thank you very much. I would if I were you. |
| boltar@cylonHQ.com: Sep 05 06:46PM On Mon, 03 Sep 2018 21:08:23 -0400 >> >mole. Keep digging! >> 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. Now, please excuse me, I must use tools like compiler to doing code! |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 05 07:54AM +0200 > Now, what would happen, if we had a special "using namespace", which only "imports" symbols for code in the namespace it is put in? A "static using namespace": > namespace MyLib { > static using namespace std; // Note "static", that's the only difference [...] > So, "static using namespace" would import symbols for MyLib only, and for user code (stuff outside MyLib) would not be affected by that. I find this feature useful. But "static" is /highly/ misleading. This is used to import static functions of a class into a namespace in other languages. The keyword "private" is more appropriate here. This behavior would be similar to a using directive in a class. Basically I would recommend to allow "private:" and "public:" within a namespace in general. Then there is no more need for the "::detail" work around. Furthermore this puts namespaces and static classes (with only static members) closer together. From my point of view there is no need for a difference of these two syntax elements at all. It should be just like "class" versus "struct". The defaults should differ. And well, instance members should not be allowed in namespaces. So namespace is basically just a class that contains only types and static members. And of course, it is never complete, so multiple definitions of the same namespace are still allowed. Maybe we should also allow inheritance of namespaces. The effect is basically the same than a using directive in the first line, but this would put "protected:" also into a meaningful semantic. From this point the next step might be to allow extension methods like in C#. The only difference that I /strongly/ recommend is that the required using directive should include the name of the defining static class and not elapse its name like in C# and import all extension methods of all classes in a namespace at once. Since in C++ you would use "namespace" for extension methods rather than "static class" the latter is straight forward. > What do you think about this idea? Is it reasonable? From my point of view yes. Although purists dislike using namespace, prefixing everything with "std::" can significantly blow up the code with impact on readability and maintainability. Especially when it appears a dozen time in a line, e.g. in case of nested template types, binder functions etc. > How big is the change to the standard? I think it's a moderate change. Marcel |
| 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