- Variable declaration syntax - 22 Updates
- why is "std::string propBulkRow = 0;" legal ? - 3 Updates
bartc <bc@freeuk.com>: Apr 11 11:36AM +0100 On 11/04/2018 09:06, Chris M. Thomasson wrote: > On 4/10/2018 3:01 PM, Rick C. Hodgin wrote: [New 'CAlive' language] > I want to try out some programs in CAlive. As far as I can tell, CAlive is and always will be vapourware. Because it's far too ambitious, and full of crazy ideas that will be found to simply not work (the one proposed in the OP is a mild example) and that nobody else apart from Rick seems to understand the benefits of. Apart from which, it's not just a language, but also a new processor, new operating system, and comprehensive, innovative IDE and debugger. (Not to mention the evangelising which must take a lot of time away from it.) On the other hand, talking about about new language ideas can be useful. (I did once implement a version of one of them.) But I think the project will fail because it's just a mish-mash of C and C++; it's not usefully different enough to be worth creating a new language for. So just use C++ or create some language that is a thin wrapper around C++ and that outputs C++. -- bartc |
bartc <bc@freeuk.com>: Apr 11 12:06PM +0100 On 11/04/2018 07:43, Alf P. Steinbach wrote: > template< class T > using ptr_ = T*; > template< Size n, class T > using raw_array_ = T[n]; > ptr_<raw_array_<10,int>> x; I think this short example illustrates the problems I have with C++, in using language building facilities to emulate some feature that ought really to be built-in. It works, but the result is unsatisfactory. (I would write this declaration elsewhere as: 'ref[10]int x', using built-in syntax.) This is similar to using macros in C to get emulate missing features or different syntax, rather that just adding them to the language. Or classes, decorators or whatever in Python. (Speaking of macros, gcc-C allows this solution: #define pointer(T) typeof(T*) #define array(N,T) typeof(T[N]) pointer(array(10,int)) x; and 'typeof' can also be directly used like this: typeof(int*) p,q,r; declaring three pointers. One neat solution to the OP's problem, which doesn't hide the pointer-ness of the type as a typedef would. But it requires the 'typeof(T)' feature.) -- bartc |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 07:09AM -0400 On 4/11/2018 6:36 AM, bartc wrote: > [New 'CAlive' language] >> I want to try out some programs in CAlive. > As far as I can tell, CAlive is and always will be vapourware. Correct. It has a formal definition, and is in progress, but there is nothing tangible for people to load and run yet, save the individual algorithms for testing. > Because it's far too ambitious, and full of crazy ideas that will be > found to simply not work (the one proposed in the OP is a mild example) > and that nobody else apart from Rick seems to understand the benefits of. Possibly. Time will bear out the truth on that one. > Apart from which, it's not just a language, but also a new processor, > new operating system, and comprehensive, innovative IDE and debugger. No. CAlive is targeted to run on 80386 and later CPUs. It will have an innovative IDE and debugger (James 4:15) and will run on a new ABI that requires a new loader to launch. I plan eventually to port it to my new CPU, new OS, etc. However, because I haven't found anyone interested in helping me, I've retreated somewhat back into my own goals, rather than those of other people. I look to the long-term to try to find a solution that honors the Lord. One un-impeded by prior "art" that is focused on sources other than Him. That is the sole reason I am doing everything from scratch. > (Not to mention the evangelising which must take a lot of time away from > it.) As I go through my days I teach of the Lord and His ways. Hey... that rhymed. :-) > C++; it's not usefully different enough to be worth creating a new > language for. So just use C++ or create some language that is a thin > wrapper around C++ and that outputs C++. It is notably different in design and style. It does keep backward compatibility, however, because there is a tremendous code base al- ready written, and I do not want to abandon that labor effort. It is valuable and should not be abandoned. I have considered making CAlive entirely new with no backward compat- ibility, and writing a converter to take existing C and some C++ code and translating it. I doubt I'll do that, however, as I do intend full C90 and C99 support at some point. ----- I do not plan to do this project alone. I just haven't found anyone who's a Christian who desires to give of their great and vast talent to the Lord in this way. Everybody wants to get paid. Everybody wants to work for money, and not for gifting. As a result, my vision may never see the light of day. However, it is still the correct vision because it re-focuses all of our life's efforts back onto the Lord where they should've been all along. -- Rick C. Hodgin |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 12:27PM +0100 > template< class T > using ptr_ = T*; > template< Size n, class T > using raw_array_ = T[n]; > ptr_<raw_array_<10,int>> x; You forgot the ;-) -- Ben. |
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. |
David Brown <david.brown@hesbynett.no>: Apr 11 01:55PM +0200 On 11/04/18 13:39, Ben Bacarisse wrote: >> declarations. > I don't understand this, but I appreciate that you may think there is > nothing more you can say to help me understand. I mean that I also find "return! x;" and "return x +1;" annoy because the spacing is "fighting the syntax". But I don't agree that "char* x" is "fighting the syntax" in the same way. When I see "char* x;", I think that says "declare a variable x of type char*". When I see "char *x;", I think that says "declare a variable x such that *x is of type char". It is only this second version that is consistent with multiple declarations in the same statement - if you write code with multiple declarations (as in your buffer example), then I can understand why "char* x;" would feel very wrong. But if you /don't/ usually write code with multiple declarations in the same statement, then it merely feels different. And if that doesn't help, then "maybe it's just down to habit" is the fallback! |
"Öö Tiib" <ootiib@hot.ee>: Apr 11 05:25AM -0700 On Wednesday, 11 April 2018 14:27:51 UTC+3, Ben Bacarisse wrote: > > template< Size n, class T > using raw_array_ = T[n]; > > ptr_<raw_array_<10,int>> x; > You forgot the ;-) I trust Alf was likely serious. He has always searched ways to achieve maximal uniformity of syntax even when result is inconvenient or unorthodox. Sometimes his ideas are quite good but more usually these meet serious criticisms (or unserious flames). He is sturdy and keeps trying. |
bartc <bc@freeuk.com>: Apr 10 07:47PM +0100 On 10/04/2018 18:21, Scott Lurndal wrote: > The type syntax created in C and inherited by C++ _is_ a good way > of doing it as evidenced by the billions of lines of C and C++ code > in existence. I can't see the connection. Maybe there were no viable alternatives for systems programming that were just at the right level. Maybe Unix started to take over the world and /that/ was written in C and it came with a C compiler and most of the dealings with it had to involve C or C interfaces. Maybe there are billions of lines, instead of only hundreds of millions, /because/ of the type system. > The fact that you refuse to understand the rules, doesn't invalidate them. I understand the rules. I just think the syntax is atrocious and many seem to agree. Even Kernighan & Ritchie acknowledge that in K&R2 where they say that C has been castigated for the syntax of its declarations, before going on to present a program to convert C declarations into English. My preferred syntax doesn't need turning into English because you can read, write and understand it almost as though it /was/ English. You are saying it is better if it's not so straightforward? (This is the type spec that means 'pointer to a void function with no parameters' in one of my languages: ref proc # or: pointer to proc # if you want it more verbose This is the same thing in C: void(*)(void) Enough said...) -- bartc |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 02:31PM +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> > I mean that I also find "return! x;" and "return x +1;" annoy because > the spacing is "fighting the syntax". But I don't agree that "char* x" > is "fighting the syntax" in the same way. Sorry. I was not clear. I understood you did not think is was "fighting the syntax", I was curious to know why. > statement, then it merely feels different. > And if that doesn't help, then "maybe it's just down to habit" is the > fallback! I think you are indeed saying it's about habit. The syntax has "operators" like *, &, &&, [...], (...) that combine with the name along with plain ()s for priority. It's very similar to the expressions you find grating. Moving the * away means the spacing no longer reflects the association that the syntax describes. -- Ben. |
bartc <bc@freeuk.com>: Apr 11 03:10PM +0100 On 11/04/2018 14:31, Ben Bacarisse wrote: > with plain ()s for priority. It's very similar to the expressions you > find grating. Moving the * away means the spacing no longer reflects > the association that the syntax describes. 'int*, without a space, is commonly used inside casts and in parameter lists where there is no associated name. It just a synonym for 'pointer-to-int', as a type specification in its own right/ So it doesn't look wrong when you write 'int* x' rather than 'int *x'. Which means it is more likely to trip you up when someone writes 'int* x,y' or adds ",y" onto "int* x". The '*' can naturally be associated with either the 'int' or the 'x'. This is the problem. -- bart |
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." |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 11:23AM -0400 On 4/11/2018 10:37 AM, Mr Flibble wrote: > Why are we still discussing this? ONE DECLARATION PER LINE. I disagree with this philosophy. I use this today, and for some functions I might have 15 pointers defined. I don't want to waste 15 lines of code when 10 of them might be the same type, and I could save a lot of screen real estate by going horizontal. In fact, in CAlive's editor design, I introduced something called "side coding," which is where a single source code line can contain information beyond source code. Compilers can inject information that's attached to a line, etc. One of the other capabilities of that ability is to block off lines of code and give them a horizontal reference relative to a prior anchor point, enabling blocks of code to be encapsulated in a cask, and result in source code which is all vertical, but is arranged in a horizontal fashion, like this: https://i.pinimg.com/736x/5b/a1/27/5ba1274b1478699de147c663ce247174--generation-s-user-interface.jpg That type of rounded form is in my app, and it's called a cask. There are different types: (Upper right) http://www.visual-freepro.org/images/vjr_047.png They are input as (|round|), [|square|], <|triangle|>, and ~|utility|~. They each serve a purpose, and there are additional forms not generally used by people, including side coding information, compiler injected information, etc. ----- In any event ... having code go vertical is not always the best idea. I want to use all of the screen real-estate, and to be able to turn on and off the simplified display for algorithms, so that more code can be shown in less space, with placeholders and local encapsulation casks which allow single-stepping through code at those encapsulated levels, rather than line-by-line, and to be able to aggregate up at multiple levels. I have good ideas for developers, Leigh. I seek to give all honor and praise to Jesus Christ for giving me these ideas in the first place. -- Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9 Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj ------------------------------------------------------------------------- Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 11 04:45PM +0100 On 11/04/2018 16:23, Rick C. Hodgin wrote: > multiple levels. > I have good ideas for developers, Leigh. I seek to give all honor and > praise to Jesus Christ for giving me these ideas in the first place. Again reminds me of TempleOS; i.e. it is batshit crazy. /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." |
Bonita Montero <Bonita.Montero@gmail.com>: Apr 11 06:05PM +0200 > One of my goals for my C-like language is to allow whitespaces in > names. To this end, I allow a ctrl+spacebar to introduce a linked > whitespace, which is a connector of related name components. That's plainly idiotic and without any necessity. |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 09:12AM -0700 On Wednesday, April 11, 2018 at 12:06:02 PM UTC-4, Bonita Montero wrote: > > names. To this end, I allow a ctrl+spacebar to introduce a linked > > whitespace, which is a connector of related name components. > That's plainly idiotic and without any necessity. 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. -- Rick C. Hodgin |
Bonita Montero <Bonita.Montero@gmail.com>: Apr 11 06:19PM +0200 > 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. A tool should give a benefit - this tool hasn't a benefit. |
Bonita Montero <Bonita.Montero@gmail.com>: Apr 11 06:21PM +0200 > It's been incorporated into other database languages, such as > Microsoft's TSQL (in TSQL you have to use [brackets for any] > names with spaces). That was because of a mistake of MS with MS Access. Access supports identifiers with a space, and thereby SQL-Server inherits this stupid "feature". |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 09:27AM -0700 On Wednesday, April 11, 2018 at 12:19:38 PM UTC-4, Bonita Montero wrote: > > Nobody has to use it. It will work just fine without spaces. It's > > just another tool in the toolbox. > A tool should give a benefit - this tool hasn't a benefit. You have not studied the many facets of my tool to be able to conclude this statement. You're free to examine them: https://groups.google.com/forum/#!forum/caliveprogramminglanguage BTW, this ability to have spaces in token names is not just given to CAlive. It is part of the base RDC framework itself. RDC will be able to compile C-like code, Java-like code, XBASE-like code, and anything else, based on the set of abilities it exposes. And whereas spaces in token names may be undesirable in C-like code, they are very desirable in other types of code. -- Rick C. Hodgin |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 05:38PM +0100 >> the association that the syntax describes. > 'int*, without a space, is commonly used inside casts and in parameter > lists where there is no associated name. I don't like that one either. A "type name" the syntactic form that goes in ()s to make a cast is a declaration without the name and I write then exactly as if that is what they were. > So it doesn't look wrong when you write 'int* x' rather than 'int *x'. To you. I'm fine with it looking OK to other people, provided they don't get confused about other forms. > Which means it is more likely to trip you up when someone writes 'int* > x,y' or adds ",y" onto "int* x". Yes, that's one of my objections to putting the * in the wrong place. > The '*' can naturally be associated with either the 'int' or the > 'x'. This is the problem. That is true in some people's minds. In mine, the * is associated with the name. When the name is not there, I would not move the *. -- Ben. |
"Öö Tiib" <ootiib@hot.ee>: Apr 11 09:41AM -0700 On Wednesday, 11 April 2018 19:27:40 UTC+3, Rick C. Hodgin wrote: > https://groups.google.com/forum/#!forum/caliveprogramminglanguage Wow! Have you made more groups to discuss things with most pleasant person whom you know? |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 09:45AM -0700 On Wednesday, April 11, 2018 at 12:41:58 PM UTC-4, Öö Tiib wrote: > > https://groups.google.com/forum/#!forum/caliveprogramminglanguage > Wow! Have you made more groups to discuss things with > most pleasant person whom you know? I have documented all of my ideas publicly so other people can come and see them and if they see value incorporate them into their own languages. It is me giving to mankind the fruit of what the Lord first gave me. It's an offering to Him, and to each of you, the best I have to give. -- Rick C. Hodgin |
legalize+jeeves@mail.xmission.com (Richard): Apr 11 04:47PM [Please do not mail me a copy of your followup] bartc <bc@freeuk.com> spake the secret code >'int*, without a space, is commonly used inside casts and in parameter >lists where there is no associated name. Meh. I write static_cast<int *>(p). int* is commonly used in casts by people who write int* x;. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
Juha Nieminen <nospam@thanks.invalid>: Apr 11 12:39PM > As a null pointer, (char*)0 is prohibited from pointing at any object, > so it cannot meet that requirement. One has to wonder why std::string couldn't accept a null char* as a valid parameter, and interpret it has being an empty string. |
"James R. Kuyper" <jameskuyper@verizon.net>: Apr 11 09:04AM -0400 On 04/11/2018 08:39 AM, Juha Nieminen wrote: >> so it cannot meet that requirement. > One has to wonder why std::string couldn't accept a null char* as a valid > parameter, and interpret it has being an empty string. An empty string is represented by "". The whole point of a null pointer is to indicate that no object of the pointed-at type is being provided. It's a logical error to confuse the two, and it's meaningless to provide no string at all, as the source from which a new std::string should be created. |
Bo Persson <bop@gmb.dk>: Apr 11 06:21PM +0200 On 2018-04-11 14:39, Juha Nieminen wrote: >> so it cannot meet that requirement. > One has to wonder why std::string couldn't accept a null char* as a valid > parameter, and interpret it has being an empty string. Originally it was considered an optimization. Assuming most std::strings are constructed from literals, a null-pointer test would be totally wasted on those. Bo Persson |
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