- Auto-incrementing or auto-decrementing values at compile-time - 2 Updates
- Why do some people hate namespace prefixes? - 20 Updates
- "Modern C++ Won't Save Us" by alex_gaynor - 2 Updates
| Mr Flibble <flibble@i42.removethisbit.co.uk>: Apr 24 02:11PM +0100 On 24/04/2019 14:07, Rick C. Hodgin wrote: >> And Satan invented fossils, yes? > He did invent your belief about fossils, Leigh. But he had no > part in what you're trying to say to me here with this sentence. And Satan invented fossils, yes? /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." |
| Ian Collins <ian-news@hotmail.com>: Apr 25 10:20AM +1200 On 25/04/2019 00:04, Rick C. Hodgin wrote: >> That's already been tried, examples being fossils and debunked case of >> blood in fossil dinosaur bones. > What points are you referring to? Go back tough some of your previous claims. > be deemed something else, and therefore "explained away." > Falseness has that luxury. It can report on data using lies and > fabrications. Truth cannot. So we can add paranoia to your list of afflictions. Do you seriously believe that the scientific community, tens of thousands of individuals from diverse political and religious backgrounds, are conspiring against your little clique? > Truth always wins in the end. It already has. >> A change that appears to blind you to the truth, common with cults. > Cults often have blindness, there is no doubt. > I am not blind. Ask any cult member and they will say the same. -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 24 05:24PM +0200 > useful, because they're unable to keep the outer context in mind. > If that hypothesis is true then your arguments are doomed to fail to > convince, because the intended audience is unable to grok what you say. Juha has a low feeling of safety that makes him thinking compulsive. That's a disorder some programmers have. And those people often want that others obey their rules. |
| scott@slp53.sl.home (Scott Lurndal): Apr 24 05:03PM >On 24.04.2019 16:46, Bart wrote: >But I think you're arguing with people who find the qualified names >useful, because they're unable to keep the outer context in mind. Horseshit. >If that hypothesis is true then your arguments are doomed to fail to >convince, because the intended audience is unable to grok what you say. In other words, everyone but Alf is too stupid to understand. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 24 10:06AM -0700 On Wednesday, 24 April 2019 17:47:12 UTC+3, Bart wrote: > Look at the question I posed at the end of my post: why does C++ (and a > few others) make such a meal of it when in most languages you basically > just use 'print'. Because C++ is often used for writing programs where are hundreds of thousands or even millions of lines of code. In namespaceless programming languages the issues that it causes are avoided either by having lot of little separate programs or by having the namespace non-optional part of name like std_print, big_print, bart_print, pig_print. > Suppose built-in types could also be part of a library, would std::int > be acceptable? Worse, int is taboo to use in large number of projects (both C and C++). It will be rejected by review with verdict: "Should use int32_t." Now about int32_t there is indeed difference. When author included <cstdint> then they should use std::int32_t; when author included <stdint.h> then they should use int32_t. > a + b > is either standard "+", or the "+" from library X, or the "+" from Y? > Should all such code be written as a std::+ b, or a X::+ b? No. Binary operators should be either inside class of first argument or inside same namespace with argument types. Compiler will search from those places and so should programmer assume that those are there. > And if a and b are globals, should it be: > X::a std::+ Y::b > just to remove all doubt? Globals don't scale anyway because one has to put locks around accesses of those to avoid race conditions. Do you program little hello word style apps only? > the "./". > Using std:: is like insisting all file names must be written in > canonical form with absolute paths. What a PITA that would be. Can't parse that analogy. I am typically programming in "different directory" than std lets say, in namespace named x and in member function of class x::Y sure I won't qualify x::F there, just write F. But how is the std::F suddenly also F for me? |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 08:30PM +0300 On 24.04.2019 18:15, Alf P. Steinbach wrote: > I agree. > But I think you're arguing with people who find the qualified names > useful, because they're unable to keep the outer context in mind. Or that might be because their own library namespace plus a couple of other heavily used namespaces are already containing thousands of symbols, and adding hundreds from std:: in the kettle would be clearly too much. There are limits for everything and everyone. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 08:46PM +0300 On 24.04.2019 17:59, Bonita Montero wrote: >> from the standard library, you need to resort to googling it. > If you don't know the name you would have to check the documentation > anyway, no matter if its prefixed or not. If I know it's from std:: then I know it has a much better chance to work correctly than everything else, so I don't need to concentrate on it when debugging. If I see std::sort in the code then I know what's doing. When it's just sort, then I don't know what it is, what it is doing and if it is doing it correctly. I have to spend my time to figure out first if it is std::sort or something else, which might be very non-trivial (recall Koenig lookup etc). Then I will need to remember that in this project and in this file the sort was meaning this and that, and recall this the next time I have to work with this code. I have no idea what you guys have against the std:: prefix, this seems like one of the easiest and simplest ways to disambiguate the code. |
| Bart <bc@freeuk.com>: Apr 24 07:12PM +0100 On 24/04/2019 18:06, Öö Tiib wrote: >> just use 'print'. > Because C++ is often used for writing programs where are hundreds > of thousands or even millions of lines of code. Some of those other languages where 'print' or equivalent is one name, can also be used for large programs. > either by having lot of little separate programs or by having the > namespace non-optional part of name like std_print, > big_print, bart_print, pig_print. I thought one of the advantages of a namespace feature is that you have the luxury of a bigger local context, even across a whole module, instead of just inside functions. That should result in less need for uniqueness among names. But since you have to prefix each one with its namespace name, there seems little point. Why not forget namespaces, and use std_string instead of std::string, if you have to write it in full anyway. > difference. When author included <cstdint> then they > should use std::int32_t; when author included <stdint.h> > then they should use int32_t. Meanwhile the rest of the world just uses int32 or i32 and everyone knows what they mean. (How many bits wide? How about taking a wild guess...) Why is it just C++ that gets its knickers in a twist about this? > Globals don't scale anyway because one has to put locks around > accesses of those to avoid race conditions. Do you program little > hello word style apps only? No. I use a language (not C++) that has namespaces, but it's rare that I need specify one with a prefix. If there's an ambiguity because the same two identifiers are visible, then the compiler will tell me. (And when I do need to use one, I use ".", not "::", which is easier on the eye.) |
| Daniel <danielaparker@gmail.com>: Apr 24 11:33AM -0700 On Wednesday, April 24, 2019 at 1:03:14 PM UTC-4, Scott Lurndal wrote: > >If that hypothesis is true then your arguments are doomed to fail to > >convince, because the intended audience is unable to grok what you say. > In other words, everyone but Alf is too stupid to understand. Alf, and most (I think most, but I'll settle for many) people programming in the .NET languages, which have far more names, but most (or many) people import the namespaces they're interested in and work with those names, in the context of those namespaces. One of the arguments in favour of prefixing everything from the standard library with std:: is that it's short, but that's just an artifact of the C++ standard library being similarly inspired as IBM was when it chose names like APL (a programming language) or PL1 (programming language #1). But as we're starting to see more meaningful names such as std::filesystem, I doubt if many people are going to fully qualify with them. Daniel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 24 06:48PM On Wed, 2019-04-24, Daniel wrote: ... > like APL (a programming language) or PL1 (programming language #1). But as > we're starting to see more meaningful names such as std::filesystem, I doubt > if many people are going to fully qualify with them. By coincidence, I removed a 'using boost::filesystem' today. I had to qualify a few declarations of something of the type 'path' (actually boost::filesystem::path) and it was a clear improvement. The rest could be avoided using 'auto' and Koenig lookup. There was one type I pulled in; I think it was boost::filesystem::basic_filesystem_error. You have to draw the line somewhere. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 10:17PM +0300 On 24.04.2019 21:48, Jorgen Grahn wrote: > There was one type I pulled in; I think it was > boost::filesystem::basic_filesystem_error. You have to draw the line > somewhere. I'm sure you know you can also use namespace aliases: namespace fs = boost::filesystem; |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 24 07:29PM On Wed, 2019-04-24, Paavo Helde wrote: ... >> somewhere. > I'm sure you know you can also use namespace aliases: > namespace fs = boost::filesystem; Yes, and that would have been worse in the case, IMO. It's an extra level of indirection to follow. Better than 'using namespace', though. Please note the "in this case". Parts of Boost has names only slightly shorter than an average Russian novel, and namespace aliases may be the right solution there a lot of the time. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Apr 24 09:49PM +0200 On 24/04/2019 16:46, Bart wrote: > the "./". > Using std:: is like insisting all file names must be written in > canonical form with absolute paths. What a PITA that would be. If only C++ had a way to let people use identifiers from a namespace without having to fully qualify them. Imagine if there were some simple method to let the compiler know that you were going to be using identifiers from a namespace and wanted to do so without prefixes. Imagine how convenient it would be if people could /choose/. Those who want to use a prefix and write "std::cout" could do so, while those that wanted to automatically use identifiers from std could just write something easy and obvious like "using namespace std;" and the compiler would magically know that "cout" really means "std::cout". People could pick the method that makes most sense for the code they are writing. Some people might think that C++ already supports this obvious feature, but that could not be true. Bart has told us that C++ is always bad, always ugly, always more awkward than any other language. And he got this knowledge without actually programming in C++, so it /must/ be true. |
| Daniel <danielaparker@gmail.com>: Apr 24 12:59PM -0700 On Wednesday, April 24, 2019 at 3:17:40 PM UTC-4, Paavo Helde wrote: > I'm sure you know you can also use namespace aliases: > namespace fs = boost::filesystem; You're right, I know that :-) But I think using boost::filesystem; is in most cases preferable. In general, we are programming within a context where the number of names is limited. Daniel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 24 10:10PM +0200 On 24.04.2019 20:48, Jorgen Grahn wrote: > By coincidence, I removed a 'using boost::filesystem' today. I had to > qualify a few declarations of something of the type 'path' (actually > boost::filesystem::path) and it was a clear improvement. I always use namespace fs = std::filesystem; ... for that, and write e.g. (and in particular) fs::path ... instead of completely unqualified `path`, and I have the impression that that's a kind of common convention? > There was one type I pulled in; I think it was > boost::filesystem::basic_filesystem_error. You have to draw the line > somewhere. :) Cheers!, - Alf |
| Daniel <danielaparker@gmail.com>: Apr 24 01:16PM -0700 On Wednesday, April 24, 2019 at 1:31:07 PM UTC-4, Paavo Helde wrote: > other heavily used namespaces are already containing thousands of > symbols, and adding hundreds from std:: in the kettle would be clearly > too much. There are limits for everything and everyone. There are more more opportunities for name leakage in C++ than in JAVA or .NET, despite the latter two having many more names in their libraries, and perhaps this suggests a different strategy. It's unfortunate that std is a garbage dump of names from such a miscellany of categories, including vector, regex, fstream, and so on. Daniel |
| Ian Collins <ian-news@hotmail.com>: Apr 25 08:32AM +1200 On 25/04/2019 08:10, Alf P. Steinbach wrote: > fs::path > .... instead of completely unqualified `path`, and I have the impression > that that's a kind of common convention? It is for me, especially when dealing with long winded nested namespaces. I started using namespace aliases for our Google protobuf namespaces (at least three levels deep) and a quick search of our code shows the practice is now common. -- Ian. |
| Bart <bc@freeuk.com>: Apr 24 09:34PM +0100 On 24/04/2019 20:49, David Brown wrote: >> canonical form with absolute paths. What a PITA that would be. > If only C++ had a way to let people use identifiers from a namespace > without having to fully qualify them. The debate here is with people who want to fully qualify them all the time. Their point appears to be that that is necessarily for the names to be always 100% unambiguous. > but that could not be true. Bart has told us that C++ is always bad, > always ugly, always more awkward than any other language. And he got > this knowledge without actually programming in C++, so it /must/ be true. You get a big hint as soon as you see: 'std::cout << "hello"'. Something that seems to have been little copied by other languages. |
| David Brown <david.brown@hesbynett.no>: Apr 24 10:42PM +0200 On 24/04/2019 22:34, Bart wrote: > The debate here is with people who want to fully qualify them all the > time. Their point appears to be that that is necessarily for the names > to be always 100% unambiguous. Of course names should be 100% unambiguous. Why would you want ambiguous identifiers? Whether that requires full qualification or not is a matter of style, preference, and the kind of code you are writing. >> /must/ be true. > You get a big hint as soon as you see: 'std::cout << "hello"'. Something > that seems to have been little copied by other languages. It is supported by almost all languages that are suitable for big programs, libraries, and multiple people working on the same code base. Which techniques you choose to use is not defined by any serious language - they offer multiple options. Thus in C++ you might use std:: (or other namespace qualifiers) on names. Or you might use "using namespace std;" at the start of the module. Or you might use it within a function. Or you might use a "using" clause for just the identifiers you want to use regularly without std::. This is not remotely something unique to C++. |
| Ian Collins <ian-news@hotmail.com>: Apr 25 08:43AM +1200 On 25/04/2019 08:34, Bart wrote: >> this knowledge without actually programming in C++, so it /must/ be true. > You get a big hint as soon as you see: 'std::cout << "hello"'. Something > that seems to have been little copied by other languages. C++ iostreams my be cumbersome for simple types, but they come into their own when outputting more complex types which contain other other non-trivial members. They also simplify streaming to things other than files. Then there's templates, a feature not shared by many other languages. -- Ian. |
| Bart <bc@freeuk.com>: Apr 24 10:10PM +0100 On 24/04/2019 21:42, David Brown wrote: > ambiguous identifiers? > Whether that requires full qualification or not is a matter of style, > preference, and the kind of code you are writing. Well, that is the debate, to use std:: everywhere or not. >>> always bad, always ugly, always more awkward than any other language. >>> And he got this knowledge without actually programming in C++, so it >>> /must/ be true. (You seem to have a strong opinion of my own languages without programming in them either.) > programs, libraries, and multiple people working on the same code base. > Which techniques you choose to use is not defined by any serious > language - they offer multiple options. Have a look at my much earlier post. Actually I'll just copy the relevant bit here: Put_Line (Ada; requires "with" and "use") echo (Bash) print (Lisp) writeln (D; requires import "std.stdio") print (Fortran) print (Haskell) print (Javascript) print (Lua) writeln (Pascal) print (Perl) print (Python) println (Scala) print (Swift) printf (C; requires include <stdio.h>) How many use anything remotely like "cout"? How many use the peculiar "<<"? How many (in the few not shown here that need a dotted name) use "::" to qualify a name?** So even this small fragment of a hello, world program seems to accurately set the scene for what C++ is going to be like. (** Out of the 400 languages here: https://rosettacode.org/wiki/Hello_world/Text I think between 1 and 4 others use those C++ features in each case.) |
| David Brown <david.brown@hesbynett.no>: Apr 24 11:52PM +0200 On 24/04/2019 23:10, Bart wrote: > printf (C; requires include <stdio.h>) > How many use anything remotely like "cout"? > How many use the peculiar "<<"? I don't know of any other languages that use "cout <<" or a similar syntax. It is a syntax with a lot of interesting features and advantages - but also some disadvantages. But that is irrelevant to the discussion. > How many (in the few not shown here that need a dotted name) use "::" to > qualify a name?** You picked an example function that is, in many languages, a built-in function or special statement. Most of these languages, if they are suitable for large-scale programming, have a system of namespaces for library and user functions. Those that don't (like C) need manual prefixes in the identifiers or other ad-hoc methods to keep control of identifiers from different blocks of code. > (** Out of the 400 languages here: > https://rosettacode.org/wiki/Hello_world/Text > I think between 1 and 4 others use those C++ features in each case.) C++ is mildly unusual in not having any equivalent to "print" immediately available in the language. But that is not relevant to the issue at hand. |
| blt_au6vi70@jby0d1iimwxs9a3.org: Apr 24 04:22PM On Wed, 24 Apr 2019 06:07:46 -0700 (PDT) >suggest to end the work contract. Either it was deliberate sabotage >or the author is totally net negative moron, anything that such >people touch turns into awfully inefficient and unmaintainable poop. To sum up the original article it seems to say that because some people cut themselves using real knives everyone should be forced to use plastic knives even though it make take 3 times longer to cut your food. This argument is getting really old and tired, especially when the (usually a) kid making the argument seems to think memory safety is the only thing that matters wrt a programming language. Taking it to its logical conclusion we should all just revert to using BASIC. To paraphrase something I read on slashdot - C and C++ are engineering tools, not toys for children. You're expected to know what you're doing when you use them. |
| Manfred <noname@add.invalid>: Apr 24 06:31PM +0200 On 4/24/2019 3:07 PM, Öö Tiib wrote: > suggest to end the work contract. Either it was deliberate sabotage > or the author is totally net negative moron, anything that such > people touch turns into awfully inefficient and unmaintainable poop. Also the example about references with lambda looks perverse to me. Such usage of references to show use-after-free denotes lack of knowledge of what C++ references are meant for, and possibly confusion with practice of GC languages like C# and Java. |
| 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