Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: faster than c |
| Date | 2015-04-24 13:36 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <mhddae$vbk$1@dont-email.me> (permalink) |
| References | (19 earlier) <b0692b7a-f0f2-47a0-8280-d6373f8d01c1@googlegroups.com> <mhaln0$nek$1@dont-email.me> <28f726a5-05f8-4975-b98c-8c3583ee0102@googlegroups.com> <mhcr3t$1jh$1@dont-email.me> <d33dcc95-19a7-42e1-96fd-762089595aa0@googlegroups.com> |
On 24/04/2015 12:45, Öö Tiib wrote: > If to imagine starting from scratch a totally separate language then > I would (purely personal preferences) suggest to: > * make everything implicitly immutable after first initialization. > It would considerably shorten my C++ code since I seem to prefer immutability where possible. > * make developer to indicate mutability with keyword (like 'mutable'). > Mutability seems to be the special case in my own code that I feel > deserves more clear indication. Would this be for multi-valued types such as arrays and structs, or also primitives such as ints? In languages such as Python mutability means being able to modify part of an object, but types such as int can't be modified, only replaced completely by assignment. With something like an array, then sometimes the set-up can be elaborate, requiring normal mutability while it's going on, and then used as a read-only table elsewhere. Or it's mutable in some places and not in others. This is difficult to express as a one-time attribute in the source code. (With Python, I think mutability can't change, so strings are never mutable, but lists always are. But then in Python, nearly everywhere is dynamic; you can't change a character in a string, but /can/ take the name of that string variable and assign a function to it!) > * indicate what has been planned to be compile-time known constant > with keyword (can be 'const' like you suggested). It may add > semantic freedom (template argument, case label or array index) and > be needed for optimizations but more important effect for me is that > it must be is diagnosed and ran during compiling. Lot of defects will > fail fast. I agree. This is very, very simple language feature that people just don't seem to want in C, instead preferring all sorts of complicated or limited alternatives. -- Bartc
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 15:23 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 10:02 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 10:58 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 08:26 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-17 13:51 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 11:24 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-18 12:11 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:29 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 13:08 +0200
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 23:33 +1200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 14:19 +0200
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:43 +0000
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-19 13:46 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-19 23:33 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:25 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 00:37 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 00:25 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-23 19:36 +1200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 09:10 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:19 +0200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 13:41 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 10:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:25 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-24 04:45 -0700
Re: faster than c Bartc <bc@freeuk.com> - 2015-04-24 13:36 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-27 06:16 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 14:44 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:10 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:03 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 16:22 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:18 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 16:58 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 09:21 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 12:51 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:47 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 17:20 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:51 -0700
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-17 23:10 +0000
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:46 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:56 -0700
csiph-web