Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126536 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2018-02-10 12:41 -0800 |
| Last post | 2018-02-12 23:21 +0100 |
| Articles | 20 on this page of 103 — 26 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C2 Aims to Modernize the C Language David Kleinecke <dkleinecke@gmail.com> - 2018-02-10 12:41 -0800
Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-10 13:38 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 00:32 +0100
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:23 -0800
Re: C2 Aims to Modernize the C Language Anton Shepelev <anton.txt@gmail.com> - 2018-02-11 13:53 +0300
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-11 13:26 +0000
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-11 13:04 -0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 01:34 +0000
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:42 -0800
Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-10 17:50 -0800
Re: C2 Aims to Modernize the C Language fir <profesor.fir@gmail.com> - 2018-02-14 11:54 -0800
Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-14 12:14 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:48 +0100
Re: C2 Aims to Modernize the C Language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-10 22:35 -0700
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 13:25 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 11:18 +0000
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 21:57 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-12 14:10 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 11:11 +0000
Re: C2 Aims to Modernize the C Language Reinhardt Behm <rbehm@hushmail.com> - 2018-02-12 20:33 +0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 13:43 +0000
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-12 06:05 -0800
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:13 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 01:17 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 09:55 +0100
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 12:28 -0600
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 11:36 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 00:59 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:19 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:07 +0000
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-03-06 15:46 +0000
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 20:31 -0600
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:42 +1300
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 01:13 -0600
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 15:13 +0000
Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-21 08:43 -0800
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:21 +0000
Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:25 -0600
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:28 +0000
Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:29 -0600
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-22 08:33 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:48 +0000
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 11:54 -0600
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 20:41 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 00:00 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 00:59 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 12:29 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 12:18 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 15:27 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 15:19 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 16:49 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:16 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:30 +1300
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 22:37 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 22:15 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 17:05 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:11 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:32 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:10 +0000
Re: C2 Aims to Modernize the C Language gordonb.5itdn@burditt.org (Gordon Burditt) - 2018-02-14 12:57 -0600
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 20:29 +0000
Re: C2 Aims to Modernize the C Language gordonb.nrdl0@burditt.org (Gordon Burditt) - 2018-02-14 19:22 -0600
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-15 14:59 +0000
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:00 -0800
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:46 +0100
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 08:49 -0800
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-13 09:52 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:47 +0100
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 05:11 -0800
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:49 +0100
Re: C2 Aims to Modernize the C Language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-13 21:52 +0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 14:45 +0000
Re: C2 Aims to Modernize the C Language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-13 07:45 -0800
Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-13 05:35 -0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:21 +0000
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:24 +0000
Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-13 13:14 +0200
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:38 -0800
Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:25 +0200
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:39 +0000
Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:42 +0200
Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-15 13:17 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:41 +0100
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 17:25 +0100
Re: C2 Aims to Modernize the C Language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-12 17:28 +0000
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:01 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:51 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 19:28 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 20:02 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:32 +0100
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:42 +0100
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:26 +0100
Re: C2 Aims to Modernize the C Language Richard Damon <Richard@Damon-Family.org> - 2018-02-13 08:06 -0500
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-13 15:16 +0100
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:53 +0100
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 15:22 -0600
Re: C2 Aims to Modernize the C Language Keith Thompson <kst-u@mib.org> - 2018-02-12 12:26 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:45 +0100
Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-12 15:52 -0800
Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-12 17:13 -0800
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:15 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 21:42 +0000
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 23:21 +0100
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Egor <egor@ruby.local> |
|---|---|
| Date | 2018-02-14 13:42 +0200 |
| Message-ID | <aujdle-k7c.ln1@ruby.opensrc.club> |
| In reply to | #126661 |
bartc <bc@freeuk.com> wrote: > Anyway, the actual ABI, the recommended mechanics of passing data around > and what goes into which register, is just part of the story. > > If C and a platform ABI are distinct entities, then perhaps library APIs > can use a neutral scheme related to the ABI, rather than to a specific > language. Even if the library might have been written in that language. That'd require a different interface for every ABI. C is basically a portable assembler, it removes the implementation details of ABI. > A clearly defined subset of C, minus extraneous typedefs and attributes, > and obfuscating macros, could also do the job. > > But that doesn't happen. I usually try to avoid clutter in my public headers, so that it's easy to understand what types are actually used.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-15 13:17 -0800 |
| Message-ID | <d52573bf-311b-42ed-9c94-d1b19c60c7c2@googlegroups.com> |
| In reply to | #126548 |
On Saturday, February 10, 2018 at 5:34:43 PM UTC-6, GOTHIER Nathan wrote: > I think the C2 design is broken with the built-in types lacking the > flexibility of the C design which doesn't force implementors to > provide slow non native types (at least for integers). Additionally, I > don't think naming integer types "iX" or "uX" is clear and relevant for > most programmers. The C Standard specifies bitfields with sufficient detail to mandate that compilers generate slow and inefficient code for them in many case, but with insufficient detail to make them useful for much in portable code. Given that compilers already have to be able to handle the masking and shifting logic necessary for bitfields, requiring that they be able to handle types like "32-bit value stored as four eight-bit chunks in big- endian order" wouldn't be much of an additional imposition. A good language should also have things for e.g. "integer type of at least 32 bits", but defining a structure type with fixed layout and using "fread" to fill it is a much cleaner approach than having to use fread into a char[] buffer and then manually assemble every field from sequences of bytes.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-11 04:41 +0100 |
| Message-ID | <20180211044128.28195075b2bb2f721cba57e1@gmail.com> |
| In reply to | #126536 |
On Sat, 10 Feb 2018 12:41:59 -0800 (PST) David Kleinecke <dkleinecke@gmail.com> wrote: > On Saturday, February 10, 2018 at 12:31:33 PM UTC-8, computer45 wrote: > > Hello.. > > > > > > C2 Aims to Modernize the C Language > > > > Read more here: > > > > https://www.infoq.com/news/2018/02/c2lang-modern-c > > Where can I find a BNF of its syntax? > > Or must I read everything on wiki.c2.com? The C2 programming language is a joke. :o) http://www.c2lang.org/forum/index.php?PHPSESSID=193c6f9e87cb272210c8af1a0b0104a6&topic=14.0 -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2018-02-12 17:25 +0100 |
| Message-ID | <p5sf62$uhq$1@gioia.aioe.org> |
| In reply to | #126536 |
On 2/10/2018 9:41 PM, David Kleinecke wrote: > On Saturday, February 10, 2018 at 12:31:33 PM UTC-8, computer45 wrote: >> Hello.. >> >> >> C2 Aims to Modernize the C Language >> >> Read more here: >> >> https://www.infoq.com/news/2018/02/c2lang-modern-c > > Where can I find a BNF of its syntax? > > Or must I read everything on wiki.c2.com? > "Undesirable aspects of C include the use of header files, which greatly slow the compiler down, and complex type declaration syntax, which C2 replaces with a module system and its uniform type syntax" I never had a problem with including headers, nor with C type declaration syntax, so the incipit is not really exciting for my personal experience. I am not really a fan of a module system either - I mean, C gives the programmer full control of declarations to be #included, and which libraries are to be linked with the code. If this comes at the cost of requiring some care with #includes and libraries, personally I am fine with it. In the "hello world" example the only potential improvement I could see between the lines is some support for namespaces, but I don't like the way this is proposed in the example: Replacing #include <stdio.h> with "import stdio as io" is not really more clear/helpful, and most importantly the syntax "io.printf()" goes in the direction of other "modern" languages of abusing the dot operator for a variety of features; here confusing module selection with struct member designation. I also agree with Gothier Nathan that C's "int" and "long" types, despite being of implementation-defined size, are a Good Thing(TM) in that they can provide access to machine native types. The C function syntax has its side effects, but still I don't really see the need for a 'func' keyword (it reminds me of the ancient ages of Fortran and Pascal); besides, it makes me wonder what would be the syntax for a function pointer - one of the greatest features of C. My two c.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-12 17:28 +0000 |
| Message-ID | <87sha6i0c4.fsf@bsb.me.uk> |
| In reply to | #126602 |
Manfred <noname@invalid.add> writes: <snip> > Replacing #include <stdio.h> with "import stdio as io" is not really > more clear/helpful, and most importantly the syntax "io.printf()" goes > in the direction of other "modern" languages of abusing the dot > operator for a variety of features; here confusing module selection > with struct member designation. I'm not sure any C aficionado can complain about a symbol's meaning being overload! What about *, *, * and * all meaning different things? I could live with another not entirely unrelated use for the dot. Anyway, syntax aside, any major overhaul of C should probably do something to split up the single external name space. C programmers learn name discipline, but even so, it gets clumsy. However, I don't think that any change to C that is not largely backwards compatible stands much chance. Where you don't need C, there are lots of fine languages to chooses from, and where you do, well, you need C. There may be a niche for a language with tidied-up syntax but which is otherwise compatible in terms of function calling, data layout and so on (and I've not check to see if C2 is such a language) but I am not sure how big that niche is. Also, if that's the goal, surely a translator is the way to go? <text removed> > The C function syntax has its side effects, but still I don't really > see the need for a 'func' keyword (it reminds me of the ancient ages > of Fortran and Pascal); besides, it makes me wonder what would be the > syntax for a function pointer - one of the greatest features of C. I'm not 100% sure but from a cursory glance it seems that all function types in C2 are really function pointer types. That's a reasonable thing to do since you can't have run-time functions as anything but a thing pointed to, but it does remove a feature I sometimes use -- declaring a name using a typedef's function type. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2018-02-12 21:01 +0100 |
| Message-ID | <p5srqr$1l08$1@gioia.aioe.org> |
| In reply to | #126604 |
On 2/12/2018 6:28 PM, Ben Bacarisse wrote: > Manfred <noname@invalid.add> writes: > <snip> >> Replacing #include <stdio.h> with "import stdio as io" is not really >> more clear/helpful, and most importantly the syntax "io.printf()" goes >> in the direction of other "modern" languages of abusing the dot >> operator for a variety of features; here confusing module selection >> with struct member designation. > > I'm not sure any C aficionado can complain about a symbol's meaning > being overload! What about *, *, * and * all meaning different things? > I could live with another not entirely unrelated use for the dot. The dot operator is particularly dear to me because it is tightly coupled with type semantics. And type semantics of C is one of the things I like about it (even more in C++) You say that these uses are not entirely unrelated, but this is IMHO only appearently true, i.e. if you look at them as some sort of generic 'containment' operation. Used as a module selector, the dot operator is more properly a 'scope' operator, which applies to the declaration space (hence it can select /types/ besides other things) Used as a members selector, it applies to the compiled memory space - one major consequence is that the C dot operator only applies to instances of structs, not to types. Overloading these two uses is IMHO a major source for confusion. > > Anyway, syntax aside, any major overhaul of C should probably do > something to split up the single external name space. C programmers > learn name discipline, but even so, it gets clumsy. Definitely true, I think this is a significant cost of C for large projects - besides name discipline, I also make extensive use of 'static' , but still there is room for improvement. <snip>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-12 17:51 +0000 |
| Message-ID | <KukgC.804$kD1.551@fx34.am4> |
| In reply to | #126602 |
On 12/02/2018 16:25, Manfred wrote: > Replacing #include <stdio.h> with "import stdio as io" is not really > more clear/helpful, and most importantly the syntax "io.printf()" goes > in the direction of other "modern" languages of abusing the dot operator > for a variety of features; here confusing module selection with struct > member designation. They are the same thing: if M is a module containing functions A,B,C; S is a struct containing functions A,B,C; and X is an instance of X, then: M.B() # calls function B in M S.B() # calls function B in S X.B() # calls function B in X's owner type S This is not quite C: C's structs can only contain function pointers; not actual functions (so S.B() is not possible; you need a filled-in instance X of S). But it shows the pattern and why "." can be consistently used. > I also agree with Gothier Nathan that C's "int" and "long" types, > despite being of implementation-defined size, are a Good Thing(TM) in > that they can provide access to machine native types. How? The machine word size on x64 is 64 bits, but C's int is usually 32 bits. (In my language, "intm" and "wordm" give you signed/unsigned types corresponding to the machine word size.) > The C function syntax has its side effects, but still I don't really see > the need for a 'func' keyword Really? How then do you figure out where each function starts? Do you rely on correct indentation? Do you have to mentally parse each declaration that is encountered to decide if it is declaring a function, function pointer or variable? Sticking 'func' in front costs almost nothing and means you can be 100% sure what it is. You can also trivially write a program to find all the function declarations in a file. (it reminds me of the ancient ages of > Fortran and Pascal) And Python. And Lua. And Ruby. And Go. And Rust. And Javascript. Not having a keyword to introduce such an important element of a program is the exception. ; besides, it makes me wonder what would be the > syntax for a function pointer - one of the greatest features of C. A function pointer is a variable. A function isn't. They are different things. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-12 19:28 +0100 |
| Message-ID | <20180212192818.9e74dec1da023ff875a63c9a@gmail.com> |
| In reply to | #126606 |
On Mon, 12 Feb 2018 17:51:43 +0000 bartc <bc@freeuk.com> wrote: > How? The machine word size on x64 is 64 bits, but C's int is usually > 32 bits. That's not true. For an AMD64 compatible architecture paired with a 64-bit operating system, a 64-bit C implementation usually stores an "int" type as 8 octets but some old 32-bit C implementations can provide 4 octets running on a 32-bit compatibilty layer. > Really? How then do you figure out where each function starts? Do you > rely on correct indentation? Do you have to mentally parse each > declaration that is encountered to decide if it is declaring a > function, function pointer or variable? There is no magic! It's all in the grammar. ;-) > Sticking 'func' in front costs almost nothing and means you can be > 100% sure what it is. You can also trivially write a program to find > all the function declarations in a file. You can be 100 % sure if you are able to understand the C syntax. Writing 4 more letters makes the syntax more cumbersome with nearly zero benefit. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-12 20:02 +0000 |
| Message-ID | <0pmgC.72$Z96.47@fx28.am4> |
| In reply to | #126608 |
On 12/02/2018 18:28, GOTHIER Nathan wrote:
> On Mon, 12 Feb 2018 17:51:43 +0000
> bartc <bc@freeuk.com> wrote:
>
>> How? The machine word size on x64 is 64 bits, but C's int is usually
>> 32 bits.
>
> That's not true. For an AMD64 compatible architecture paired with a
> 64-bit operating system, a 64-bit C implementation usually stores an
> "int" type as 8 octets but some old 32-bit C implementations can
> provide 4 octets running on a 32-bit compatibilty layer.
Any examples of where that is true? My machine does this:
c:\c>ver
Microsoft Windows [Version 6.1.7601]
c:\c>type c.c
#include <stdio.h>
int main(void) {
printf("sizeof(int) = %d\n", sizeof(int));
}
c:\c>\tdm\bin\gcc -m64 c.c -oc.exe
c:\c>c
sizeof(int) = 4
c:\c>
This must be Windows 64-bit otherwise the 64-bit c.exe wouldn't run.
So, what do I have to do on this machine to declare an int the same
width as a machine register? That is, find a int type T where sizeof(T)
is 4 in 32 bits, and 8 on 64 bits.
>> Really? How then do you figure out where each function starts? Do you
>> rely on correct indentation? Do you have to mentally parse each
>> declaration that is encountered to decide if it is declaring a
>> function, function pointer or variable?
>
> There is no magic! It's all in the grammar. ;-)
I can't really argue with that. Yes, it's all in the grammar, provided
your brain is constantly running a C parser (and a C preprocessor for
all those tricky extras).
The problem is that the difference between a function, function pointer
or even just any other variable can be very subtle:
int (*a)(void),(*b),(*c)(),(d)(void*),(*e)(void(*)(void f));
There is one function, three function pointers and one pointer.
Here is an actual example from LuaJIT sources:
LJLIB_PUSH(top-3)
LJLIB_SET(_VERSION)
These lines are outside of a function, but that's the only clue you
have. Although people could simply incorporate 'func' inside a macro
where it's not much use, if these /are/ functions, then it can also be
placed outside:
func LJLIB_PUSH(top-3)
func LJLIB_SET(_VERSION)
(I haven't been able to figure out what those do; they seem to be empty
macros.)
> You can be 100 % sure if you are able to understand the C syntax.
> Writing 4 more letters makes the syntax more cumbersome with nearly
> zero benefit.
Seriously? Writing: 'const _restrict_ unsigned long long int*' - per
item in a function list - is fine, as are multiple attributes such as
__attribute__(whatever), but one 'func' for the whole function is extra
typing and is too cumbersome?!
You're having a laugh I think.
Anyway C is not going anywhere; if you want to continue writing
obfuscated code, no one's stopping you.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-12 23:32 +0100 |
| Message-ID | <20180212233230.6e4dea9eacff81a37b80dc80@gmail.com> |
| In reply to | #126614 |
On Mon, 12 Feb 2018 20:02:09 +0000 bartc <bc@freeuk.com> wrote: > So, what do I have to do on this machine to declare an int the same > width as a machine register? That is, find a int type T where sizeof > (T) is 4 in 32 bits, and 8 on 64 bits. I'm afraid my GCC implementation looks broken too but not really. :-) I assume that GCC developers kept the "int" type size as 4 octets to not break existing bad code thinking that "int" should always be 4 octets. However, giving 8 octets for "int" isn't a great deal since C only guarantee at least 65536 values on any implementation. And yes, "short" and "int" ranges defined by C are broken. We have to live with that! It could be clearer if we had limits such as: short: 8 bits or more int: 16 bits or more long: 32 bits or more extra: 64 bits or more But C couldn't be easily implemented on many limited architectures. The current limits of C types are the legacy of Dennis M. RITCHIE's work on the PDP-11 architecture (16 bits). At that time I suppose the extra work to implement the "long" type as a 16-bit aggregate was acceptable similarly with the transition to the AMD64 architecture. IMHO, the "char" type should have been from the start an alias for the smallest integer type but time decided otherwise... -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-13 10:42 +0100 |
| Message-ID | <p5ubtb$ufu$1@dont-email.me> |
| In reply to | #126625 |
On 12/02/18 23:32, GOTHIER Nathan wrote: > On Mon, 12 Feb 2018 20:02:09 +0000 > bartc <bc@freeuk.com> wrote: > >> So, what do I have to do on this machine to declare an int the same >> width as a machine register? That is, find a int type T where sizeof >> (T) is 4 in 32 bits, and 8 on 64 bits. > > I'm afraid my GCC implementation looks broken too but not really. :-) By that, I take it you mean that your /understanding/ of gcc is broken? > > I assume that GCC developers kept the "int" type size as 4 octets to not > break existing bad code thinking that "int" should always be 4 > octets. However, giving 8 octets for "int" isn't a great deal since C > only guarantee at least 65536 values on any implementation. "int" is required to be 16-bit minimum, and intended to be the fastest general-purpose integer type. 32-bit "int" is faster on x86-64 (and most 64-bit architectures) than 64-bit types because it gives more efficient use of cache and memory buses, while giving a range that is suitable for most integer uses. Thus almost all 64-bit targets use 32-bit "int" - the Cray is the only exception I can think of. > > And yes, "short" and "int" ranges defined by C are broken. We have to > live with that! They are not broken - they are just defined in a way that is not ideal for all purposes. If you prefer to use types with precisely defined sizes, C has them too - it's your choice. > > It could be clearer if we had limits such as: > > short: 8 bits or more Why? We have signed char and unsigned char for that. "short" gives a handy type for 16-bit size when "int" is 32-bit. > int: 16 bits or more That is what we have now. > long: 32 bits or more That is what we have now. > extra: 64 bits or more That is what we have now, except it is called "long long". > > But C couldn't be easily implemented on many limited architectures. C /has/ been implemented on many limited architectures. Your minor tweaks above would not change that. > > The current limits of C types are the legacy of Dennis M. RITCHIE's > work on the PDP-11 architecture (16 bits). At that time I suppose the > extra work to implement the "long" type as a 16-bit aggregate was > acceptable similarly with the transition to the AMD64 architecture. The types in C are surprisingly flexible and forward-thinking. Sure, they could have been defined in different ways, and that would have been better in some ways. But what we have works fine as long as you understand it. > > IMHO, the "char" type should have been from the start an alias for the > smallest integer type but time decided otherwise... > There are a number of changes that I think could have made C's types nicer - that would definitely not be one of them.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-13 13:26 +0100 |
| Message-ID | <20180213132653.d1216c77632a9b306638f07f@gmail.com> |
| In reply to | #126643 |
On Tue, 13 Feb 2018 10:42:02 +0100 David Brown <david.brown@hesbynett.no> wrote: > There are a number of changes that I think could have made C's types > nicer - that would definitely not be one of them. The semantic of a char integer is clearly broken, whence the need of an alias for char like wchar_t. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-02-13 08:06 -0500 |
| Message-ID | <8pBgC.42088$m03.5392@fx38.iad> |
| In reply to | #126653 |
On 2/13/18 7:26 AM, GOTHIER Nathan wrote: > On Tue, 13 Feb 2018 10:42:02 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> There are a number of changes that I think could have made C's types >> nicer - that would definitely not be one of them. > > The semantic of a char integer is clearly broken, whence the need of an > alias for char like wchar_t. > Char, as a basic char actually works quite well. One thing is it doubles as a way to access fundamental chunks of memory (though sometimes unsigned char works better there). It also handles multi-byte character sets (like UTF-8) well, for efficient storage of text. wchar_t was added when character sets wider than 8 bits started to become popular. It does have an issue that for a machine that uses Unicode, it technically should be a 32 bit type (or at least 21 bits), so all code points are a single element, but on some implementations it is 16 bits, for backwards compatibility to the time when Unicode was expected to be a 16 bit type. Thus it really only properly handles UCS-2, but is sometimes used for UTF-16. I will agree that if C was created anew, and didn't need to worry about backwards compatibility, having separate types for usage as an 8 bit integer (signed and unsigned) and as a character could be useful.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2018-02-13 15:16 +0100 |
| Message-ID | <p5urv3$j14$1@gioia.aioe.org> |
| In reply to | #126656 |
On 2/13/2018 2:06 PM, Richard Damon wrote: > On 2/13/18 7:26 AM, GOTHIER Nathan wrote: >> On Tue, 13 Feb 2018 10:42:02 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> There are a number of changes that I think could have made C's types >>> nicer - that would definitely not be one of them. >> >> The semantic of a char integer is clearly broken, whence the need of an >> alias for char like wchar_t. >> > > Char, as a basic char actually works quite well. One thing is it doubles > as a way to access fundamental chunks of memory (though sometimes > unsigned char works better there). It also handles multi-byte character > sets (like UTF-8) well, for efficient storage of text. > > wchar_t was added when character sets wider than 8 bits started to > become popular. It does have an issue that for a machine that uses > Unicode, it technically should be a 32 bit type (or at least 21 bits), > so all code points are a single element, but on some implementations it > is 16 bits, for backwards compatibility to the time when Unicode was > expected to be a 16 bit type. Thus it really only properly handles > UCS-2, but is sometimes used for UTF-16. Which proves that, after the initial equivalence "char == byte" adopted by C and most other languages at the time, later attempts like wchar_t to introduce a better character entity have not been entirely successful - AFAIK nowadays the most widely accepted[*] Unicode standard is UTF-8, which uses bytes, not wchar_t's as storage elements, as you noted. > > I will agree that if C was created anew, and didn't need to worry about > backwards compatibility, having separate types for usage as an 8 bit > integer (signed and unsigned) and as a character could be useful. I think the only confusing issue about char is that it is natively called 'char' instead of 'byte', which can be regarded as no more than cosmetics when you know it. I agree that a high-level character entity is missing in C, but in my opinion it needs not be necessarily part of the /language/ - as a higher level entity, it can well be (as in fact it is) part of dedicated text manipulation libraries and/or services provided by the OS. The whole UI subsystem in C is very limited, this part is usually provided by higher level components in a complete program. [*] except on Windows, which is nonetheless catching up.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-13 14:53 +0100 |
| Message-ID | <p5uqkb$vcl$1@dont-email.me> |
| In reply to | #126653 |
On 13/02/18 13:26, GOTHIER Nathan wrote: > On Tue, 13 Feb 2018 10:42:02 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> There are a number of changes that I think could have made C's types >> nicer - that would definitely not be one of them. > > The semantic of a char integer is clearly broken, whence the need of an > alias for char like wchar_t. > I agree that the semantics of "char" is broken - I think the main failing is that it is considered an integer type. That is why I would not like your changes for "char", as it would not fix the actual problem.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-02-13 15:22 -0600 |
| Message-ID | <p5vktd$hir$1@news.albasani.net> |
| In reply to | #126665 |
On 2/13/2018 7:53 AM, David Brown wrote: > On 13/02/18 13:26, GOTHIER Nathan wrote: >> On Tue, 13 Feb 2018 10:42:02 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> There are a number of changes that I think could have made C's types >>> nicer - that would definitely not be one of them. >> >> The semantic of a char integer is clearly broken, whence the need of an >> alias for char like wchar_t. >> > > I agree that the semantics of "char" is broken - I think the main > failing is that it is considered an integer type. That is why I would > not like your changes for "char", as it would not fix the actual problem. > my thinking, if it "could" be changed: * byte, represents an 8-bit integer type. ** comes in signed and unsigned variants. * char, actual working size is not strictly defined ** big enough to represent a character value on the target. ** default element type for strings. in my BS2 language, char was nominally 16-bits (in arrays or similar), like in Java and friends, though most string literals remained as 8-bit. similarly, as a standalone variable, it was "however wide as was convenient" (in this case, quietly promoted to 'int'). "string" was a distinct type from "char*" or "char[]"; and it was up to the implementation but otherwise mostly transparent if a given string were encoded as ASCII/8859-1 or UTF-16. ASCII was used mostly because it had a few advantages in this use-case (over UTF-8), and was sufficient in most cases (for strings which fell outside ASCII range, UTF-16 was used). M-UTF-8 was the default representation though for serialized text (IOW: most things other than string literals or similar). BS2 wasn't really intended as a "C alternative" though, but amusingly is in many regards still closer than C than a lot of the "C alternatives" I have seen... I have my own C compiler as well though as: sometimes I need to compile C to something mainstream compilers don't support; in many use-cases, C still remains more useful to me than trying to use BS2 as if it were C would be (granted, if I did try using it for things like bare-metal development and my experimental CPU arch project, it would make it better as a "C alternative"...). but, would probably need to glue my BS2 VM's front-end onto my C compiler's backend, which gets into the annoying area that while both use a stack-machine as an intermediate stage (and both translate to 3AC/SSA for the back end), there are some fundamental differences in how these stack-machines operate. would need to come up with a good compromise which is "sufficient" in terms of both design elegance and effort. but, pretty much no one is sufficiently interested in this (not even really myself) to make me want to throw the needed effort at it, so...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-12 12:26 -0800 |
| Message-ID | <lnfu66osxv.fsf@kst-u.example.com> |
| In reply to | #126608 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Mon, 12 Feb 2018 17:51:43 +0000
> bartc <bc@freeuk.com> wrote:
>
>> How? The machine word size on x64 is 64 bits, but C's int is usually
>> 32 bits.
>
> That's not true. For an AMD64 compatible architecture paired with a
> 64-bit operating system, a 64-bit C implementation usually stores an
> "int" type as 8 octets but some old 32-bit C implementations can
> provide 4 octets running on a 32-bit compatibilty layer.
[...]
I've never seen an x64 (x86_64) C implementation with 64-bit int.
Usually int is 32 bits and long is 64 bits (though 64-bit Windows
seems tends to make long 32 bytes). Do you have an example of an
implementation with 64-bit int?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-12 23:45 +0100 |
| Message-ID | <20180212234534.8bc7f9874ad7c44b0768c540@gmail.com> |
| In reply to | #126619 |
On Mon, 12 Feb 2018 12:26:36 -0800 Keith Thompson <kst-u@mib.org> wrote: > I've never seen an x64 (x86_64) C implementation with 64-bit int. > Usually int is 32 bits and long is 64 bits (though 64-bit Windows > seems tends to make long 32 bytes). Do you have an example of an > implementation with 64-bit int? I'm afraid I shot too rapidly my bullet. :-) I'm going to complain here like bartc that C types are broken, I have to build my own "better than C" programming language. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-02-12 15:52 -0800 |
| Message-ID | <006e5822-922b-462e-b3da-419a20cb1924@googlegroups.com> |
| In reply to | #126619 |
On Monday, February 12, 2018 at 3:26:45 PM UTC-5, Keith Thompson wrote: > I've never seen an x64 (x86_64) C implementation with 64-bit int. > Usually int is 32 bits and long is 64 bits (though 64-bit Windows > seems tends to make long 32 bytes). 32 bytes!? Yowzers! "That's a big twinky." -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2018-02-12 17:13 -0800 |
| Message-ID | <348e6143-dfff-497f-9c48-bce011d2d57a@googlegroups.com> |
| In reply to | #126627 |
We also neeed to modernize the workforce such that women shouldn't be allowed to leggings as pants at the office.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web