- Shorthand ~> pointers - 22 Updates
- Shorthand ~~ pointers - 3 Updates
| nobody@example.org (Scott): Dec 21 01:14AM On Wed, 19 Dec 2018 21:31:34 -0500, "Rick C. Hodgin" >I've had the idea to introduce the ~> symbol for shorthand pointers. It's a bad idea. I had to go back and remind myself why, and it's for much the same reason that Pascal's "with" keyword turned out to be a bad idea. It brings ambiguity, hides scoping issues, makes code easier to write at the expense of being harder to read. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 21 03:23AM +0100 On 21.12.2018 02:14, Scott wrote: > much the same reason that Pascal's "with" keyword turned out to be a > bad idea. It brings ambiguity, hides scoping issues, makes code easier > to write at the expense of being harder to read. Well, I liked Pascal's `with`, but not the one in Visual Basic 6.x. One can have roughly the Pascal functionality in C++ by defining #define WITH( ... ) if( auto&& _ = __VA_ARGS__; true or !!&_ ) #define ITEMS( c ) std::begin( *&c ), std::end( c ) Then one can write e.g. using To = ostream_iterator<char>; WITH( to_string( 3.14 ) ) { copy( ITEMS( _ ), To( cout, " " ) ); } cout << endl; There `true or` effectively disables a sillywarning from g++, warning that it understands that `!!&_` will always be true. There is however a corresponding sillywarning from Visual C++, number 4127, that it's best to just disable. I don't think there's any good code workaround. Cheers!, - Alf |
| nobody@example.org (Scott): Dec 21 09:45AM On Fri, 21 Dec 2018 03:23:34 +0100, "Alf P. Steinbach" >One can have roughly the Pascal functionality in C++ by defining > #define WITH( ... ) if( auto&& _ = __VA_ARGS__; true or !!&_ ) > #define ITEMS( c ) std::begin( *&c ), std::end( c ) Ah, my fault, I meant to trim headers back to CLC only. C++ as it exists today seems only loosely related to the C++ I learned 20 years ago, and it's not really on my short list. > using To = ostream_iterator<char>; > WITH( to_string( 3.14 ) ) { copy( ITEMS( _ ), To( cout, " " ) ); } > cout << endl; Hey, do you remember that time when I said something is a bad idea if it makes code easier to write at the expense of being harder to read? |
| David Brown <david.brown@hesbynett.no>: Dec 21 12:05PM +0100 On 21/12/18 10:45, Scott wrote: >> cout << endl; > Hey, do you remember that time when I said something is a bad idea if > it makes code easier to write at the expense of being harder to read? What if it makes code harder to read /and/ harder to write? Surely that restores the balance? (To be fair, Alf said you /could/ do this - not that you /should/ do it.) |
| Juha Nieminen <nospam@thanks.invalid>: Dec 21 11:36AM > Uniqueness of the member might not be enough. There might be multiple > paths to that unique member Another problem is that a member may become non-unique in the future, breaking all code that uses the shortcut syntax. Suppose there are thousands of instances of accessing a member using the shortcut syntax, and then you simply add a new member object to the struct/class which happens to introduce an ambiguity. Suddenly those thousands of lines of code just broke, and need to be fixed, even though nothing that already existed in the struct/class was changed, only a new member object was added. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 07:57AM -0500 On 12/20/2018 8:14 PM, Scott wrote: > much the same reason that Pascal's "with" keyword turned out to be a > bad idea. It brings ambiguity, hides scoping issues, makes code easier > to write at the expense of being harder to read. I'm not sure what that syntax is or does. The purpose of the ~> (now renamed ~~) is to indicate there are intermediate members that are not typed out, but are there. The editor would be able to expand them for you when needed, either visibly on the line, or logically as a tooltip popup or some other information displayed nearby. It's not for all types of code. But there are types of code it would be desirable. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 08:05AM -0500 On 12/21/2018 6:36 AM, Juha Nieminen wrote: >> paths to that unique member > Another problem is that a member may become non-unique in the future, > breaking all code that uses the shortcut syntax. Two things: #1 -- The developer making that change would know it immediately, and likely then pick another name, or #2 the ability would be introduced to allow automatic refactoring of any instances of the ~~ use, so that you are no longer only a typist, you are now part of a system that knows the software, and is able to refactor things for you intelligently. Our toolsets must grow up and be more than piecemeal. They need to be integrated so that you're in a system, not just a functional com- ponent of a system. > those thousands of lines of code just broke, and need to be fixed, > even though nothing that already existed in the struct/class was > changed, only a new member object was added. Use a different name for the new name collision (problem solved), or use the built-in refactoring tools to expand out all instances of the collision name so that they are unique (problem solved). You must not be limited in your thinking by what we have today, but you must expand your thinking to address problems by solving even the deeper issues that are there. I've used this example before. You approach a 1700s farmer and tell him about how you can make his life easier. He says, "How?" You say, you'll need about 1500 lbs of refined metal, a hundred pounds of the finest safety glass, specialized rubber materials, specialized alloys for various parts (like pistons, rings, bearings), and you'll need a large factory to manufacture all of this stuff with hundreds, maybe thousands of workers on an assembly line and when it's finished, you need gallons and gallons of refined fuel brought up from oil thou- sands of feet down in the ground ... and he looks at you like you're insane. But very few people would state that a pickup truck has less utility than a horse and wagon for most tasks. The horse may be be better for going into the woods, but the truck is better for nearly every other task. You must get past your horse. You must seek to build the full infra- structure we need, and proceed with your vision there. You can't just move piecemeal in bits over time. A vision has to be brought forth, pursued, with effort put into the long-range vision. It's a type of terraforming the computer landscape. The disparate vistas of varying inhospitable climates seen today... they need to be colon- ized, populated, roads need to be built between various areas, and so on. It must be made livable, and even beautiful, for the long term. -- Rick C. Hodgin |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 02:56PM >> breaking all code that uses the shortcut syntax. >Two things: #1 -- The developer making that change would know it >immediately, and likely then pick another name, No, the developer is likely to discard the stupid compiler and use one that doesn't fuck up his perfectly good program. Especially when recompiling a 20 year old source base. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 02:57PM >Our toolsets must grow up and be more than piecemeal. They need to >be integrated so that you're in a system, not just a functional com- >ponent of a system. This is so wrong that it's hard to decide where to begin. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 10:03AM -0500 On 12/21/2018 9:56 AM, Scott Lurndal wrote: > No, the developer is likely to discard the stupid compiler and > use one that doesn't .. his perfectly good program. Especially > when recompiling a 20 year old source base. How many of those 20 year old source code bases used the new ~~ syntax, Scott? -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 10:20AM -0500 On 12/21/2018 9:57 AM, Scott Lurndal wrote: >> be integrated so that you're in a system, not just a functional com- >> ponent of a system. > This is so wrong that it's hard to decide where to begin. Man's cities used to be isolated requiring each person to make a long journey to get from there to here to have communication with other places. Then the telegraph and steam locomotive were invented. And then the telephone and automobile were invented. Now we have the jet airplanes and the Internet and our communications and mobility is un- precedented in this world. And it is only growing more and more each day. Future programs show full-size rooms where doctors on one conti- nent communicate with doctors on another, showing a type of hologram of the patient from the digital scan data. Collaboration across the world! In the beginning we had isolated computer systems. People had to carry tapes or disks from one place to another to install new soft- ware. Then they began to locally network and copy things. Then we began to have wide networking. Today we are all interconnected and our individual CPUs are multi-core machines with more memory and hard disk capacity than many highest-end servers of the 1990s. Our software needs to grow into integrated systems, all working toge- ther, but presented to people in a type of flexible, dynamic, yet easy access UI, with those functions related to their operation being inside and aware of the other functions inside as well, integrating into a smooth experience for the user, one that's reliable, consistent. The base design of object-orientation allows for this, as each thing added is extensible, and adds to the other things already in existence. It's also time for our compiler systems begin communicating with the things they're a part of, to be aware of the CPUs they target, and to be powerful tools working for developers in developer mode, and for optimized code when not in developer mode, and to provide interfaces making it easier for developers to do their work, to essentially be moving forward just like all things do and must do as time marches on. It's a natural evolution for all things. And those big old dinosaurs that used to roam the Earth ... where are they now, Scott? Modern science teaches that they couldn't adapt, so they became extinct. And those tremendous buggy whip manufacturers when the automobile came along ... where are they now? Are you able to adapt, Scott? Or is casting stones at new ideas more your forte? -- Rick C. Hodgin |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 03:35PM >> when recompiling a 20 year old source base. >How many of those 20 year old source code bases used the new ~~ syntax, >Scott? You, of course, know that "syntax" is completely unrelated to the point about duplicate structure tags, which is the issue with any legacy code base being compiled with your proposed language change. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 03:37PM >>> be integrated so that you're in a system, not just a functional com- >>> ponent of a system. >> This is so wrong that it's hard to decide where to begin. Paragraphs of irrelevent attempts to draw parallels to reality elided. >Are you able to adapt, Scott? Or is casting stones at new ideas more >your forte? I adapt every day; that's what life is, adapting to change. Not all change is good, including your proposed structure tag access change to the C language. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 10:41AM -0500 On 12/21/2018 10:35 AM, Scott Lurndal wrote: > You, of course, know that "syntax" is completely unrelated to the > point about duplicate structure tags, which is the issue with any legacy > code base being compiled with your proposed language change. The same happens if you try and refactor something today. There's al- ways the possibility of breaking existing code. The art of being good at it comes from being able to integrate refactoring changes without breaking existing code. That seamless integration requires a mastery of understanding and coding ability. It's not often seen to be honest. Regardless, it's not a concern for me. I do not expect any existing C/C++ stalwart to ever seek to use my software. I think it will be for a new type of developer, a new way of thinking, a new philosophy of computer use. I expect a new ecosystem to rise that didn't exist previously, and only there will CAlive be successful. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 10:42AM -0500 On 12/21/2018 10:37 AM, Scott Lurndal wrote: > I adapt every day; that's what life is, adapting to change. > Not all change is good, including your proposed > structure tag access change to the C language. Don't use it then. It's an extension to the language, not a requirement. And it's not even a requirement that you use my language when/if it's released. You're fighting an idea presently, Scott. While I respect your right to have your position, I do think your position is wrong. I think your judgment is clouded by personal issues. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 21 03:41PM On 21/12/2018 15:41, Rick C. Hodgin wrote: > I expect a new ecosystem to rise that didn't exist > previously, and only there will CAlive be successful. Quite delusional. /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." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 21 03:42PM On 21/12/2018 15:42, Rick C. Hodgin wrote: > You're fighting an idea presently, Scott. While I respect your right > to have your position, I do think your position is wrong. I think your > judgment is clouded by personal issues. 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." |
| David Brown <david.brown@hesbynett.no>: Dec 21 05:39PM +0100 On 21/12/18 16:42, Rick C. Hodgin wrote: > Don't use it then. It's an extension to the language, not a requirement. > And it's not even a requirement that you use my language when/if it's > released. I don't think Scott is saying he would not want to use the feature - I think that is so obvious it does not need to be put down in words. He is advising /you/ not to include the feature in your own language, never mind attempt to add it as an extension to C and/or C++. > You're fighting an idea presently, Scott. While I respect your right > to have your position, I do think your position is wrong. I think your > judgment is clouded by personal issues. No, Scott (and others) have given good technical reasons to dislike your suggestion. It is /you/ whose judgement seems to be entirely a matter of personal issues. We see the pattern again and again: 1. Rick suggests a new idea. 2. People say why they think it is unnecessary, how the problem could better be solved with existing language constructs, and how the feature would conflict with existing software or tools. 3. Rick declares it to be the best idea since sliced bread, and that it will revolutionise programming. 4. People say they advise against it, and give more helpful technical reasoning and suggestions. 5. Rick bemoans the imaginary hatred and negativity, while taking it as proof that the idea is brilliant. 6. People try to convince Rick that their objections are technical, not personal. 7. Rick insults people, declaring them haters, blind, unable to adapt, possessed by the devil, etc. This is backed by references to science fiction programs and/or rabid TV evangelists. 8. People start complaining about the off-topic posting and wondering why anybody ever responds to Rick. Many of those who responded wonder that too - but can't resist the temptation to do so again in the future. 9. Rick leaves the group in a huff, declaring that he will change the world alone. We all know he'll be back. I think these threads can start off quite interesting and lead to some entertaining or informative discussions for a while. But we are now in stage 7 - maybe it is possible to skip the later stages. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 05:04PM >> point about duplicate structure tags, which is the issue with any legacy >> code base being compiled with your proposed language change. >The same happens if you try and refactor something today. refactoring != recompiling |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 05:05PM >Don't use it then. It's an extension to the language, not a requirement. >And it's not even a requirement that you use my language when/if it's >released. But it causes any code I write with the compiler to not be future proof, so I can't use the language for that reason alone. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 12:23PM -0500 On 12/21/2018 12:04 PM, Scott Lurndal wrote: >>> code base being compiled with your proposed language change. >> The same happens if you try and refactor something today. > refactoring != recompiling You're right. You could refactor and then leave the source code in that state without recompiling. What a time saver that would be. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 12:24PM -0500 On 12/21/2018 12:05 PM, Scott Lurndal wrote: >> released. > But it causes any code I write with the compiler to not > be future proof, so I can't use the language for that reason alone. Don't use it then. You won't hurt my feelings. -- Rick C. Hodgin |
| Richard Damon <Richard@Damon-Family.org>: Dec 21 06:38AM -0500 On 12/20/18 2:08 PM, Rick C. Hodgin wrote: > Even though it might use the same ~~ symbol, it's used differently, like > the way << and >> are used in C++ differently than when they're used as > i = j << 2; A completely different meaning from cout << 2; But cout << 2 is NOT different than i = j << 2, both become effectively calls to operator<<() (the latter case to the implicitly definded fundamental version for built in types, just like all the other operator functions). The fact that count << 2 doesn't act like a shift is just a matter of library definition, and not a core language issue (just like making list += element be an append operation). |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 21 08:09AM -0500 On 12/21/2018 6:38 AM, Richard Damon wrote: > calls to operator<<() (the latter case to the implicitly definded > fundamental version for built in types, just like all the other operator > functions). I would be surprised to learn that cout << 2 and j << 2 call the same operator() function. If they do, I view that as a fundamental flaw in the language. > The fact that count << 2 doesn't act like a shift is just a > matter of library definition, and not a core language issue (just like > making list += element be an append operation). It's more or less the same in CAlive. CAlive identifies the template usage of the token at compile-time. It calls the appropriate internal handler at that time, which then emits whatever is required for the operation. Nonetheless, they remain different. The call for cout << 2 is different than the call for j << 2 in all ways. The fact that the same symbol is used is just a choice made by the C++ designers. CAlive does not support cout or cin, by the way. I think they are inappropriate additions to the base C language, features that should've been handled differently. -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Dec 21 02:31PM +0100 On 21/12/18 14:09, Rick C. Hodgin wrote: > I would be surprised to learn that cout << 2 and j << 2 call the same > operator() function. If they do, I view that as a fundamental flaw in > the language. They do not call the same function - they use the same operator name. The function "operator<<" is overloaded - you have the same name, but different functions depending on the type of the arguments. This is a key feature in C++. It means that you can make, for example, a matrix class - and then write "M1 + M2" just as you would write "x + y". The only different between "cout << 2" and "j << 2" is that the "operator<<" function acting on streams is defined in a library, while the function operating on integers is built into the language. This is a fundamental /strength/ of the C++ language. (Whether or not the streams library is well designed, and whether or not the choice of the << and >> operators is well conceived, is a different matter. Opinions vary on that one.) > operation. > Nonetheless, they remain different. The call for cout << 2 is different > than the call for j << 2 in all ways. The implementation of the functions is different. The syntax and mechanism for calling them is the same (except that for some cases, such as integers, the function is built into the language). > used is just a choice made by the C++ designers. CAlive does not support > cout or cin, by the way. I think they are inappropriate additions to the > base C language, features that should've been handled differently. "cout" and its use of << is not built into the C++ language, it is part of the standard library. |
| 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