- Rust has the same memory problem as C and C++ - 12 Updates
- How to use extern C with _Bool - 5 Updates
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 23 09:01AM +0200 Le 22/04/2020 à 13:52, Öö Tiib a écrit : > It is no way feature of JavaSript any more than Win32 Bluetooth API > is feature of C somehow. > <https://docs.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-start-page> The point is that you can use Bluetooth from java script without using inline asm or C or other non java script stuff. The problem with Rust is that you are forced to use procedures declared as "unsafe" for doing that, leaving the promises of the Rust language of safe memory operations. The solution for Rust would be to drop "unsafe" and stick with its language throughout. A FFI would provide the interface to any API declared for C or C++. But that would have a cost in performance since you would have to go through an interface, and the designers decided against it, for performance's sake. And that is the problem. They opened the Pandora box. jacob |
| Juha Nieminen <nospam@thanks.invalid>: Apr 23 07:04AM >>> Can you get it to run and produce a rendering? ct_plane.ppm >> Oh you used complex ;) > bingo! Therefore its C++... ;^) Hey, at least it doesn't use "typedef struct whatever { ... } whatever;" Also, I'm not sure it's completely valid C++ either, since it uses "sin" and "cos" without the namespace specifier and without a <cmath>/<math.h> include. (If I understand correctly those names are guaranteed to be in the global namespace only if you #include <math.h>, which is not done here. I'm not sure those names are guaranteed to be defined at all without <math.h> or <cmath>. I don't know if #include <complex> guarantees <cmath>.) |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 23 09:15AM +0200 Le 22/04/2020 à 22:52, Dan Cross a écrit : > features; use of that superset is even preceded > by the `unsafe` keyword, so the notion of unsafety > is built into the language at the syntactic level. The problem with Rust is then, that to do anything like bluetooth or low level i/o you have to use "unsafe". Then, you are in your own and all the problems of C and C++ appear, eliminating any advantage of Rust over those languages, the point I wanted to make with the article where I started this thread. > that it's up to the programmer to enforce those > guarantees. Second, it's a note to future > programmers that, "there be dragons here." No checks, yes. I am used to it since I program in C. My point is, what's the point of learning Rust since I have to do the same thing as in C... > in question violated Rust's rules through misuse > of `unsafe`. In other words, the programmers > messed up. Of course the programmers messed up. Just like in C I mess up sometimes. > could have restricted themselves to the safe > subset of the language, it's not clear that any > of these bugs would have been arisen. The point being here, is that they CAN'T RESTRICT THEMLSEVES TO THAT SAFE PART because they have to do things that are necessary and not possible within the safe part! Can Rust > but I don't think anyone disputes that. Rust > helps, but doesn't absolve programmers from > knowing what they are doing. I.E. the added value of Rust is zero. > over-used by those getting working with the > language for the first time. > - Dan C. In the article they point out to bugs in the standard library of Rust, i.e. programmers that should be fairly advanced... I do not blame them. Programming is hard. I just wanted to point out that there is NO magic bullet, no language that will be of help, unless the language takes a performance hit by checking everything. I wrote a container library for C. Should I check everything? Should all functions check for NULL values or wrong parameters? That slows down the library... And I decided against performance. We have now machines that run at incredible speeds with vast amounts of memory and ressources and we still hesitate to make that NULL check? This obsession with performance is what I question in Rust. They should never allow "unsafe". The whole point of a new language disappears then. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 23 12:18AM -0700 On Thursday, 23 April 2020 10:04:33 UTC+3, Juha Nieminen wrote: > namespace only if you #include <math.h>, which is not done here. I'm not sure > those names are guaranteed to be defined at all without <math.h> or <cmath>. > I don't know if #include <complex> guarantees <cmath>.) The <complex> guarantees overloads like std::cos(const std::complex<T>& x). The lookup rules quarantee looking cos up in std namespace when argument std::complex is in that namespace. |
| Juha Nieminen <nospam@thanks.invalid>: Apr 23 11:19AM > The <complex> guarantees overloads like std::cos(const std::complex<T>& x). > The lookup rules quarantee looking cos up in std namespace when argument > std::complex is in that namespace. In this case sin() and cos() are being called with double type parameters. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 23 05:38AM -0700 On Thursday, 23 April 2020 14:19:27 UTC+3, Juha Nieminen wrote: > > The lookup rules quarantee looking cos up in std namespace when argument > > std::complex is in that namespace. > In this case sin() and cos() are being called with double type parameters. The overloads that take fundamental parameters are not guaranteed by <complex> and also the namespace lookup does not work with those. It is another lousy thing with those textual inclusions ... implementation "may". So it is likely that on some platforms additional #includes and/or qualification is needed. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 23 01:53PM > the problems of C and C++ appear, eliminating any advantage of Rust over > those languages, the point I wanted to make with the article where I > started this thread. It is not problem if you sepparate unsafe and safe code. Small portions written in unsafe code and well tested... > No checks, yes. I am used to it since I program in C. My point is, > what's the point of learning Rust since I have to do the same thing as > in C... Point is that you don't have to program in unsafe blocks all the time... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... 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 |
| cross@spitfire.i.gajendra.net (Dan Cross): Apr 23 06:57PM In article <r7rfb2$bsu$1@dont-email.me>, >the problems of C and C++ appear, eliminating any advantage of Rust over >those languages, the point I wanted to make with the article where I >started this thread. That's simply not true, or rather, not true to the extent the paper's authors make it out to be. I've written three kernels in Rust now, including doing lots of "low-level i/o" and you'd be really surprised how far you can push safe code. >No checks, yes. I am used to it since I program in C. My point is, >what's the point of learning Rust since I have to do the same thing as >in C... Seat belts don't save all lives, so what's the point of wearing a seat belt? A blade guard on a table saw can't stop you from _ever_ cutting off your fingers, so why bother? Rust can't prevent _all_ bugs; but that's axiomatic. But like all sorts of safety apparatus, it can cut out a lot of them. You may have to do some, or even many things the same way you do them in C. But many bugs that would be runtime failures in C will be compile-time errors in Rust. >> of `unsafe`. In other words, the programmers >> messed up. >Of course the programmers messed up. Just like in C I mess up sometimes. Obviously it won't prevent you from _ever_ messing up. It just dramatically decreases the possible error surface. >The point being here, is that they CAN'T RESTRICT THEMLSEVES TO THAT >SAFE PART because they have to do things that are necessary and not >possible within the safe part! I find this argument specious at best. I've written a lot of Rust code in the last two years and more often than not, _most_ programmers _can_ restrict themselves to that safe subset. Where they cannot, the interface can be tightly controlled. I've written a lot _more_ C code over three decades. The things you can do in Rust with respect to safetly are things you simply cannot do in C or C++. >> helps, but doesn't absolve programmers from >> knowing what they are doing. >I.E. the added value of Rust is zero. I'm sorry, but that's ridiculous. Have you ever actually written anything in Rust? >> language for the first time. >In the article they point out to bugs in the standard library of Rust, >i.e. programmers that should be fairly advanced... Certainly there are bugs. Now compare the number of bugs in the Rust standard library to the number of bugs in, e.g., glibc. >I do not blame them. Programming is hard. I just wanted to point out >that there is NO magic bullet, no language that will be of help, unless >the language takes a performance hit by checking everything. I don't think anyone suggest that Rust is a silver bullet. Also, I think you probably haven't written much if anything in Rust. Much of the burden of the types of checks you describe are shifted to compile time in the safe subset. The properties of the language allow the compiler to make assertions that just cannot be made in, say, a C program. In many ways, Rust is more restrictive, but that's a tradeoff: one trades permissiveness for safety without a runtime penalty. >And I decided against performance. We have now machines that run at >incredible speeds with vast amounts of memory and ressources and we >still hesitate to make that NULL check? If I can create a situation where I _know_ that, say, a pointer _cannot_ be NULL, then why would i check it for NULL? static const char *foo = "hi"; if (foo != NULL) { if (strcmp(foo, "hi") == 0) printf("Hi!\n"); Here, the check for `NULL` is obviously superflous; the programmer could omit it without sacrificing correctness or safety. In Rust, the semantics of the language are such that the compiler can often make this determination _at compile time_ (note that even a C compiler can do this for this particular, contribed example). >This obsession with performance is what I question in Rust. They should >never allow "unsafe". The whole point of a new language disappears then. `unsafe` exists for situations where you need `unsafe`: that sounds tautological, but the safe subset of the language is _sometiems_ too restrictive. The seatbelt in my car prevents me from flying through the windshield should I get into a crash. That's good, but it also precents me from picking something up from the floor at the other seat if I'm stopped. I don't care to do it, but if I'm stopped at e.g. a traffic light I have occasionally taken the car out of gear, unbuckled the seatbelt, reached over, and retrieved something that fell, then re-buckled my seatbelt and put the car back into gear. I don't think anyone would argue that that renders seatbelts "useless". That's the analogous situation with Rust's `unsafe` superset. - Dan C. |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 23 10:19PM +0200 Am 22.04.20 um 13:52 schrieb Öö Tiib: > It is no way feature of JavaSript any more than Win32 Bluetooth API > is feature of C somehow. > <https://docs.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-start-page> The point was, if I understood you correctly, that for access of I/O devices like camera, microphone, acceleration, fancy graphics etc. you call out to unsafe APIs, and that in most high level languages (with no direct access to memory) you need to interface in an unsafe way with C APIs, which means that to be useful, a language must provide a unsafe FFI to support C APIs - or otherwise can do only "boring" programs like numerical calculations. JavaScript in the browser is a counterexample because many - if not all - of the things you mentioned are wrapped in a safe way and standardized. It is impossible from JavaScript to execute arbitrary native code, for security reasons, and still you can write very useful software in it, because the standard library provides safe access to all those features. E.g. there are videoconferencing systems written in JavaScript, you can write games, etc. Plus all of this is moderately portable across OSes and to some extent across browsers. Christian |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:49PM -0700 On 4/23/2020 12:04 AM, Juha Nieminen wrote: > Hey, at least it doesn't use "typedef struct whatever { ... } whatever;" > Also, I'm not sure it's completely valid C++ either, since it uses "sin" and > "cos" without the namespace specifier and without a <cmath>/<math.h> include. Yup! I totally forgot to add std:: to many function calls! Damn. I was quickly porting this from C over to C++, and it slipped my mind. ;^o |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:51PM -0700 On 4/23/2020 1:49 PM, Chris M. Thomasson wrote: >> include. > Yup! I totally forgot to add std:: to many function calls! Damn. I was > quickly porting this from C over to C++, and it slipped my mind. ;^o I forgot <cmath> as well. Missed it when everything compiled right up with just <complex>. double damn! ;^o |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 24 12:10AM +0200 On 23.04.2020 22:49, Chris M. Thomasson wrote: >> include. > Yup! I totally forgot to add std:: to many function calls! Damn. I was > quickly porting this from C over to C++, and it slipped my mind. ;^o Always compile with at least 2 compilers, if possible. > [snip] - Alf |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Apr 23 04:50AM -0700 I have a function in a C source file as follows: #include <stdbool.h> int EnableDebug(bool en_dbg) { /* Do Something */ return 0; } I compile this C source file to an object file. Later I want to use it in a C++ program, and so I need to declare this function in a C++ header. But which one do I use? extern "C" int EnableDebug(bool); or: extern "C" int EnableDebug(int); My understanding in C is that "bool" is a typedef for "_Bool". But is "_Bool" just a regular 'int' or is it something smaller (e.g. char) ? |
| "Öö Tiib" <ootiib@hot.ee>: Apr 23 05:46AM -0700 On Thursday, 23 April 2020 14:50:30 UTC+3, Frederick Gotham wrote: > or: > extern "C" int EnableDebug(int); > My understanding in C is that "bool" is a typedef for "_Bool". But is "_Bool" just a regular 'int' or is it something smaller (e.g. char) ? So use bool and require C code to #include <stdbool.h>. AFAIK C _Bool and C++ bool are same type (in every ABI in practice) but I do not know if it is formally guaranteed somewhere or not. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 23 02:38PM +0100 On Thu, 23 Apr 2020 05:46:06 -0700 (PDT) > So use bool and require C code to #include <stdbool.h>. AFAIK C _Bool > and C++ bool are same type (in every ABI in practice) but I do not > know if it is formally guaranteed somewhere or not. I should either (i) use int for both C and C++, or (ii) use _Bool/bool for both C and C++, and not mix ints with bools. bool(0.5) is different in both languages from int(0.5). As I recall it when I looked into it there was no requirement for C's _Bool to be the same size as C++'s bool, although it would be a brain dead implementation which made them different sizes. As an aside, I cannot now recall whether the incorporation of parts of C into C++ in Annex C formally requires C's ints to be the same size as C++'s ints but I think it is implicit from the incorporation of parts of C's standard library into C++ that they must be. |
| David Brown <david.brown@hesbynett.no>: Apr 23 03:54PM +0200 On 23/04/2020 15:38, Chris Vine wrote: > Annex C formally requires C's ints to be the same size as C++'s ints > but I think it is implicit from the incorporation of parts of C's > standard library into C++ that they must be. I expect that technically the C++ compiler is a separate implementation from the C compiler, even when they are both part of the same package (like gcc). In C++, "int" used by functions in the C library must match "int" used by other parts of C++, but there is no requirement that it match "int" used by a C compiler, or by any other compiler on the system. The same applies between two C compilers on the same system. But as you say, it would take a brain-dead implementation to end up with anything different in "int" (or bool/_Bool) on a given platform. These sorts of things are specified in platform ABI's and any compiler for C or C++ will follow the ABI for the platform. (I know of a couple of C compilers where the size of "int" can be changed from the command line, but these won't be of concern to most people.) |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 23 10:28AM -0400 On 4/23/20 9:38 AM, Chris Vine wrote: ... > Annex C formally requires C's ints to be the same size as C++'s ints > but I think it is implicit from the incorporation of parts of C's > standard library into C++ that they must be. I agree. The C standard says nothing about interoperability with C++, and the C++ standard says very little about interoperability with C. However, <stdbool.h> and <cstdbool> are both supported headers in C++, and are both prohibited from defining the macro named 'bool' that is a mandatory feature of <stdbool.h> in C. There would be almost no point in allowing those headers in C++, if C++ bool isn't compatible with C's _Bool type. |
| 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