- Virtual functions - 3 Updates
- Variable declaration syntax - 18 Updates
- EXAMPLE - 2 Updates
- Why do we have type& and type* - 1 Update
- recursion in lambda - 1 Update
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 07:31AM -0700 > used the terminology before it was "established by Java" or > "established by C#". About the only other OO languages that were > around when C++ was created were Smalltalk and Simula. For subclass/superclass: IIRC, Simula, and Smalltalk used the terms from Simula. Simula was an explicit precursor to C++. For functor: long established usage in mathematics. Like I said to a friend of mind years ago about C++ "functors": "It acts like a function. Why not just call it a function?" If it's important to distinguish, "stateful function". For signature: in several programming languages, dating back to the 1970s, to mean (roughly) module interface specification. I can almost forgive using "signature" in C++, because it sort of fits with other uses (ie, outside of programming), but now there is the confusion that people misuse "signature" when what they mean is the type of a function. > to the different models that template arguments are supposed to have, > e.g. InputIterator concept requires *i and ++i if i is an instance of > a type that models the InputIterator concept. I don't think so. I have just now reviewed all uses of "concept" (including in larger words like "conceptually") in n4659. In no instance was "concept" used in the sense that it is defined now in the post-C++17 draft. > While we might be able to come up with a better term than concept at > this point, the historical presence in the standard means that using > another term would lead to more confusion than illumination. I think this idea is simply flat out wrong. Up to now no one has been using this feature in their programs (not counting experimental uses, etc). Picking an appropriate term now before the vast majority of developers start using it will reduce confusion in the years to come. > Human languages are messy. They are. All the more reason to not add to the mess by using non-standard terminology or poor word choices. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 09:09AM -0700 > languages, it means a function or operator which can be applied to a > module and which returns a module. In C++ it happens to mean a class > type with a function application operator. That's absolutely fine. A module in ML is roughly analogous to a category in category theory. A functor maps a category to a category, which is like an ML functor mapping a module to a module. It isn't exactly the same, but I think it's close enough so that "functor" makes sense. The C++ usage is way out in left field. > And C++'s use of "signature" to describe how overloading works is also > fine in my view. Again, in other languages it means different things - > in ML it is used to describe the interface of a module. I think the key point is that before C++ it meant roughly the same thing in the other languages that used it. I'm thinking of two, ML being one, Russell being the other. > There is nothing odd in my view about C++'s use of the words "base > class" and "derived class", and they are understood to be > interchangeable with superclass and subclass respectively. I don't think that's true for all people. It's true for people that use C++, but not always for people that don't use C++. Even if all C++ people now understand the two sets of terms to be interchangeable (and I'm not sure even that is true), it is still the case that non-standard terminology was introduced when it didn't need to be. > And I think > "concept" is fine for describing C++'s brand of type classes. I find it hard to take this remark seriously. The word "concept" means idea, thought, or notion. What is defined in the latest draft C++ standard as "concept" is not an idea, thought, or notion. It might be called a property set, a requirements specification, a feature set, a template interface, template pre-requisites, a meta-template, template constraints, or any number of other terms, all of which are more apt than "concept". > first lot together as static (compile-time) polymorphism and the last > as dynamic (run-time) polymorphism seems to me to be fine, since that is > how C++ works. Overloading provides what is usually called ad-hoc polymorphism in the general programming language community. Templates provide what might be called "expansion polymorphism" or "generative polymorphism", where information at the invocation site is used to generate a specific instance of single general definition of a class or function. Virtual functions provide what the general programming language community just calls polymorphism. (Subtype polymorphism is a special case of polymorphism.) Nothing in C++ provides parametric polymorphism. Nothing can, because the type space in C++ is not rich enough. If for some reason someone wanted to lump the first two together and call them "build-time polymorphism", that's probably reasonable. It's a little bit misleading, because ad-hoc polymorphism and generative polymorphism are fairly different in character, and lumping the two under a single term confuses that. Still, I could live with that (and I won't quibble about the difference between "static" and "build-time" as adjectives). But "dynamic polymorphism" is a gratuitous introduction of a new term where none is needed, because there was already a perfectly good term in use with the desired meaning. Moreover the new term is a little bit linguistically dishonest, implying that the two kinds are just special cases of a more general "polymorphism". That's not right. Code that uses, eg, virtual function calls, is truly polymorphic: what executes in the program can operate on more than one form of data. Build-time polymorphic code is not really polymorphic at all. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 12 06:52PM +0100 On Thu, 12 Apr 2018 09:09:35 -0700 > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes: [snip] > an ML functor mapping a module to a module. It isn't exactly the > same, but I think it's close enough so that "functor" makes > sense. The C++ usage is way out in left field. I am not going to reply to all of your email which was considerably discursive. I shall restrict myself to the bits I particularly disagree with. And it is a real stretch to say modules in ML are roughly analogous to a category, and by analogy that ML functors are roughly analogous to functors in category theory in a way which is violated by C++'s usage of the term. ML functors are not necessarily morphisms. MLs basically consist of two languages, one of which operates on modules and one on values. Functors are what operate on modules. And if a module is so analogous, then so is an object in C++. A functor in C++ maps from an object to the return value of the functor. (The object of which of the functor is a member is in effect the first or only argument of the function represented by the functor.) On this analogy, there is a close relationship between C++ functors and ML functors. A ML module is just a collection ("struct") of types and values. First class modules are objects on steroids. In fact every function in C++ is a mapping from some kind of type to another (assuming you take 'void' to be a unit type). That's what functions do. They may of course have side effects also in most languages, including in ML and C++. A functor in ML can have a side effect, albeit that is unusual: it can construct its output module for example by taking a value from stdin. [snip] > specification, a feature set, a template interface, template > pre-requisites, a meta-template, template constraints, or any > number of other terms, all of which are more apt than "concept". I think you had better begin to take is seriously, because it is what they are going to be called. A concept in C++ is a collection of behaviours or traits comprising at its simplest descriptions such as "Comparable" or "Movable". Concept is fine as a label for that, in my opinion. > Virtual functions provide what the general programming language > community just calls polymorphism. (Subtype polymorphism is > a special case of polymorphism.) Since you appear to know something about functional languages this statement is astonishing. Virtual functions are not what the general programming language community calls polymorphism. They are what Java, C# and some poorly informed C++ programmers call polymorphism. In fact, by saying that "subtype polymorphism is a _special case_ of polymorphism" (my emphasis), you are implicitly agreeing with me and contradicting yourself. Virtual functions implement subtype polymorphism in C++. > Nothing in C++ provides parametric polymorphism. Nothing can, > because the type space in C++ is not rich enough. I didn't say function templates provide parametric polymorphism. I said they perform the role of parametric polymorphism: they provide type inference on the template arguments. It is as close as C++ gets to it. > "dynamic polymorphism" is a gratuitous introduction of a new term > where none is needed, because there was already a perfectly good > term in use with the desired meaning. The word "dynamic" is well established in C++. We have had dynamic_cast since 1998 for example in exactly the same context. > polymorphic: what executes in the program can operate on more > than one form of data. Build-time polymorphic code is not really > polymorphic at all. I completely disagree. I also have the feeling that this discussion is becoming more or less futile because arguing about semantics quickly becomes pointless. In summary, your starting argument was that C++ chooses its terms more poorly than other programming languages. I disagree. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 11 01:05AM -0700 On 4/9/2018 5:51 PM, Rick C. Hodgin wrote: > When the product is > released you'll be able to download it, source code and all, and > examine it fully. Well, that is nice. Btw, would you consider being able to download it a form of "get it out there."? |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 12:39PM +0100 > On 11/04/18 00:22, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 10/04/18 16:29, Ben Bacarisse wrote: <snip> >> * placed as far away as possible from the declarator. > I actually write "char * x;" in my code. But again, preferences > differ. Yes, I got that from the previous message. I was talking about what you said about char* x; specifically -- that it puts the emphasis in the right place. That surprised me because it does exactly the opposite for me so I was curious to know a bit more. But maybe it's just down to habit. If you are used to seeing and writing the star in one place, that's where you will look for "pointerness". When I see a bare " x ", my first thought is of an un-decorated declarator. <snip> >> you saying that that carries less weight for you in declarations? > No - I just disagree a little on what is "fighting the syntax" in > declarations. I don't understand this, but I appreciate that you may think there is nothing more you can say to help me understand. -- Ben. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 11 03:37PM +0100 On 11/04/2018 15:10, bartc wrote: > x,y' or adds ",y" onto "int* x". > The '*' can naturally be associated with either the 'int' or the 'x'. > This is the problem. Why are we still discussing this? ONE DECLARATION PER LINE. /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." |
| David Brown <david.brown@hesbynett.no>: Apr 12 11:33AM +0200 On 11/04/18 18:12, Rick C. Hodgin wrote: > Agreed that it's not a necessity. It is an extension, and a feature. > Nobody has to use it. It will work just fine without spaces. It's > just another tool in the toolbox. You say that about many of your features that are of questionable value. From one viewpoint, it is entirely true - when someone is writing code, if they don't like identifiers with spaces, then they simply don't have to use spaces in their identifiers. The same applies to alternative syntaxes for pointers, and all your other bits and pieces that many have advised against. However, there is another viewpoint that you seem to be missing here. People rarely code in isolation. Programmers have to deal with other people's code - either for modifying it, or using it (like a library). So if I say that I hate the idea of white space in identifiers, I would never use it, on the editors I use char 255 would show as ÿ or muck up the UTF-8 encoding - that's okay for code /I/ write. But if I have to make changes to a file written by someone else who likes these identifiers, I am scuppered. If I want to use a library that exports functions like "Draw a big circle()", I am lost. Support for things like this affects /everyone/ using the language - not just people who /want/ to use it. People always have to deal with code written in a way they don't like. But there is a big difference between working with code that is written in a different way that you would choose yourself, and code that you simply cannot work with using the tools you want. If you are going to allow such a feature, then it would have to be something of /huge/ benefit, but where its use would be rare and restricted. (Inline assembly would be an example of such a feature in C and C++ compilers.) This particular feature - allowing white spaces in identifiers - is guaranteed to cause confusion. And the way you implement it - with a non-standard use of a non-standard character 255 - is perhaps the worst imaginable choice, and conflicts with /every/ existing editor, viewer, character set, character encoding, etc. This is a huge cost, for a totally non-existent benefit - it gives no advantages whatsoever over the completely standard underline "_" space symbol. (C has opened itself to a related situation with its "extended identifiers". I can use "Draw…a…big…circle" in clang, and I can easily type that in Linux - but I can't use it in gcc or most other C or C++ compilers, I can't show it in half the editors on Windows, and I can't type it on Windows.) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 04:19AM -0700 On Thursday, April 12, 2018 at 5:34:16 AM UTC-4, David Brown wrote: > You say that about many of your features that are of questionable value. There's a loaded statement. Reminds me of: "Do you still beat your wife?" I'm not interested in your personal input or guidance on my projects, David. You have vastly different viewpoints and goals than I do. I accept that, but I do not want your input or advice because I believe there are things that need to be changed or extended about C/C++ to make it a better long-term language. I'm proceeding along those lines. Time and a consensus among many will prove out if I am right or not when the product is completed and available for testing. -- Rick C. Hodgin |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 04:49AM -0700 > But maybe its just down to habit. If you are used to seeing and > writing the star in one place, that's where you will look for > "pointerness". [...] For what it's worth I believe it is not all just habit. Incidentally I share your reactions to the various "grating" examples given. But it isn't because I share those reactions that I say it isn't all just habit. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 04:50AM -0700 >> The '*' can naturally be associated with either the 'int' or the >> x'. This is the problem. > Why are we still discussing this? ONE DECLARATION PER LINE. A foolish consistency is the hobgoblin of little minds. |
| David Brown <david.brown@hesbynett.no>: Apr 12 02:12PM +0200 On 12/04/18 13:19, Rick C. Hodgin wrote: > On Thursday, April 12, 2018 at 5:34:16 AM UTC-4, David Brown wrote: >> You say that about many of your features that are of questionable value. > There's a loaded statement. Reminds me of: "Do you still beat your wife?" No, it is not. Many of the features you suggest for CAlive /are/ of questionable value - as shown by the number of people in newsgroups who have questioned them. It does not mean they would not be suitable for your programming language - it merely means that people do not agree with you that they are a good idea. And it is also correct that you say that "people can choose to use them or not" for these sorts of features. > I'm not interested in your personal input or guidance on my projects, > David. You have vastly different viewpoints and goals than I do. We do have different viewpoints on many things, including what would be good features in a programming language. That's fine - if we agreed on everything, there would be no discussion and I could not give any useful advice or alternative viewpoints. I have no goals of any sort regarding CAlive - it is your concept, your project, your challenge. It will never be of use or interest to me, no matter how complete and successful it may be - I work on a different kind of programming. The extent of my goals here is the same as for anyone else - you post ideas and suggestions in public, I give opinions and advice about them in public. You are entirely free to take that advice or ignore it, or to discuss more. > accept that, but I do not want your input or advice because I believe > there are things that need to be changed or extended about C/C++ to > make it a better long-term language. I'm proceeding along those lines. Please stop suggesting you are trying to change or extend C or C++. You are not. You are trying to develop a new language and a new set of tools to /replace/ these existing languages. And that is /fine/ - I have no problem with that. But don't pretend you are changing C or C++ - that is not what you are doing, it would not get you where you want to go, and it would not be realistic anyway. You tried to change C, and were rejected - you have moved on from that into creating your own language to replace C and C++. And I am not trying to stop you writing your language, or your tools. I just give advice and commentary on whether I think your proposed features are a good idea, or how you might make them better. Note that there are huge differences between what I think would be useful changes or extensions to C (or C++), and what I think would be good features in a /new/ language. A proposed feature might be a marvellous idea for a new language and yet insanity as a change to C. > Time and a consensus among many will prove out if I am right or not > when the product is completed and available for testing. It is no secret that I think your CAlive project (indeed, all your projects) is unrealistic and nothing concrete will come of it, but that does not stop me being willing to offer honest technical advice. Look elsewhere for moral support and motivation, but I am happy to discuss technical issues. These are the same regardless of your goals or the purpose of your work. |
| David Brown <david.brown@hesbynett.no>: Apr 12 02:33PM +0200 On 12/04/18 13:50, Tim Rentsch wrote: >>> x'. This is the problem. >> Why are we still discussing this? ONE DECLARATION PER LINE. > A foolish consistency is the hobgoblin of little minds. That is a straw man argument, unless you can demonstrate why one declaration per line is foolish. It has been clear from this thread that one declaration per line has its advantages in code clarity. There have also been examples of multiple declarations in a single line that had good reasoning - but not that it was an improvement over two neighbouring lines. If you want to argue against a "one declaration per line" rule, then you need to say when putting multiple declarations would be /better/ in some clear way than having them on adjacent separate lines. (I think such cases do exist - the great majority of my declarations are one per line, but I have exceptions.) Examples would be a lot more helpful than giving a quotation as though its familiarity made it a law. |
| bartc <bc@freeuk.com>: Apr 12 01:55PM +0100 On 12/04/2018 13:33, David Brown wrote: > cases do exist - the great majority of my declarations are one per line, > but I have exceptions.) Examples would be a lot more helpful than > giving a quotation as though its familiarity made it a law. My C code generator does exactly that, write one declaration per line. But often it doesn't look right and I have to tweak it if it's code I want to post. Example: int64 x; int64 y; int64 z; I'm sure it wouldn't faze anyone if that first line was written as: int64 x,y,z; Since x,y,z are clearly related and need to be of the same type, it makes sense to write the type just once. But also, since many people including Tim advocate making functions as short as possible (median length 14 lines in his case, as posted on c.l.c), then half a dozen local variables is going to take up half of that if they each need their own line. Another problem is when the type declaration is elaborate (especially in C++), so having to repeat it on multiple lines is more work and extra effort in maintaining. Unless you adopt this scheme: T a, b, c; (And some might even put T on its own line, putting extra pressure on the function length.) But here you get the 'int* a,b,c;' problem all over again. This poor syntax decision is at the root of it. -- bartc |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 02:05PM +0100 On 12/04/2018 12:50, Tim Rentsch wrote: >>> x'. This is the problem. >> Why are we still discussing this? ONE DECLARATION PER LINE. > A foolish consistency is the hobgoblin of little minds. What consistency? Consistently using multiple declarations per line with the problems that has (as evidenced by this discussion thread) rather than using a single declaration per line which has no problems? Fucktard. /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." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 02:11PM +0100 On 12/04/2018 13:55, bartc wrote: > int64 x,y,z; > Since x,y,z are clearly related and need to be of the same type, it > makes sense to write the type just once. You are asserting that is makes sense. This is a subjective style issue. > short as possible (median length 14 lines in his case, as posted on > c.l.c), then half a dozen local variables is going to take up half of > that if they each need their own line. A rule which limits a function's length to an arbitrary line count is fucktarded at worst and egregious at best. Line count is orthogonal to cyclomatic complexity which is a much more important metric. Yes functional decomposition is very important but there is no magic LOC number past which a function becomes "too big". > the function length.) > But here you get the 'int* a,b,c;' problem all over again. This poor > syntax decision is at the root of it. typedef/using can help with that. /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." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 06:20AM -0700 On Thursday, April 12, 2018 at 8:13:02 AM UTC-4, David Brown wrote: > No, it is not. Many of the features you suggest for CAlive /are/ of > questionable value - as shown by the number of people in newsgroups who > have questioned them. The people here are C++ developers who have never had this ability. To them it is hogwash. But CAlive is one component of the target languages intended for the underlying RDC tool. It is my goal to get RDC sufficiently developed to then be able to create databases for CAlive, Java, C#, and other languages, without changing or extending RDC, but simply creating a new database which describes how to compile those other languages. My goals in RDC are to expose a wide range of abilities. One of them is spaces in token names. That naturally flows through to CAlive, and all other languages. But, as I say, nobody has to use that feature. It is just another tool in the toolbox for those who, unlike yourself and others here, find value in it. You really like to argue, don't you? I don't. I'm done with this conversation. This is the way CAlive is, and that's that. -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Apr 12 03:22PM +0200 On 12/04/18 14:55, bartc wrote: > int64 x; > int64 y; > int64 z; For a code generator, it typically doesn't matter if you have all on one line or all on separate lines. The C compiler doesn't care - this is about how humans read or write code. If you expect people to read your generated code then you must pay attention - most generated C code is illegible to people. > I'm sure it wouldn't faze anyone if that first line was written as: > int64 x,y,z; No, indeed. Anyone who can read C, can understand that. (Though most would prefer a standard C type here, and some of us insist on having spaces.) But is there any real improvement on writing it that way? I don't consider "saving a few keystrokes" as an improvement - but showing a close relationship might be, and avoiding unnecessarily loose and wordy code can make the code easier to read. Note, however, that you rarely need to define variables like that in C (especially C99 onwards) and C++. (Generated code may be different.) Usually you only declare your variables when you are ready to use them, and that means when you have a value to put in them. It is not /always/ the case, but it is very common - especially in C++. So is it better to write: int64_t x = 1000; int64_t y = MAX_NO_OF_THINGS; int64_t z = 0; or int64_t x = 1000, y = MAX_NO_OF_THINGS, z = 0; ? > short as possible (median length 14 lines in his case, as posted on > c.l.c), then half a dozen local variables is going to take up half of > that if they each need their own line. First, I don't think anyone suggests making functions as short as possible - keeping them as short as practical and clear is a better description. Second, short functions generally have few local variables. The length of the code and the number of variables needed are not unrelated. > T a, > b, > c; I don't think anyone would advocate that. > (And some might even put T on its own line, putting extra pressure on > the function length.) If type declarations are complicated, used "typedef" (or "using" in modern C++) to make the code clearer and easier to maintain. For C++, "auto" can be useful for particularly hairy types. |
| bartc <bc@freeuk.com>: Apr 12 02:30PM +0100 On 12/04/2018 14:11, Mr Flibble wrote: >> Since x,y,z are clearly related and need to be of the same type, it >> makes sense to write the type just once. > You are asserting that is makes sense. This is a subjective style issue. Unnecessarily repeating the same thing in source code is what programming languages are supposed to help you avoid. (And partly why they have functions and loops.) The 'T x,y,z' also tells you that x, y and z are probably related, which is not so clear if declared independently. If x and y have the same type, is that coincidence, or are they supposed to? And this I find annoying: void fn(int a, int b, int c, int d) {} as there is no way to write the 'int' just once, for example: void fn(int a, b, c, d) {} >> But here you get the 'int* a,b,c;' problem all over again. This poor >> syntax decision is at the root of it. > typedef/using can help with that. You'd use something like 'typedef int *Intptr;' ? You don't often see that. And when you do, everyone will use a different name for 'Intptr'. (And a different type name has to be invented for each kind of pointer.) It really doesn't help. This syntax however would: *int a,b,c; // declare three pointers (Although it would need something to avoid clashes with expressions that start with "*".) -- bartc |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 02:44PM +0100 On 12/04/2018 14:30, bartc wrote: > void fn(int a, int b, int c, int d) {} > as there is no way to write the 'int' just once, for example: > void fn(int a, b, c, d) {} Now I have to look to the left to work out what type 'd' is rather than seeing it straight away as 'int d'. Sorry but IMO your idea is more annoying not less. >>> syntax decision is at the root of it. >> typedef/using can help with that. > You'd use something like 'typedef int *Intptr;' ? No because I wouldn't class 'int *' as an "elaborate" type as you put it. When I introduce a typedef alias it usually has a name that has a domain/business logic specific meaning to enhance the self documenting nature of my code; "Intptr" doesn't add any value at all in fact it substracts value as it has more characters to type and grok. > You don't often see that. And when you do, everyone will use a different > name for 'Intptr'. (And a different type name has to be invented for > each kind of pointer.) That is what I do: I use typedef A LOT to introduce sensibly named aliases for simple types. > *int a,b,c; // declare three pointers > (Although it would need something to avoid clashes with expressions that > start with "*".) My idea of using one declaration per line works NOW i.e. doesn't require a change to the core language. /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." |
| bartc <bc@freeuk.com>: Apr 12 05:23PM +0100 On 12/04/2018 14:44, Mr Flibble wrote: > Now I have to look to the left to work out what type 'd' is rather than > seeing it straight away as 'int d'. Sorry but IMO your idea is more > annoying not less. OK, so you would outlaw the use of a comma in many situations because you have to scan all the way to the left (or to the top) to find out the context: ... a, b, c .... might be: - Part of a set of enum names - Part of an argument list for a function or macro - Part of a comma-expression - Part of the initialisation data for an array or struct - Part of a parameter list (with names) when a,b,c are types - Part of a sequence of declared variable names - Etc (no doubt C++ provides more possibilities) Sorry, your objection doesn't stand up. >> invented for each kind of pointer.) > That is what I do: I use typedef A LOT to introduce sensibly named > aliases for simple types. (And that's what drives me round the bend trying to decipher other people's code because you have to go and track down all these aliases. And eventually you find it's just a 'short'. Why not just say so in the first place?) >> that start with "*".) > My idea of using one declaration per line works NOW i.e. doesn't require > a change to the core language. It is just avoiding the problem in a way that is unsatisfactory. -- bartc |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 05:49PM +0100 On 12/04/2018 17:23, bartc wrote: > - Part of a sequence of declared variable names > - Etc (no doubt C++ provides more possibilities) > Sorry, your objection doesn't stand up. Your assertion is false. > people's code because you have to go and track down all these aliases. > And eventually you find it's just a 'short'. Why not just say so in the > first place?) Most of the time you don't care what the underlying type is which is the whole point; what you do care about is what the variable MEANS: "short" is meaningless. >> My idea of using one declaration per line works NOW i.e. doesn't >> require a change to the core language. > It is just avoiding the problem in a way that is unsatisfactory. Another false assertion. /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." |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 04:05AM -0700 > function. > But chances are that author actually needs to improve his refactoring > skills. And what may be more important, initial composition skills. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 04:31AM -0700 > I not agree... Some function has to be big: It's hard to disagree with that, but the question is which functions, and how big? I don't remember seeing any function longer than 100 lines that couldn't be improved by rewriting it as several smaller functions. > as some printf like function, Implementing printf easily decomposes into a cluster of relatively small functions (which at a guess are 20 to 40 lines each, with floating-point perhaps twice that). > or the big num division function A straightforward multiple-precision integer division function can easily be written in a single relatively short function. A more sophisticated multiple-precision division function will naturally divide into different strategies depending on sizes of the inputs, which already gives a decomposition into more than one function. Furthermore the more elaborate subcases will need to make use of multiple-precision multiplication, which leads to further subdivision, and recursion, for the different regimes of fast multiplication algorithms. So neither of these examples seems compelling as a case where any really big functions are needed (arbitrarily defining "really big" as more than 100 lines). |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 12 04:02AM -0700 > const pointers. C++ retains pointers both for backwards > compatibility with C, and because its possible for a pointer to be > null, [...] And because pointers are mutable. |
| Ben Bacarisse <ben.lists@bsb.me.uk>: Apr 04 12:03AM +0100 > }; > but I get some errors. So can I use lambda and recursion? I use visual > studio 2015. The trouble is you are trying to use expand before it's type can be deduced. One solution would be to avoid using auto. To do this you pretty much have to use std::function because lambdas that have a capture are not convertible to function pointers. To take a simpler example: std::function<int(int)> f = [&f](int n) { return n < 1 ? 1 : n * f(n-1); }; If the lambda has no capture, f could be a pointer to function object, but then you could not refer to f in the body. There are some tricks you can play that simulate the effect of a Y combinator, but these appeal to me simply on academic grounds. For example I enjoyed the fact that this works with gcc: auto f = [](int n, auto g){ if (n < 1) return 1; else return n * g(n-1, g); }; where the call now becomes f(5, f); However, switching back to the big picture, if expand is the only thing captured, why not write a named function to do this? -- Ben. |
| 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