- Why do we have type& and type* - 9 Updates
- [OT] Re: Variable declaration syntax - 14 Updates
- John 4:23-24, KJV - 1 Update
- EXAMPLE - 1 Update
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 12 04:40PM -0700 On Thursday, April 12, 2018 at 5:20:25 PM UTC-4, Mr Flibble wrote: > > i = 5; // As reference > And if you want to make the pointer address 5 rather than what it points > to 5? Nope. To assign a pointer from a constan t would require a cast. To workaround it, use the syntax i& for reference usage. It would signal it's a reference visually, and remove ambiguity. > Try thinking before posting. Mitch: "Did you know there's a guy living in our closet?" Chris: "You've seen him too?" Mitch: "Who is he?" Chris: "Hollyfeld." Mitch: "Why does he keep going into our closet?" Chris: "Why do you keep going into our closet?" Mitch: "To get my clothes. But that's not why he keeps going in there." Chris: "Of course not, Mitch. He's twice your size. Your clothes would never fit him. " Mitch: "Yeah." Chris: "Think before you ask these things, Mitch. Twenty points higher than me, thinks a big guy like that can wear his clothes?" -- Rick C. Hodgin |
| bartc <bc@freeuk.com>: Apr 13 01:17AM +0100 On 12/04/2018 22:15, Rick C. Hodgin wrote: > nonull int* i; > *i = 5; // As pointer > i = 5; // As reference So both *i and i involve a dereference, and both have type 'int'? That means you can write: *i = i; or i=*i; ? And, if you want to assign to the pointer itself as Mr Flibble said, what goes on the left; is it still: i = <a pointer> ? So the type of 'i' here depends on the whether the RHS is an int or pointer? (You may just have re-invented Algol68.) (You seem to have a penchant for inventing obscure, ambiguous, and confusing language features of little or no discernible benefit that anyone else can see. I wonder if that tells you something...) > nonull CAbc* abc; > abc->member(); // As pointer > abc.member(); // As reference OK, let's go with this, and extend it to: nonull CAbc** def; (**def).member(); (*def).member(); (*def)->member(); def->member(); Are these all valid? I assume the pattern is, if there are N pointer levels, you can deref N times, or N-1 times. One slight problem, these two expressions have the same rank, but abc and def have different types: abc->member(); def->member(); More confusion. The idea of a & reference parameter, is that apart from that, you don't need to bother with pointers at all. Or with & on arguments; it's not clear how your scheme deals with that, unless it is to either use & or not. (And also, as I think of my implementation of &, the mechanism for dealing with references exists outside of the type system of the language. So that in: void fn(int &a, int* &b){a, b;} the parameter a always has type int; b always has type int*. Calling fn(x,y), x must be of type int, and y must be of type int*. Very straightforward. And the exactly the same as if the function was: void fn(int a, int* b){a, b;} ) -- bartc |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 13 07:34AM +0300 On 13.04.2018 0:52, bartc wrote: >> somewhere (hopefully not in the global table of constants ;-). > Really? In my language, I guess in C too, & must be applied to an > lvalue. A constant number isn't an lvalue, otherwise you could do 0=1. Yes, that's one of the reasons why in C or C++ a thing like &0 is not valid. But I think there were some languages where you could indeed do 0=1. For example Fortran, with the "literal pool" optimization. See e.g. the quiz at "https://stuff.mit.edu/afs/net/user/tytso/archive/hackers.test" : 0015 Ever change the value of 4? 0016 ... Unintentionally? 0017 ... In a language other than Fortran? |
| David Brown <david.brown@hesbynett.no>: Apr 13 09:43AM +0200 On 13/04/18 06:34, Paavo Helde wrote: > 0015 Ever change the value of 4? > 0016 ... Unintentionally? > 0017 ... In a language other than Fortran? You can do it in Forth too. But there you are not changing the value of the constant 0, you are redefining the meaning of "0": 0 1 + . Puts 0 on the data stack, puts 1 on the stack, adds them, and prints the result of 1. : 0 1 ; Defines "0" to be a word (a Forth function/macro equivalent) that pushes the value 1 onto the data stack. 0 1 + . Calls the word "0" pushing 1 on the data stack, then puts another 1 on the stack, adds them, and prints the result of 2. People who think C has too much scope for error and confusion should try a few other languages! |
| Stuart Redmann <DerTopper@web.de>: Apr 13 03:31PM +0200 >> I am guessing you meant something like "{width = 10; height = 20;}" ? > Yes; I wondered what happened to all my height=20's. I'm sure they were > there before I posted! (And how did you know it was 20?) David certainly knows that "= 20" might be misinterpreted by some news server as url-encoded space, probably because there are some news clients out there that transmit the contents of postings using url encoding. Regards, Stuart |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:12AM -0700 > At the time C++ was invented, some languages (notably C) used > call-by-value argument evaluation, other (e.g. FORTRAN) used > call-by-reference evaluation. I'm pretty sure FORTRAN used call by value-result, at least in the FORTRAN IV era which is when I learned FORTRAN. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:13AM -0700 >>> null, [...] >> And because pointers are mutable. > ...and nullptr'able. Wasn't that already pointed out by James Kuyper's comment? |
| David Brown <david.brown@hesbynett.no>: Apr 13 04:27PM +0200 On 13/04/18 15:31, Stuart Redmann wrote: > David certainly knows that "= 20" might be misinterpreted by some news > server as url-encoded space, probably because there are some news clients > out there that transmit the contents of postings using url encoding. I do know that, and I considered it - but I thought it more likely that he just forgot, especially since it has not been replaced by a space character. But it's another reason to use spaces properly - "height = 20" would not be misinterpreted! |
| jameskuyper@verizon.net: Apr 13 07:34AM -0700 On Thursday, April 12, 2018 at 5:15:41 PM UTC-4, Rick C. Hodgin wrote: > Did you read the rest of my post? When passing pointers like that, > auto-allow the reference syntax when a name is used in a reference > syntax that goes back to a pointer. No, I ignored that part of your suggestion - allowing pointers to be confused with non-pointers is not any sane person's idea of a improvement to C. Sorry - I should have mentioned that. |
| 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. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 12 09:02PM -0700 On 4/12/2018 2:55 PM, Chris M. Thomasson wrote: > stdatomic.h and threads.h. CAlive has to be able to support these. So > far, the threading interface you showed here is way to abstract and > limiting. Your existing thread t behavior should be compatible with at least C11 thrd_create and thrd_join. It just needs the abstraction layer to make compatible with C11 source code. Wrt adding stdatomic.h, well lets go one function at a time. Okay, let us focus on atomic exchange. The C11 behavior for this is the same as an atomic swap: Here is a working C11 program: __________________________ #include <stdio.h> #include <stdint.h> #include <stdatomic.h> int main(void) { atomic_uintptr_t target = 0; uintptr_t result = atomic_exchange_explicit( &target, 123, memory_order_relaxed ); uintptr_t result_load = atomic_load_explicit( &target, memory_order_relaxed ); printf( "result:(%zu)\n" "result_load:(%zu)\n", result, result_load ); return 0; } __________________________ Now, afaict, this atomic_exchange_explicit with at least memory_order_relaxed can be used with your existing thread t behavior. Are you primarily targeting x86 and/or x64? If you combine a simple atomic exchange with your existing threading scheme, well, we can build a mutex, and some other interesting items from a much lower level. You would need a thrd_yield at this point. On a side note, we can build proper waiting and condvars in time. For now, let us focus on abstracting your threading to handle thrd_create, thrd_join and atomic_exchange_explicit first, with a memory_order_relaxed membar. Okay? Three functions. |
| 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." |
| Robert Wessel <robertwessel2@yahoo.com>: Apr 12 11:39PM -0500 On Thu, 12 Apr 2018 23:55:15 +0200, David Brown >the same thing. It is bad enough that some languages allow you to be >inconsistent in capitalisation - but at least you can use >case-insensitive searches. It also leads to some rather "amusing" bugs in Fortran. A classic bug is attempting to write a DO loop, like: DO 10 I=1,9 The "10" is the label ending the body of the loop, and the loop is expected to iterate I from one to nine. Whitespace not being significant, you could code the above as: DO10I=1,9 And it would work exactly the same way. The classic bug is mistyping the comma as a period, IOW: DO 10 I=1.9 In which case that's actually an assignment statement: DO10I = 1.9 That's made worse by the automatic definition of variables (here we've created a "REAL" variable named DO10I), and the fact that the end of the loop body is an ordinary label, with no particular tie to the DO (so you can't even find the equivalent of a mismatched "NEXT" statement in a Basic program). At some point a comma was allowed after the label in the DO, and it became good style to always code DOs as: DO 10, I=1,9 For which mistyping either, or both, commas as periods will result in an error. |
| 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 |
| gazelle@shell.xmission.com (Kenny McCormack): Apr 13 10:26AM In article <pan968$k9b$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: ... >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. The thing you have to realize is that, in Rick's world, you wouldn't be allowed to use your own editor. Well, that's a bit of an exaggeration, but there would be such social and cultural pressure put upon you that you wouldn't want to. What I mean by all this is that, in Rick's world, the editor is part of the language. If (God forbid!) you ever coded in CDead, you'd be expected to use his editor, which would (so it is claimed) do all the right things - including doing the right thing with identifiers with spaces. There is precedent for this sort of thing - that is, programming languages that are really designed to be used with one specific editor, such that that editor becomes an integral part of the language. For example, .NET languages, where you are assumed to be using MSVS to do your editing/development/testing/etc. You *CAN* use other editors, and, truth to tell, what very little .NET programming I did, I did with GVIM, since, well, I use GVIM for everything, but clearly, everyone around me was using MSVS and, well, I had to admit that if I was ever going to get serious about it, that would be the thing to use. That's the kind of model Ricky is going for. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/ForFoxViewers |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 13 05:41AM -0700 On Friday, April 13, 2018 at 6:26:18 AM UTC-4, Kenny McCormack wrote: > allowed to use your own editor. Well, that's a bit of an exaggeration, but > there would be such social and cultural pressure put upon you that you > wouldn't want to. In Rick's world you can use any editor you like. If you'd like to have the full power of the RDC-known information, then you can use the API which accesses that information, and make use of it in your editor. Each language will come with its own editor which integrates that API information, but it will not be exclusive to those editors. The API will be documented, and anyone can use it. Rick's world involves sharing. "Sharing" Kenny. That's your new word for the day. :-) > language. If (God forbid!) you ever coded in CDead, you'd be expected to > use his editor, which would (so it is claimed) do all the right things - > including doing the right thing with identifiers with spaces. Bzzzzz! Oh I'm sorry, contestant, but your answer is incorrect. We're going to have to take your total down to $0 and place you on probation. One more wrong answer and it will be "game over" for you. > well, I use GVIM for everything, but clearly, everyone around me was using > MSVS and, well, I had to admit that if I was ever going to get serious > about it, that would be the thing to use. Microsoft's integrated IDE has been my model. But, I plan to do it one better because I'm a very visual person. My goals are to make coding a visual and tactile experience. > That's the kind of model Ricky is going for. Whatever you say, Kennyy. -- Rick C. Hodgin PS -- God loves you, Kenny. He wants to give you all He has. He wants to prosper you throughout eternity as His remarkable creation, loved and cared for. Ask Jesus to forgive your sin so you can share in that end. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 13 06:03AM -0700 On Thursday, April 12, 2018 at 2:42:42 PM UTC-4, Rick C. Hodgin wrote: > You should read about my Village Freedom Project sometime: > http://www.visual-freepro.org/wiki/index.php/Village_Freedom_Project You can listen to the original inspiration for this project. It was from a recording I made in 2012. It was my attempt to summarize my thoughts that had been brewing for years. Begins about 35:00 into the video: http://www.visual-freepro.org/videos/2012_12_08__01_vvmmc__and_vfrps_relationship_to_christianity.ogv It speaks specifically about Vsual FreePro and my virtual machine, and how I am able to contribute these things to the world, but it goes into a much deeper general philosophy. It was also most surprising I went there in that video. It was sort of flowing out of me. When I finished recording it I was thinking in my thoughts, "Wow. That was interesting," because I had not intended anything like that. It just proceeded to pour out. BTW, if you like clean humor: Apostles of Comedy 2013: https://www.imdb.com/title/tt2894338/ It's available for rent on Amazon Prime. Quite humorous. "Why are you crying?" (You'll get it once you see the video) -- Rick C. Hodgin |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:09AM -0700 > 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? It should be obvious even to a casual observer that nearly all stylistic choices have both plusses and minusses. Some people think never having more than one declarator per declaration (or more than one declaration on a line) always outweighs all other considerations. Others think that position is overly dogmatic, and in some situations other concerns should take precedence. I am in the second camp. I acknowledge the benefits of writing only one declarator per declaration (and only one declaration per line). I think it's good advice to follow such a rule most of the time. At the same time, in some cases other considerations are more important, and those considerations can outweigh the cost/benefit balance of the "one declaration per line" rule. > Fucktard. Do you always call people who don't agree with you a fucktard? |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:19AM -0700 > count is fucktarded at worst and egregious at best. [...] Yes > functional decomposition is very important but there is no magic > LOC number past which a function becomes "too big". Does this mean that if you were asked to operate under a set of style constraints that required function bodies to be no more than thirteen million lines long that you would object and insist there be no fixed limit? |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:22AM -0700 > But also, since many people including Tim advocate making functions as > short as possible [...] Bart is up to his usual trolling tricks of misrepresenting what other people say. I advocate writing short functions. I have never advocated making functions as short as possible. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:33AM -0700 >> 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 isn't a straw man argument, for the simple reason that it isn't an argument. (It also isn't a straw man, but never mind that now.) > 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.) [...] It's quite amusing to see how you start by attacking what I said but then at end admit that you yourself follow the principle put forth. Next you'll be saying it's both a floor wax and a dessert topping. :) |
| "Rick C. Hodgin" <rick.c.hodgin@g.com>: Apr 13 10:31PM +0800 John 4:23-24, KJV "But the hour cometh, and now is, when the true worshippers shall worship the Father in spirit and in truth: for the Father seeketh such to worship him. God is a Spirit: and they that worship him must worship him in spirit and in truth." Do you know God? He wants to know you. Ask me for help in understanding why we need Jesus. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 13 01:58PM On Mon, 2018-04-09, Richard wrote: > reasonably. Now maybe the reason you can't do this for your internal > classes is that you don't document them: no description of assumed > preconditions, guaranteed postconditions, purpose of each class, etc. Uh, I never said I can't (or don't) do this. In fact I agree about what makes it possible: factored-out code which you can understand without remembering or revisiting its detailed implementation, like the standard library. Sometimes documentation is needed, but often decent naming is enough. My point was, I'd rather have one long function than a badly refactored version, if those were the only two choices. ... > This sort of coding style is acknowledging that there is already a > series of higher-order steps in this long function, they just couldn't > be bothered to extract those steps into cohesive functions. I'm not a big fan of refactoring long functions by splitting them into steps. It's tempting, but there's often IME too much state to pass between steps. I'm more inclined to keep the function -- keep the business logic in some sense -- but factor out classes and functions for the boring details. Like the 2D coordinate you mention further down, or some abstraction that just happens to make sense very locally. [snip] > into much more detail about how to apply this thinking beyond simple > value types like point_2d. I highly recommend it. > <https://amzn.to/2EyHWVU> Keeping that paragraph since it seems like a good recommendation. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| 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