- "Microsoft Exploring Rust as the Solution for Safe Software" - 4 Updates
- Hard work pays off - 4 Updates
- A question about if constexpr - 4 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 02 01:59PM -0600 "Microsoft Exploring Rust as the Solution for Safe Software" https://www.infoq.com/news/2019/11/microsoft-exploring-rust-safety/ I doubt it. Lynn |
| "Öö Tiib" <ootiib@hot.ee>: Dec 02 12:33PM -0800 On Monday, 2 December 2019 21:59:31 UTC+2, Lynn McGuire wrote: > "Microsoft Exploring Rust as the Solution for Safe Software" > https://www.infoq.com/news/2019/11/microsoft-exploring-rust-safety/ > I doubt it. Why? There is need and opportunity. C# won't ever be useful for system programming. C, C++ and JavaScript are wild and can not be tamed under control of any monster. D had just too few changes to C++ to bother with it. Everything else is under control of other monsters. So Rust is good opportunity to adopt something from kindergarten and to spoil it. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Dec 02 09:17PM > too few changes to C++ to bother with it. Everything else is under > control of other monsters. So Rust is good opportunity to adopt > something from kindergarten and to spoil it. I don't think it is about control. Rust is pain to program for novice, exactly because it forces safety. Development time is also bigger. If goal is safety in that kind of safety Rust is ok choice. There were times I loved it (beginnings) then hated it, then I love it again. One cannot be indeferent to Rust, that's for sure. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 02 11:08PM +0100 On 02.12.2019 22:17, Melzzzzz wrote: > One cannot be indeferent to Rust, that's for sure. Why not? I am. I once downloaded a/the Rust implementation, wrote "Hello, world!", and haven't bothered with it since. - Alf |
| woodbrian77@gmail.com: Dec 02 07:51AM -0800 I have these lines in a file: #include<winsock2.h> #include<ws2tcpip.h> . If I remove the first include, the code still compiles on my Windows 10 machine. Do you think it's OK to commit it without that include? This is the file: https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/Buffer.hh Tia. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| "Öö Tiib" <ootiib@hot.ee>: Dec 02 10:27AM -0800 > compiles on my Windows 10 machine. Do you think it's > OK to commit it without that include? This is the file: > https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/Buffer.hh I usually comment #include why I include it, what I plan in current file to use from it. All your #includes are without comments ... you perhaps dislike commenting in general? So now it is interesting task how can we figure why you included these headers? May be you have notes somewhere else and so can tell? |
| woodbrian77@gmail.com: Dec 02 11:13AM -0800 On Monday, December 2, 2019 at 12:27:19 PM UTC-6, Öö Tiib wrote: > I usually comment #include why I include it, what I plan in current > file to use from it. > All your #includes are without comments Some of the #includes in that file have comments. > ... you perhaps > dislike commenting in general? I don't think there's much point in commenting all of them. I admit it would be better if there were a comment on the line in question. Sorry the code isn't perfect... it is by the grace of G-d getting better. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 02 11:57AM -0800 > > file to use from it. > > All your #includes are without comments > Some of the #includes in that file have comments. Mea culpa. > were a comment on the line in question. Sorry the > code isn't perfect... it is by the grace of G-d > getting better. Ok. I wasn't trying to distract you from that process just to give an hint why it is difficult for us to aid: |
| Ned Latham <nedlatham@woden.valhalla.oz>: Dec 01 07:27PM -0600 Christian Gollwitzer wrote: > > XBNF is no mere scripting language; it is a mathematical meta-language > > capable of defining the syntax of any context-free grammar: > here is your problem: There *is* no problem. > C is not context free. It is usually dealt with > the "lexer hack" to use a parser for context-free grammar. I am not trying to write something for C. (Though if the project's a success, someone will eventually write an XBNF syntax definition of it.) > Also, parsing the syntax is only a minor step in most actual compilers. The point with XBNF is its flexibility and the fact that it *is* just a meta-language. Syntaces can be written for every programming language, every OS, every machine architecture and for every stage of a compilation. In this system, the problems dealt with by the initial "lexer hack", are dealt with by xbnf's use of symbol tables (somewhat like Clang, I guess). > The big pile of work is in the optimizer (which is in theory optional) That is low a priority. > and the code generator, That's just a matter of writing XBNF syntax and output files for the CPU software model. > and another big pile is in the library. Pure C > without the library is good for nothing. You're talking about the linker now, not the compiler. > That's why most regulars in this group are rather sceptical of Flibble's > project. A more realistic approach would sit on top of LLVM, where years > of work have been done already. Looks good. But I'll continue with XBNF. If nothing else, it provides the open source community with another alternative to the over-complication and versionitis of present-day offerings, to the lack of access to machine idiosyncracies, and to corporate rapacity. |
| boltar@nowhere.co.uk: Dec 02 08:33AM On Sun, 1 Dec 2019 18:33:25 +0100 >The big pile of work is in the optimizer (which is in theory optional) >and the code generator, and another big pile is in the library. Pure C >without the library is good for nothing. Depends if you can embed assembler in it or not. If not its basically useless, if you can it becomes a posh assembler. |
| boltar@nowhere.co.uk: Dec 02 08:34AM On Sun, 01 Dec 2019 19:27:21 -0600 >community with another alternative to the over-complication and versionitis >of present-day offerings, to the lack of access to machine idiosyncracies, >and to corporate rapacity. Newflash - no one cares. As long as the compiler compiles their code and does a reasonable optimisation job thats all that matters to them. Whether "cc" calls gcc, clang or something else is irrelevant unless they're trying to use some bleeding edge features. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Dec 02 04:21AM -0600 boltar wrote: > > source community with another alternative to the over-complication > > and versionitis of present-day offerings, to the lack of access to > > machine idiosyncracies, and to corporate rapacity. I should have said "xbnf"; XBNF itself is done, and is and advance in that area. It will continue regardless. It's xbnf that will provide the alternative. > and does a reasonable optimisation job thats all that matters to them. > Whether "cc" calls gcc, clang or something else is irrelevant unless > they're trying to use some bleeding edge features. You're missing the point. Compilers and languages both are becoming more and more affected by versionitis, and the resultant compatibility issues. This puts version control in the programmer's hands. |
| 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