- What a reference actually is - 6 Updates
- std::sort( std::execution::par, v2.begin(), v2.end()); // parallel sort - 2 Updates
- problem with c++ union as argument: - 1 Update
- What is a `**ppEnum`? - 1 Update
- The most convenient way to show a process tree with windows - 2 Updates
- converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++, part 2 - 1 Update
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 19 02:34AM -0500 On 11/18/22 06:23, Michael S wrote: > On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: ... > What alternative do have in mind? if-else-if chains? > Both more typing and intentions of using the same selection variable > for all choices is not pronounced clearly. I get the impression that you've missed his point. He's not arguing that C would be made better by dropping all of those things. He's pointing out that just because something is not necessary, is not a reason for dropping it from the language. It is precisely his point that the language would be less easy to use if these features were removed for no better reason than the fact that they are unnecessary. |
| Michael S <already5chosen@yahoo.com>: Nov 19 08:20AM -0800 > dropping it from the language. It is precisely his point that the > language would be less easy to use if these features were removed for no > better reason than the fact that they are unnecessary. I don't know about your or Juha, but I personally draw a line at DRY. Features that help to DRY can be controversial, can be even harmful, (as many preprocessor macros) but they are not nutrient-free syntactic sugar. Of all features of 'C' listed by Juha, only 'while' and 'const' do not help DRY at all and only [] help it minimally, but [] obviously help other aspects of readability. C++ references do not help DRY at all, except if you consider & here or * there as repeating yourself. And, IMHO, presence of references in the language makes understanding somebody else's code significantly harder. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 19 05:10PM On Thu, 2022-11-17, Juha Nieminen wrote: > While a reference might in practice be internally implemented by the > compiler pretty much as if it were a pointer, it shouldn't really be > thought as such at the language level. Especially since the beginners you're explaining things to should learn about references long before they learn about pointers. And they don't always have a C background nowadays. > A reference should be thought of as an "alias" for the original variable > it's referencing. s/variable/object/. (Happily you use "object" in the rest of the text.) [snip] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <eesnimi@osa.pri.ee>: Nov 20 12:37AM +0200 19.11.2022 18:20 Michael S kirjutas: > Features that help to DRY can be controversial, can be even harmful, > (as many preprocessor macros) but they are not nutrient-free syntactic > sugar. [...] > or * there as repeating yourself. And, IMHO, presence of references > in the language makes understanding somebody else's code > significantly harder. That's strange, are you sure you mean the same DRY ("Don't repeat yourself")? Because with pointers you need to consider and repeat the fact that you are calling via a pointer at each call site, with references this is not so. I agree the code might be hard to understand if references or pointers are abused for implementing "output parameters". But thankfully, C++ has perfectly fine ways to return multiple values from the function, so there is no need to abuse pointers or references for that purpose. And for normal input parameters references (const or rvalue) are just fine and often a much better choice than pointers. Also, if you say presence of references is what makes C++ hard to understand, I start to suspect you haven't seen half of C++ yet. Look up any template code posts from Bonita, for starters ;-) |
| "Öö Tiib" <ootiib@hot.ee>: Nov 19 03:13PM -0800 On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote: > or * there as repeating yourself. And, IMHO, presence of references > in the language makes understanding somebody else's code > significantly harder. Pointer can be null, so everywhere it is passed has to check that it is not null and that gets quite repetitive to do after a while. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 19 03:18PM -0800 On 11/19/2022 3:13 PM, Öö Tiib wrote: >> significantly harder. > Pointer can be null, so everywhere it is passed has to check that it is > not null and that gets quite repetitive to do after a while. Or, a lib writer can say passing a null pointer into function void* foo(void*) will result in undefined behavior. |
| "gdo...@gmail.com" <gdotone@gmail.com>: Nov 19 01:02PM -0800 from C++20 for programmers, a Deitel book ... std::sort( std::execution::par, v2.begin(), v2.end()); // parallel sort ... std::execution::par, is it usable in c++20? |
| "Öö Tiib" <ootiib@hot.ee>: Nov 19 03:09PM -0800 > std::sort( std::execution::par, v2.begin(), v2.end()); // parallel sort > ... > std::execution::par, is it usable in c++20? It is since C++17: <https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag> |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 19 10:42PM On Sun, 2022-11-13, aotto1968 wrote: > struct MqMsgqueCallbackC { > enum MqMsgqueCallbackE { > PC_CallbackF, Unrelated to your question, but: The idea with namespaces is to group names so you don't need common prefixes. Your namespace is ccmqmsgque, so you have already established that the context is "cc", "mq" and "msgque" (whatever those mean). Your struct can then be called CallbackC. The struct is also a namespace, so your enum can just be called E. Or you can come up with a meaningful name, now that it's more obvious that the current name is poor. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 19 02:16PM +0100 On 18 Nov 2022 01:39, T wrote: > wmic won't tell you mirrored status. Only Diskpart. This is now totally off topic, but you're mindlessly repeating your earlier assertion and failing to notice what was written in the posting you responded to. - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 19 12:05PM +0100 Unfortunately lambdas couldn't be recursive without some tricks. #include <Windows.h> #include <TlHelp32.h> #include <iostream> #include <vector> #include <set> #include <algorithm> #include <compare> #include <functional> #include <sstream> #if defined(_MSC_VER) #pragma warning(disable: 6319) // comma-statement with unused return-value 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment