Hi Mat With the current Gcc compiler
const char *post ="abcdefghij"; *post='5'; generates a compiler error as post is pointing to a read only string which could be in read-only memory. instead char post[]="abcdefghij"; allows *post = '5'; with const char const *post both post is blocked from changing and you may not modify the string. If you attempt to do so, ==>compiler diagnostic and no object file is created. Regards Leslie Mr. Leslie Satenstein 50 years in Information Technology and going strong. Yesterday was a good day, today is a better day, and tomorrow will be even better. mailto:[email protected] alternative: [email protected] www.itbms.biz www.eclipseguard.com Regards Leslie Mr. Leslie Satenstein 50 years in Information Technology and going strong. Yesterday was a good day, today is a better day, and tomorrow will be even better. mailto:[email protected] alternative: [email protected] www.itbms.biz www.eclipseguard.com --- On Fri, 8/10/12, Mathieu Trudel-Lapierre <[email protected]> wrote: From: Mathieu Trudel-Lapierre <[email protected]> Subject: Re: [MLUG] Obsolete C To: "Montreal Linux Users Group" <[email protected]> Date: Friday, August 10, 2012, 12:07 AM On Thu, Aug 9, 2012 at 1:07 PM, Hendrik Boom <[email protected]> wrote: [...] > I'll give a technical argument about the kind of thing that's > wrong with C. Thanks. I figured that with your background there's be really good argumentation. > > You can't write any significant program in it without using unsafe > features, such as pointer arithmetic, or malloc/free. Corresponding > safe features (such as bounds-checked subscripts or > garbage-collectin) just don't exist in the language. Agree, but I don't think the fact that it's unsafe makes it obsolete. Programming is art. There will always be those who program for fun, those who program for a living, and the prodigy; and they'll have varying levels of success with a particular language like C. [...] > A languagee can have safe and unsafe dialects. In the "safe" dialect > you'd have bounds-checked subscripts and garbage collection. In the > "unsafe" dialect you would have these, but in addition, you could use > explicit pointer arithmetic and explicit storage allocation and > deallocation. Gotcha. I'm just of the opinion that it's just fine if there is a language that is truly powerful but makes the developer jump through a few more hoops, and the "simpler" or more friendly languages that will be perhaps just a little less fast or a little less efficient, yet far easier to develop with. [...] > The vast majority of code in the vast majority of programs never needs > the unsafe features. By making it impoossible to use them by accident, > you achieve a vast improvement in reliability at very low cost. Agreed. It turns out that even the interpreted languages are, in my experience, sufficient for quite a lot of use cases. At least so far Python has certainly proven that it's very flexible. > But C is such that trying to restrict it to its safe subset, > produces an unusable language. Perhaps I'm just a bit of an elitist, even if I'll obviously commit some of the unspeakable horrors than can be make in C code myself, but I think not restricting it is perfectly acceptable. People know to be extra careful when they have to write C, and to get code reviews and write tests. Or at least I hope they do. [...] > You don't have to lose the flexibility and power to gain garbage > collection. Coding convenience. My first conccern in the choice of a > programming language is how easy it is to get a program to be correct. > My second is how fast the code runs, because it doesn't matter how fast > it runs if it's wrong. I have to say, most interpreted languages fail > on both counts. Any set of flexibility, power, execution speed, garbage collection, coding convenience or any property will normally be a trade-off, to varying degrees. You can't expect any language to be the best fix for the task you're trying to accomplish, but need to choose one. I think we're still in full agreement there. C isn't fit for all jobs. Perhaps it's getting chosen a little too fast in many cases, but then, it *does* deliver, despite the high price to pay as a developer for getting it to agree to do the job. [...] > And trying to find out just what X does internally is an almost > impossible task. It isn't even properly documented. I looked for such > documentation a few years ago, and at that time the best documentation > was years obsolete, not recommended, and out of print. Right. X isn't necessarily the best example, but even despite the lack of documentation and really cryptic code (and the tens of years of accumulated cruft), some reimplementation projects are getting real work done and generally being successful... and also being written in C. > > Mind you, I'm not saying you shouldn't use C. Modula 3, for > example, is a better language in many ways, even for the low-level > coding that C was designed for. But it's not widely enough used to > ensure it'll still be there in ten years when you have to migrate your > critical softeare to another OS or annother machine. If you can > afford to maintain and port the language yoursef, though, things can be > different. I know of one copany that's hosting the development > repositories for Moduka 3 to ensure they will have it available > into the future. But that's something to take into account too when building something new. Using a time-proven, widely accepted tool than can be understood by a large number of people is good for companies as well as open source projects. It's a far better idea to use <insert well-known language> than another niche language, even if the other might be a little better, if in the long run it means you can get new employees or new contributors to hit the ground running when they have to touch your software. Economically, it's a huge win. For small projects, just about anything will probably do, but as soon as it gets bigger, it becomes increasingly likely that you can't maintain it alone. What I was getting at with Modula 3 is that there may be what, 20 developers at most who designed the language and looked at the internals? Some of them are probably retired by now, too. That's true for just about any corporate language, and most languages that haven't gained much attention. For C/C++, Java, Perl, Python, etc, there's a pool of thousands and thousands of people who are familiar enough with the language to be efficient programmers, and hundreds who know about the internals, who have contributed to compilers, etc. These languages are still getting lots of attention, which is what makes them not obsolete. I feel a language becomes obsolete at the point where most people want to steer away from a language, and when the pool of people able to use it is reducing. When there are great, time-proven alternatives that "have legs", meaning that they clearly have the same level of power and enough attention. I don't think that's true *yet* for C, but there's a chance to be getting there with Go. Then again, perhaps not. C++ certainly isn't this alternative :) / Matt _______________________________________________ mlug mailing list [email protected] https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
_______________________________________________ mlug mailing list [email protected] https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
