* Re: why learn C? [not found] ` <546qkhF1tr7dtU1@mid.individual.net> @ 2007-02-23 8:09 ` Marc Boyer 2007-03-20 17:37 ` adaworks 0 siblings, 1 reply; 167+ messages in thread From: Marc Boyer @ 2007-02-23 8:09 UTC (permalink / raw) Le 23-02-2007, Default User <defaultuserbr@yahoo.com> a �crit�: > Marc Boyer wrote: > >> Le 22-02-2007, arnuld <geek.arnuld@gmail.com> a �crit�: >> >> > 1. C gives you a strong base of Procedural style of programming >> which >> > forms the basis of learning other paradigms e.g OOP >> > >> >> I am not sure that C gives better 'strong base' than Ada. >> > >> > OK, 1st have to Google for Ada as i never came across some >> > Ada-code. i never even read about its design-goals and/or any >> > articles related to it. >> >> comp.lang.ada >> >> > BTW, your "summary of Ada" can be useful for me, if you can. >> >> In a very few words, Ada is a modern Pascal. > > That's way too few. If you have time to give a long definition of Ada, just do it. > Ada was a language created from scratch for > high-safety programming, commissioned by the US Department of Defense. > It's based on Pascal, but no more a "modern Pascal" than C++ is a > "modern C". I agree. >> And Ada 83 >> is, to me, a very good langage to learn procedural programming. > > It used to be difficult to find free Ada compilers (or even any that > didn't cost a fortune). A brief bit of searching seems to indicate that > that's not so much the case anymore. What about GNAT ? Marc Boyer ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-02-23 8:09 ` why learn C? Marc Boyer @ 2007-03-20 17:37 ` adaworks 2007-03-21 8:07 ` Maciej Sobczak ` (3 more replies) 0 siblings, 4 replies; 167+ messages in thread From: adaworks @ 2007-03-20 17:37 UTC (permalink / raw) "Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message > > > If you have time to give a long definition of Ada, just do it. > Definition is not a word that would apply when one is seeking a deeper understanding of a subject. One could provide a definition of calculus, quantum mechanics, or the word, virus, but a definition would not provide a deep insight into those subjects. Ada is a language designed to maximize the amount of error detection as early in the development process as possible, and throughout each subsequent step of that process. Ada provides the developer with more engineering tools and idioms for the development of software than one finds in a lot of other languages. A source code model, in the form of Ada package specifications, can be created long before anyone writes any algorithmic code. The entire design can be structured and tested prior to committing too much to small details. For a large project, where many thousands of lines of code are required, that project can be decomposed and distributed over several programming teams without excessive worry about whether the resulting code will conform to the design. Unlike the C family of languages, which are generally no help at all, an Ada compiler frequently eliminates the need for extensive debugging of silly errors; e.g., the kind that originate from case-sensitivity, wrong order of arguments to parameters, improper spacing, missing curly-braces, and the plethora of language "features" that plague those who have chosen to use any member of the C family of languages. It has always seemed rather odd to me that people who are as intelligent as programmers, rarely question the silliness of using tools such as C and C++ for serious work. They simply take for granted that the kind of errors that are so common in those languages are somehow akin to the laws of nature. Java inherits many of those same properties and is not much better. It is taken as an article of faith that programming involves heavy use of debuggers. Instead of asking why this is so, they simply believe it is a fundamental law of programming -- mainly because the languages they have chosen make it so. Ada is a programming language that makes it easier to focus on the design before dealing with the details of that design. Then, Ada makes it easier to ensure that the details conform to the design. I wonder why that is such a difficult concept for so many. Richard Riehle It always amazes me that someone would choose an error-prone programming language such as C++ and expect error-free programs. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-20 17:37 ` adaworks @ 2007-03-21 8:07 ` Maciej Sobczak 2007-03-21 13:39 ` Martin Krischik ` (2 more replies) 2007-03-21 13:29 ` why learn C? Alexander E. Kopilovich ` (2 subsequent siblings) 3 siblings, 3 replies; 167+ messages in thread From: Maciej Sobczak @ 2007-03-21 8:07 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > Unlike the C family of languages, I presume you mean C, C++, D, Java, C#. > which are generally no help at all, That's indeed "generally". > an Ada compiler frequently eliminates the need for extensive debugging > of silly errors; e.g., the kind that originate from case-sensitivity Tha last time I made case-sensitivity error the compiler helped me. > wrong > order of arguments to parameters I can do this error in Ada quite easily. Yes, there are named parameters in Ada. And structures with named components in other languages. > improper spacing, Please provide an example of code where improper spacing leads to extensive debugging. > missing curly-braces, The last time I missed the curly brace the compiler told me that. (for the sake of this discussion let's forget about the fact that in any self-respecting programmer's editor missing curly-brace is plain impossible, because braces are part of text formatting rules) > and the plethora of language "features" that plague those who have > chosen to use any member of the C family of languages. Any language (from any family) older than one version has "features". > It has always seemed rather odd to me that people who are as intelligent > as programmers, rarely question the silliness of using tools such as C > and C++ for serious work. Maybe because they are intelligent and can reasonably balance pros and cons of various technology choices. > They simply take for granted that the kind > of errors that are so common in those languages are somehow akin to > the laws of nature. That's a good point and indeed a significant fraction of the community takes errors as part of the game. But I wouldn't attribute it only to the language choice (although that's an important factor indeed), also to the massive approach to education ("learn programming in 24 hours now!"). Teach millions to program in Ada and you get tons of crappy code. > Java inherits many of those same properties and > is not much better. True. > It is taken as an article of faith that programming > involves heavy use of debuggers. Not necessarily. The advocates of test-driven development (TDD for short) openly say good bye to debuggers, at least in blogs. > Ada is a programming language that makes it easier to focus on the design > before dealing with the details of that design. Yes, but Ada is not unique here. In C++ or Java you can do a lot of design before actual implementation starts. > Then, Ada makes it easier to > ensure that the details conform to the design. Yes, but Ada is not unique here. There are differences in what is the scope and precision of design expression, of course, and this is where Ada shines. But conformance between the details and the design (specs) is ensured in every static language. > I wonder why that is such > a difficult concept for so many. It isn't. Only the tradeoffs change. > It always amazes me that someone would choose an error-prone > programming language such as C++ and expect error-free programs. It always amazes me that someone would choose a language that has no measurable user base such as Ada and expect to build a successful team. The missing user base is one of two major problems that prevent me from starting an Ada project, whether at work or in my free time. The other is the lack of *free* Ada compiler on one of my target platforms (LynxOS). "There are just two kinds of languages: the ones everybody complains about and the ones nobody uses." - Bjarne Stroustrup. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 8:07 ` Maciej Sobczak @ 2007-03-21 13:39 ` Martin Krischik 2007-03-22 7:54 ` Maciej Sobczak 2007-03-21 14:10 ` Dmitry A. Kazakov 2007-03-21 18:48 ` adaworks 2 siblings, 1 reply; 167+ messages in thread From: Martin Krischik @ 2007-03-21 13:39 UTC (permalink / raw) Maciej Sobczak schrieb: >> missing curly-braces, > > The last time I missed the curly brace the compiler told me that. The editor to fix deficiencies of the language - great! > (for the sake of this discussion let's forget about the fact that in any > self-respecting programmer's editor missing curly-brace is plain > impossible, because braces are part of text formatting rules) I guess he speaks of if (X=1) A=2; B=2; and if (X=1); A=2; i.E. you forget the both - in which case no editor will help you. >> and the plethora of language "features" that plague those who have >> chosen to use any member of the C family of languages. > > Any language (from any family) older than one version has "features". But if you start with too few features and a foundation to weak to build on (in version 1) then add on features are a greater problem (in version 3). In the end worse is not better. >> It has always seemed rather odd to me that people who are as intelligent >> as programmers, rarely question the silliness of using tools such as C >> and C++ for serious work. > > Maybe because they are intelligent and can reasonably balance pros and > cons of various technology choices. I did and after 10+ years of C/C++ the scale finally tilted and I switched to Ada. Recently I went to an Weblogic course with lots of Java in it - yuck! > "There are just two kinds of languages: the ones everybody complains > about and the ones nobody uses." - Bjarne Stroustrup. :-\ Martin ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 13:39 ` Martin Krischik @ 2007-03-22 7:54 ` Maciej Sobczak 0 siblings, 0 replies; 167+ messages in thread From: Maciej Sobczak @ 2007-03-22 7:54 UTC (permalink / raw) Martin Krischik wrote: >>> missing curly-braces, >> >> The last time I missed the curly brace the compiler told me that. > > The editor to fix deficiencies of the language - great! There is no word "editor" above. I said "compiler". > I guess he speaks of > > if (X=1) > A=2; > B=2; > > and > > if (X=1); > A=2; > > i.E. you forget the both - in which case no editor will help you. My editor will help me. I have a coding standard that prevents me from writing if (same with while, for, etc.) without any braces, so the above will not even go to the compilation stage. You can call it "fixing the defficiencies of the language", I call it "extending the static tool-chain which is already multiphase anyway". The final effect - which is really the only thing that matters - is that I *don't* have these problems. But I agree that the bare possibility (standard-wise) to do the above is a bad thing. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 8:07 ` Maciej Sobczak 2007-03-21 13:39 ` Martin Krischik @ 2007-03-21 14:10 ` Dmitry A. Kazakov 2007-03-21 17:57 ` adaworks 2007-03-21 18:48 ` adaworks 2 siblings, 1 reply; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-03-21 14:10 UTC (permalink / raw) On Wed, 21 Mar 2007 09:07:30 +0100, Maciej Sobczak wrote: > "There are just two kinds of languages: the ones everybody complains > about and the ones nobody uses." - Bjarne Stroustrup. Looks that he isn't much satisfied with his life work? To me C++ has too much aftertaste, like a sticky candy found in a pocket of your old coat... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 14:10 ` Dmitry A. Kazakov @ 2007-03-21 17:57 ` adaworks 0 siblings, 0 replies; 167+ messages in thread From: adaworks @ 2007-03-21 17:57 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:10qp8zioik6f5$.11yljhdfb5t44$.dlg@40tude.net... > On Wed, 21 Mar 2007 09:07:30 +0100, Maciej Sobczak wrote: > >> "There are just two kinds of languages: the ones everybody complains >> about and the ones nobody uses." - Bjarne Stroustrup. > > Looks that he isn't much satisfied with his life work? > > To me C++ has too much aftertaste, like a sticky candy found in a pocket of > your old coat... > Or like peanut brittle. It can initially taste good, but it eventually helps rot your teeth (or program), and breaks easily. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 8:07 ` Maciej Sobczak 2007-03-21 13:39 ` Martin Krischik 2007-03-21 14:10 ` Dmitry A. Kazakov @ 2007-03-21 18:48 ` adaworks 2007-03-21 18:39 ` Georg Bauhaus ` (2 more replies) 2 siblings, 3 replies; 167+ messages in thread From: adaworks @ 2007-03-21 18:48 UTC (permalink / raw) "Maciej Sobczak" <no.spam@no.spam.com> wrote in message news:etqp42$4g6$1@cernne03.cern.ch... > adaworks@sbcglobal.net wrote: > >> Unlike the C family of languages, > > I presume you mean C, C++, D, Java, C#. > Actually, D and C# seem a little better than the others you named. In fact, there are some features of C# I quite like, especially when one compares Java. > > Tha last time I made case-sensitivity error the compiler helped me. > But C/C++/Java compilers are not consistent in this respect, and one would be foolish to rely on them for that. > >> wrong order of arguments to parameters > > I can do this error in Ada quite easily. > Unless you use named association and avoid the use of predefined types. > > Yes, there are named parameters in Ada. And structures with named components > in other languages. > This is not even an option in C/C++/Java/ or other of the C family. > > Please provide an example of code where improper spacing leads to extensive > debugging. > Another responder dealt with this. > >> missing curly-braces, > > The last time I missed the curly brace the compiler told me that. > It is not the absence of a single curly-brace, but the occasional absence of a pair of them that sometimes leads to long and entertaining sessions of debugging. This would not happen in Ada. > > (for the sake of this discussion let's forget about the fact that in any > self-respecting programmer's editor missing curly-brace is plain impossible, > because braces are part of text formatting rules) > As noted, the problem is not a single missing curly brace. Further, misplacement of a curly-brace can also be highly entertaining. Units in Ada, including declare blocks (which ought to be used minimally) have the option of being named. I use this option consistently. I don't have that option in any of the C family of languages. > >> and the plethora of language "features" that plague those who have >> chosen to use any member of the C family of languages. > > Any language (from any family) older than one version has "features". > And some have more "features" than others. > >> It has always seemed rather odd to me that people who are as intelligent >> as programmers, rarely question the silliness of using tools such as C >> and C++ for serious work. > > Maybe because they are intelligent and can reasonably balance pros and cons of > various technology choices. > I rather think not. With all the advantages of Ada over the C family of languages, it simply makes no sense to choose one of those languages for any reason other than their availability. It is somewhat like going to a fast-food restaurant instead of a restaurant where one would get better quality food. The fast food restaurants are quite popular, but they are not especially beneficial froma dietary perspective. > >> They simply take for granted that the kind >> of errors that are so common in those languages are somehow akin to >> the laws of nature. > > That's a good point and indeed a significant fraction of the community takes > errors as part of the game. But I wouldn't attribute it only to the language > choice (although that's an important factor indeed), also to the massive > approach to education ("learn programming in 24 hours now!"). > Teach millions to program in Ada and you get tons of crappy code. > I take your point. No language by itself can eliminate stupidity. However, choosing good tools can make a difference. Ada is not the right tool for everything. I like some of the languages such as Python and Ruby that have recently come on the scene. However, those languages are not suitable for every kind of problem. We always want to choose the right tool for the right job. This discussion centers around the idea of debugging. Even crappy Ada is less likely to lead to the onerous level of debugging found in C or C++. >> Java inherits many of those same properties and is not much better. > > True. > >> It is taken as an article of faith that programming >> involves heavy use of debuggers. > > Not necessarily. The advocates of test-driven development (TDD for short) > openly say good bye to debuggers, at least in blogs. > I am quite aware of TDD. I am not a fan. While many of the claims of the TDD advocates have some virtue, it is a fact that not all errors in a program can be detected through testing. Further, as Dijkstra notes, "We can test for the presence of errors, but not for their absence." TDD can be a good technique for augmenting the correctness of a design and its implementation, but it is no substitute for other methods. Reliance on TDD exclusively seems a bit foolhardy, just as reliance on type-safety alone, inspection alone, exception handling alone, or any of the other popular approaches to software dependability. > Too many TDD advocates seem to reject the importance of developing rigorous software requirements prior to beginning the programming process. The notion that the tests are the requirements is naive, at best. This might work for smaller software projects where the domain is well-understood, but it is not appropriate for large-scale software systems where dependability is life or mission critical. > >> Ada is a programming language that makes it easier to focus on the design >> before dealing with the details of that design. > > Yes, but Ada is not unique here. In C++ or Java you can do a lot of design > before actual implementation starts. > The design of Java fails to encourage good design. This is, in part, due to the tight relationship between all of its parts within a single library and compilation unit. C++, while supporting a model of separate compilation, does not support it well. The relationship between the specification and the implementation in C++ is sloppy, at best. > >> Then, Ada makes it easier to ensure that the details conform to the design. > > Yes, but Ada is not unique here. There are differences in what is the scope > and precision of design expression, of course, and this is where Ada shines. > But conformance between the details and the design (specs) is ensured in every > static language. > Well, this is not the case unless one jumps through a lot of hoops to make sure it is. It is certainly not the case in C++. Consider the requirement for #IFNDEF and other bits of fluff that a C++ programmer must provide to ensure that all the pieces are where they ought to be. Ada provides the developer with options that make it much more likely that everything will snap together as expected. It gives more of an engineering flavor of the design and development process. While it is true that an Ada developer need not use the options that provide this capability, those options are not even available in C, C++, Java, D, or C#. If I have a torque wrench available and fail to use it, the twisting of the head from the bolt is my fault. If, however, I use the torque wrench correctly, I have a greater chance of doing the job right. Ada is like a torque wrench in software. I can measure the level of torque more easily than I can simply using any old long handled wrench. C and C++ are like a long-handled wrench. I can do the job, but I have little hope of getting it right, and I don't know I've gotten it wrong until it breaks. That is one of things I find so fascinating about modern programming: that programmers take for granted that they cannnot know how good their program is until something breaks. With Ada (and also with Eiffel), one can know much more about what might break, can prevent such breakage before it happens, and can set the limits for breakages so they are less probable at testing time and deployment time. > >> I wonder why that is such a difficult concept for so many. > > It isn't. Only the tradeoffs change. > >> It always amazes me that someone would choose an error-prone >> programming language such as C++ and expect error-free programs. > > It always amazes me that someone would choose a language that has no > measurable user base such as Ada and expect to build a successful team. > Again. I would rather eat at a good restaurant than at a popular fast-food restaurant, even though such restaurants are not as abudant. > > The missing user base is one of two major problems that prevent me from > starting an Ada project, whether at work or in my free time. > The other is the lack of *free* Ada compiler on one of my target platforms > (LynxOS). > One must live with the limitations imposed. If there is no compiler for the platform, the choices are not as happy. Also, as I noted earlier, Ada is not the only good tool and is not the right tool in every case. However, from my perspective, C++ ought to be the tool of last resort. > > "There are just two kinds of languages: the ones everybody complains about and > the ones nobody uses." - Bjarne Stroustrup. > Dr. Stroustrup did a remarkable design within a boundary that imposed a lot of restrictions that, even he admits, were not ideal. Given the constraints at the time C++ was designed, no one can fault him or criticize him for his work. It was brilliant. However, I am reminded of a TV show called McGiver where the hero, also highly intelligent and innovative, was able to invent solutions with a minimum of resources at hand. Even the most brilliant of minds, when constrained by an context that limits the options for a design, will produce a solution that is less than ideal. The Pythagoreans fell short of their goal of making "number" the universal foundation for an enduring religion. They simply did not have everything they needed to make that happen. Renes Descartre could not quite bring himself to recognize negative coordinates. Many brilliant people over the millennia have made significant contributions within the constraints of their environment and context. C++ was a brilliant piece of design. It is just not good enough when one considers the other options currently available. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 18:48 ` adaworks @ 2007-03-21 18:39 ` Georg Bauhaus 2007-03-21 20:09 ` Dmitry A. Kazakov 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt 2 siblings, 0 replies; 167+ messages in thread From: Georg Bauhaus @ 2007-03-21 18:39 UTC (permalink / raw) On Wed, 2007-03-21 at 10:48 -0800, adaworks@sbcglobal.net wrote: > "Maciej Sobczak" <no.spam@no.spam.com> wrote in message > > Yes, there are named parameters in Ada. And structures with named components > > in other languages. > > > This is not even an option in C/C++/Java/ or other of the C family. C99 has finally got named components, though. Consistent with the language, it doesn't seem necessary to give a value to all components of C's equivalent of aggregates: struct foo { int real_part; int surreal_part; }; typedef struct foo Foo; Foo plus(Foo a, Foo b) { const Foo result = { .real_part = a.real_part + b.real_part, // .surreal_part = a.surreal_part + b.surreal_part // fine? }; return result; } ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-21 18:48 ` adaworks 2007-03-21 18:39 ` Georg Bauhaus @ 2007-03-21 20:09 ` Dmitry A. Kazakov 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt 2 siblings, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-03-21 20:09 UTC (permalink / raw) On Wed, 21 Mar 2007 10:48:45 -0800, adaworks@sbcglobal.net wrote: > "Maciej Sobczak" <no.spam@no.spam.com> wrote in message > news:etqp42$4g6$1@cernne03.cern.ch... >> Not necessarily. The advocates of test-driven development (TDD for short) >> openly say good bye to debuggers, at least in blogs. >> > I am quite aware of TDD. I am not a fan. While many of the claims of > the TDD advocates have some virtue, it is a fact that not all errors in a > program can be detected through testing. Further, as Dijkstra notes, "We > can test for the presence of errors, but not for their absence." I don't think that this is the main weakness of "spinal driven" design. A more fundamental problem I see in TDD, is that it does not define what is the goal to achieve [by means of programming]. Dijkstra's critique presumes existence of some stated correct program behavior. But TDD does not have it. The target is moving, and all but visible. That is supposed to be a strength of the approach. But as a consequence the very word "correct" looses any meaning. Does TDD converge? If it does, what are the properties of what it would to? What about metrics? etc. In short, I don't trust in "tests as specifications." -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Use of declare blocks 2007-03-21 18:48 ` adaworks 2007-03-21 18:39 ` Georg Bauhaus 2007-03-21 20:09 ` Dmitry A. Kazakov @ 2007-03-21 20:25 ` Randy Brukardt 2007-03-21 20:36 ` Gautier ` (4 more replies) 2 siblings, 5 replies; 167+ messages in thread From: Randy Brukardt @ 2007-03-21 20:25 UTC (permalink / raw) <adaworks@sbcglobal.net> wrote in message news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net... ... >Units > in Ada, including declare blocks (which ought to be used minimally) > have the option of being named. While I generally agree with Richard, I certainly don't agree on the "ought to be used minimally" here. I use declare blocks extensively to reduce the scope of temporary variables in subprograms. They're especially important when the object exists just to take an unused out parameter, because they greatly reduce the need to come up with names for the objects. I often have code like: declare Junk : Index; begin Insert_Something (..., Result => Junk); end; where the result isn't needed by the following code. (Sure, one could argue that the underlying library should be improved to avoid the need for this, but that isn't always possible and in any case changes to widely used specifications shouldn't be made lightly. And this is just one example, any sort of temporary has these sorts of requirements.) The advantage is that if in the future you find that you no longer need the temporary, you can remove it without heavy code analysis: it is used only in the one place and there is no worries that it might be reused, or have a side-effect, or the like. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt @ 2007-03-21 20:36 ` Gautier 2007-03-21 20:37 ` Gautier ` (3 subsequent siblings) 4 siblings, 0 replies; 167+ messages in thread From: Gautier @ 2007-03-21 20:36 UTC (permalink / raw) They are also pretty useful for make a relatively comfortable use of strings with the fixed-length type String, when you don't want to begin using Unbounded_String and conversions from and towards the type String - IHMO. ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt 2007-03-21 20:36 ` Gautier @ 2007-03-21 20:37 ` Gautier 2007-03-21 20:43 ` Niklas Holsti ` (2 subsequent siblings) 4 siblings, 0 replies; 167+ messages in thread From: Gautier @ 2007-03-21 20:37 UTC (permalink / raw) They are also pretty useful for making a relatively comfortable use of strings with the fixed-length type String, when you don't want to begin using Unbounded_String and conversions from and towards the type String - IHMO. ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt 2007-03-21 20:36 ` Gautier 2007-03-21 20:37 ` Gautier @ 2007-03-21 20:43 ` Niklas Holsti 2007-03-21 21:29 ` Randy Brukardt 2007-03-22 8:34 ` Dmitry A. Kazakov 2007-03-22 1:06 ` Adam Beneschan 2007-03-22 17:59 ` adaworks 4 siblings, 2 replies; 167+ messages in thread From: Niklas Holsti @ 2007-03-21 20:43 UTC (permalink / raw) Randy Brukardt wrote: > I use declare blocks extensively to reduce the scope of temporary variables > in subprograms. They're especially important when the object exists just to > take an unused out parameter, because they greatly reduce the need to come > up with names for the objects. I often have code like: > > declare > Junk : Index; > begin > Insert_Something (..., Result => Junk); > end; > > where the result isn't needed by the following code. How about a language extension to omit unused out parameters, for example Insert_Something (..., Result => <>); Perhaps even allowing declaration of optional out parameters, as in procedure Insert_Something (..., Result : out Index := <>); and then a call of Insert_Something could omit Result entirely. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:43 ` Niklas Holsti @ 2007-03-21 21:29 ` Randy Brukardt 2007-03-22 1:17 ` Adam Beneschan 2007-03-22 8:34 ` Dmitry A. Kazakov 1 sibling, 1 reply; 167+ messages in thread From: Randy Brukardt @ 2007-03-21 21:29 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@nospam.please> wrote in message news:460198f2$0$24601$39db0f71@news.song.fi... > Randy Brukardt wrote: > > > I use declare blocks extensively to reduce the scope of temporary variables > > in subprograms. They're especially important when the object exists just to > > take an unused out parameter, because they greatly reduce the need to come > > up with names for the objects. I often have code like: > > > > declare > > Junk : Index; > > begin > > Insert_Something (..., Result => Junk); > > end; > > > > where the result isn't needed by the following code. > > How about a language extension to omit unused out parameters, for example > > Insert_Something (..., Result => <>); > > Perhaps even allowing declaration of optional out parameters, as in > > procedure Insert_Something (..., Result : out Index := <>); > > and then a call of Insert_Something could omit Result entirely. I think both of these would be a tough sell. I'm sure some people would feel that having an out parameter that you don't need is a design flaw, and we shouldn't be encouraging design flaws. They come up a lot of foreign library interfaces, and I suppose the argument would be that they should be wrapped and hidden (even if that is too expensive for the particular usage). After all, once of the good things about Ada is that you have to do something explicit to ignore returned values (including error returns). If they're mapped as out parameters, you have to write code to discard them (like the above). If they're mapped as exceptions, you have to handle and ignore (with a null handler) the exception (or all exceptions). Both of these are obvious when reading the code. It's a lot harder to detect an error of omission than an error of commission. This is similar in some ways to the arguments against out parameters in functions, where the possibility of unnoticed order dependencies and tricky expressions makes some people uncomfortable. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 21:29 ` Randy Brukardt @ 2007-03-22 1:17 ` Adam Beneschan 0 siblings, 0 replies; 167+ messages in thread From: Adam Beneschan @ 2007-03-22 1:17 UTC (permalink / raw) On Mar 21, 2:29 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote: > "Niklas Holsti" <niklas.hol...@nospam.please> wrote in message > > > declare > > > Junk : Index; > > > begin > > > Insert_Something (..., Result => Junk); > > > end; > > > > where the result isn't needed by the following code. > > > How about a language extension to omit unused out parameters, for example > > > Insert_Something (..., Result => <>); > > > Perhaps even allowing declaration of optional out parameters, as in > > > procedure Insert_Something (..., Result : out Index := <>); > > > and then a call of Insert_Something could omit Result entirely. > > I think both of these would be a tough sell. Not to me. Well, maybe the second one would be. But the first one, the ability to call a procedure with a "please discard this" syntax for an OUT parameter, is something I've often considered suggesting too. Of course, it's just syntactic sugar so it's not all that important, which is one reason why I never bothered to send a proposal to Ada-Comment. But I think it would be a cool feature. I'd use it. > After all, once of the good things about Ada is that you have to do > something explicit to ignore returned values (including error returns). If > they're mapped as out parameters, you have to write code to discard them > (like the above). If they're mapped as exceptions, you have to handle and > ignore (with a null handler) the exception (or all exceptions). Both of > these are obvious when reading the code. It's a lot harder to detect an > error of omission than an error of commission. I'm guessing that you meant this argument to apply only to Niklas's second suggestion, which would allow the out parameter to be eliminated entirely from the procedure call; having something like "Result => <>" in a procedure call seems to satisfy your requirement that you'd have to write code to discard the parameter. -- Adam ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:43 ` Niklas Holsti 2007-03-21 21:29 ` Randy Brukardt @ 2007-03-22 8:34 ` Dmitry A. Kazakov 1 sibling, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-03-22 8:34 UTC (permalink / raw) On Wed, 21 Mar 2007 22:43:58 +0200, Niklas Holsti wrote: > Randy Brukardt wrote: > >> I use declare blocks extensively to reduce the scope of temporary variables >> in subprograms. They're especially important when the object exists just to >> take an unused out parameter, because they greatly reduce the need to come >> up with names for the objects. I often have code like: >> >> declare >> Junk : Index; >> begin >> Insert_Something (..., Result => Junk); >> end; >> >> where the result isn't needed by the following code. > > How about a language extension to omit unused out parameters, for example > > Insert_Something (..., Result => <>); Unused function results are even more offending. I would like to see: null <expression>; instead of declare Dummy : Guess_What; begin Dummy := <expression>; end; > Perhaps even allowing declaration of optional out parameters, as in > > procedure Insert_Something (..., Result : out Index := <>); > > and then a call of Insert_Something could omit Result entirely. That could be difficult because of discriminants. Consider: procedure Insert_Something (..., Result : in out String (1..80) := <>); procedure Insert_Something (..., Result : in out String (<>) := <>); ... I guess if optional [in] out parameters weren't better solvable with lazy expressions. If the latter were supported one could provide a non-intrusive default for outs without magical stuff like <>. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt ` (2 preceding siblings ...) 2007-03-21 20:43 ` Niklas Holsti @ 2007-03-22 1:06 ` Adam Beneschan 2007-03-22 17:59 ` adaworks 4 siblings, 0 replies; 167+ messages in thread From: Adam Beneschan @ 2007-03-22 1:06 UTC (permalink / raw) On Mar 21, 1:25 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote: > <adawo...@sbcglobal.net> wrote in message > > news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net... > ... > > >Units > > in Ada, including declare blocks (which ought to be used minimally) > > have the option of being named. > > While I generally agree with Richard, I certainly don't agree on the "ought > to be used minimally" here. > > I use declare blocks extensively to reduce the scope of temporary variables > in subprograms. They're especially important when the object exists just to > take an unused out parameter, because they greatly reduce the need to come > up with names for the objects. I often have code like: > > declare > Junk : Index; > begin > Insert_Something (..., Result => Junk); > end; > > where the result isn't needed by the following code. The thing I don't like about this is that it breaks up the algorithm. If you have a sequence of statements that implements some sort of algorithm, or a sequence of steps for getting what you want, I'd prefer to have all the statements together instead of being interrupted by lines with just keywords or declarations that I don't care about and that don't add to my understanding of the program. Having to skip over that stuff is harder on my eyes. But this is IMHO strictly a matter of personal preference and taste; there's certainly nothing wrong with your style and you have good reasons for it. -- Adam ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt ` (3 preceding siblings ...) 2007-03-22 1:06 ` Adam Beneschan @ 2007-03-22 17:59 ` adaworks 2007-03-23 2:35 ` Randy Brukardt 4 siblings, 1 reply; 167+ messages in thread From: adaworks @ 2007-03-22 17:59 UTC (permalink / raw) When I say they "ought to be used minimally," I am speaking from the experience of seeing programmers at former client sites who used them maximally. There are several problems with declare blocks. 1) They often lead to ad hoc designs, 2) They often become long passages of code extending over many pages, 3) They look like procedures It is quite easy in Ada to promote a declare block to a subprogram and in-line it. This often has the effect of inspiring the designer of that declare block to think it through a bit more carefully. Sometimes it results in improving the overall design of the final set of programs. I recall one aerospace user of Ada in California where the programmers sprinkled declare blocks all through their code, almost in a stream-of-consciousness fashion. When used by someone such as Randy, a programmer who uses every construct with care and intelligence, the declare block is not a primay design structure but a way of bringing subtle refinement to an already good design. When used in place of careful planning, as it often is, or as an afterthought, as it often is, the declare block can do more to muddle the understanding of a piece of code than to improve it. That being said, Ada blocks, including declare blocks, do have the virtue that they are well-bounded, can be named, are rigorous in their obedience to the underlying rules of the language, and useful in those rare circumstances where they make sense. Finally. I have noticed over the past forty + years of being a programmer that the people who make up rules for programmers tend to be people who no longer write programs, or, in some cases, never have written any programs. I would not want anyone to think I am making up a rule about declare blocks. I do maintain my view that they need to be used sparingly, and sometimes promoted to in-lined procedures -- but this is not a rule. Richard Riehle ================================================ "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:ets49o$m8j$1@jacob-sparre.dk... > <adaworks@sbcglobal.net> wrote in message > news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net... > ... >>Units >> in Ada, including declare blocks (which ought to be used minimally) >> have the option of being named. > > While I generally agree with Richard, I certainly don't agree on the "ought > to be used minimally" here. > > I use declare blocks extensively to reduce the scope of temporary variables > in subprograms. They're especially important when the object exists just to > take an unused out parameter, because they greatly reduce the need to come > up with names for the objects. I often have code like: > > declare > Junk : Index; > begin > Insert_Something (..., Result => Junk); > end; > > where the result isn't needed by the following code. (Sure, one could argue > that the underlying library should be improved to avoid the need for this, > but that isn't always possible and in any case changes to widely used > specifications shouldn't be made lightly. And this is just one example, any > sort of temporary has these sorts of requirements.) > > The advantage is that if in the future you find that you no longer need the > temporary, you can remove it without heavy code analysis: it is used only in > the one place and there is no worries that it might be reused, or have a > side-effect, or the like. > > Randy. > > > > ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-22 17:59 ` adaworks @ 2007-03-23 2:35 ` Randy Brukardt 2007-03-23 5:23 ` adaworks 0 siblings, 1 reply; 167+ messages in thread From: Randy Brukardt @ 2007-03-23 2:35 UTC (permalink / raw) <adaworks@sbcglobal.net> wrote in message news:bByMh.11141$P47.10468@newssvr22.news.prodigy.net... ... > When used by someone such as Randy, a programmer who > uses every construct with care and intelligence, the declare > block is not a primay design structure but a way of bringing > subtle refinement to an already good design. Richard, thanks for the vote of confidence. But I have to admit that the above gave me a good laugh. My code tends to look just like the things you describe you don't like (especially in the Janus/Ada compiler), especially in regards to long subprograms. Part of that comes from the nature of compiling: it's impossible to usefully shorten case statements with dozens of branches. And I'm sure another part comes from Janus/Ada having started as a university project, where things like naming and encapsulation weren't used consistently (the latter because separate compilation was very weak in our early tools). I just looked a couple of favorites: Gen_Name (which generates the code for Ada "names") is 950 lines long, and it is mostly made up of calls to other things. The root semantic routine is 2700 lines long (it's a just a giant case statement with 378 whens at this writing: it decides what to do with each grammar production as it is recognized). Anyway, I do understand the readability concerns, but I think they're overblown. If you have to look 5 pages away to find a variable declaration, the readability of the code it is used in isn't necessarily enhanced: you're still flipping back and forth. Moreover, trying to come up with good names for code that are made into subprograms just to keep the code "short" is hard, and I know I'm not good at it. These supposed helpers are a real headache during maintenance, because its rarely obvious what they do! How do that help readability?? Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-23 2:35 ` Randy Brukardt @ 2007-03-23 5:23 ` adaworks 2007-03-23 5:15 ` Randy Brukardt 0 siblings, 1 reply; 167+ messages in thread From: adaworks @ 2007-03-23 5:23 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:etveau$g29$1@jacob-sparre.dk... > > Anyway, I do understand the readability concerns, but I think they're > overblown. If you have to look 5 pages away to find a variable declaration, > the readability of the code it is used in isn't necessarily enhanced: you're > still flipping back and forth. Moreover, trying to come up with good names > for code that are made into subprograms just to keep the code "short" is > hard, and I know I'm not good at it. These supposed helpers are a real > headache during maintenance, because its rarely obvious what they do! How do > that help readability?? > Actually, you make my point for me. We certainly do not want to look all over the place for the name of a variable. On reason I like to use in-lined procedures instead of declare blocks is the ease of grouping like things together. Consider this contrived example: case X is when C1 => declare xxxxxx begin -- fifty lines of code end; when C2 => declare zzzzzzzz begin - twenty lines of code end; when ... end case; Even when we label the declare blocks, which I tend to do, this can get to be difficult to read and difficult to maintain. I might do this: procedure some_unit_name is procedure C1_Process is ... end C1_Process; pragma Inline (C1_Process); procedure C2_Process is ... end C2_Process; pragma Inline (C2_Process); -- more procedures as needed begin -- set up stuff case X is when C1 => C1_Process; when C2 => C2_Process; when ... end case; end some_unit_name; In the aerospace example, cited earlier, this is exactly how the code was rewritten to make it easier to read as well as easier to keep current. Originally, when I did not know better, we considered trying to make the nested procedures separate, but that did not work under the rules of Ada. I did hear that someone later worked this up into a package body and was able to do something using separate at the library level. I am not sure about that since I did not get to see the subsequent code. In your case, you and the small number of programmers who work with you are intimately familiar with the code. One of the benefits of Ada is that it makes it easier to manage turnover, reassignments, and all the other personnel movements that occur in a large software organization. I have seen declare blocks used in an ad hoc manner where the lack of documentation created difficulties for newcomers to a project. Giving something a specific, meaningful name can help, especially when it is the name of a procedure along with good names for the local variables used to make it work. I suppose we simply use the coding style most appropriate to the context in which we are working. As I noted, I am not opposed to declare blocks, but I am uncomfortable when large systems are designed so they rely heavily on them. Most organizations don't have the luxury of a stable workforce. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-23 5:23 ` adaworks @ 2007-03-23 5:15 ` Randy Brukardt 2007-03-23 10:20 ` Georg Bauhaus 0 siblings, 1 reply; 167+ messages in thread From: Randy Brukardt @ 2007-03-23 5:15 UTC (permalink / raw) <adaworks@sbcglobal.net> wrote in message news:%CIMh.1791$rj1.394@newssvr23.news.prodigy.net... > > "Randy Brukardt" <randy@rrsoftware.com> wrote in message > news:etveau$g29$1@jacob-sparre.dk... > > > > Anyway, I do understand the readability concerns, but I think they're > > overblown. If you have to look 5 pages away to find a variable declaration, > > the readability of the code it is used in isn't necessarily enhanced: you're > > still flipping back and forth. Moreover, trying to come up with good names > > for code that are made into subprograms just to keep the code "short" is > > hard, and I know I'm not good at it. These supposed helpers are a real > > headache during maintenance, because its rarely obvious what they do! How do > > that help readability?? > > > Actually, you make my point for me. We certainly do not want to look > all over the place for the name of a variable. On reason I like to use > in-lined procedures instead of declare blocks is the ease of grouping > like things together. Consider this contrived example: > > case X is > when C1 => declare > xxxxxx > begin > -- fifty lines of code > end; > when C2 => declare > zzzzzzzz > begin > - twenty lines of code > end; > when ... > end case; > > Even when we label the declare blocks, which I tend to do, > this can get to be difficult to read and difficult to maintain. I > might do this: > > procedure some_unit_name is > procedure C1_Process is ... end C1_Process; > pragma Inline (C1_Process); > procedure C2_Process is ... end C2_Process; > pragma Inline (C2_Process); > -- more procedures as needed > begin > -- set up stuff > > case X is > when C1 => C1_Process; > when C2 => C2_Process; > when ... > end case; > end some_unit_name; Ahhh, but this is unrealistic, for a couple of reasons. First, you have to access the local variables and parameters of Some_Unit_Name from the xx_Process routines. (I don't want to think about routines that only use global variables!) Those necessarily will be far away, and not even in the same scope (especially if you succeed in compiling these separately - in which case they'll be in a different file. You can pass them all as parameters, but then you're adding to the clutter that you're supposedly reducing. Second, you're not taking into account the likelyhood that some of the processing is the same in several of these branches. That argues for making that similar processing into a subprogram, too, and pretty soon you have dozens of subprograms doing small parts of the processing. And I'm not even going to point out that naming these "sub" routines is very hard, because they tend to be only part of the processing (especially if some action for all of the cases happens afterwards, which is common). You can make it a bit easier sometimes by splitting the code into even more subprograms, but all of the "noise" of a subprogram isn't going to necessarily improve the readability. ... > In your case, you and the small number of programmers who work > with you are intimately familiar with the code. That's no excuse for using a bad organization. I know how hard it is to go back to code you haven't touched in a couple of years. It doesn't matter if you wrote it originally: you won't remember much about it. > One of the benefits of > Ada is that it makes it easier to manage turnover, reassignments, and > all the other personnel movements that occur in a large software > organization. I have seen declare blocks used in an ad hoc manner > where the lack of documentation created difficulties for newcomers > to a project. Giving something a specific, meaningful name can help, > especially when it is the name of a procedure along with good names > for the local variables used to make it work. True enough; but good names are very hard to come up with. (We never succeeded at that for maybe 50% of the routines in Janus/Ada. Quick: tell me the difference between "Base_Type" and "Formal_Base_Type" and "Almost_Base_Type" and "Matching_Base_Type"! :-) And it's almost a waste of effort to come up with names for throw-aways, much less good names. I still often use the Fortran "I" for the loop parameter of a for loop. The name is nearly irrelevant a lot of the time (and the need for it is really a deficiency of the language -- I want to do something to all of the components of an array; naming each one in turn is not really necessary for that purpose). [I do try to use a better name if the loop is going to longer than a few lines.] Anyway, declare blocks are so close to subprograms that there isn't that much difference between them. Surely naming is more important than that?? > I suppose we simply use the coding style most appropriate to the context > in which we are working. As I noted, I am not opposed to declare blocks, > but I am uncomfortable when large systems are designed so they rely heavily > on them. Most organizations don't have the luxury of a stable workforce. I don't find small blocks to matter much at all - they just serve to narrow the scope of objects as much as possible, which is important if you're not going to use something anymore (let it get cleaned up). I also use locks extensively in some code; those are always controlled objects so they work properly when an exception propagates. The only way to control the locking time is with a declare block, and it provides a nice visual bracket for this use. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Use of declare blocks 2007-03-23 5:15 ` Randy Brukardt @ 2007-03-23 10:20 ` Georg Bauhaus 2007-03-23 18:25 ` commenting, was " tmoran 0 siblings, 1 reply; 167+ messages in thread From: Georg Bauhaus @ 2007-03-23 10:20 UTC (permalink / raw) On Fri, 2007-03-23 at 00:15 -0500, Randy Brukardt wrote: > <adaworks@sbcglobal.net> wrote in message > > In your case, you and the small number of programmers who work > > with you are intimately familiar with the code. > > That's no excuse for using a bad organization. I know how hard it is to go > back to code you haven't touched in a couple of years. It doesn't matter if > you wrote it originally: you won't remember much about it. In this situation I have started pushing and forcing myself to write one line of comment above each meaningful group of statements, even when their meaning seemed obvious to me. In particular, when their meaning seemed obvious. As you say, it won't stay obvious, and the programmer's knowledge at the time of writing is lost with the missing comment and has to be regained. "What's next" style comments provide the problem and solution context necessary for better understanding the LOC made for solving the problem. This context information is much harder to extract from the context that the program text might provide by following formal implication chains. I wish we could again have a language (not tool) whose definition honestly adds the requirement that there be an utterance of the programmer about the intent of his lines. It might be a cultural change well worth it, in any sense of the word. Algol 60 impressed me with its «comment» symbol, and a rule where to place it: after a «begin» symbol. ^ permalink raw reply [flat|nested] 167+ messages in thread
* commenting, was Re: Use of declare blocks 2007-03-23 10:20 ` Georg Bauhaus @ 2007-03-23 18:25 ` tmoran 2007-03-24 0:32 ` adaworks 0 siblings, 1 reply; 167+ messages in thread From: tmoran @ 2007-03-23 18:25 UTC (permalink / raw) > even when their meaning seemed obvious to me. In particular, when their > meaning seemed obvious. As you say, it won't stay obvious, and > the programmer's knowledge at the time of writing is lost with > the missing comment and has to be regained. I'd like comments that are fuller as the code gets older. I've long wanted a system that each day would find those files that are, say, two days old and it would ask me to either delete or give a (very) short description (but longer than an 8.3 file name!). Files that haven't been accessed in two weeks would either be deleted or it would require me to give a somewhat longer description. Similarly after two months, with a description that would make sense two years from now. This would have to be system-enforced, since I can't bring myself to do it manually (and sometimes it isn't clear how long certain files will continue to exist anyway). It would be nice to do something similar with source code and comments. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: commenting, was Re: Use of declare blocks 2007-03-23 18:25 ` commenting, was " tmoran @ 2007-03-24 0:32 ` adaworks 2007-03-24 2:12 ` tmoran 0 siblings, 1 reply; 167+ messages in thread From: adaworks @ 2007-03-24 0:32 UTC (permalink / raw) I once wrote a program that enabled files of comments to be inserted in the program wherever I wanted them. I wrote it for a client, but I am not sure I still have the source code. However, it would be easy to write. Wherever I wanted to be able to expand the source code with additional documentation, I included a --{file-name} Then, we could print the source file with all the comments embedded or not, depending on the option in the print routine. Actually, this program included several other printing options, as well. Maybe I need to find it and make it available in the source code repository. Richard Riehle ==================================================== <tmoran@acm.org> wrote in message news:pqednfl5KJ4GhpnbnZ2dnUVZ_v2knZ2d@comcast.com... >> even when their meaning seemed obvious to me. In particular, when their >> meaning seemed obvious. As you say, it won't stay obvious, and >> the programmer's knowledge at the time of writing is lost with >> the missing comment and has to be regained. > I'd like comments that are fuller as the code gets older. > I've long wanted a system that each day would find those files that > are, say, two days old and it would ask me to either delete or give a > (very) short description (but longer than an 8.3 file name!). Files that > haven't been accessed in two weeks would either be deleted or it would > require me to give a somewhat longer description. Similarly after two > months, with a description that would make sense two years from now. > This would have to be system-enforced, since I can't bring myself to > do it manually (and sometimes it isn't clear how long certain files > will continue to exist anyway). > It would be nice to do something similar with source code and comments. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: commenting, was Re: Use of declare blocks 2007-03-24 0:32 ` adaworks @ 2007-03-24 2:12 ` tmoran 2007-03-24 3:19 ` Randy Brukardt 0 siblings, 1 reply; 167+ messages in thread From: tmoran @ 2007-03-24 2:12 UTC (permalink / raw) > Wherever I wanted to be able to expand the source code > with additional documentation, I included a > > --{file-name} My problem is that I don't go back to yesterday's code that wasn't throw-away after all and comment it, or go back to last month's library routine that was easily readable by anyone working in last month's context, and expand on its comments. I would have to be forced, or at least "re-educated". ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: commenting, was Re: Use of declare blocks 2007-03-24 2:12 ` tmoran @ 2007-03-24 3:19 ` Randy Brukardt 2007-03-24 7:36 ` tmoran 0 siblings, 1 reply; 167+ messages in thread From: Randy Brukardt @ 2007-03-24 3:19 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:GYydnepKEqaRFJnbnZ2dnUVZ_uqvnZ2d@comcast.com... > > Wherever I wanted to be able to expand the source code > > with additional documentation, I included a > > > > --{file-name} > My problem is that I don't go back to yesterday's code that wasn't > throw-away after all and comment it, or go back to last month's library > routine that was easily readable by anyone working in last month's > context, and expand on its comments. I would have to be forced, > or at least "re-educated". I find that going back and expanding comments is a fool's game, because by the time the need is obvious, it is too late to do a good job (at least without wasting a lot of time relearning the code in question). Here's what works for me: (1) Throw-away code doesn't need to be commented, but then it must be thrown away. That means immediately. I find the latter hard, so I hardly ever write throw-away code (most of it is still on my computer somewhere - or on one of my older computers...). (2) Code that isn't likely to be used frequently gets commented in critical places, and every subprogram gets a basic description. I use good names and the like, so it will be possible to figure it out again in the future. After all, a lot of Ada code doesn't need comments if the entity names are decent. (3) If I find myself working on/reusing older code, if I find the comments inadequate, I immediately improve them so that they make more sense. (Once I figure out what is going on, of course.) Once you've used something twice, it's a pretty good bet that you'll use it a third time - so don't even think about delaying about improving the comments and other documentation. After all, having insufficient comments the first time is understandable; it isn't possible to predict what will be hard to understand in the future. But once you have an firm answer to that question, failing to act on it is silly and unprofessional. If you really wanted to be forced to do something, it should be to throw away throw away code. Keeping it around is more likely to be harmful than helpful (especially if it is totally uncommented). Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: commenting, was Re: Use of declare blocks 2007-03-24 3:19 ` Randy Brukardt @ 2007-03-24 7:36 ` tmoran 2007-03-24 15:35 ` Simon Wright 0 siblings, 1 reply; 167+ messages in thread From: tmoran @ 2007-03-24 7:36 UTC (permalink / raw) I think we mostly agree. It's bad to have a machine cluttered with files, or code, that you think might be useful, but in fact it's so poorly described that it can't be found, or understood when it is found. So the system should force throwing away such things. If you truly think you might need it in the future, you should adequately describe it now, before you've forgotten. Sometimes you know the code or file you are creating is "for the ages" and you spend the necessary time thoroughly documenting it. But often you don't know for sure, and think the likelihood of future use is low, so spending a lot of care is a probable waste of time. Minimal documentation is then appropriate. Rather than having two levels - minimal docs/full docs - and going from level 1 to level 2 when you need the program the second time, I suggest several levels, with transitions dependent on your estimate of the likelihood you'll need it again, and the rate of decay of your memory. For example, in developing a binding to some API, I do a lot of throw-away programs to test that I understand the API calls correctly. I then document the binding. But then a few years later, on some newer project, I recall "I once did a program that did much of what I need now, I wonder where that old program might be." I'd like to either know that program is definitely long gone, don't waste time looking for it, or else have a file description that lets me easily find it, and internal documentation that makes it easy to refresh my memory, to help with today's project. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: commenting, was Re: Use of declare blocks 2007-03-24 7:36 ` tmoran @ 2007-03-24 15:35 ` Simon Wright 0 siblings, 0 replies; 167+ messages in thread From: Simon Wright @ 2007-03-24 15:35 UTC (permalink / raw) tmoran@acm.org writes: > But then a few years later, on some newer project, I recall "I once > did a program that did much of what I need now, I wonder where that > old program might be." I'd like to either know that program is > definitely long gone, don't waste time looking for it, or else have > a file description that lets me easily find it, and internal > documentation that makes it easy to refresh my memory, to help with > today's project. Descriptive comments (including key words) in the file can be found by tools like Spotlight. That would get you to the right area on the disk. In my case the problem is often that the disk was in a machine that's gone to recycling ... ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-20 17:37 ` adaworks 2007-03-21 8:07 ` Maciej Sobczak @ 2007-03-21 13:29 ` Alexander E. Kopilovich 2007-03-30 0:51 ` kevin cline 2007-04-16 2:09 ` Brian May 3 siblings, 0 replies; 167+ messages in thread From: Alexander E. Kopilovich @ 2007-03-21 13:29 UTC (permalink / raw) To: comp.lang.ada >It has always seemed rather odd to me that people who are as intelligent >as programmers, rarely question the silliness of using tools such as C >and C++ for serious work. Well, which work is "serious", and which is not? And even if some project as a whole is commonly agreed as "serious", does this imply that every piece of it (perhaps easily replaceble), every subcontracted supply for it, and every tool used (directly or indirectly) for it - is "serious" also? > They simply take for granted that the kind >of errors that are so common in those languages are somehow akin to >the laws of nature. They simply see that too many programmers that participate (directly or indirectly) in very many projects - including big projects - do not posses understanding of what they are doing, and actually quite often aren't much interested in it. It should be only too clear for every "intelligent programmer" that widespread (and ever-increasing) use of hordes of low-paid half-educated programmers matters much more than a particular choice of programming language. And indeed, it may be well possible that in such circumstances C/C++ is really better choice than Ada for many reasons, including the languages attitudes that are more congenial to the mentality of the vast majority of developers. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-20 17:37 ` adaworks 2007-03-21 8:07 ` Maciej Sobczak 2007-03-21 13:29 ` why learn C? Alexander E. Kopilovich @ 2007-03-30 0:51 ` kevin cline 2007-03-30 4:09 ` Steve ` (4 more replies) 2007-04-16 2:09 ` Brian May 3 siblings, 5 replies; 167+ messages in thread From: kevin cline @ 2007-03-30 0:51 UTC (permalink / raw) On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: > "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > > > It has always seemed rather odd to me that people who are as intelligent > as programmers, rarely question the silliness of using tools such as C > and C++ for serious work. > They simply take for granted that the kind > of errors that are so common in those languages are somehow akin to > the laws of nature. No, what actually happened is that expert C++ developers learned to use C++ in such a way that those errors can not happen. While it is possible to write unsafe code in C++, it is also possible to adopt coding guidelines that makes it easy to find and eliminate unsafe code, and for most applications, that's quite good enough. One reason that experts choose C++ over Ada for performance-critical applications because C++ templates allow compile-time type safety in high-level code in a way that Ada generics do not. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 0:51 ` kevin cline @ 2007-03-30 4:09 ` Steve 2007-03-30 4:58 ` kevin cline 2007-04-02 11:47 ` Shortage on C / C++ experts Larry Kilgallen 2007-03-30 4:52 ` why learn C? jimmaureenrogers ` (3 subsequent siblings) 4 siblings, 2 replies; 167+ messages in thread From: Steve @ 2007-03-30 4:09 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175215906.645110.217810@e65g2000hsc.googlegroups.com... > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > >> >> It has always seemed rather odd to me that people who are as intelligent >> as programmers, rarely question the silliness of using tools such as C >> and C++ for serious work. >> They simply take for granted that the kind >> of errors that are so common in those languages are somehow akin to >> the laws of nature. > > No, what actually happened is that expert C++ developers learned to > use C++ in such a way that those errors can not happen. While it is > possible to write unsafe code in C++, it is also possible to adopt > coding guidelines that makes it easy to find and eliminate unsafe > code, and for most applications, that's quite good enough. One reason > that experts choose C++ over Ada for performance-critical applications > because C++ templates allow compile-time type safety in high-level > code in a way that Ada generics do not. > Please give an example of one case where a C++ template gives more compile time safety than an Ada generic. I have found just the opposite to be true. Regards, Steve (The Duck) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:09 ` Steve @ 2007-03-30 4:58 ` kevin cline 2007-03-30 7:44 ` Lutz Donnerhacke ` (3 more replies) 2007-04-02 11:47 ` Shortage on C / C++ experts Larry Kilgallen 1 sibling, 4 replies; 167+ messages in thread From: kevin cline @ 2007-03-30 4:58 UTC (permalink / raw) On Mar 29, 10:09 pm, "Steve" <nospam_steve...@comcast.net> wrote: > "kevin cline" <kevin.cl...@gmail.com> wrote in message > > news:1175215906.645110.217810@e65g2000hsc.googlegroups.com... > > > > > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: > >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > > > >> It has always seemed rather odd to me that people who are as intelligent > >> as programmers, rarely question the silliness of using tools such as C > >> and C++ for serious work. > >> They simply take for granted that the kind > >> of errors that are so common in those languages are somehow akin to > >> the laws of nature. > > > No, what actually happened is that expert C++ developers learned to > > use C++ in such a way that those errors can not happen. While it is > > possible to write unsafe code in C++, it is also possible to adopt > > coding guidelines that makes it easy to find and eliminate unsafe > > code, and for most applications, that's quite good enough. One reason > > that experts choose C++ over Ada for performance-critical applications > > because C++ templates allow compile-time type safety in high-level > > code in a way that Ada generics do not. > > Please give an example of one case where a C++ template gives more compile > time safety than an Ada generic. I have found just the opposite to be true. Christopher Grein covered the topic thoroughly here: (http://home.t- online.de/home/Christ-Usch.Grein/Ada/Dimension.html) On attempts to achieve compile-time checking of physical units computations in Ada, he wrote: "Our attempt leads us to a plethora of overloaded functions. The number of function definitions afforded runs into the hundreds... So we have to confess that our attempt to let the compiler check equations at compile time has miserably failed." "The big difference is that C++ templates allow type checking during compile-time, so that no overhead neither in memory space nor in runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL than Ada generics." Ada gives you low-level type safety out of the box, but does not afford the tools necessary to achieve type-safety in high-level programming. Low-level C++ coding is not type safe, but C++ provides powerful mechanisms to write high-level type-safe code. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:58 ` kevin cline @ 2007-03-30 7:44 ` Lutz Donnerhacke 2007-03-30 9:09 ` Dmitry A. Kazakov 2007-03-30 8:29 ` Markus E Leypold ` (2 subsequent siblings) 3 siblings, 1 reply; 167+ messages in thread From: Lutz Donnerhacke @ 2007-03-30 7:44 UTC (permalink / raw) * kevin cline wrote: > "The big difference is that C++ templates allow type checking during > compile-time, so that no overhead neither in memory space nor in > runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL > than Ada generics." This is correct. C++-Templates itself are a Lisp dialect and Turing complete. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 7:44 ` Lutz Donnerhacke @ 2007-03-30 9:09 ` Dmitry A. Kazakov 2007-04-02 4:29 ` kevin cline 0 siblings, 1 reply; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-03-30 9:09 UTC (permalink / raw) On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote: > * kevin cline wrote: >> "The big difference is that C++ templates allow type checking during >> compile-time, so that no overhead neither in memory space nor in >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL >> than Ada generics." > > This is correct. C++-Templates itself are a Lisp dialect and Turing complete. One should be careful with such statements. In fact it is apples and oranges, because whatever power templates might have, they are *not* executed on the target machine. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 9:09 ` Dmitry A. Kazakov @ 2007-04-02 4:29 ` kevin cline 2007-04-02 6:45 ` adaworks ` (2 more replies) 0 siblings, 3 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 4:29 UTC (permalink / raw) On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote: > > * kevin cline wrote: > >> "The big difference is that C++ templates allow type checking during > >> compile-time, so that no overhead neither in memory space nor in > >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL > >> than Ada generics." > > > This is correct. C++-Templates itself are a Lisp dialect and Turing complete. > > One should be careful with such statements. In fact it is apples and > oranges, because whatever power templates might have, they are *not* > executed on the target machine. So what? The discussion was about compile-time type safety, and the point is that C++ templates, being Turing complete, allow more thorough compile type checking than is possible in Ada. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 4:29 ` kevin cline @ 2007-04-02 6:45 ` adaworks 2007-04-02 7:52 ` Dmitry A. Kazakov 2007-04-03 0:16 ` why learn C? Markus E Leypold 2 siblings, 0 replies; 167+ messages in thread From: adaworks @ 2007-04-02 6:45 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175488143.324741.283480@y80g2000hsf.googlegroups.com... > On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote: >> > * kevin cline wrote: >> >> "The big difference is that C++ templates allow type checking during >> >> compile-time, so that no overhead neither in memory space nor in >> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL >> >> than Ada generics." >> >> > This is correct. C++-Templates itself are a Lisp dialect and Turing >> > complete. >> >> One should be careful with such statements. In fact it is apples and >> oranges, because whatever power templates might have, they are *not* >> executed on the target machine. > > So what? The discussion was about compile-time type safety, and the > point is that C++ templates, being Turing complete, allow more > thorough compile type checking than is possible in Ada. > Quite simply not true. I wonder whether you really understand Ada. The principle design goal of Ada is for a language that supports the maximum amount of error checking as early in the development process as possible. With a very small number of exceptions, Ada does this better than most existing languages and certainly better than C++. As to C++ templates, the Grein paper is rather narrowly focused and in ordinary cases, Ada templates are as type-safe as those in C++, and in all but a few cases more so. Further, C++ templates support an excessively complicated model that is easily turned into a mismash of errors that are not so easily detected until one is well along into the debugging process. Ada's visibility rules, which I suspect you do not understand very well due to your assertions about the language, are a powerful capability for ensuring a substantial amount of error-checking at compile time. C++ does not have this feature. Ada's library model, where the specification and the implementation are separately compiled, but also checked bit by bit by the compiler is also missing from C++. C++ data types are rather thin compared to those in Ada, and the ability of an Ada designer to design new types with constrained values is also missing from C++, unless one chooses to jump through hoops. There are so many benefits of Ada over C++ that anyone who wants to make an objective comparison can only conclude that Ada is, in most respects (not all respects), a far better language for developing dependable software. C++, on the other hand, is inherently error-prone. There are so many gotchas in the syntax and semantics that C++ developers are forced to depend on long hours of debugging -- far more of this than the equivalent Ada developer. If you do not know Ada, you can be forgiven for not realizing any of this. However, it might be useful for you to become acquainted with it so you will have a better understanding of what you criticize. I have programmed in Ada and C++. From my own experience, C++ is not a language I would ever want to use for anything that had to work predictably after being deployed. It is just too full of surprises. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 4:29 ` kevin cline 2007-04-02 6:45 ` adaworks @ 2007-04-02 7:52 ` Dmitry A. Kazakov 2007-04-02 8:19 ` kevin cline 2007-04-03 0:16 ` why learn C? Markus E Leypold 2 siblings, 1 reply; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-02 7:52 UTC (permalink / raw) On 1 Apr 2007 21:29:03 -0700, kevin cline wrote: > On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote: >>> * kevin cline wrote: >>>> "The big difference is that C++ templates allow type checking during >>>> compile-time, so that no overhead neither in memory space nor in >>>> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL >>>> than Ada generics." >> >>> This is correct. C++-Templates itself are a Lisp dialect and Turing complete. >> >> One should be careful with such statements. In fact it is apples and >> oranges, because whatever power templates might have, they are *not* >> executed on the target machine. > > So what? That templates have power = 0 on the machine. You can compute *nothing* using templates. They are simply not executed there. Period. > The discussion was about compile-time type safety, and the > point is that C++ templates, being Turing complete, allow more > thorough compile type checking than is possible in Ada. 1. Here you compare the language of templates (a quite crippled one) with the language in which the Ada compiler was written. Clearly, this comparison cannot be in favor of templates. In case you doubt it, try write a parser and code generator in C++ templates... 2. This all has nothing to do with types, because the meta language of templates does not deal with language objects (types of which are supposed to be checked). Templates are about templates of types, not types. The result of template execution (by the compiler) is a C++ program which is then checked using C++ types system. Thus templates add/remove absolutely nothing to types safety. (Same as Ada generics, BTW) 3. The meta language of C++ templates is itself untyped. In contrast to the language of Ada generics which is typed. So much for types safety. P.S. There should better be neither templates nor generics. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 7:52 ` Dmitry A. Kazakov @ 2007-04-02 8:19 ` kevin cline 2007-04-02 12:04 ` Dmitry A. Kazakov 2007-04-02 23:37 ` Randy Brukardt 0 siblings, 2 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 8:19 UTC (permalink / raw) On Apr 2, 2:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > 1. Here you compare the language of templates (a quite crippled one) with > the language in which the Ada compiler was written. Probably C or C++. > Clearly, this > comparison cannot be in favor of templates. In case you doubt it, try write > a parser and code generator in C++ templates... The Ada compiler is closed. I can't go modify the Ada compiler and get it to ensure that the physical units in my Ada program are consistent. But I can use C++ templates to define a type algebra, and then use those types to insure that the equations in my C++ program are consistent. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 8:19 ` kevin cline @ 2007-04-02 12:04 ` Dmitry A. Kazakov 2007-04-02 23:37 ` Randy Brukardt 1 sibling, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-02 12:04 UTC (permalink / raw) On 2 Apr 2007 01:19:19 -0700, kevin cline wrote: > On Apr 2, 2:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >> 1. Here you compare the language of templates (a quite crippled one) with >> the language in which the Ada compiler was written. > > Probably C or C++. Ask AdaCore. As for me, I have developed compilers of specialized languages in C++, Ada, even in Assembly (with macros). No, I wouldn't advise anybody to use C++ for compiler construction... >> Clearly, this >> comparison cannot be in favor of templates. In case you doubt it, try write >> a parser and code generator in C++ templates... > > The Ada compiler is closed. I can't go modify the Ada compiler and > get it to ensure that the physical units in my Ada program are > consistent. You don't need to modify the compiler for that. If you meant static checks, then it were trivially impossible in general case. Units can be statically checked only under certain [rather rare] conditions. A good design should support static checks where possible and go run-time elsewhere. Templated / generic solution obviously does not scale. > But I can use C++ templates to define a type algebra, Which is a wrong way in a statically typed language, because see above. It should be an algebra of the type *constraints*, which C++ has no notion of. > and > then use those types to insure that the equations in my C++ program > are consistent. Try �C, K, sqrt (m�), then come back. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 8:19 ` kevin cline 2007-04-02 12:04 ` Dmitry A. Kazakov @ 2007-04-02 23:37 ` Randy Brukardt 2007-04-03 12:42 ` Erasing inappropriate operations (was: why learn C?) Ludovic Brenta 1 sibling, 1 reply; 167+ messages in thread From: Randy Brukardt @ 2007-04-02 23:37 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175501959.751535.23190@d57g2000hsg.googlegroups.com... > On Apr 2, 2:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > > > 1. Here you compare the language of templates (a quite crippled one) with > > the language in which the Ada compiler was written. > > Probably C or C++. The front-end of every Ada compiler that I know of (and know the implementation language) is written in Ada. Some of them use shared back-ends that are out of their control and are likely written in other things. My experience is that Ada is a great language for writing a compiler, because it has strong type checking that is hard to circumvent. The issues with type systems (like physical units) are irrelevant to compiler construction. I'm not quite sure why you're so concerned about generics/templates anyway. There is little reason to write a generic if all you want to do is create types in Ada: you just write an appropriate type declaration and package. (Maybe it is because C++ doesn't have a separate encapsulation mechanism, so you're pretty much stuck using classes for anything.) Yes, I agree that writing a good package for units is a pain (especially since the method you're suggesting won't work; it's probably best to just bite the bullet and write out every operation you need), but you only have to do it once per organization. (And the Amendment fixed the most important problem in Ada 95: the inability to "erase" an inappropriate operation from a unit type package.) Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Erasing inappropriate operations (was: why learn C?) 2007-04-02 23:37 ` Randy Brukardt @ 2007-04-03 12:42 ` Ludovic Brenta 2007-04-03 23:44 ` Randy Brukardt 0 siblings, 1 reply; 167+ messages in thread From: Ludovic Brenta @ 2007-04-03 12:42 UTC (permalink / raw) Randy Brukardt: > the Amendment fixed the most important problem in Ada 95: > the inability to "erase" an inappropriate operation from a unit type > package. Could you please explain what you mean by this? A quick perusal of the Ada 2005 rationale failed to enlighten me. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Erasing inappropriate operations (was: why learn C?) 2007-04-03 12:42 ` Erasing inappropriate operations (was: why learn C?) Ludovic Brenta @ 2007-04-03 23:44 ` Randy Brukardt 2007-04-04 8:34 ` Erasing inappropriate operations Ludovic Brenta 0 siblings, 1 reply; 167+ messages in thread From: Randy Brukardt @ 2007-04-03 23:44 UTC (permalink / raw) "Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message news:1175604129.583861.40720@q75g2000hsh.googlegroups.com... > Randy Brukardt: > > the Amendment fixed the most important problem in Ada 95: > > the inability to "erase" an inappropriate operation from a unit type > > package. > > Could you please explain what you mean by this? A quick perusal of the > Ada 2005 rationale failed to enlighten me. In Ada 95, abstract operators of untagged types are considered in resolution. So, you still might call them;then get an error message. That is especially problematical if an appropriate operator is defined somewhere else, because the expression might be ambiguous. (It's also a problem with literals). The Amendment 1 changed that so that they do not participate in resolution. Thus, they no longer clog up resolution. For instance, if you had: type F1 is digits 3; type F2 is digits 3; function "*" (Left : F1, Right : F2) return F2; function "*" (Left, Right : F2) return F2 is abstract; -- Don't want this operator. A : F1 := 1.0; B : F2 := A * 1.0; -- (1) The expression (1) is ambiguous in Ada 95 (even though one of the possible operators is illegal). But Amendment 1 makes it OK; you'll get the intended operator without interference from the predefined ones you don't want. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Erasing inappropriate operations 2007-04-03 23:44 ` Randy Brukardt @ 2007-04-04 8:34 ` Ludovic Brenta 2007-04-04 22:00 ` Randy Brukardt 0 siblings, 1 reply; 167+ messages in thread From: Ludovic Brenta @ 2007-04-04 8:34 UTC (permalink / raw) Randy Brukardt writes: > In Ada 95, abstract operators of untagged types are considered in > resolution. So, you still might call them;then get an error message. That is > especially problematical if an appropriate operator is defined somewhere > else, because the expression might be ambiguous. (It's also a problem with > literals). > > The Amendment 1 changed that so that they do not participate in resolution. > Thus, they no longer clog up resolution. > > For instance, if you had: > > type F1 is digits 3; > type F2 is digits 3; > function "*" (Left : F1, Right : F2) return F2; > function "*" (Left, Right : F2) return F2 is abstract; -- Don't want > this operator. > > A : F1 := 1.0; > B : F2 := A * 1.0; -- (1) > > The expression (1) is ambiguous in Ada 95 (even though one of the possible > operators is illegal). But Amendment 1 makes it OK; you'll get the intended > operator without interference from the predefined ones you don't want. Even in Ada 95 mode, GNAT does not consider (1) to be ambiguous because only one of the operators matches the actual parameter profile. Is this a bug? In the absence of the first (non-abstract) operator, it says "cannot call abstract subprogram". Fair enough, I still see no bug here. Or perhaps you meant... with Ada.Text_IO; procedure Proc1 is type F1 is digits 3; type F2 is digits 3; function "*" (Left : F1; Right : F2) return F2; function "*" (Left, Right : F2) return F2 is abstract; -- Don't want this operator. function "*" (Left : F1; Right : F2) return F2 is begin Ada.Text_IO.Put_Line ("* called"); return F2 (Float (Left) * Float (Right)); end "*"; A : F1 := 1.0; B : F2 := 1.0 * F2 (A); -- (1) begin null; end Proc1; which gives me: gcc-4.1 -c -gnatwa -gnat95 proc1.adb proc1.adb:15:18: ambiguous expression (cannot resolve "*") proc1.adb:15:18: possible interpretation at line 6 proc1.adb:15:18: possible interpretation at line 5 The abstract subprogram is indeed considered in overload resolution. But since the resolution fails (the call is ambiguous), there is still no way to call the abstract subprogram. So if I understand correctly, in Amendment 1, the call is no longer ambiguous and the first operator is called. Correct? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Erasing inappropriate operations 2007-04-04 8:34 ` Erasing inappropriate operations Ludovic Brenta @ 2007-04-04 22:00 ` Randy Brukardt 0 siblings, 0 replies; 167+ messages in thread From: Randy Brukardt @ 2007-04-04 22:00 UTC (permalink / raw) "Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message news:87vegcfsh1.fsf@ludovic-brenta.org... > Randy Brukardt writes: ... > The abstract subprogram is indeed considered in overload resolution. > But since the resolution fails (the call is ambiguous), there is still > no way to call the abstract subprogram. So if I understand correctly, > in Amendment 1, the call is no longer ambiguous and the first operator > is called. Correct? Correct. It's not legal to call the abstract subprogram, but because it is considered in expression resolution, the mere fact that it exists can make some expressions that otherwise be legal illegal. That is a significant problem for unit types, because you generally don't want the predefined multiply and divide routines (that is meters * meters = meters is wrong). I think you are correct that my example was wrong; I wrote it bunch of times and kept finding problems (and didn't want to waste all afternoon trying to figure it out). I think I meant: B : F1 := A * 1.0; No, that isn't right either. Anyway, I wanted an example without a type conversion (because if you're trying to do units checking, you're not going to be converting seconds to meters). They're certainly possible, I just had trouble coming up with an example. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 4:29 ` kevin cline 2007-04-02 6:45 ` adaworks 2007-04-02 7:52 ` Dmitry A. Kazakov @ 2007-04-03 0:16 ` Markus E Leypold 2007-04-04 16:14 ` jayessay 2 siblings, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-04-03 0:16 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: > On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote: >> > * kevin cline wrote: >> >> "The big difference is that C++ templates allow type checking during >> >> compile-time, so that no overhead neither in memory space nor in >> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL >> >> than Ada generics." >> >> > This is correct. C++-Templates itself are a Lisp dialect and Turing complete. >> >> One should be careful with such statements. In fact it is apples and >> oranges, because whatever power templates might have, they are *not* >> executed on the target machine. > > So what? The discussion was about compile-time type safety, and the > point is that C++ templates, being Turing complete, allow more > thorough compile type checking than is possible in Ada. I fail to see what the one has to do with the other. Indeed, I'd rather not write my own type checker in a lispish compile time language. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-03 0:16 ` why learn C? Markus E Leypold @ 2007-04-04 16:14 ` jayessay 2007-04-05 7:14 ` Hyman Rosen 0 siblings, 1 reply; 167+ messages in thread From: jayessay @ 2007-04-04 16:14 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > "kevin cline" <kevin.cline@gmail.com> writes: > > > On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > >> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote: > >> > * kevin cline wrote: > >> >> "The big difference is that C++ templates allow type checking during > >> >> compile-time, so that no overhead neither in memory space nor in > >> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL > >> >> than Ada generics." > >> > >> > This is correct. C++-Templates itself are a Lisp dialect and Turing complete. <delurk, in order to correct this nonsense> This is only half correct and totally misleading. C++ templates, other than being Turing complete, have absolutely nothing to do with Lisp or Lisp like languages. Nothing. And to think otherwise shows a complete ignorance of the matter. This poster probably saw someone somewhere claim that templates are "like" Lisp macros because they are a (very weak) example of metaprogramming. > >> One should be careful with such statements. In fact it is apples and > >> oranges, because whatever power templates might have, they are *not* > >> executed on the target machine. > > > > So what? The discussion was about compile-time type safety, and the > > point is that C++ templates, being Turing complete, allow more > > thorough compile type checking than is possible in Ada. > > I fail to see what the one has to do with the other. They _can_ be related, but in general are not. An example of how something like this might be useful can be seen in this (admittedly artificial) example: Allow a user/programmer to define a dictionary like object while ensuring at _compile_ time that the size of the table implementing it is a prime number. That's something that is easy to do in Lisp. It is at least theoretically possible (if mind numbingly painful) to achieve with C++ templates. I don't think you can achieve this with Ada without writing some sort of external preprocessor. If you can, it would be neat to see. > Indeed, I'd rather not write my own type checker in a lispish > compile time language. That wouldn't be so bad (or even such a big deal), but C++ templates are nothing like this and are in general a clumsy giant PITA. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-04 16:14 ` jayessay @ 2007-04-05 7:14 ` Hyman Rosen 2007-04-05 15:35 ` jayessay 0 siblings, 1 reply; 167+ messages in thread From: Hyman Rosen @ 2007-04-05 7:14 UTC (permalink / raw) jayessay wrote: > C++ templates, other than being Turing complete, have absolutely nothing > to do with Lisp or Lisp like languages. Nothing. And to think otherwise > shows a complete ignorance of the matter. Sorry, I'm afraid you're wrong about that. In fact, many C++ template metaprograms use techniques that would be quite familiar to Lisp users. For example, one might build up type lists as follows: struct Nil { }; template <typename T1, typename T2 = Nil> struct Cons { typedef T1 Car; typedef T2 Cdr; }; typedef Cons<int, Cons<bool, Cons<float> > > my3types; my3types::Car an_int; my3types::Cdr::Car a_bool; my3types::Cdr::Cdr::Car a_float; > Allow a user/programmer to define a dictionary like object while > ensuring at _compile_ time that the size of the table implementing it > is a prime number. > > That's something that is easy to do in Lisp. It is at least > theoretically possible (if mind numbingly painful) to achieve with C++ > templates. It's actually quite easy with templates, although the following may hit compiler limits that a better algorithm would avoid. It takes just three lines to implement straightforwardly the definition that a prime number has exactly two divisors. template<int N, int K> struct divNleK { enum { v = ((N % K) == 0) + divNleK<N,K-1>::v }; }; template<int N> struct divNleK<N, 1> { enum { v = 1 }; }; template<int N> struct prime_test { enum { v = divNleK<N,N>::v == 2 }; }; > That wouldn't be so bad (or even such a big deal), but C++ templates > are nothing like this and are in general a clumsy giant PITA. I don't agree at all. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-05 7:14 ` Hyman Rosen @ 2007-04-05 15:35 ` jayessay 2007-04-06 2:02 ` Hyman Rosen 0 siblings, 1 reply; 167+ messages in thread From: jayessay @ 2007-04-05 15:35 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > jayessay wrote: > > C++ templates, other than being Turing complete, have absolutely nothing > > to do with Lisp or Lisp like languages. Nothing. And to think otherwise > > shows a complete ignorance of the matter. > > Sorry, I'm afraid you're wrong about that. In fact, many C++ template > metaprograms use techniques that would be quite familiar to Lisp users. Again, this is just wrong. I've tried to explain this before, but it is a hard slog if you don't really know or use Lisp in anger. Really, there is nothing about templates that is remotely "lisp like". > For example, one might build up type lists as follows: > > struct Nil { }; > template <typename T1, typename T2 = Nil> > struct Cons { typedef T1 Car; typedef T2 Cdr; }; > > typedef Cons<int, Cons<bool, Cons<float> > > my3types; > my3types::Car an_int; > my3types::Cdr::Car a_bool; > my3types::Cdr::Cdr::Car a_float; Please. You are embarassing yourself with this. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-05 15:35 ` jayessay @ 2007-04-06 2:02 ` Hyman Rosen 2007-04-06 5:57 ` Ray Blaak 2007-04-06 17:52 ` jayessay 0 siblings, 2 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-06 2:02 UTC (permalink / raw) jayessay wrote: > Please. You are embarassing yourself with this. I notice you have no comment on the lack of mind-numbingness in my C++ template primality tester. Given that you're wrong about C++, I have no trouble believing that you're wrong about Lisp as well. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 2:02 ` Hyman Rosen @ 2007-04-06 5:57 ` Ray Blaak 2007-04-06 11:01 ` Markus E Leypold ` (2 more replies) 2007-04-06 17:52 ` jayessay 1 sibling, 3 replies; 167+ messages in thread From: Ray Blaak @ 2007-04-06 5:57 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > jayessay wrote: > > Please. You are embarassing yourself with this. > > I notice you have no comment on the lack of mind-numbingness > in my C++ template primality tester. Given that you're wrong > about C++, I have no trouble believing that you're wrong about > Lisp as well. This is getting stupid. Jon probably knows both C++ templates and definitely knows Lisp quite well. The fact that you can code up a Car/Cdr abstraction in some programming notation does note make it lisp like. You can code these list abstractions in any language you choose, and that does not make a lisp. What makes something a Lisp is a whole philosophy of symbolic, dynamic and introspective (and protected!) programming that C++ simply is not natively capable of. Also, Lisp's list syntax notation is also critical (Dylan be damned!), as that syntax is what allows the whole "programs as data" paradigm to practically work. Your basic point that C++ templates need not be considered as a fundamental evil is properly taken. In fact C++ in general tends to get a bad rap in c.l.a. The simple fact of the matter is that a professional programmer worth their salt should know how to use C++ properly so as to readily and easily avoid its stupidities and program safely. However, even with your demonstration of some cool templates, it is still the case that "programming" like this with templates is fundamentally strange. One has to think very differently compared to the usual programming languages. More importantly, the need to program like this in templates I have strong doubts about. If you really want to test a prime, for example, why on earth would you not do so at run time, when you actually need the value? Even if it's for a constant, you can compute it lazily, or during initialization, making it externally read only, etc. That is a much much clearer and understandable way to present things. The proper way to program at compile time should be with traditional program statements that happen to run in the "build" phase. This is much more direct and clearer to understand. I note that you can actually do that with Lisp/Scheme. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 5:57 ` Ray Blaak @ 2007-04-06 11:01 ` Markus E Leypold 2007-04-07 23:00 ` Ray Blaak 2007-04-08 19:44 ` jayessay 2007-04-06 18:05 ` jayessay 2007-04-06 22:16 ` Hyman Rosen 2 siblings, 2 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-06 11:01 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > Hyman Rosen <hyrosen@mail.com> writes: > >> jayessay wrote: >> > Please. You are embarassing yourself with this. >> >> I notice you have no comment on the lack of mind-numbingness >> in my C++ template primality tester. Given that you're wrong >> about C++, I have no trouble believing that you're wrong about >> Lisp as well. > > This is getting stupid. Jon probably knows both C++ templates and definitely > knows Lisp quite well. > > The fact that you can code up a Car/Cdr abstraction in some programming > notation does note make it lisp like. You can code these list abstractions in > any language you choose, and that does not make a lisp. Not to defend Hyman (who in the past was rather quick to call me "confused" when I discussed differences of C++ Templates vs. Ada generics and the consequences as I see them -- and yes, I'm sometimes a bit vengeful), but: Hymans point here was, I think that the list expressions are evaluated during compile time. Personally _I_ do not see the need for something like this (if I want to dabble in new type systems I write a compiler from an extended to the target language or I use something like Qi where even type checking is user programmable), but from that Hyman argues that Templates are "more powerful". Others denied this (the premise that Template expressions are "like Lisp") , so he brought this example. I have to admit that I didn't check Hymans example and it's limitations and I don't now templates well enough to do so in 2 minutes (and don't want to spent more time in anothe C++ vs. Ada thread -- the weather is too beautiful today), but it seemd to me that you have been missing the point that was made here. Is that possible? > What makes something a Lisp is a whole philosophy of symbolic, dynamic and > introspective (and protected!) programming that C++ simply is not natively > capable of. Also, Lisp's list syntax notation is also critical (Dylan be > damned!), as that syntax is what allows the whole "programs as data" paradigm > to practically work. I completely agree with that, though. Regards -- Markus PS: Perhaps this post was completely besides your point. I'm not sure. If so, please don't feel offended :-). ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 11:01 ` Markus E Leypold @ 2007-04-07 23:00 ` Ray Blaak 2007-04-08 19:41 ` jayessay 2007-04-09 14:08 ` Markus E Leypold 2007-04-08 19:44 ` jayessay 1 sibling, 2 replies; 167+ messages in thread From: Ray Blaak @ 2007-04-07 23:00 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > Hymans point here was, I think that the list expressions are evaluated > during compile time. Sure, his example shows that, but a) list expressions don't make a lisp b) template programming for compile time computations are a convoluted way of achieving compile time computations. > PS: Perhaps this post was completely besides your point. I'm not > sure. If so, please don't feel offended :-). Given usenet, I could only be offended if you are *too* polite :-). -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-07 23:00 ` Ray Blaak @ 2007-04-08 19:41 ` jayessay 2007-04-09 14:08 ` Markus E Leypold 1 sibling, 0 replies; 167+ messages in thread From: jayessay @ 2007-04-08 19:41 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > > Hymans point here was, I think that the list expressions are evaluated > > during compile time. > > Sure, his example shows that, but > > a) list expressions don't make a lisp > b) template programming for compile time computations are a > convoluted way of achieving compile time computations. Couldn't have said it better. Succinct and exact. > > PS: Perhaps this post was completely besides your point. I'm not > > sure. If so, please don't feel offended :-). > > Given usenet, I could only be offended if you are *too* polite :-). It is indeed extremely difficult to not trip up on usenet and somehow step on someone's toes without the slightest intent or knowledge of it. This is a big reason why I try not to post to usenet anymore. Another problem involves individuals (such as exhibited in this subthread) who appear more interested in scoring some "debating" points in some sort of weird zero-sum game they are imagining than furthering understanding or even accepting simple facts. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-07 23:00 ` Ray Blaak 2007-04-08 19:41 ` jayessay @ 2007-04-09 14:08 ` Markus E Leypold 2007-04-10 15:48 ` jayessay 1 sibling, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-04-09 14:08 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: >> Hymans point here was, I think that the list expressions are evaluated >> during compile time. > > Sure, his example shows that, but > a) list expressions don't make a lisp I got that point later in your post. Therefore the postscript :-). > b) template programming for compile time computations are a > convoluted way of achieving compile time computations. I completely agree with that. I even was on the verge of writing that macros and pre processors are always evil and that I think it would be better that people wrote domain specific languages as external translators to their favorite target language. Then you post reminded me that the Lisp macros are quit succesfull and don't seem to be the problem I always experienced with macro languages. Still I have a bad feeling with macros: They are a really big temptation to misuse them. I'm not sure wether that isn't the feature that makes me really mistrust Lisp and Scheme. >> PS: Perhaps this post was completely besides your point. I'm not >> sure. If so, please don't feel offended :-). > > Given usenet, I could only be offended if you are *too* polite :-). :-). Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-09 14:08 ` Markus E Leypold @ 2007-04-10 15:48 ` jayessay 0 siblings, 0 replies; 167+ messages in thread From: jayessay @ 2007-04-10 15:48 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > translators to their favorite target language. Then you post reminded > me that the Lisp macros are quit succesfull and don't seem to be the > problem I always experienced with macro languages. The primary thing to realize here about this point is that Lisp "macros" are not anything like the typical notion of macros from pretty much any<where/thing> else. They are not text substituters or code templates, or code parameterizers, etc. They are functions which, like any other function, can make use of the entire language (including the compiler and evaluator - which are part of the language definition), any libs, external environment (databases, distributed objects (via corba or other IDL/sockets), whatever), etc. The difference is that they are 1) called at a special time (macro expansion time - which most typically occurs during compile time), 2) they are invoked with their arguments _un_evaluated (this is a big part of why they can be so useful in creating new language level constructs), and 3) they can be passed the current lexical environment (this last was not properly fleshed out in the ANSI spec, but Franz has done a very nice job of doing that and providing the spec and implementation to the community). Because of this, things like external "preprocessing" become empty and irrelevant concepts. It also means you can build layered families of seamlessly interconnected domain level languages. > Still I have a bad feeling with macros: They are a really big > temptation to misuse them. I would substitute "possibility" for "really big temptation". Just like for unchecked conversion, goto, and OOP. Of course, YMMV. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 11:01 ` Markus E Leypold 2007-04-07 23:00 ` Ray Blaak @ 2007-04-08 19:44 ` jayessay 1 sibling, 0 replies; 167+ messages in thread From: jayessay @ 2007-04-08 19:44 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > > from an extended to the target language or I use something like Qi ^^ A very interesting and impressive system. Mark Tarver is a very clever guy. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 5:57 ` Ray Blaak 2007-04-06 11:01 ` Markus E Leypold @ 2007-04-06 18:05 ` jayessay 2007-04-06 22:00 ` Hyman Rosen 2007-04-06 22:16 ` Hyman Rosen 2 siblings, 1 reply; 167+ messages in thread From: jayessay @ 2007-04-06 18:05 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > Hyman Rosen <hyrosen@mail.com> writes: > > > jayessay wrote: > > > Please. You are embarassing yourself with this. > > > > I notice you have no comment on the lack of mind-numbingness > > in my C++ template primality tester. Given that you're wrong > > about C++, I have no trouble believing that you're wrong about > > Lisp as well. > > This is getting stupid. Jon probably knows both C++ templates and definitely > knows Lisp quite well. > > The fact that you can code up a Car/Cdr abstraction in some programming > notation does note make it lisp like. You can code these list abstractions in > any language you choose, and that does not make a lisp. Exactly. One wonders why that's hard to understand. > What makes something a Lisp is a whole philosophy of symbolic, > dynamic and introspective (and protected!) programming that C++ > simply is not natively capable of. Also, Lisp's list syntax notation > is also critical (Dylan be damned!), as that syntax is what allows > the whole "programs as data" paradigm to practically work. Again, on the mark. > Your basic point that C++ templates need not be considered as a > fundamental evil is properly taken. In fact C++ in general tends to > get a bad rap in c.l.a. The simple fact of the matter is that a > professional programmer worth their salt should know how to use C++ > properly so as to readily and easily avoid its stupidities and > program safely. I agree with this also. > would you not do so at run time, when you actually need the value? Even if > it's for a constant, you can compute it lazily, or during initialization, > making it externally read only, etc. That is a much much clearer and > understandable way to present things. Yes, as I stated, the example was artificial (and silly). > The proper way to program at compile time should be with traditional > program statements that happen to run in the "build" phase. This is > much more direct and clearer to understand. I note that you can > actually do that with Lisp/Scheme. Yes. Quite. No "preprocessor" nonsense needed or wanted. Also no "funny weird extra little language" (aka templates) needed or wanted either. Full language, libs, external environment (databases, networking, etc.) available at all phases for metaprogramming. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 18:05 ` jayessay @ 2007-04-06 22:00 ` Hyman Rosen 2007-04-06 23:46 ` jayessay 2007-04-06 23:59 ` jayessay 0 siblings, 2 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-06 22:00 UTC (permalink / raw) jayessay wrote: > Also no "funny weird extra little language" (aka templates) > needed or wanted either. How odd. If I may quote from Abelson & Sussman, found here on the web, <http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>, "Metalinguistic abstraction -- establishing new languages -- plays an important role in all branches of engineering design. It is particularly important to computer programming, because in programming not only can we formulate new languages but we can also implement these languages by constructing evaluators ... We come to see ourselves as designers of languages, rather than only users of languages designed by others." So again, I may believe some of the most respected names in the Lisp pantheon, or I can believe you. Gee, let me think. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 22:00 ` Hyman Rosen @ 2007-04-06 23:46 ` jayessay 2007-04-06 23:59 ` jayessay 1 sibling, 0 replies; 167+ messages in thread From: jayessay @ 2007-04-06 23:46 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > jayessay wrote: > > Also no "funny weird extra little language" (aka templates) > > needed or wanted either. > > How odd. If I may quote from Abelson & Sussman, found here on the web, > <http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>, Nice quote, but totally irrelevant. > So again, I may believe some of the most respected names in the Lisp > pantheon, or I can believe you. Gee, let me think. Let me think - you can stop making category errors. Sheesh! /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 22:00 ` Hyman Rosen 2007-04-06 23:46 ` jayessay @ 2007-04-06 23:59 ` jayessay 1 sibling, 0 replies; 167+ messages in thread From: jayessay @ 2007-04-06 23:59 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > jayessay wrote: > > Also no "funny weird extra little language" (aka templates) > > needed or wanted either. > > How odd. If I may quote from Abelson & Sussman, found here on the web, > <http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>, > > "Metalinguistic abstraction -- establishing new languages -- plays > an important role in all branches of engineering design. It is > particularly important to computer programming, because in > programming not only can we formulate new languages but we can also > implement these languages by constructing evaluators ... > > We come to see ourselves as designers of languages, rather than only > users of languages designed by others." Oh, just so you might understand what he actually means by this: he is, in general, talking about building domain specific languages. You build the _language_ up to the specific problem space. More particularly in this context, the idea is to use "programmable programming languages" to do this, i.e., to extend them _within themselves_ to have the DSL. This is connected to the last point Ray made. Really, I don't know why you are going on here. From past postings, I would say you are in general a fairly savy guy, but it's pretty clear you don't have even a clue about this stuff. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 5:57 ` Ray Blaak 2007-04-06 11:01 ` Markus E Leypold 2007-04-06 18:05 ` jayessay @ 2007-04-06 22:16 ` Hyman Rosen 2007-04-06 23:52 ` jayessay 2 siblings, 1 reply; 167+ messages in thread From: Hyman Rosen @ 2007-04-06 22:16 UTC (permalink / raw) Ray Blaak wrote: > it is still the case that "programming" like this with templates > is fundamentally strange. One has to think very differently compared > to the usual programming languages. It is a declarative style involving immutable objects and pattern matching. I understand that this is similar to the way functional programming languages work in some respects. Thinking differently isn't necessarily a flaw, either. > If you really want to test a prime, for example, why on earth > would you not do so at run time, when you actually need the value? Because in C++, these values direct the compiler into different code-generation pathways, allowing the generation of code that is as efficient as if plain constants had appeared in the code. This is generative programming, as expounded by Czarnecki & Eisenecker. > The proper way to program at compile time should be with traditional > program statements that happen to run in the "build" phase. C++ happened to find itself in a position where compile-time programming became possible through a happy accident, and that has led to where it is today. There are people working on more straightforward approaches to this, and if they work out, they may make it into C++. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 22:16 ` Hyman Rosen @ 2007-04-06 23:52 ` jayessay 2007-04-07 0:39 ` Ray Blaak 0 siblings, 1 reply; 167+ messages in thread From: jayessay @ 2007-04-06 23:52 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Ray Blaak wrote: > > it is still the case that "programming" like this with templates > > is fundamentally strange. One has to think very differently compared > > to the usual programming languages. > > It is a declarative style involving immutable objects and pattern > matching. I understand that this is similar to the way functional > programming languages work in some respects. Thinking differently > isn't necessarily a flaw, either. Declarative isn't the same as functional. But even if it were, what's the point? I'm not sure, but I believe Ray's point was that using a limited type language to do general computation is, shall we say, convoluted. > > If you really want to test a prime, for example, why on earth > > would you not do so at run time, when you actually need the value? > > Because in C++, these values direct the compiler into different Yes, but really - as Ray points out this is a silly artificial example. > is today. There are people working on more straightforward > approaches to this, and if they work out, they may make it into C++. Ah - even more Greenspunning. *sigh* /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 23:52 ` jayessay @ 2007-04-07 0:39 ` Ray Blaak 0 siblings, 0 replies; 167+ messages in thread From: Ray Blaak @ 2007-04-07 0:39 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > Hyman Rosen <hyrosen@mail.com> writes: > > > Ray Blaak wrote: > > > it is still the case that "programming" like this with templates > > > is fundamentally strange. One has to think very differently compared > > > to the usual programming languages. > > > > It is a declarative style involving immutable objects and pattern > > matching. I understand that this is similar to the way functional > > programming languages work in some respects. Thinking differently > > isn't necessarily a flaw, either. > > Declarative isn't the same as functional. But even if it were, what's > the point? I'm not sure, but I believe Ray's point was that using a > limited type language to do general computation is, shall we say, > convoluted. Right. I have no problem with declarative programming. C++ template programming, however, achieves its ends as a "fortunate" accidental side effect. If the purpose is to do compile time computation, then the language should be designed to be clear and understandable for that purpose, whether declarative or functaional. Note I am not saying that C++ templates are in themselves confusing for their original purpose of parametized code generation (although they can be justifiably criticized), but only that their application to the purpose of compile time computation is confusing. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-06 2:02 ` Hyman Rosen 2007-04-06 5:57 ` Ray Blaak @ 2007-04-06 17:52 ` jayessay 1 sibling, 0 replies; 167+ messages in thread From: jayessay @ 2007-04-06 17:52 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > jayessay wrote: > > Please. You are embarassing yourself with this. > > I notice you have no comment on the lack of mind-numbingness > in my C++ template primality tester. Given that you're wrong > about C++, I have no trouble believing that you're wrong about > Lisp as well. Ah, irrelevant non argument. Believe what you wish - just don't expect it to be close to reality. Oh, and your "primality tester" doesn't implement what I mentioned (though, as I say, I know it can be done), so why should I comment on it? /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:58 ` kevin cline 2007-03-30 7:44 ` Lutz Donnerhacke @ 2007-03-30 8:29 ` Markus E Leypold 2007-03-30 8:35 ` Markus E Leypold 2007-03-30 17:39 ` adaworks 2007-04-02 5:03 ` Brian May 3 siblings, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-03-30 8:29 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: > On Mar 29, 10:09 pm, "Steve" <nospam_steve...@comcast.net> wrote: >> "kevin cline" <kevin.cl...@gmail.com> wrote in message >> >> news:1175215906.645110.217810@e65g2000hsc.googlegroups.com... >> >> >> >> > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: >> >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > >> >> >> It has always seemed rather odd to me that people who are as intelligent >> >> as programmers, rarely question the silliness of using tools such as C >> >> and C++ for serious work. >> >> They simply take for granted that the kind >> >> of errors that are so common in those languages are somehow akin to >> >> the laws of nature. >> >> > No, what actually happened is that expert C++ developers learned to >> > use C++ in such a way that those errors can not happen. While it is >> > possible to write unsafe code in C++, it is also possible to adopt >> > coding guidelines that makes it easy to find and eliminate unsafe >> > code, and for most applications, that's quite good enough. One reason >> > that experts choose C++ over Ada for performance-critical applications >> > because C++ templates allow compile-time type safety in high-level >> > code in a way that Ada generics do not. >> >> Please give an example of one case where a C++ template gives more compile >> time safety than an Ada generic. I have found just the opposite to be true. > > Christopher Grein covered the topic thoroughly here: (http://home.t- > online.de/home/Christ-Usch.Grein/Ada/Dimension.html) > > On attempts to achieve compile-time checking of physical units > computations in Ada, he wrote: > > "Our attempt leads us to a plethora of overloaded functions. The > number of function definitions afforded runs into the hundreds... So > we have to confess that our attempt to let the compiler check > equations at compile time has miserably failed." > > "The big difference is that C++ templates allow type checking during > compile-time, so that no overhead neither in memory space nor in > runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL > than Ada generics." > > Ada gives you low-level type safety out of the box, but does not > afford the tools necessary to achieve type-safety in high-level > programming. I'm inclined to shout nonsense here: You people tend to mistake a type system for a proof system on the correctness of your program. That are two different things. Type safety is to avoid execution errors (once again see Cardelli's introduction into type systems), whereas a type system is hardly ever powerful enough to proof interesting things about the correctness of your code -- so if you start proofing correctness you can well start with a simple, but safe type system and handle pre- and post-conditions completely in your proof system (that also applies to subrange types and this kind of stuff). (And yes that critique also applies to Ada subtyping to a certain extend.) > Low-level C++ coding is not type safe, but C++ provides > powerful mechanisms to write high-level type-safe code. That's a bit like saying, "I can write type safe code in C". The point is, I might be able to write safe code in C, but type safe is an attribute applying to a language (NOT a single instance of code) and means that if the type checks are passed, the code is safe with regard to execution errors (execution errors as defined in Cardelli's paper again: That are error that bring the program into "undefined states" or "invoke undefined behaviour" (hello, comp.std.c, can you hear me :-)))). The definition allow show that "this piece of code is type safe" makes no sense, and that saying "I can write type safe code by keeping to certain rules" makes hardly sense also, since it's the very essence of type safety that it's the type checks that are the litmus test wether you stuck to the rules or not. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 8:29 ` Markus E Leypold @ 2007-03-30 8:35 ` Markus E Leypold 0 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-03-30 8:35 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > "kevin cline" <kevin.cline@gmail.com> writes: > >> On Mar 29, 10:09 pm, "Steve" <nospam_steve...@comcast.net> wrote: >>> "kevin cline" <kevin.cl...@gmail.com> wrote in message >>> >>> news:1175215906.645110.217810@e65g2000hsc.googlegroups.com... >>> >>> >>> >>> > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: >>> >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > >>> >>> >> It has always seemed rather odd to me that people who are as intelligent >>> >> as programmers, rarely question the silliness of using tools such as C >>> >> and C++ for serious work. >>> >> They simply take for granted that the kind >>> >> of errors that are so common in those languages are somehow akin to >>> >> the laws of nature. >>> >>> > No, what actually happened is that expert C++ developers learned to >>> > use C++ in such a way that those errors can not happen. While it is >>> > possible to write unsafe code in C++, it is also possible to adopt >>> > coding guidelines that makes it easy to find and eliminate unsafe >>> > code, and for most applications, that's quite good enough. One reason >>> > that experts choose C++ over Ada for performance-critical applications >>> > because C++ templates allow compile-time type safety in high-level >>> > code in a way that Ada generics do not. >>> >>> Please give an example of one case where a C++ template gives more compile >>> time safety than an Ada generic. I have found just the opposite to be true. >> >> Christopher Grein covered the topic thoroughly here: (http://home.t- >> online.de/home/Christ-Usch.Grein/Ada/Dimension.html) >> >> On attempts to achieve compile-time checking of physical units >> computations in Ada, he wrote: >> >> "Our attempt leads us to a plethora of overloaded functions. The >> number of function definitions afforded runs into the hundreds... So >> we have to confess that our attempt to let the compiler check >> equations at compile time has miserably failed." >> >> "The big difference is that C++ templates allow type checking during >> compile-time, so that no overhead neither in memory space nor in >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL >> than Ada generics." >> >> Ada gives you low-level type safety out of the box, but does not >> afford the tools necessary to achieve type-safety in high-level >> programming. > > I'm inclined to shout nonsense here: You people tend to mistake a type > system for a proof system on the correctness of your program. That are > two different things. Type safety is to avoid execution errors (once > again see Cardelli's introduction into type systems), whereas a type > system is hardly ever powerful enough to proof interesting things > about the correctness of your code -- so if you start proofing > correctness you can well start with a simple, but safe type system and > handle pre- and post-conditions completely in your proof system (that > also applies to subrange types and this kind of stuff). > > (And yes that critique also applies to Ada subtyping to a certain > extend.) > >> Low-level C++ coding is not type safe, but C++ provides >> powerful mechanisms to write high-level type-safe code. > > That's a bit like saying, "I can write type safe code in C". The point > is, I might be able to write safe code in C, but type safe is an > attribute applying to a language (NOT a single instance of code) and > means that if the type checks are passed, the code is safe with regard > to execution errors (execution errors as defined in Cardelli's paper > again: That are error that bring the program into "undefined states" > or "invoke undefined behaviour" (hello, comp.std.c, can you hear me > :-)))). > > The definition allow show that "this piece of code is type safe" makes Should've been: "The definition also shows ..." > no sense, and that saying "I can write type safe code by keeping to > certain rules" makes hardly sense also, since it's the very essence of > type safety that it's the type checks that are the litmus test wether > you stuck to the rules or not. > > Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:58 ` kevin cline 2007-03-30 7:44 ` Lutz Donnerhacke 2007-03-30 8:29 ` Markus E Leypold @ 2007-03-30 17:39 ` adaworks 2007-03-31 14:59 ` Steve ` (2 more replies) 2007-04-02 5:03 ` Brian May 3 siblings, 3 replies; 167+ messages in thread From: adaworks @ 2007-03-30 17:39 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175230700.925143.28490@n59g2000hsh.googlegroups.com... > > Ada gives you low-level type safety out of the box, but does not > afford the tools necessary to achieve type-safety in high-level > programming. Low-level C++ coding is not type safe, but C++ provides > powerful mechanisms to write high-level type-safe code. > On reading the Grein paper, it is clear that the advantage is a very small, and very narrowly focused one. Any suggestion that C++ is, as a general principle, safer than Ada is simply a fantasy. Overall, compile-time safety in Ada is substantially superior to that in C++. C and C++ are highly error-prone. Programmers who choose C++ take for granted that long hours of debugging obscure errors is the way life ought to be. As for high-level programming, this is where Ada does excel. For large-scale, multi-developer projects C++ simply is a mess. There is no dependable model for separate programming. Oh yes, those CPP files! Well, they are inherently part of their own specification and they need to be augmented by compiler directives just to make sure there are not errors. I nearly guffawed when reading your last sentence. C++ as type safe? What a joke. Sadly, I suspect you actually believe this. With all mechanisms available in Ada for developing solid, dependable code and a language definition that focuses on creating compilers that maximize the amount of error detection that can be done early in the development process, I wonder whether you really understand Ada at all. Have you any understanding of the visbility rules? This goes well beyond type-safety. Do you understand the library model and how it affects separate compilation? As for the safety of generics, Grein's paper, which you take delight in citing, does not discount the fact that most generic constructs are type-safe at compile time. Further, getting it right, with C++ templates is no trivial feat either. There are plenty of opportunities to create errors in C++ templates. I have programmed in both languages. I have taught C++ and I have taught Ada. I have colleagues who use both languages who realize that C++ is far more error-prone than Ada. While one can get a good set of working software in C++ using heroic efforts, the chance of errors in a C++ program is much higher in a corresponding program written in Ada. I find it strange that anyone who understands both languages well would come to any other conclusion. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 17:39 ` adaworks @ 2007-03-31 14:59 ` Steve 2007-03-31 15:59 ` Markus E Leypold 2007-03-31 15:14 ` Pascal Obry 2007-04-02 5:27 ` kevin cline 2 siblings, 1 reply; 167+ messages in thread From: Steve @ 2007-03-31 14:59 UTC (permalink / raw) <adaworks@sbcglobal.net> wrote in message news:6XbPh.4025$u03.802@newssvr21.news.prodigy.net... > [snip] > >.... I have colleagues who use both languages who realize > that C++ is far more error-prone than Ada. While one can get a > good set of working software in C++ using heroic efforts, the chance > of errors in a C++ program is much higher in a corresponding program > written in Ada. I find it strange that anyone who understands both > languages well would come to any other conclusion. > > Richard Riehle > Me too. Steve (The Duck) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 14:59 ` Steve @ 2007-03-31 15:59 ` Markus E Leypold 2007-04-01 14:32 ` Ed Falis 2007-04-02 7:03 ` adaworks 0 siblings, 2 replies; 167+ messages in thread From: Markus E Leypold @ 2007-03-31 15:59 UTC (permalink / raw) "Steve" <nospam_steved94@comcast.net> writes: > <adaworks@sbcglobal.net> wrote in message > news:6XbPh.4025$u03.802@newssvr21.news.prodigy.net... >> > [snip] >> >>.... I have colleagues who use both languages who realize >> that C++ is far more error-prone than Ada. While one can get a >> good set of working software in C++ using heroic efforts, the chance >> of errors in a C++ program is much higher in a corresponding program >> written in Ada. I find it strange that anyone who understands both >> languages well would come to any other conclusion. >> >> Richard Riehle >> > > Me too. I think I've tried to explain before that it is very rare, that real projects can choose a language absolutely freely, based only on the merits / properties of the languages in question. In reality, most people work with a given language on a historically grown code base. If new projects are started, they are usually started in a corporate environment which also has existing infrastructure, experience, a source code base, coding guide lines etc. All this is often a motivation not to change the language or at least "not just now". The way Richard presents things distorts reality somewhat: He gives the impression that there is a number of peple out there, which know C++ and Ada equally well, start projects with an absolutely clean slate (no development environment, no code base on which to build, no corporate guide lines) and then -- with seeing eyes -- decide for C++ and against Ada, but still expect completely error free software. This is not so. (And given the state of vendor support on various platforms from embedded to PC operating systems in both C++ and Ada, I could still understand if some people came to the conclusion that, to retain the flexibility, both in moving from platform to platform as well as in hiring developers, that they would be prepared to accept "proneness" to lesser quality -- if I had to make that decision I'd try to avoid this outcome, but I certainly would understand the point of somebody who would decide differently). In summary: Technical merits of languages play only a tiny part in decisions for or against a given language. But I already have said that often enough, haven't I? Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 15:59 ` Markus E Leypold @ 2007-04-01 14:32 ` Ed Falis 2007-04-02 7:03 ` adaworks 1 sibling, 0 replies; 167+ messages in thread From: Ed Falis @ 2007-04-01 14:32 UTC (permalink / raw) Markus E Leypold wrote: .. > In summary: Technical merits of languages play only a tiny part in > decisions for or against a given language. But I already have said > that often enough, haven't I? Perhaps you should pick up a copy of Peter Middleton's and James Sutton's "Lean Software Strategies". They make the same argument with respect to purely technical factors, but then go on to recommend Ada as the most appropriate language for the strategies they promote based on its contribution to the integrity of the software production process. The latter is a value that they rate as much, much more important than sheer technical characteristics (contributing something like 40% vs 5% to project outcomes). http://www.amazon.com/gp/product/1563273055/103-1669742-0555007 - Ed ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 15:59 ` Markus E Leypold 2007-04-01 14:32 ` Ed Falis @ 2007-04-02 7:03 ` adaworks 1 sibling, 0 replies; 167+ messages in thread From: adaworks @ 2007-04-02 7:03 UTC (permalink / raw) "Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in message news:0fbqi9tncx.fsf@hod.lan.m-e-leypold.de... > > > The way Richard presents things distorts reality somewhat: He gives > the impression that there is a number of peple out there, which know > C++ and Ada equally well, start projects with an absolutely clean > slate (no development environment, no code base on which to build, no > corporate guide lines) and then -- with seeing eyes -- decide for C++ > and against Ada, but still expect completely error free software. > Good observation. Well-phrased and thoughtful. I realize that few people know both languages well. I also know that projects rarely start with a clean slate. There are certainly circumstances where C++ is the preferred option. These usually are environments where everyone is already well-trained and experienced in C++. Moving to a new language should never be taken lightly. One reason C++ has been so successful is that it is familiar with those who originally programmed in C. I have counseled people to avoid new languages on many occasions. On one occasion, a three-star general asked me whether he should convert all his Fortran code to Ada. My answer was, No. On another occasion, I was asked about what to do about COBOL in a shop that had hundreds of thousands of code in COBOL. "Should we convert to Java?" My answer was again an emphatic No! In my own experience, I have had the opportunity to program in many different languages on a lot of different kinds of projects. I have been doing this for well over forty years. I realize that every language has its good points and bad points. Some have more bad points than others. When I look at C++, versus the alternatives, I see a language that should be retired from service at the earliest opportunity. It is dangerous, messy, and error-prone. It served its purpose for a while. It was considered useful for its alleged efficiency. This issue is largely moot. At present, C++ is nothing more than an object-oriented universal Assembler. From time to time it is still useful. However, newer languages have come into existence and C++ is something of a buggy-whip equivalent. If we are to move the profession forward to a more engineering discipline, the buggy-whip needs to be replaced with more appropiate tools. Functional languages such as OCAML are showing their advantages, where they are used. Eiffel continues to be an excellent alternative when one needs an OOP language with a bit more dependabilty. And Ada continues to evolve well, even though it still needs more evolution in subsequent iterations. C++, on the other hand, seems to be evolving new features with the principle intent of fixing things in the existing language that are broken. With all the better alternatives available, I can only wonder why anyone would deliberately choose C++. Of particular concern, for me, is the nitwits who have chosen C++ over Ada for military weapon systems. This is absolutely horrible. I deal regularly with the young military personnel who are going to have to rely on the software in those systems, and it frightens me that we are sending them into combat with equipment programmed in language that is inherently error-prone. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 17:39 ` adaworks 2007-03-31 14:59 ` Steve @ 2007-03-31 15:14 ` Pascal Obry 2007-04-02 5:27 ` kevin cline 2 siblings, 0 replies; 167+ messages in thread From: Pascal Obry @ 2007-03-31 15:14 UTC (permalink / raw) To: adaworks adaworks@sbcglobal.net a �crit : > I have programmed in both languages. I have taught C++ and I have > taught Ada. I have colleagues who use both languages who realize > that C++ is far more error-prone than Ada. While one can get a > good set of working software in C++ using heroic efforts, the chance > of errors in a C++ program is much higher in a corresponding program > written in Ada. I find it strange that anyone who understands both > languages well would come to any other conclusion. Same experience on my side, same questioning! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 17:39 ` adaworks 2007-03-31 14:59 ` Steve 2007-03-31 15:14 ` Pascal Obry @ 2007-04-02 5:27 ` kevin cline 2007-04-02 6:04 ` Harald Korneliussen ` (6 more replies) 2 siblings, 7 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 5:27 UTC (permalink / raw) On Mar 30, 12:39 pm, <adawo...@sbcglobal.net> wrote: > "kevin cline" <kevin.cl...@gmail.com> wrote in message > > news:1175230700.925143.28490@n59g2000hsh.googlegroups.com... > > > Ada gives you low-level type safety out of the box, but does not > > afford the tools necessary to achieve type-safety in high-level > > programming. Low-level C++ coding is not type safe, but C++ provides > > powerful mechanisms to write high-level type-safe code. > > On reading the Grein paper, it is clear that the advantage is a very > small, and very narrowly focused one. To me, it's a large advantage, and not narrowly focused at all. I would think the inability to perform complete compile-time checking of physical units would be pretty serious in real-time control applications. Do Ada programmers make do with run-time type checking, or just write more and more generic function instantiations until the application is finished? The rest of use have more important things to do. Any suggestion that C++ > is, as a general principle, safer than Ada is simply a fantasy. It's not safer, AS A GENERAL PRINCIPLE. But in the hands of experts, C ++ allows compile-time type checking that is impossible in Ada. > > Overall, compile-time safety in Ada is substantially superior to that > in C++. C and C++ are highly error-prone. ... when used by poorly lead mediocre programmers. > Programmers who > choose C++ take for granted that long hours of debugging obscure > errors is the way life ought to be. No doubt some programmers do. Good C++ programmers don't. I certainly don't. > As for high-level programming, this is where Ada does excel. Not for most of us, because the advantages in safety are overwhelmed by the increased verbosity. > For > large-scale, multi-developer projects C++ simply is a mess. There > is no dependable model for separate programming. Oh yes, those > CPP files! Well, they are inherently part of their own specification > and they need to be augmented by compiler directives just to make > sure there are not errors. > > I nearly guffawed when reading your last sentence. C++ as type > safe? What a joke. Sadly, I suspect you actually believe this. > > With all mechanisms available in Ada for developing solid, dependable > code and a language definition that focuses on creating compilers that > maximize the amount of error detection that can be done early in > the development process, I wonder whether you really understand > Ada at all. Have you any understanding of the visbility rules? This > goes well beyond type-safety. Do you understand the library model > and how it affects separate compilation? Do you understand how unimportant those theoretical considerations are for those of us faced with time-to-market pressure? Do you understand how the start of the art in C++ compilers and C++ programming has advanced since Ada-95 was introduced? > > As for the safety of generics, Grein's paper, which you take delight > in citing, does not discount the fact that most generic constructs > are type-safe at compile time. Further, getting it right, with C++ > templates is no trivial feat either. Actually, it's pretty trivial once you learn to think at the right level of abstraction. And if no one on a team can think at the right level of abstraction, you will end up with a mess regardless of the language chosen. > There are plenty of opportunities > to create errors in C++ templates. > > I have programmed in both languages. How much? > I have taught C++ Which textbook did you use? > and I have > taught Ada. I have colleagues who use both languages who realize > that C++ is far more error-prone than Ada. While one can get a > good set of working software in C++ using heroic efforts, Heroic efforts are not necessary. These days, about all that is necessary is to avoid writing code that produces compiler warnings. the chance > of errors in a C++ program is much higher in a corresponding program > written in Ada. I find it strange that anyone who understands both > languages well would come to any other conclusion. For me, the short reason is that Ada generics are not as powerful as C+ + templates. The power of C++ templates has enabled me to write compact, efficient type-safe application code at a very high level in a way which is not possible in Ada. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:27 ` kevin cline @ 2007-04-02 6:04 ` Harald Korneliussen 2007-04-02 6:33 ` Shortage on C / C++ experts Martin Krischik ` (5 subsequent siblings) 6 siblings, 0 replies; 167+ messages in thread From: Harald Korneliussen @ 2007-04-02 6:04 UTC (permalink / raw) To ensure that minimal safety guidelines are in fact followed in C++, and not just stand there on some piece of paper, you need a programmable static analyzer a la Coverity, Klocwork, etc. The template system can be (ab)used to do static checking for you in some cases (you mention units), but not all - you can't ensure that the elaborately constructed safe functions are actually used, for instance. But if you already need a programmable static analyzer, couldn't you use it to get the checks through that instead of templates? I dare say you don't need a big static analyzer of that kind to make type safe Ada. (concering "power", the C preprosessor is also turing-complete, which means that there probably is a way to use that for type safe units as well.) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Shortage on C / C++ experts 2007-04-02 5:27 ` kevin cline 2007-04-02 6:04 ` Harald Korneliussen @ 2007-04-02 6:33 ` Martin Krischik 2007-04-02 7:07 ` why learn C? adaworks ` (4 subsequent siblings) 6 siblings, 0 replies; 167+ messages in thread From: Martin Krischik @ 2007-04-02 6:33 UTC (permalink / raw) kevin cline schrieb: >> Any suggestion that C++ >> is, as a general principle, safer than Ada is simply a fantasy. > > It's not safer, AS A GENERAL PRINCIPLE. But in the hands of experts, C > ++ allows compile-time type checking that is impossible in Ada. So does Assembler. Problem is that only 1% of C / C++ programmers are experts. You don't belive me? Well, on the last C++ project I worked I was the only developer who knew that virtual inheritance exitst. And one team created (simplification): class A: IMouseHander, IKeyboardHandler class B: public A, IMouseHander, IKeyboardHandler class C: public B, IMouseHander, IKeyboardHandler class D: public C, IMouseHander, IKeyboardHandler This is how real live looks. Of course abstraction is bullshit. But using inheritance saved them aprox. 50 keystrokes per handler. No such thing as "in the hands of experts" or "Good C++ programmers don't.". The feature is there it will be used. Whole teams go for years without a single "expert" at there disposal. And when they asked the only expert around (me) it was to late. > Heroic efforts are not necessary. These days, about all that is > necessary is to avoid writing code that produces compiler warnings. Of course the team in question did not have /W4 activated - they used no /W at all witch is "/W0". They did not have an expert to analyse there compiler switches. The bitter truth is: There are not enough experts around. Martin ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:27 ` kevin cline 2007-04-02 6:04 ` Harald Korneliussen 2007-04-02 6:33 ` Shortage on C / C++ experts Martin Krischik @ 2007-04-02 7:07 ` adaworks 2007-04-02 7:18 ` kevin cline 2007-04-02 13:00 ` adaworks ` (3 subsequent siblings) 6 siblings, 1 reply; 167+ messages in thread From: adaworks @ 2007-04-02 7:07 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175491660.511530.58430@y80g2000hsf.googlegroups.com... > > For me, the short reason is that Ada generics are not as powerful as C+ > + templates. The power of C++ templates has enabled me to write > compact, efficient type-safe application code at a very high level in > a way which is not possible in Ada. > Those of us who use Ada write efficient, type-safe application code in Ada all the time and it is certainly possible in Ada. Further, those Ada generics are checked at compile-time. That is a fundamental feature of the language. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 7:07 ` why learn C? adaworks @ 2007-04-02 7:18 ` kevin cline 0 siblings, 0 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 7:18 UTC (permalink / raw) On Apr 2, 2:07 am, <adawo...@sbcglobal.net> wrote: > "kevin cline" <kevin.cl...@gmail.com> wrote in message > > news:1175491660.511530.58430@y80g2000hsf.googlegroups.com... > > > For me, the short reason is that Ada generics are not as powerful as C+ > > + templates. The power of C++ templates has enabled me to write > > compact, efficient type-safe application code at a very high level in > > a way which is not possible in Ada. > > Those of us who use Ada write efficient, type-safe application code in > Ada all the time and it is certainly possible in Ada. No doubt you do. I have written efficient type-safe application code in Ada too. But for the most interesting sorts of computationally intensive applications I have written, I found C++'s powerful templates to be indispensable. For example, for a logistics application, variable quantities were modeled as piecewise constant functions of time, but for efficiency there were multiple implementing classes: one for functions that were constant over all time, another for functions that were periodic, another for functions whose variation was defined by a table, and so on. With C++ templates it was a relatively simple matter to define an algebra on those functions so that one could say things like: Time end = integrate_until(f1 * phase_shift(f2,start) / f3 + f4, q); even though f1, f2, f3, and f4 were possibly of different types. In Ada, dozens of lines of generic instantiations would have been needed before the expression could be written. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:27 ` kevin cline ` (2 preceding siblings ...) 2007-04-02 7:07 ` why learn C? adaworks @ 2007-04-02 13:00 ` adaworks 2007-04-12 15:28 ` Hyman Rosen 2007-04-03 0:26 ` Markus E Leypold ` (2 subsequent siblings) 6 siblings, 1 reply; 167+ messages in thread From: adaworks @ 2007-04-02 13:00 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175491660.511530.58430@y80g2000hsf.googlegroups.com... > > For me, the short reason is that Ada generics are not as powerful as C+ > + templates. The power of C++ templates has enabled me to write > compact, efficient type-safe application code at a very high level in > a way which is not possible in Ada. > I take your central point to be something related to the number of instantiations required in Ada to accomplish a roughly equivalent result in C++. I will grant you that Ada does require more code for each instantiation. This tends to increase, not decrease, the dependability since each instantiation is checked at compile-time. Further, an example you provide, shown below: With C++ templates it was a relatively simple matter to define an algebra on those functions so that one could say things like: Time end = integrate_until(f1 * phase_shift(f2,start) / f3 + f4, q); even though f1, f2, f3, and f4 were possibly of different types. illustrates the problem quite nicely. In fact, your acknowledgement of the "different types" is quite telling. Further, the ad hoc pointer is potentially problematic. A similar construct in Ada, using an access to a function, requires the function to be type conformant and parameter conformant prior to being incorporated into the construct. That is, there is more compiler checking before this construct is even allowed to be compiled. Type-safety is not a very strong argument for C++. Granted, there has been improvement in the latest version of the language. Some (but not all) of the unruly pointer behavior is gone. However, by reference constructs are still a potential source of error. Friends are still problematic. And the disjoint between .h and .cpp files can create entertaining moments in the life of the programmer. You use typdef quite a bit. The examples you give are reasonable. However, typedef does not provide the level of type safety one would expect in a corresponding Ada program. There is a structural equivalence that poses some danger. The reality is that C++ is not really as type-safe as Ada. Consider the automatic promotion of values from an integer to a float. While this might seem trivial on the surface, it is not a good example of type-safety -- certainly not an example of strict typing. I take your point about not using simple arrays. The responsible C++ programmer will not use that feature. Ooops! Sorry. I still see a lot of C++ code written that way, and even using pointer computation. It is just too easy to do that instead of using those pesky libraries. And the wonderful assortment of type-casting one finds in C++ brings even more joy to the development process. Particularly amusing is casting away const. One could go on, but it is 5 AM in the morning, and I need to get ready for work. The verbosity in Ada is no accident. The programs are intended to be more readable than writeable. They are intended to be more reliable and to be more checkable at compile-time. Those are fundamental goals. They are, for the most part, achieved. There is a good reason why Ada does not have some of the wonderful little shortcuts you find so charming in C++: those shortcuts and defaults are simply not suitable for producing dependable code. In my most recent meeting with a bunch of C++ developers, there was general agreement that one must use C++ with great care to avoid creating horrible programs. Everyone who uses C++ (except you, it seems) realizes that the language is fraught with traps for the unwary programmer -- and even the wary programmer. I would expect one would want a language where the focus was on using the language to solve application problems, not to solve language problems. This is where Ada and C++ part company. When using Ada, I am able to focus on the application problem rather than worrying about the pitfalls inherent in the language. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 13:00 ` adaworks @ 2007-04-12 15:28 ` Hyman Rosen 2007-04-12 18:32 ` Robert A Duff 2007-04-22 18:53 ` adaworks 0 siblings, 2 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-12 15:28 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > This tends to increase, not decrease, the dependability since each > instantiation is checked at compile-time. Every C++ template instantiation is done, and therefore checked, at compile-time. It's Ada that has run-time instantiation (with compile-time checking). >> Time end = integrate_until(f1 * phase_shift(f2,start) / f3 + f4, q); >> even though f1, f2, f3, and f4 were possibly of different types. > In fact, your acknowledgement of the "different types" is quite telling. Telling of what? Automatic instantiation lets generic functions come into being as programs use them. > Further, the ad hoc pointer is potentially problematic. What pointer? I see no pointer in this code. > A similar construct in Ada, using an access to a function, requires the > function to be type conformant and parameter conformant prior to being > incorporated into the construct. The C++ code has no pointers at all. The automatic instantiation done by the C++ template mechanism is similar in its goals to Ada's operator overloading. A universe of candidate functions is searched through a rules system that picks one best choice or reports an error. > However, typedef does not provide the level of type safety one would > expect in a corresponding Ada program. Typedef merely creates a synonym for a type, another name by which that type is known. It cannot increase or decrease safety in any way, although it may increase abstraction. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 15:28 ` Hyman Rosen @ 2007-04-12 18:32 ` Robert A Duff 2007-04-13 15:59 ` Hyman Rosen 2007-04-22 18:53 ` adaworks 1 sibling, 1 reply; 167+ messages in thread From: Robert A Duff @ 2007-04-12 18:32 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > The C++ code has no pointers at all. The automatic instantiation done by > the C++ template mechanism is similar in its goals to Ada's operator > overloading. A universe of candidate functions is searched through a rules > system that picks one best choice or reports an error. Operator overloading is just one subset of subprogram overloading -- there's nothing special about operators, except they use a different notation. The same is true in C++, although C++ doesn't allow top-down overload resolution, which is an annoying restriction. - Bob ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 18:32 ` Robert A Duff @ 2007-04-13 15:59 ` Hyman Rosen 2007-04-14 22:20 ` Robert A Duff 0 siblings, 1 reply; 167+ messages in thread From: Hyman Rosen @ 2007-04-13 15:59 UTC (permalink / raw) Robert A Duff wrote: > Operator overloading is just one subset of subprogram overloading Sure. I was just replying to the notion that manual instantiation is better than automatic because it avoids having the compiler pick your functions for you, pointing out that Ada already does that. > C++ doesn't allow top-down overload resolution, > which is an annoying restriction. Yep. But given all of the automatic type conversions that C++ allows, most of the time you would wind up in ambiguity land anyway. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-13 15:59 ` Hyman Rosen @ 2007-04-14 22:20 ` Robert A Duff 2007-04-14 22:46 ` Randy Brukardt 0 siblings, 1 reply; 167+ messages in thread From: Robert A Duff @ 2007-04-14 22:20 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Robert A Duff wrote: >> Operator overloading is just one subset of subprogram overloading > > Sure. I was just replying to the notion that manual instantiation is > better than automatic because it avoids having the compiler pick your > functions for you, pointing out that Ada already does that. Right. Ada also has the "is <>" default notation for generic formal parameters, which is a similar sort of "implicit / behind-the-scenes-magic". It means "pick something with the same name, visible at the place of the instantiation". Some might consider that rather error prone, but it's also rather useful. It probably wouldn't mix well with implicit instantiation. - Bob ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-14 22:20 ` Robert A Duff @ 2007-04-14 22:46 ` Randy Brukardt 0 siblings, 0 replies; 167+ messages in thread From: Randy Brukardt @ 2007-04-14 22:46 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcc647ybnsl.fsf@shell01.TheWorld.com... ... > Ada also has the "is <>" default notation for generic formal parameters, Only for *some* kinds of formal parameters. It clearly would be useful to have defaults for *all* kinds of formal parameters; it would reduce the effort to create explicit instantiations a lot. (Of course, the ARG didn't have the will for this idea; see AI95-00299.) Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 15:28 ` Hyman Rosen 2007-04-12 18:32 ` Robert A Duff @ 2007-04-22 18:53 ` adaworks 2007-04-22 19:50 ` Gautier 1 sibling, 1 reply; 167+ messages in thread From: adaworks @ 2007-04-22 18:53 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:_esTh.11650$eC.2533@trndny03... > adaworks@sbcglobal.net wrote: >> This tends to increase, not decrease, the dependability since each > > instantiation is checked at compile-time. > > Every C++ template instantiation is done, and therefore checked, > at compile-time. It's Ada that has run-time instantiation (with > compile-time checking). > As you note, the checking is done at compile-time in Ada. generic type Num is range <>; package ... When I instantiate Num with some actual type, the unit containing that type has already been checked at compile time of the instantiation will not compile. The package being instantiated is using that type instead of some phantom type. I have looked at the C++ instantiation model and I find it confusing and error-prone -- especially at the human level. Several months ago I had to go over it with a colleague who was trying to unravel its complexity in a piece of code he inherited. He finally got it, but not without a lot of head-scratching. To suggest that C++ is more dependable in its template model, or in any other way, than Ada, is simply wrong -- or a strained interpretation of the relative language designs. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-22 18:53 ` adaworks @ 2007-04-22 19:50 ` Gautier 0 siblings, 0 replies; 167+ messages in thread From: Gautier @ 2007-04-22 19:50 UTC (permalink / raw) > "Hyman Rosen" <hyrosen@mail.com> wrote in message >> Every C++ template instantiation is done, and therefore checked, >> at compile-time. It's Ada that has run-time instantiation (with >> compile-time checking). adaworks@sbcglobal.net wrote: > As you note, the checking is done at compile-time in Ada. [...] By the way, Hyman's "It's Ada that has run-time instantiation" is misleading, since it could be interpreted that Ada instantiations are systematically done at run-time, which is wrong... ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:27 ` kevin cline ` (3 preceding siblings ...) 2007-04-02 13:00 ` adaworks @ 2007-04-03 0:26 ` Markus E Leypold 2007-04-03 0:34 ` Markus E Leypold 2007-04-03 2:22 ` jimmaureenrogers 6 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-03 0:26 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: > To me, it's a large advantage, and not narrowly focused at all. I > would think the inability to perform complete compile-time checking of > physical units would be pretty serious in real-time control > applications. Do Ada programmers make do with run-time type checking, > or just write more and more generic function instantiations until the > application is finished? The rest of use have more important things > to do. <...> > It's not safer, AS A GENERAL PRINCIPLE. But in the hands of experts, C > ++ allows compile-time type checking that is impossible in Ada. <...> > ... when used by poorly lead mediocre programmers. <...> > No doubt some programmers do. Good C++ programmers don't. I > certainly don't. Is this a macho / male ego thing to you? It certainly sounds like it. >> As for high-level programming, this is where Ada does excel. > > Not for most of us, because the advantages in safety are overwhelmed > by the increased verbosity. Haha. You don't sound like an experienced developer to my suspicious ears ... >> With all mechanisms available in Ada for developing solid, dependable >> code and a language definition that focuses on creating compilers that >> maximize the amount of error detection that can be done early in >> the development process, I wonder whether you really understand >> Ada at all. Have you any understanding of the visbility rules? This >> goes well beyond type-safety. Do you understand the library model >> and how it affects separate compilation? > > Do you understand how unimportant those theoretical considerations are > for those of us faced with time-to-market pressure? Do you understand "those of us faced with time to market pressure"? :-), indeed :-))). I see you hunting bugs after you shipped banana software then for the next years. > how the start of the art in C++ compilers and C++ programming has > advanced since Ada-95 was introduced? >> As for the safety of generics, Grein's paper, which you take delight >> in citing, does not discount the fact that most generic constructs >> are type-safe at compile time. Further, getting it right, with C++ >> templates is no trivial feat either. > Actually, it's pretty trivial once you learn to think at the right > level of abstraction. And if no one on a team can think at the right > level of abstraction, you will end up with a mess regardless of the > language chosen. :-))) >> There are plenty of opportunities >> to create errors in C++ templates. >> >> I have programmed in both languages. > > How much? > >> I have taught C++ > Which textbook did you use? > For me, the short reason is that Ada generics are not as powerful as C+ > + templates. The power of C++ templates has enabled me to write > compact, efficient type-safe application code at a very high level in > a way which is not possible in Ada. More marketing speak ... Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:27 ` kevin cline ` (4 preceding siblings ...) 2007-04-03 0:26 ` Markus E Leypold @ 2007-04-03 0:34 ` Markus E Leypold 2007-04-03 2:22 ` jimmaureenrogers 6 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-03 0:34 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: <... many things ...> To me Kevin, what you write sounds plenty like so much bullshitting. It's less that you oppose Ada and advocate C++ but the way you do it. I still think that in reality the case against C++ as vs. for Ada is not as clear cut as many here think since other factors beside the language itself have to be taken into consideration -- but whereas I hopefully have been trying to explain my reasoning you're just bragging about how much better you supposedly are than the average of the industry and spouting so much nonsense (you're not even using the word "type safe" right). I can't get rid of the impression that -- as a programmer -- you're actually rather immature and rather full of yourself. Learn humility. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:27 ` kevin cline ` (5 preceding siblings ...) 2007-04-03 0:34 ` Markus E Leypold @ 2007-04-03 2:22 ` jimmaureenrogers 2007-04-12 15:47 ` Hyman Rosen 6 siblings, 1 reply; 167+ messages in thread From: jimmaureenrogers @ 2007-04-03 2:22 UTC (permalink / raw) While the C++ template language is very powerful it is also amazingly crippled in the eyes of an Ada programmer (me). In discussions with C++ programmers concerning the ability to write templates for range-specified numeric types I discovered that C++ template language does not allow the specification of a floating point value as a template parameter. Therefore, while one can write a C++ template to handle range-specified integer classes, one cannot write a C++ template to handle range-specified floating point classes. In other words, C++ allows you to write a template that is equivalent to: type My_Integer_Type is range 1..10; But you cannot write a template equivalent to: type Voltage_Type is digits 11 range -5.0..5.0; Jim Rogers ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-03 2:22 ` jimmaureenrogers @ 2007-04-12 15:47 ` Hyman Rosen 2007-04-12 16:18 ` Markus E Leypold ` (2 more replies) 0 siblings, 3 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-12 15:47 UTC (permalink / raw) jimmaureenrogers@worldnet.att.net wrote: > I discovered that C++ template language does not allow the > specification of a floating point value as a template parameter. In C++, instantiations are considered the same if their parameters are the same, and the standards committee did not want the burden of defining T<3.0*(1.0/3.0)> vis a vis T<1.0>. > one cannot write a C++ template to handle range-specified > floating point classes. Of course this is wrong. Every floating point number that you write in a program is in fact a rational number, and therefore depending on the purpose those numbers will have in the template, they be represented using small sets of integers in a variety of ways. The template itself can then assemble these parts into a floating-point constant and use it. Or if that's too burdensome, references to floating-point variables are permitted, so getting what you want looks rather like Ada generic instantiation. > But you cannot write a template equivalent to: > type Voltage_Type is digits 11 range -5.0..5.0; Using the variable reference approach, we can do template <typename T, int digits, T const &lo, T const &hi> class FloatRange; extern double const vtlo = -5.0; extern double const vthi = 5.0; typedef FloatRange<double, 11, vtlo, vthi> Voltage_Type; ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 15:47 ` Hyman Rosen @ 2007-04-12 16:18 ` Markus E Leypold 2007-04-13 23:18 ` kevin cline 2007-04-15 0:59 ` Hyman Rosen 2007-04-12 16:39 ` Dmitry A. Kazakov 2007-04-14 1:20 ` jimmaureenrogers 2 siblings, 2 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-12 16:18 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > jimmaureenrogers@worldnet.att.net wrote: >> I discovered that C++ template language does not allow the >> specification of a floating point value as a template parameter. > > In C++, instantiations are considered the same if their > parameters are the same, and the standards committee did > not want the burden of defining T<3.0*(1.0/3.0)> vis a vis > T<1.0>. We have been through that discussion before. IMHO that this decision was even necessarry indicates (in my eyes) the inferiority of the automatic instantion approach. In C++ the "identity" of an instance needs to be determined by the parameters. In Ada (and many other languages with functors) by the act of instantiation. > >> one cannot write a C++ template to handle range-specified > > floating point classes. > > Of course this is wrong. Every floating point number that you > write in a program is in fact a rational number, and therefore > depending on the purpose those numbers will have in the template, > they be represented using small sets of integers in a variety of > ways. The template itself can then assemble these parts into a > floating-point constant and use it. Or if that's too burdensome, > references to floating-point variables are permitted, so getting > what you want looks rather like Ada generic instantiation. Groan. How ugly. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:18 ` Markus E Leypold @ 2007-04-13 23:18 ` kevin cline 2007-04-14 9:38 ` Georg Bauhaus 2007-04-14 10:57 ` Markus E Leypold 2007-04-15 0:59 ` Hyman Rosen 1 sibling, 2 replies; 167+ messages in thread From: kevin cline @ 2007-04-13 23:18 UTC (permalink / raw) On Apr 12, 11:18 am, Markus E Leypold <development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote: > Hyman Rosen <hyro...@mail.com> writes: > > jimmaureenrog...@worldnet.att.net wrote: > >> I discovered that C++ template language does not allow the > >> specification of a floating point value as a template parameter. > > > In C++, instantiations are considered the same if their > > parameters are the same, and the standards committee did > > not want the burden of defining T<3.0*(1.0/3.0)> vis a vis > > T<1.0>. > > We have been through that discussion before. IMHO that this decision > was even necessarry indicates (in my eyes) the inferiority of the > automatic instantion approach. Automatic instantiation allows one to write very powerful libraries in C++ that are impractical to implement in Ada. For a good example, see the SPIRIT parser library (http://www.boost.org/libs/spirit/ index.html). So the choice can comes down to hundreds of lines of C++ or thousands of lines of Ada. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-13 23:18 ` kevin cline @ 2007-04-14 9:38 ` Georg Bauhaus 2007-04-14 10:57 ` Markus E Leypold 1 sibling, 0 replies; 167+ messages in thread From: Georg Bauhaus @ 2007-04-14 9:38 UTC (permalink / raw) On Fri, 2007-04-13 at 16:18 -0700, kevin cline wrote: > Automatic instantiation allows one to write very powerful libraries in > C++ that are impractical to implement in Ada. For a good example, see > the SPIRIT parser library (http://www.boost.org/libs/spirit/ You've said this in August 2004, and were given your example written in the (technically more powerful) Spitbol pattern matcher of GNAT. Same LOC. Are there new properties of Boost::spirit that have changed the relation? > index.html). So the choice can comes down to hundreds of lines of C++ > or thousands of lines of Ada. Try this: template <int x> int more(int y) { return x + y; } int main(void) { int result = 0; for (int p = 0; p < 100; ++p) { result += more<p>(5); } return result; } ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-13 23:18 ` kevin cline 2007-04-14 9:38 ` Georg Bauhaus @ 2007-04-14 10:57 ` Markus E Leypold 2007-04-15 15:10 ` Simon Wright 1 sibling, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-04-14 10:57 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: > On Apr 12, 11:18 am, Markus E Leypold > <development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote: >> Hyman Rosen <hyro...@mail.com> writes: >> > jimmaureenrog...@worldnet.att.net wrote: >> >> I discovered that C++ template language does not allow the >> >> specification of a floating point value as a template parameter. >> >> > In C++, instantiations are considered the same if their >> > parameters are the same, and the standards committee did >> > not want the burden of defining T<3.0*(1.0/3.0)> vis a vis >> > T<1.0>. >> >> We have been through that discussion before. IMHO that this decision >> was even necessarry indicates (in my eyes) the inferiority of the >> automatic instantion approach. > > Automatic instantiation allows one to write very powerful libraries in > C++ that are impractical to implement in Ada. For a good example, see > the SPIRIT parser library (http://www.boost.org/libs/spirit/ > index.html). So the choice can comes down to hundreds of lines of C++ > or thousands of lines of Ada. [] You know what you're talking about? And, BTW, even if it were so, I'm not sure wether I wouldn't go for the longer, readable and perhaps more likely correct code instead of code which is terse, "smart", unreadable and therefore unreviewable and probably wrong. As much issue as I have with some of the culture surrounding Ada (i.e. a kind of corral mentality with respect to a number of topics), the language itself as written in the ARM isn't a problem. The number of instantiations you're referring to can probably be kept under control by using hierarchies of generics and instantiation the whole hierarchy in one line (see e.g. the Booch components). Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-14 10:57 ` Markus E Leypold @ 2007-04-15 15:10 ` Simon Wright 2007-04-15 16:05 ` Markus E Leypold 0 siblings, 1 reply; 167+ messages in thread From: Simon Wright @ 2007-04-15 15:10 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > The number of instantiations you're referring to can probably be > kept under control by using hierarchies of generics and > instantiation the whole hierarchy in one line (see e.g. the Booch > components). One line per level, you'll find! ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-15 15:10 ` Simon Wright @ 2007-04-15 16:05 ` Markus E Leypold 0 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-15 16:05 UTC (permalink / raw) Simon Wright <simon.j.wright@mac.com> writes: > Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > >> The number of instantiations you're referring to can probably be >> kept under control by using hierarchies of generics and >> instantiation the whole hierarchy in one line (see e.g. the Booch >> components). > > One line per level, you'll find! Yes. That does not make one line per instance, but interesting enough, one line per different parameter. I find that acceptable. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:18 ` Markus E Leypold 2007-04-13 23:18 ` kevin cline @ 2007-04-15 0:59 ` Hyman Rosen 2007-04-15 15:28 ` Markus E Leypold 1 sibling, 1 reply; 167+ messages in thread From: Hyman Rosen @ 2007-04-15 0:59 UTC (permalink / raw) Markus E Leypold wrote: > the inferiority of the automatic instantion approach. > In C++ the "identity" of an instance needs to be determined > by the parameters. In Ada (and many other languages with > functors) by the act of instantiation. But without the C++ way of identity, and without specialization, the language cannot do template metaprogramming, as is impossible in Ada. That's a trade-off I'll gladly make. > Groan. How ugly. Well, maybe they'll add it in one day. But, Lord knows, this isn't the ugliest workaround that C++ requires. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-15 0:59 ` Hyman Rosen @ 2007-04-15 15:28 ` Markus E Leypold 0 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-15 15:28 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Markus E Leypold wrote: >> the inferiority of the automatic instantion approach. > > In C++ the "identity" of an instance needs to be determined > > by the parameters. In Ada (and many other languages with > > functors) by the act of instantiation. > > But without the C++ way of identity, and without specialization, > the language cannot do template metaprogramming, as is impossible > in Ada. That's a trade-off I'll gladly make. Me too. I'll gladly forgo "template metaprogramming" for explicit instantition. >> Groan. How ugly. > > Well, maybe they'll add it in one day. But, Lord knows, this isn't > the ugliest workaround that C++ requires. No. Which in itself speaks volumes. C++ is only a big workaround (around the deficiencies of C when use how it wasn't designed: As a high level language). Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 15:47 ` Hyman Rosen 2007-04-12 16:18 ` Markus E Leypold @ 2007-04-12 16:39 ` Dmitry A. Kazakov 2007-04-12 20:54 ` Georg Bauhaus 2007-04-14 1:20 ` jimmaureenrogers 2 siblings, 1 reply; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-12 16:39 UTC (permalink / raw) On Thu, 12 Apr 2007 15:47:36 GMT, Hyman Rosen wrote: > floating point number that you > write in a program is in fact a rational number, No, this is an incorrect statement. I can build hardware for floating-point numbers with the radix e. These will not be rational numbers. A correct statement is: the floating-point numbers are classes of equivalence of real numbers. These classes are typically intervals and each such interval contains a rational number. But that alone, does not make the job of comparing classes of equivalence much easier. Which is the reason why the notion of structural equivalence (used by templates) is a can of worms. > and therefore > depending on the purpose those numbers will have in the template, > they be represented using small sets of integers in a variety of > ways. The template itself can then assemble these parts into a > floating-point constant and use it. Yes, but see above, you cannot tell which class of equivalence that constant would denote. You cannot enumerate real numbers, so the approach is fundamentally flawed. You need a type to identify the classes because you have to know the delta and the radix when you compare "universal" real literals. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:39 ` Dmitry A. Kazakov @ 2007-04-12 20:54 ` Georg Bauhaus 2007-04-12 20:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 167+ messages in thread From: Georg Bauhaus @ 2007-04-12 20:54 UTC (permalink / raw) On Thu, 2007-04-12 at 18:39 +0200, Dmitry A. Kazakov wrote: > On Thu, 12 Apr 2007 15:47:36 GMT, Hyman Rosen wrote: > > > floating point number that you > > write in a program is in fact a rational number, > > No, this is an incorrect statement. I can build hardware for floating-point > numbers with the radix e. Will radix e hardware be digital hardware? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 20:54 ` Georg Bauhaus @ 2007-04-12 20:33 ` Dmitry A. Kazakov 2007-04-12 21:40 ` Georg Bauhaus 0 siblings, 1 reply; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-12 20:33 UTC (permalink / raw) On Thu, 12 Apr 2007 22:54:02 +0200, Georg Bauhaus wrote: > On Thu, 2007-04-12 at 18:39 +0200, Dmitry A. Kazakov wrote: >> On Thu, 12 Apr 2007 15:47:36 GMT, Hyman Rosen wrote: >> >>> floating point number that you >>> write in a program is in fact a rational number, >> >> No, this is an incorrect statement. I can build hardware for floating-point >> numbers with the radix e. > > Will radix e hardware be digital hardware? Why not? It is just about representation of numbers in the form X = sum Xk e**k That's computable. Nothing requires us to have accurate rational numbers or any given number in our system. I guess one could even have a system where 0 would be represented by a non-periodic sequence of "digits". (:-)) http://en.wikipedia.org/wiki/Non-integer_representation http://en.wikipedia.org/wiki/Golden_ratio_base -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 20:33 ` Dmitry A. Kazakov @ 2007-04-12 21:40 ` Georg Bauhaus 2007-04-12 20:50 ` Dmitry A. Kazakov 2007-04-13 0:32 ` Markus E Leypold 0 siblings, 2 replies; 167+ messages in thread From: Georg Bauhaus @ 2007-04-12 21:40 UTC (permalink / raw) On Thu, 2007-04-12 at 22:33 +0200, Dmitry A. Kazakov wrote: > I can build hardware for floating-point > >> numbers with the radix e. > > > > Will radix e hardware be digital hardware? > > Why not? It is just about representation of numbers in the form > > X = sum Xk e**k > > That's computable. Hm. Are you saying that e is computable using digital hardware in finite time? Or that we interpret some discrete unit in the computer as a base named e? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 21:40 ` Georg Bauhaus @ 2007-04-12 20:50 ` Dmitry A. Kazakov 2007-04-13 0:32 ` Markus E Leypold 1 sibling, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-12 20:50 UTC (permalink / raw) On Thu, 12 Apr 2007 23:40:47 +0200, Georg Bauhaus wrote: > On Thu, 2007-04-12 at 22:33 +0200, Dmitry A. Kazakov wrote: >> I can build hardware for floating-point >>>> numbers with the radix e. >>> >>> Will radix e hardware be digital hardware? >> >> Why not? It is just about representation of numbers in the form >> >> X = sum Xk e**k >> >> That's computable. > > Hm. Are you saying that e is computable using digital hardware > in finite time? Sure. Here it is: e. The question is meaningless without specifying the language. In my language e is computable, but 10 is probably not. > Or that we interpret some discrete unit in the computer as > a base named e? Yes. Some computer states are associated with the variable x having the value e. That is. It is no different from associating them x=0 or x=1. Computer states are not numbers. We, humans, interpret them as numbers. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 21:40 ` Georg Bauhaus 2007-04-12 20:50 ` Dmitry A. Kazakov @ 2007-04-13 0:32 ` Markus E Leypold 2007-04-14 22:27 ` Robert A Duff 1 sibling, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-04-13 0:32 UTC (permalink / raw) Georg Bauhaus <bauhaus@futureapps.de> writes: > On Thu, 2007-04-12 at 22:33 +0200, Dmitry A. Kazakov wrote: >> I can build hardware for floating-point >> >> numbers with the radix e. >> > >> > Will radix e hardware be digital hardware? >> >> Why not? It is just about representation of numbers in the form >> >> X = sum Xk e**k >> >> That's computable. > > Hm. Are you saying that e is computable using digital hardware > in finite time? As much as I disklike Dmitry's disgressions in the obscure and wonderful: But here he is right: A real number representation (X_n, ... X_0 ..., X_u) means X = sum X_k e**k has a well defined meaning and those number representations can be manipulated in finite time by some algorithm (hard or software) that the operation corresponds to multiplication or addition. The representations are just a bit long -- but so are those handled by arbitrary precision libraries like GMP. And of course it tedious to convert those representations to "normal" floats and most natural numbers have no (that is no finite representation) in that system. Fortunately 'e' has a finite representation - '1'. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-13 0:32 ` Markus E Leypold @ 2007-04-14 22:27 ` Robert A Duff 0 siblings, 0 replies; 167+ messages in thread From: Robert A Duff @ 2007-04-14 22:27 UTC (permalink / raw) Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes: > As much as I disklike Dmitry's disgressions in the obscure and > wonderful: I think they're fun, and in some cases, even instructive. ;-) >...But here he is right: >... Yup. - Bob ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 15:47 ` Hyman Rosen 2007-04-12 16:18 ` Markus E Leypold 2007-04-12 16:39 ` Dmitry A. Kazakov @ 2007-04-14 1:20 ` jimmaureenrogers 2 siblings, 0 replies; 167+ messages in thread From: jimmaureenrogers @ 2007-04-14 1:20 UTC (permalink / raw) On Apr 12, 9:47 am, Hyman Rosen <hyro...@mail.com> wrote: > jimmaureenrog...@worldnet.att.net wrote: > > one cannot write a C++ template to handle range-specified > > > floating point classes. > > Of course this is wrong. Every floating point number that you > write in a program is in fact a rational number, and therefore > depending on the purpose those numbers will have in the template, > they be represented using small sets of integers in a variety of > ways. The template itself can then assemble these parts into a > floating-point constant and use it. Or if that's too burdensome, > references to floating-point variables are permitted, so getting > what you want looks rather like Ada generic instantiation. > > > But you cannot write a template equivalent to: > > type Voltage_Type is digits 11 range -5.0..5.0; > > Using the variable reference approach, we can do > > template <typename T, int digits, T const &lo, T const &hi> class FloatRange; > extern double const vtlo = -5.0; > extern double const vthi = 5.0; > typedef FloatRange<double, 11, vtlo, vthi> Voltage_Type; Your example relies upon passing pre-defined constants for the parameters lo and hi. It also allows you to specify whatever type is aliased by typename T. How does this template ensure that typename T is an alias for a floating point type? It appears that T could be instantiated with any type, including for instance the String type. C++ template syntax provides no way to pass float or double literals for the parameters lo and hi. It also provides no syntax to ensure that typename T is a floating point type. These deficiencies render your example not equivalent to the Ada example. Furthermore, they are weaknesses that are not a problem in the Ada generic formal parameter syntax. Jim Rogers ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:58 ` kevin cline ` (2 preceding siblings ...) 2007-03-30 17:39 ` adaworks @ 2007-04-02 5:03 ` Brian May 2007-04-02 6:16 ` kevin cline 3 siblings, 1 reply; 167+ messages in thread From: Brian May @ 2007-04-02 5:03 UTC (permalink / raw) >>>>> "kevin" == kevin cline <kevin> writes: kevin> "The big difference is that C++ templates allow type kevin> checking during compile-time [...] How is this any different from Ada generics? Ada generics do type checking at compile-time too. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 5:03 ` Brian May @ 2007-04-02 6:16 ` kevin cline 2007-04-03 0:00 ` Brian May 2007-04-03 0:13 ` Markus E Leypold 0 siblings, 2 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 6:16 UTC (permalink / raw) On Apr 2, 12:03 am, Brian May <b...@snoopy.apana.org.au> wrote: > >>>>> "kevin" == kevin cline <kevin> writes: > > kevin> "The big difference is that C++ templates allow type > kevin> checking during compile-time [...] > > How is this any different from Ada generics? Because Ada generics have to be explicitly instantiated. Ada requires an explicit instantiation for every combination of types that appears in the program. C++ template functions are implicitly instantiated, and can be defined once to cover all combinations of physical units, like this: template <int M, int L, int T> class Unit // Mechanical unit with mass dimension M, length dimension L, // and time dimension T. { private: double value; public: explicit Unit(double v): value(v) {} Unit operator+(Unit rhs) { return Unit(v + rhs.v); } Unit operator-(Unit rhs) { return Unit(v - rhs.v); } Unit<M+M2,L+L2,T+T2> operator*(Unit<M2,L2,T2>& rhs) { return Unit<M+M2,L+L2,T+T2>(v * rhs.v); } ... }; typedef Unit<0,0,0> Scalar; typedef Unit<1,0,0> Mass; typedef Unit<0,1,0> Length; typedef Unit<0,0,1> Time; typedef Unit<1,1,-2> Force; typedef Unit<1,-1,-2> Pressure; typedef Unit<1,-3,0> Density; Mass gram(1); Length meter(1); Time second(1); Pressure water_pressure(Length head) { Force g_earth = Scalar(9.8)*meter/second/second; Density water_density = Scalar(1000000)*gram/meter/meter/meter; return head * g_earth * water_density; } Ada would require a separate instantiations for each of these operations: Scalar * Length (returning Length) Length / Time (returning Velocity) Velocity / Time (returning Acceleration) Scalar * Mass (returning Mass) Mass / Length (returning Unit<1,-1,0>) Unit<1,-1,0>/Length (returning Unit<1,-2,0>) Unit<1,-2,0>/Length (returning Density) Length * Acceleration (returning Unit<0,-2,2>) Unit<0,2,2>*Density (returning Pressure) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 6:16 ` kevin cline @ 2007-04-03 0:00 ` Brian May 2007-04-12 15:56 ` Hyman Rosen 2007-04-03 0:13 ` Markus E Leypold 1 sibling, 1 reply; 167+ messages in thread From: Brian May @ 2007-04-03 0:00 UTC (permalink / raw) >>>>> "kevin" == kevin cline <kevin> writes: kevin> Because Ada generics have to be explicitly instantiated. kevin> Ada requires an explicit instantiation for every kevin> combination of types that appears in the program. C++ kevin> template functions are implicitly instantiated, and can be kevin> defined once to cover all combinations of physical units, kevin> like this: It is a compromise between: - having a language where you are forced to be specific about the details OR - having a language where the compiler tries to guess what you meant. Personally I prefer the first option, as I have found the second option hides bugs. Many programmers prefer the later, which is (presumably) why languages like Perl, PHP, Python and ASP are so popular. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-03 0:00 ` Brian May @ 2007-04-12 15:56 ` Hyman Rosen 2007-04-12 16:19 ` Markus E Leypold 0 siblings, 1 reply; 167+ messages in thread From: Hyman Rosen @ 2007-04-12 15:56 UTC (permalink / raw) Brian May wrote: > - having a language where the compiler tries to guess what you meant Then why does Ada have operator overloading? Ada's generic model is different from C++ templates. Automatic instantiation is a much less comfortable fit in Ada for language design reasons, not safety reasons. That's largely because C++ types are static compile-time things, while Ada types are dynamic runtime things. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 15:56 ` Hyman Rosen @ 2007-04-12 16:19 ` Markus E Leypold 2007-04-13 23:42 ` Georg Bauhaus 0 siblings, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-04-12 16:19 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > That's largely because C++ types are static compile-time > things, while Ada types are dynamic runtime things. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ How so? That is indeed news to me. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:19 ` Markus E Leypold @ 2007-04-13 23:42 ` Georg Bauhaus 0 siblings, 0 replies; 167+ messages in thread From: Georg Bauhaus @ 2007-04-13 23:42 UTC (permalink / raw) On Thu, 2007-04-12 at 18:19 +0200, Markus E Leypold wrote: > > Hyman Rosen <hyrosen@mail.com> writes: > > > That's largely because C++ types are static compile-time > > things, while Ada types are dynamic runtime things. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > How so? That is indeed news to me. In this sense: type P is tagged null record; procedure here(n: Positive) is subtype S is Positive range 1 .. n; type T is array (S range <>) of Character; type D is new P with record item: T(1 .. n); end record; begin pragma assert(S'last = 42); null; end here; ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 6:16 ` kevin cline 2007-04-03 0:00 ` Brian May @ 2007-04-03 0:13 ` Markus E Leypold 1 sibling, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-03 0:13 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: > On Apr 2, 12:03 am, Brian May <b...@snoopy.apana.org.au> wrote: >> >>>>> "kevin" == kevin cline <kevin> writes: >> >> kevin> "The big difference is that C++ templates allow type >> kevin> checking during compile-time [...] >> >> How is this any different from Ada generics? > > Because Ada generics have to be explicitly instantiated. That doesn't make them non type checking. Quite the opposite. And as far as type checking in templates goes: Last time I looked, many usage errors intemplates where not caught by a kind of type systems (which would say "you can't use this tape as a parameter in a template), but rather by the linker wwhich told me that there is no usch function/method for this type: This is not type checking. > Ada requires > an explicit instantiation for every combination of types that appears > in the program. C++ template functions are implicitly instantiated, > and can be defined once to cover all combinations of physical units, > like this: I think we had the problem already once: What about floating point parameters to templates? :-) > > template <int M, int L, int T> class Unit > // Mechanical unit with mass dimension M, length dimension L, > // and time dimension T. > { > private: > double value; > public: > explicit Unit(double v): value(v) {} > Unit operator+(Unit rhs) { return Unit(v + rhs.v); } > Unit operator-(Unit rhs) { return Unit(v - rhs.v); } > Unit<M+M2,L+L2,T+T2> operator*(Unit<M2,L2,T2>& rhs) > { return Unit<M+M2,L+L2,T+T2>(v * rhs.v); } > ... > }; > > typedef Unit<0,0,0> Scalar; > typedef Unit<1,0,0> Mass; > typedef Unit<0,1,0> Length; > typedef Unit<0,0,1> Time; > typedef Unit<1,1,-2> Force; > typedef Unit<1,-1,-2> Pressure; > typedef Unit<1,-3,0> Density; > > Mass gram(1); > Length meter(1); > Time second(1); > > Pressure water_pressure(Length head) > { > Force g_earth = Scalar(9.8)*meter/second/second; > Density water_density = Scalar(1000000)*gram/meter/meter/meter; > return head * g_earth * water_density; > } > > Ada would require a separate instantiations for each of these > operations: > > Scalar * Length (returning Length) > Length / Time (returning Velocity) > Velocity / Time (returning Acceleration) > Scalar * Mass (returning Mass) > Mass / Length (returning Unit<1,-1,0>) > Unit<1,-1,0>/Length (returning Unit<1,-2,0>) > Unit<1,-2,0>/Length (returning Density) > Length * Acceleration (returning Unit<0,-2,2>) > Unit<0,2,2>*Density (returning Pressure) Who cares? I'm a physicist (by education), but I have come to the conclusion that judging the merits of a programming system on how much I have to type to support checking physical units is cranky: It's a fringe application and I can write a "physical units" definition file and a translator to translate this into a Physical_Units package (which does not only contain kg*m/s^2 (as your template does) but actually the type Force) in some hours. BTW: I haven't checked your C++ example, but I'd expect trouble if one calculates f / m * t1 * t2 as opposed to t1 * t2 * f / m since you need (dependend on the implicit grouping/association of the multiplication operator) also operations time * time -> time^2 time * force -> momemntum [kg*m/s] and so on. Maybe the templating would automatically provide all this (more power to C++ then), but it certainly looks like a complete mess Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Shortage on C / C++ experts 2007-03-30 4:09 ` Steve 2007-03-30 4:58 ` kevin cline @ 2007-04-02 11:47 ` Larry Kilgallen 2007-04-02 12:01 ` Ludovic Brenta 1 sibling, 1 reply; 167+ messages in thread From: Larry Kilgallen @ 2007-04-02 11:47 UTC (permalink / raw) In article <4610a3c8$1@news.post.ch>, Martin Krischik <krischik@users.sourceforge.net> writes: > kevin cline schrieb: > >>> Any suggestion that C++ >>> is, as a general principle, safer than Ada is simply a fantasy. >> >> It's not safer, AS A GENERAL PRINCIPLE. But in the hands of experts, C >> ++ allows compile-time type checking that is impossible in Ada. > > So does Assembler. Problem is that only 1% of C / C++ programmers are > experts. So the problem is how to ensure that only experts are hired by the company for whom you work. And the larger problem is how to ensure that only experts are hired by the manufacturers of airplanes on which you fly. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Shortage on C / C++ experts 2007-04-02 11:47 ` Shortage on C / C++ experts Larry Kilgallen @ 2007-04-02 12:01 ` Ludovic Brenta 2007-04-02 12:15 ` Dmitry A. Kazakov 0 siblings, 1 reply; 167+ messages in thread From: Ludovic Brenta @ 2007-04-02 12:01 UTC (permalink / raw) Larry Kilgallen wrote: > So the problem is how to ensure that only experts are hired by the > company for whom you work. > > And the larger problem is how to ensure that only experts are hired > by the manufacturers of airplanes on which you fly. And how to ensure that the experts never have a momentary lapse of reason, to quote a well-known band. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Shortage on C / C++ experts 2007-04-02 12:01 ` Ludovic Brenta @ 2007-04-02 12:15 ` Dmitry A. Kazakov 2007-04-02 18:47 ` Alexander E. Kopilovich 0 siblings, 1 reply; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-02 12:15 UTC (permalink / raw) On 2 Apr 2007 05:01:05 -0700, Ludovic Brenta wrote: > Larry Kilgallen wrote: >> So the problem is how to ensure that only experts are hired by the >> company for whom you work. >> >> And the larger problem is how to ensure that only experts are hired >> by the manufacturers of airplanes on which you fly. > > And how to ensure that the experts never have a momentary lapse of > reason, to quote a well-known band. Umm, no, it is how to tie expertise to money. The rest is secondary. It is the tickets we are paying for, not for speed, schedule, comfort, not even for a chance to not to crash. After all both the first and the economy classes would crash together... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Shortage on C / C++ experts 2007-04-02 12:15 ` Dmitry A. Kazakov @ 2007-04-02 18:47 ` Alexander E. Kopilovich 2007-04-02 20:43 ` tmoran 0 siblings, 1 reply; 167+ messages in thread From: Alexander E. Kopilovich @ 2007-04-02 18:47 UTC (permalink / raw) To: comp.lang.ada Dmitry A. Kazakov wrote: > After all both the first and the economy classes would crash together... This is not exactly true. Perhaps you meant that business class and economy class crash together; but business class in regular airline can't be regarded as first class these days - there is plenty of private and corporate business jets in the world... and they crash separately from economy class. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: Shortage on C / C++ experts 2007-04-02 18:47 ` Alexander E. Kopilovich @ 2007-04-02 20:43 ` tmoran 0 siblings, 0 replies; 167+ messages in thread From: tmoran @ 2007-04-02 20:43 UTC (permalink / raw) > ... there is plenty of private and corporate business > jets in the world... and they crash separately from economy class. I understand Boeing use Ada for flight control software on their big (ie, containing economy class) jets. What about the makers of executive jets? Does one executive say to another "I was going to buy one of your jets, but then I learned it was programmed in C." ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 0:51 ` kevin cline 2007-03-30 4:09 ` Steve @ 2007-03-30 4:52 ` jimmaureenrogers 2007-03-30 6:30 ` Case Crab ` (2 more replies) 2007-03-30 8:16 ` Markus E Leypold ` (2 subsequent siblings) 4 siblings, 3 replies; 167+ messages in thread From: jimmaureenrogers @ 2007-03-30 4:52 UTC (permalink / raw) On Mar 29, 6:51 pm, "kevin cline" <kevin.cl...@gmail.com> wrote: > No, what actually happened is that expert C++ developers learned to > use C++ in such a way that those errors can not happen. While it is > possible to write unsafe code in C++, it is also possible to adopt > coding guidelines that makes it easy to find and eliminate unsafe > code, and for most applications, that's quite good enough. Coding guidelines cannot by themselves prevent any errors. For example, the JSF AV C++ Coding Standard, which is intended to limit the unsafe features of C++, contains 221 rules. It is not possible to check 6 million lines of code against 221 rules by hand in any timely or economical manner. The NASA Ada Flight Software coding guidelines contain 14 rules. The intent of both coding standards is to produce software safe enough to use for airborne avionics systems. Coding standards can help up to a point. When the coding standards are oppresively complex they cease to help. Jim Rogers ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:52 ` why learn C? jimmaureenrogers @ 2007-03-30 6:30 ` Case Crab 2007-03-30 6:37 ` Gautier ` (3 more replies) 2007-03-31 11:40 ` Larry Kilgallen [not found] ` <1175236212.771445.135460@y66g2Organization: LJK Software <c82IfUV$xbi8@eisner.encompasserve.org> 2 siblings, 4 replies; 167+ messages in thread From: Case Crab @ 2007-03-30 6:30 UTC (permalink / raw) On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net" <jimmaureenrog...@worldnet.att.net> wrote: > On Mar 29, 6:51 pm, "kevin cline" <kevin.cl...@gmail.com> wrote: > > > No, what actually happened is that expert C++ developers learned to > > use C++ in such a way that those errors can not happen. While it is > > possible to write unsafe code in C++, it is also possible to adopt > > coding guidelines that makes it easy to find and eliminate unsafe > > code, and for most applications, that's quite good enough. > > Coding guidelines cannot by themselves prevent any errors. Really? I have found that coding practices can preclude certain classes of errors. > For example, > the JSF AV C++ Coding Standard, which is intended to limit the unsafe > features of C++, contains 221 rules. How many rules distinguish SPARK from the full Ada language? > It is not possible to check > 6 million lines of code against 221 rules by hand in any timely or > economical manner. I expect that most of the checking can and will be done automatically. In any case, I would expect such mission-critical code would be inspected, regardless of whether the implementation language is C++ or Ada. > > The NASA Ada Flight Software coding guidelines contain 14 rules. > The intent of both coding standards is to produce software safe enough > to use for airborne avionics systems. Interesting that one organization has 221 rules while the other has only 14. > Coding standards can help up to a point. When the coding standards are > oppresively complex they cease to help. Compile-time checks can also help, up to a point. But they don't solve the whole problem. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 6:30 ` Case Crab @ 2007-03-30 6:37 ` Gautier 2007-03-30 9:17 ` Georg Bauhaus ` (2 subsequent siblings) 3 siblings, 0 replies; 167+ messages in thread From: Gautier @ 2007-03-30 6:37 UTC (permalink / raw) Case Crab: >> For example, >> the JSF AV C++ Coding Standard, which is intended to limit the unsafe >> features of C++, contains 221 rules. ... >> The NASA Ada Flight Software coding guidelines contain 14 rules. >> The intent of both coding standards is to produce software safe enough >> to use for airborne avionics systems. > > Interesting that one organization has 221 rules while the other has > only 14. Probably the difference is more that the 221 rules are needed for "securizing" C++ and the 14 ones for Ada ? ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 6:30 ` Case Crab 2007-03-30 6:37 ` Gautier @ 2007-03-30 9:17 ` Georg Bauhaus 2007-03-31 13:18 ` Peter C. Chapin 2007-03-30 17:47 ` adaworks 2007-03-31 2:41 ` jimmaureenrogers 3 siblings, 1 reply; 167+ messages in thread From: Georg Bauhaus @ 2007-03-30 9:17 UTC (permalink / raw) On Thu, 2007-03-29 at 23:30 -0700, Case Crab wrote: > On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net" > > Coding guidelines cannot by themselves prevent any errors. > > Really? I have found that coding practices can preclude certain > classes of errors. Can coding practices be improved by making them language definitions? > How many rules distinguish SPARK from the full Ada language? If you allow me to be pedantic, SPARK is not distinguished from Ada by external rules for programmers. Rather, it has its own language definition, and translators that know about nothing but the SPARK language. This approach is very different from establishing coding rules. For example, a coding rule might say, don't use recursion. SPARK turns this coding rule into a language definition. Unfortunately. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 9:17 ` Georg Bauhaus @ 2007-03-31 13:18 ` Peter C. Chapin 2007-04-01 1:23 ` Georg Bauhaus 2007-04-02 6:37 ` kevin cline 0 siblings, 2 replies; 167+ messages in thread From: Peter C. Chapin @ 2007-03-31 13:18 UTC (permalink / raw) Georg Bauhaus <bauhaus@futureapps.de> wrote in news:1175246243.5771.67.camel@localhost.localdomain: > If you allow me to be pedantic, SPARK is not distinguished from > Ada by external rules for programmers. Rather, it has its own > language definition, and translators that know about nothing > but the SPARK language. This approach is very different from > establishing coding rules. How is it different than using coding guidelines together with a tool that checks them automatically? I've used lint-like tools with C++ and I've found the combination effective. I express my coding guidelines in terms of which checks I enable in the tool. This is a tedious process but once done the configuration can be reused with multiple projects so it's not too terrible. Then I write programs so that the tool produces no messages. The tool essentially defines a language that is a subset of the full language. By insisting that the tool produces no messages I'm getting mechanical verification that I'm using just that subset. In some respects it's not that different from using a stricter language in the first place except that I get to define the precise subset I want to use. Using a lax language like C++ together with a configurable tool thus gives me a degree of flexibility over the case where the programming language itself specifies all sorts of required checks that I can't configure. On the other hand there is a portability issue introduced by using a third party tool. I can see that as being a major problem for programs written by multiple teams. Since Ada targets exactly those kinds of programs, Ada's approach of incorporating as much checking as possible into the standard language makes sense. I either work alone or in small groups, however, so using a third party tool is less of an issue for me. The approach I outline here is not without its problems, but it does help one write reliable programs with a lax language. I don't consider myself a genius programmer (although I do have a lot of experience with C++) but I spend very little time in the debugger. All around I appreciate Ada's approach and I enjoy working with Ada. Indeed, knowing Ada has made me a better C++ programmer. I especially like Ada's clean syntax and standards such as ASIS that make writing advanced tools for Ada easier. As you can probably guess, I'm a big believer in extending a programming language with tools. It's too bad that building tools for C++ is such a big pain in the neck. C++'s nasty syntax, together with the preprocessor, are probably the worst things about the language because they inhibit tool building. Peter ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 13:18 ` Peter C. Chapin @ 2007-04-01 1:23 ` Georg Bauhaus 2007-04-01 11:59 ` Peter C. Chapin 2007-04-02 6:37 ` kevin cline 1 sibling, 1 reply; 167+ messages in thread From: Georg Bauhaus @ 2007-04-01 1:23 UTC (permalink / raw) Peter C. Chapin wrote: > Georg Bauhaus <bauhaus@futureapps.de> wrote in > news:1175246243.5771.67.camel@localhost.localdomain: > >> If you allow me to be pedantic, SPARK is not distinguished from >> Ada by external rules for programmers. Rather, it has its own >> language definition, and translators that know about nothing >> but the SPARK language. This approach is very different from >> establishing coding rules. > > How is it different than using coding guidelines together with a tool > that checks them automatically? Maybe I was incorrectly assuming that coding rules are not enforced in the same way that language rules are enforced, because using a special language parser with rule checks built in requires additional efforts and tedious discipline (in the short run). But I'm not too confident that the efficacy of coding rules without such a tool is de facto the same as that of existing language rules. Coding rules require programmers who will apply the rules by their own free will and who know quite a bit about programming. > As you can probably guess, I'm a big > believer in extending a programming language with tools. I would even hope that a systematic survey of how tools for translation, checking, "architecture" etc. are used can help establish some knowledge of what a future very high level language should provide. But here's a case demonstrating that now we are (still) in sore need of good language rather than good rules. (A difficulty of arguing in favor of a "strict" Ada-like language will be the "works for me razor" applied by those who seem to be using less strict languages with seemingly good success. The argument is similar to that of very good Lisp programmers who build well working macros reflecting their own sophistication with all pros and cons of that. As you have mentioned, it may be fine for small teams.) The case is that of conditionals where a condition is written after the statement that it controls, but the programming language is not really using postfix notation. Postfix conditionals aren't in either C++ or Ada, but they serve well as an example of where the human element matters in adopting rules or not. The postfix conditional has been in Perl for some time, and postfix forms of conditionals and loops are being added to Python. Perl::Critic, a rule checking tool, will warn about postfix conditionals, a negative rule being based on the recommendations of a well received book (Perl Best Practices (PBP)). But why is the postfix form of "if" nevertheless popular in new Perl code, even added to Python, although it has been identified as a problem? My guess is that a human can say, "do this unless there is X", a postfix conditional. By doing so he or she uses a common mode of expression that is well understood by a human, hence seems acceptable, even natural.[1] Another reason of continuing popularity of postfix if, opposing the PBP rules, might be that a popular Perl book doesn't talk about the dangers of postfix if. Like C++ and Ada, Perl is a given language. Corresponding tools are just not used frequently, so we will continue to see code that recreates fancy pitfalls. Therefore, the best way for years of rule checking experience to manifest itself in software is adding the most important results to the language proper. Or, where possible, use a language that enforces these rules by definition. [1] "The *if* and *unless* modifiers work pretty much as you'd expect if you speak English." (Wall, L.; Christiansen, T.; and Schwartz, R.L.: Programming Perl) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-01 1:23 ` Georg Bauhaus @ 2007-04-01 11:59 ` Peter C. Chapin 0 siblings, 0 replies; 167+ messages in thread From: Peter C. Chapin @ 2007-04-01 11:59 UTC (permalink / raw) Georg Bauhaus <bauhaus@futureapps.de> wrote in news:460f0951$0$23134$9b4e6d93@newsspool1.arcor-online.net: > Like C++ and Ada, Perl is a given language. Corresponding tools are > just not used frequently, so we will continue to see code that > recreates fancy pitfalls. Therefore, the best way for years of rule > checking experience to manifest itself in software is adding the most > important results to the language proper. Or, where possible, use a > language that enforces these rules by definition. The advantage of using tool checked coding guidelines is that everyone can customize them. The disadvantage of using tool checked coding guidelines is that everyone can customize them. :-) Peter ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 13:18 ` Peter C. Chapin 2007-04-01 1:23 ` Georg Bauhaus @ 2007-04-02 6:37 ` kevin cline 2007-04-02 9:39 ` Harald Korneliussen 1 sibling, 1 reply; 167+ messages in thread From: kevin cline @ 2007-04-02 6:37 UTC (permalink / raw) On Mar 31, 8:18 am, "Peter C. Chapin" <pcha...@sover.net> wrote: > As you can probably guess, I'm a big > believer in extending a programming language with tools. It's too bad > that building tools for C++ is such a big pain in the neck. C++'s nasty > syntax, together with the preprocessor, are probably the worst things > about the language because they inhibit tool building. The preprocessor is no trouble at all, because it can be run separately. But it's true that C and C++ are hard to parse with a LALR grammar. Building a full Ada parser from scratch is not easy either. The easiest way to write tools for either language is probably to build on the GNU parsers. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 6:37 ` kevin cline @ 2007-04-02 9:39 ` Harald Korneliussen 0 siblings, 0 replies; 167+ messages in thread From: Harald Korneliussen @ 2007-04-02 9:39 UTC (permalink / raw) On Apr 2, 8:37 am, "kevin cline" <kevin.cl...@gmail.com> wrote: > The preprocessor is no trouble at all, because it can be run > separately. No trouble at all? Ha! You can tell that to the Edison Design Group people. For some real-life experiences about C++, see the first article from this staic analysis summit: http://samate.nist.gov/docs/NIST_Special_Publication_500-262.pdf > But it's true that C and C++ are hard to parse with a LALR > grammar. It seems EDG are about the only ones with a decent semantic parser for C++, even they have no chance whatsoever of supporting everything out there (I'm stuck with a c++ compiler from this obscure little company called Borland, so I can forget about static analysis tools) > Building a full Ada parser from scratch is not easy either. The > easiest way to write tools for either language is probably to build on > the GNU parsers. In which case you get a GNU-specific parser, which is not a good thing. I don't know how much easier it is to build an Ada parser, you could ask the Bauhaus folks, their tool handles Ada (and is mostly written in it, too). ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 6:30 ` Case Crab 2007-03-30 6:37 ` Gautier 2007-03-30 9:17 ` Georg Bauhaus @ 2007-03-30 17:47 ` adaworks 2007-03-30 19:25 ` Markus E Leypold 2007-03-30 20:29 ` Randy Brukardt 2007-03-31 2:41 ` jimmaureenrogers 3 siblings, 2 replies; 167+ messages in thread From: adaworks @ 2007-03-30 17:47 UTC (permalink / raw) "Case Crab" <casecrab@gmail.com> wrote in message news:1175236212.771445.135460@y66g2000hsf.googlegroups.com... > > Compile-time checks can also help, up to a point. But they don't > solve the whole problem. > True. Software is never easy. We always need a set of tools to ensure that what we intended is what we got. Further, Ada is not restricted to the checking of data types at compile-time. It includes a powerful set of options that allow a variety of kinds of checks, when the developer uses them. This is better than the alternative languages such as C++ that simply fail to provide the range of options found in Ada. One of my favorite columns in the now defunct C++ Report magazine was titled "Obfuscated C++." I still have some of those articles clipped out an in a three-ring binder. In every case, the obfuscation illustrated was something that simply could not happen in Ada. I cannot imagine anyone writing a column called "Obfuscated Ada." Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 17:47 ` adaworks @ 2007-03-30 19:25 ` Markus E Leypold 2007-03-30 20:29 ` Randy Brukardt 1 sibling, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-03-30 19:25 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > One of my favorite columns in the now defunct C++ > Report magazine was titled "Obfuscated C++." I > still have some of those articles clipped out an in a > three-ring binder. In every case, the obfuscation > illustrated was something that simply could not happen > in Ada. I cannot imagine anyone writing a column > called "Obfuscated Ada." Wasn't there a obfuscated Ada thread some time ago her at c.l.a? Some 6 or 10 months ago? > Richard Riehle BTW, wasn't it you who still wants to explain to me how Java is not type safe, or am I mixing something up? Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 17:47 ` adaworks 2007-03-30 19:25 ` Markus E Leypold @ 2007-03-30 20:29 ` Randy Brukardt 2007-03-31 9:52 ` Dmitry A. Kazakov 2007-04-01 1:35 ` adaworks 1 sibling, 2 replies; 167+ messages in thread From: Randy Brukardt @ 2007-03-30 20:29 UTC (permalink / raw) <adaworks@sbcglobal.net> wrote in message news:o2cPh.4026$u03.1786@newssvr21.news.prodigy.net... > I cannot imagine anyone writing a column > called "Obfuscated Ada." Not a column, perhaps, but surely you could write an interesting article. Ada has plenty of ways to write something simple in wonderfully long-winded ways which potentially harm readability. And there are various non-obvious idioms that are very handy, like using Boolean'Pos to get the effect of a conditional expression: Something : Integer := Boolean'Pos(<condition>)*Function1 + Boolean'Pos(not <condition>)*Function2; I always comment such things extensively, but it would be interesting to figure out the meaning without it. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 20:29 ` Randy Brukardt @ 2007-03-31 9:52 ` Dmitry A. Kazakov 2007-04-01 1:35 ` adaworks 1 sibling, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-03-31 9:52 UTC (permalink / raw) On Fri, 30 Mar 2007 15:29:18 -0500, Randy Brukardt wrote: > And there are various non-obvious > idioms that are very handy, like using Boolean'Pos to get the effect of a > conditional expression: > > Something : Integer := Boolean'Pos(<condition>)*Function1 + Boolean'Pos(not > <condition>)*Function2; That's great and it is used extensively, not in Ada of course, but in some scripting languages used in process control. Especially interesting it becomes when the condition and its inversion expressions are a subject of race condition. In the language I am talking about it is practically always the case... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 20:29 ` Randy Brukardt 2007-03-31 9:52 ` Dmitry A. Kazakov @ 2007-04-01 1:35 ` adaworks 1 sibling, 0 replies; 167+ messages in thread From: adaworks @ 2007-04-01 1:35 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:eujrs1$9e$1@jacob-sparre.dk... > <adaworks@sbcglobal.net> wrote in message > news:o2cPh.4026$u03.1786@newssvr21.news.prodigy.net... >> I cannot imagine anyone writing a column >> called "Obfuscated Ada." > > Not a column, perhaps, but surely you could write an interesting article. > Ada has plenty of ways to write something simple in wonderfully long-winded > ways which potentially harm readability. And there are various non-obvious > idioms that are very handy, like using Boolean'Pos to get the effect of a > conditional expression: > > Something : Integer := Boolean'Pos(<condition>)*Function1 + Boolean'Pos(not > <condition>)*Function2; > This does not compare with the possibilities for obfuscation in C++. Further, we know quite a bit about this example early, even though we may not know what its intent is on first reading. I do know that there is no automatic promotion of values. I am confident that Something, as described is of type Integer. I am also secure in understanding that the expression needs to evaluate to a predefined type Integer. Type qualification, Boolean'Pos(...) ensures there is no type mismatch anywhere in the expression. In other words, one can easily reason about the expression without knowing its details. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 6:30 ` Case Crab ` (2 preceding siblings ...) 2007-03-30 17:47 ` adaworks @ 2007-03-31 2:41 ` jimmaureenrogers 2007-03-31 12:25 ` not NASA Ada coding standard Stephen Leake ` (2 more replies) 3 siblings, 3 replies; 167+ messages in thread From: jimmaureenrogers @ 2007-03-31 2:41 UTC (permalink / raw) On Mar 30, 12:30 am, "Case Crab" <casec...@gmail.com> wrote: > On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net" > > <jimmaureenrog...@worldnet.att.net> wrote: > > On Mar 29, 6:51 pm, "kevin cline" <kevin.cl...@gmail.com> wrote: > > > > No, what actually happened is that expert C++ developers learned to > > > use C++ in such a way that those errors can not happen. While it is > > > possible to write unsafe code in C++, it is also possible to adopt > > > coding guidelines that makes it easy to find and eliminate unsafe > > > code, and for most applications, that's quite good enough. > > > Coding guidelines cannot by themselves prevent any errors. > > Really? I have found that coding practices can preclude certain > classes of errors. The JSF C++ coding standards are available from several sources on the web. One link is http://www.research.att.com/~bs/JSF-AV-rules.pdf The corresponding Ada coding standard is found at http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf > > > For example, > > the JSF AV C++ Coding Standard, which is intended to limit the unsafe > > features of C++, contains 221 rules. > > How many rules distinguish SPARK from the full Ada language? > > > It is not possible to check > > 6 million lines of code against 221 rules by hand in any timely or > > economical manner. > > I expect that most of the checking can and will be done > automatically. In any case, I would expect such > mission-critical code would be inspected, regardless of whether the > implementation language is C++ or Ada. > Inspection is the problem. It is inefficient and error prone to manually inspect 6 million lines of code against 221 rules. There is an automated tool for checking the JSF standard. That tool cannot perform a 100% check either due to the nature of the rules. > > > > The NASA Ada Flight Software coding guidelines contain 14 rules. > > The intent of both coding standards is to produce software safe enough > > to use for airborne avionics systems. > > Interesting that one organization has 221 rules while the other has > only 14. If you analyze the two standards, and understand the two languages, you will see that the 221 rules for C++ bring you close to the same safety level you achieve with the 14 rules for Ada. Many of the language features prohibited in the C++ standard simply do not exist in Ada. This explains the bulk of the differences in the two standards. For instance: AV Rule 20 (MISRA Rule 122) The setjmp macro and the longjmp function shall not be used. Ada has no macros and no equivalent to the longjmp function. There is no reason to prohibit their use in Ada. Similarly: AV Rule 29 The #define pre-processor directive shall not be used to create inline macros. Inline functions shall be used instead. Rationale: Inline functions do not require text substitutions and behave well when called with arguments (e.g. type checking is performed). Ada does allow inline functions and procedures, but has no language defined macro capability. AV Rule 71.1 A class's virtual functions shall not be invoked from its destructor or any of its constructors. Rationale: A class's virtual functions are resolved statically (not dynamically) in its constructors and destructor. Ada does not provide a direct equivalent to C++ constructors and destructors. While this may seem a problem to a C++ or Java programmer, it does have the virtue of not providing an avenue for the error handled by this rule. And the C++ multiple inheritance model provides interesting opportunities for unsafe code: AV Rule 89 A base class shall not be both virtual and non-virtual in the same hierarchy. Rationale: Hierarchy becomes difficult to comprehend and use. Do not forget about all the wonders of pointers in C and C++. For example: AV Rule 97 Arrays shall not be used in interfaces. Instead, the Array class should be used. Rationale: Arrays degenerate to pointers when passed as parameters. This "array decay" problem has long been known to be a source of errors. Ada arrays do not decay to pointers. This problem is unknown in Ada with or without coding standards. > > > Coding standards can help up to a point. When the coding standards are > > oppresively complex they cease to help. > > Compile-time checks can also help, up to a point. But they don't > solve the whole problem. No, run time checks are needed for things that cannot be checked at compile time. Ada helps is more helpful with run time checks than is C or C++ due to the automated check writing built by the compilers. For instance, if you define an integer type with a valid range of values from -10 to 10, the compiler will perform all necessary range checking for that type. type My_Int is range -10..10; You can provide run time checking in any language. In C++ you would need to define a class for My_Int. The assignment operator would need to be re-defined to check for the range, and throw an exception when the range limits are violated. C++ provides additional challenges to the definition and checking of limited range integer types. In C and C++ (and Java) all numeric types are initialized by default to 0. What does that do to your program if 0 is not within the valid range for your type? The compiler will simply initialize the data member of your class to an invalid value. You will need to provide a default constructor to initialize the value to some valid value, along with the overridden assignment operator. Jim Rogers ^ permalink raw reply [flat|nested] 167+ messages in thread
* not NASA Ada coding standard 2007-03-31 2:41 ` jimmaureenrogers @ 2007-03-31 12:25 ` Stephen Leake 2007-03-31 15:44 ` Markus E Leypold 2007-04-01 16:22 ` Simon Clubley 2007-04-02 7:43 ` why learn C? kevin cline 2007-04-02 8:13 ` kevin cline 2 siblings, 2 replies; 167+ messages in thread From: Stephen Leake @ 2007-03-31 12:25 UTC (permalink / raw) "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > The corresponding Ada coding standard is found at > http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf Putting on my NASA hat, I must point out that those standards are _not_ NASA-wide standards, but Goddard flight software standards. Goddard is only one of many NASA centers, and the flight software group at Goddard is a small part of the Goddard software community. And in fact, my group, consisting of 5 programmers, is the only group following those standards. Things on the web are not always what they seem :). There is a slightly more up-to-date version on my project website: http://fsw.gsfc.nasa.gov/gds/gds_internal.html Enforcement of the standard is accomplished partly by using GNAT and Emacs, but mostly by me reading _all_ of the code, as it is checked into CVS. -- -- Stephe ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: not NASA Ada coding standard 2007-03-31 12:25 ` not NASA Ada coding standard Stephen Leake @ 2007-03-31 15:44 ` Markus E Leypold 2007-04-01 16:22 ` Simon Clubley 1 sibling, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-03-31 15:44 UTC (permalink / raw) Stephen Leake <stephen_leake@stephe-leake.org> writes: > "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > >> The corresponding Ada coding standard is found at >> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf > > Putting on my NASA hat, I must point out that those standards are > _not_ NASA-wide standards, but Goddard flight software standards. > Goddard is only one of many NASA centers, and the flight software > group at Goddard is a small part of the Goddard software community. > > And in fact, my group, consisting of 5 programmers, is the only group > following those standards. Things on the web are not always what they > seem :). > > There is a slightly more up-to-date version on my project website: > http://fsw.gsfc.nasa.gov/gds/gds_internal.html > > Enforcement of the standard is accomplished partly by using GNAT and > Emacs, but mostly by me reading _all_ of the code, as it is checked > into CVS. And it is well known, that review is the most effective QA measure anyway: So it _is_ useful to read (or better let read) the code before chacking in to the main code base. Which also gives another 2-cent contribution to this thread: Reviewing against a small number of rules is of course less error prone (and does cost less) than reviewing against a huge number of rules. And furthermore reviews are easier if the language is readable (a plus for Ada and its generics, a minus for C++ and templates in my eyes). I think this is one up for Ada here. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: not NASA Ada coding standard 2007-03-31 12:25 ` not NASA Ada coding standard Stephen Leake 2007-03-31 15:44 ` Markus E Leypold @ 2007-04-01 16:22 ` Simon Clubley 2007-04-02 10:08 ` Stephen Leake 1 sibling, 1 reply; 167+ messages in thread From: Simon Clubley @ 2007-04-01 16:22 UTC (permalink / raw) In article <u648hbnx1.fsf_-_@stephe-leake.org>, Stephen Leake <stephen_leake@stephe-leake.org> writes: > "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > >> The corresponding Ada coding standard is found at >> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf > > Putting on my NASA hat, I must point out that those standards are > _not_ NASA-wide standards, but Goddard flight software standards. > Goddard is only one of many NASA centers, and the flight software > group at Goddard is a small part of the Goddard software community. > Do you have online pointers to the other NASA department level, or even better, NASA-wide, standards ? I, for one, would be very interested in reading them. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: not NASA Ada coding standard 2007-04-01 16:22 ` Simon Clubley @ 2007-04-02 10:08 ` Stephen Leake 0 siblings, 0 replies; 167+ messages in thread From: Stephen Leake @ 2007-04-02 10:08 UTC (permalink / raw) clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes: > In article <u648hbnx1.fsf_-_@stephe-leake.org>, Stephen Leake > <stephen_leake@stephe-leake.org> writes: >> "jimmaureenrogers@worldnet.att.net" >> <jimmaureenrogers@worldnet.att.net> writes: >> >>> The corresponding Ada coding standard is found at >>> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf >> >> Putting on my NASA hat, I must point out that those standards are >> _not_ NASA-wide standards, but Goddard flight software standards. >> Goddard is only one of many NASA centers, and the flight software >> group at Goddard is a small part of the Goddard software community. >> > > Do you have online pointers to the other NASA department level, or even > better, NASA-wide, standards ? Unfortunately, no. We need to do a better job of this. -- -- Stephe ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 2:41 ` jimmaureenrogers 2007-03-31 12:25 ` not NASA Ada coding standard Stephen Leake @ 2007-04-02 7:43 ` kevin cline 2007-04-02 8:45 ` Martin Krischik 2007-04-02 10:54 ` Georg Bauhaus 2007-04-02 8:13 ` kevin cline 2 siblings, 2 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 7:43 UTC (permalink / raw) On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net" <jimmaureenrog...@worldnet.att.net> wrote: > On Mar 30, 12:30 am, "Case Crab" <casec...@gmail.com> wrote: > > > On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net" > > > <jimmaureenrog...@worldnet.att.net> wrote: > > > On Mar 29, 6:51 pm, "kevin cline" <kevin.cl...@gmail.com> wrote: > > > > > No, what actually happened is that expert C++ developers learned to > > > > use C++ in such a way that those errors can not happen. While it is > > > > possible to write unsafe code in C++, it is also possible to adopt > > > > coding guidelines that makes it easy to find and eliminate unsafe > > > > code, and for most applications, that's quite good enough. > > > > Coding guidelines cannot by themselves prevent any errors. > > > Really? I have found that coding practices can preclude certain > > classes of errors. > > The JSF C++ coding standards are available from several sources on the > web. One link ishttp://www.research.att.com/~bs/JSF-AV-rules.pdf > > The corresponding Ada coding standard is found athttp://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf > > > > > > > > For example, > > > the JSF AV C++ Coding Standard, which is intended to limit the unsafe > > > features of C++, contains 221 rules. > > > How many rules distinguish SPARK from the full Ada language? > > > > It is not possible to check > > > 6 million lines of code against 221 rules by hand in any timely or > > > economical manner. > > > I expect that most of the checking can and will be done > > automatically. In any case, I would expect such > > mission-critical code would be inspected, regardless of whether the > > implementation language is C++ or Ada. > > Inspection is the problem. It is inefficient and error prone to > manually inspect 6 million lines of code against 221 rules. > > There is an automated tool for checking the JSF standard. That > tool cannot perform a 100% check either due to the nature of the > rules. > > > > > > The NASA Ada Flight Software coding guidelines contain 14 rules. > > > The intent of both coding standards is to produce software safe enough > > > to use for airborne avionics systems. > > > Interesting that one organization has 221 rules while the other has > > only 14. > > If you analyze the two standards, and understand the two languages, > you > will see that the 221 rules for C++ bring you close to the same safety > level you achieve with the 14 rules for Ada. > > Many of the language features prohibited in the C++ standard simply do > not exist in Ada. This explains the bulk of the differences in the two > standards. For instance: > > AV Rule 20 (MISRA Rule 122) > The setjmp macro and the longjmp function shall not be used. > > Ada has no macros and no equivalent to the longjmp function. > There is no reason to prohibit their use in Ada. > > Similarly: > > AV Rule 29 > The #define pre-processor directive shall not be used to create > inline macros. Inline functions shall be used instead. > Rationale: Inline functions do not require text substitutions > and behave well when called with arguments > (e.g. type checking is performed). > > Ada does allow inline functions and procedures, but has no > language defined macro capability. > > AV Rule 71.1 > A class's virtual functions shall not be invoked from its > destructor or any of its constructors. > Rationale: A class's virtual functions are resolved > statically (not dynamically) in its constructors and > destructor. > > Ada does not provide a direct equivalent to C++ constructors > and destructors. While this may seem a problem to a C++ or > Java programmer, it does have the virtue of not providing > an avenue for the error handled by this rule. > > And the C++ multiple inheritance model provides interesting > opportunities for unsafe code: > > AV Rule 89 > A base class shall not be both virtual and non-virtual in > the same hierarchy. > Rationale: Hierarchy becomes difficult to comprehend and use. > > Do not forget about all the wonders of pointers in C and C++. > For example: > > AV Rule 97 > Arrays shall not be used in interfaces. Instead, the Array > class should be used. > Rationale: Arrays degenerate to pointers when passed as > parameters. This "array decay" problem has long been known to be > a source of errors. > > Ada arrays do not decay to pointers. This problem is unknown in > Ada with or without coding standards. > > > > > > Coding standards can help up to a point. When the coding standards are > > > oppresively complex they cease to help. > > > Compile-time checks can also help, up to a point. But they don't > > solve the whole problem. > > No, run time checks are needed for things that cannot be checked at > compile time. Ada helps is more helpful with run time checks than is > C or C++ due to the automated check writing built by the compilers. > For instance, if you define an integer type with a valid range of > values from -10 to 10, the compiler will perform all necessary > range checking for that type. > > type My_Int is range -10..10; > > You can provide run time checking in any language. In C++ you would > need to define a class for My_Int. Actually, you would define a template class RangedInt, and then write something like: typedef RangedInt<-10,10> My_Int; > The assignment operator would need > to be re-defined to check for the range, and throw an exception when > the range limits are violated. Right. One eight-line class to replicate the Ada ranged integer type. > > C++ provides additional challenges to the definition and checking of > limited range integer types. In C and C++ (and Java) all numeric types > are initialized by default to 0. Not exactly. > What does that do to your program if > 0 is not within the valid range for your type? > The compiler will > simply initialize the data member of your class to an invalid value. > You will need to provide a default constructor to initialize the value > to some valid value, along with the overridden assignment operator. True. The C++ design philosophy was that features would not be added to the language if they could be implemented as library classes. A limited-range integer is a pretty trivial class to write, so there was no need to add it to the language. Also, C++ was designed with the idea that if you didn't need it, you didn't have to pay for it. So variables are not automatically initialized. Modern compilers produce warnings if it is possible for a variable to be used before it has been initialized. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 7:43 ` why learn C? kevin cline @ 2007-04-02 8:45 ` Martin Krischik 2007-04-02 10:54 ` Georg Bauhaus 1 sibling, 0 replies; 167+ messages in thread From: Martin Krischik @ 2007-04-02 8:45 UTC (permalink / raw) kevin cline schrieb: > True. The C++ design philosophy was that features would not be added > to the language if they could be implemented as library classes. A > limited-range integer is a pretty trivial class to write, so there was > no need to add it to the language. That would be fair enough if they actually added a limited-range integer class. And how about a limited-range float ;-) Martin ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 7:43 ` why learn C? kevin cline 2007-04-02 8:45 ` Martin Krischik @ 2007-04-02 10:54 ` Georg Bauhaus 2007-04-12 16:05 ` Hyman Rosen 1 sibling, 1 reply; 167+ messages in thread From: Georg Bauhaus @ 2007-04-02 10:54 UTC (permalink / raw) On Mon, 2007-04-02 at 00:43 -0700, kevin cline wrote: > On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net" > > type My_Int is range -10..10; > > > > You can provide run time checking in any language. In C++ you would > > need to define a class for My_Int. > > Actually, you would define a template class RangedInt, and then write > something like: > > typedef RangedInt<-10,10> My_Int; > > > The assignment operator would need > > to be re-defined to check for the range, and throw an exception when > > the range limits are violated. > > Right. One eight-line class to replicate the Ada ranged integer type. I'd add a few more lines to a RangedInt in order to have iteration support, explicit range test, 'Valid, using integer operations with compatible subtypes, computing in the base type, and having template compile/link time checks for array-style data structures built on top of the type properties of RangedInt. (Type casts?) And then, unfortunately, C++ doesn't have dynamic types (unless I'm missing something): template <int left> int foo(int n) { typedef class RangedInt<left, n> Int; Int x(12); // ... return *x; } Int would have to be visible only from within foo(), its values would have to be bound by n. Objects of type Int would only exist within foo, and be accessible while foo executes (no & allowed). With Ada 2005, this is true of all locally extensible types. But OTOH, is there any good reason to replace the handful of machine oriented base types that C++ has (inherited from C) and instead use something that is more predictable and more expressive? I think, yes, when apparently students can do their homework significantly more successfully when they can choose names, values, named values and types in the ways that have inspired the Ada type system. (According at least to a seemingly unbiased report presented here some weeks ago, about an embedded systems class.) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 10:54 ` Georg Bauhaus @ 2007-04-12 16:05 ` Hyman Rosen 2007-04-12 16:48 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-12 16:05 UTC (permalink / raw) Georg Bauhaus wrote: > And then, unfortunately, C++ doesn't have dynamic types > (unless I'm missing something): > > template <int left> > int foo(int n) > { > typedef class RangedInt<left, n> Int; You are correct that C++ does not support this, but incorrect that it is unfortunate. The purely static types of C++ is what permits automatic instantiation to work. Having dynamic types is what leads to Ada's requirement of explicit instantiation. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:05 ` Hyman Rosen @ 2007-04-12 16:48 ` Dmitry A. Kazakov 2007-04-12 18:27 ` Robert A Duff 2007-04-12 21:11 ` Georg Bauhaus 2 siblings, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-12 16:48 UTC (permalink / raw) On Thu, 12 Apr 2007 16:05:00 GMT, Hyman Rosen wrote: > The purely static > types of C++ is what permits automatic instantiation > to work. Having dynamic types is what leads to Ada's > requirement of explicit instantiation. I would say that it is rather named (vs. structural) equivalence which makes explicit instantiation necessary. C++ has types algebra limited to compile-time only expressions. Is it good? I don't think so. Does it imply a need in templates to evaluate some of these expressions? I doubt it. To me generics in a language merely indicate a lack of imagination of the language designers. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:05 ` Hyman Rosen 2007-04-12 16:48 ` Dmitry A. Kazakov @ 2007-04-12 18:27 ` Robert A Duff 2007-04-13 16:21 ` Hyman Rosen 2007-04-12 21:11 ` Georg Bauhaus 2 siblings, 1 reply; 167+ messages in thread From: Robert A Duff @ 2007-04-12 18:27 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: >...Having dynamic types is what leads to Ada's > requirement of explicit instantiation. I don't understand that. Ada's types are entirely compile time, and generic instantiation happens at compile time. It is true that Ada's subtypes can have dynamic constraints, and when you pass one to a generic, there is some data stored at run time (array bounds or whatever). But I don't see any way in which that would prevent me from designing an Ada-like language with implicit instantiation. I think implicit instantiation is probably a good idea. As you said in another post, it's something like overloading of subprograms, and I think it can be designed so that it's not too error prone. If I remember, the C++ rules include preference rules, though. Is that correct? Preference rules can cause Beaujolais effects, which in my opinion are very bad. - Bob ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 18:27 ` Robert A Duff @ 2007-04-13 16:21 ` Hyman Rosen 0 siblings, 0 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-13 16:21 UTC (permalink / raw) Robert A Duff wrote: > But I don't see any way in which that would prevent > me from designing an Ada-like language with implicit instantiation. Yes, I think you're right. I'm thinking of what can be done with C++ template metaprogramming. That requires specialization and the ability to distinguish between types based on their names and template parameters, and I don't know if that can be fitted into the context of Ada where subtypes and generic instantiations depend upon local context. > If I remember, the C++ rules include preference rules, though. Is that > correct? Preference rules can cause Beaujolais effects, which in my > opinion are very bad. Yes, preference rules abound. They're applied one parameter at a time, though, which helps limit the confusion. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:05 ` Hyman Rosen 2007-04-12 16:48 ` Dmitry A. Kazakov 2007-04-12 18:27 ` Robert A Duff @ 2007-04-12 21:11 ` Georg Bauhaus 2007-04-13 15:45 ` Hyman Rosen 2 siblings, 1 reply; 167+ messages in thread From: Georg Bauhaus @ 2007-04-12 21:11 UTC (permalink / raw) On Thu, 2007-04-12 at 16:05 +0000, Hyman Rosen wrote: > Georg Bauhaus wrote: > > And then, unfortunately, C++ doesn't have dynamic types > > (unless I'm missing something): > > > > template <int left> > > int foo(int n) > > { > > typedef class RangedInt<left, n> Int; > > You are correct that C++ does not support this, but > incorrect that it is unfortunate. I beg to differ. When there are reasons not to support this kind of nesting in C++, I still see nesting of things including types as a feature of Ada that is valuable. Much like local subprograms can act as a locally needed singleton with suitably restricted visibility of its surroundings: there is no need for a singleton at the service of a single subprogram, say. But there are local packages, local types, ..., and now inward closures. Is a std::unary_function so much more attractive for the cases it can handle? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 21:11 ` Georg Bauhaus @ 2007-04-13 15:45 ` Hyman Rosen 0 siblings, 0 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-13 15:45 UTC (permalink / raw) Georg Bauhaus wrote: > On Thu, 2007-04-12 at 16:05 +0000, Hyman Rosen wrote: >> You are correct that C++ does not support this, but >> incorrect that it is unfortunate. > I beg to differ. When there are reasons not to support > this kind of nesting in C++, I still see nesting of things > including types as a feature of Ada that is valuable. Oh, sure, it's immensely valuable. It just isn't C++. The type system in C++ is completely static, and that deeply affects the language, especially templates. I think that it's essentially impossible to shoehorn a dynamic type system into the language and still retain its qualities. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 2:41 ` jimmaureenrogers 2007-03-31 12:25 ` not NASA Ada coding standard Stephen Leake 2007-04-02 7:43 ` why learn C? kevin cline @ 2007-04-02 8:13 ` kevin cline 2007-04-02 23:54 ` Randy Brukardt ` (2 more replies) 2 siblings, 3 replies; 167+ messages in thread From: kevin cline @ 2007-04-02 8:13 UTC (permalink / raw) On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net" For instance: > > AV Rule 20 (MISRA Rule 122) > The setjmp macro and the longjmp function shall not be used. > > Ada has no macros and no equivalent to the longjmp function. > There is no reason to prohibit their use in Ada. I haven't seen setjmp or longjmp used in about twenty years. This is not a practical problem in C++ programming. > > Similarly: > > AV Rule 29 > The #define pre-processor directive shall not be used to create > inline macros. Inline functions shall be used instead. > Rationale: Inline functions do not require text substitutions > and behave well when called with arguments > (e.g. type checking is performed). Preprocessor macros are quite out of fashion for C++ programming. > > Ada does allow inline functions and procedures, but has no > language defined macro capability. > > AV Rule 71.1 > A class's virtual functions shall not be invoked from its > destructor or any of its constructors. > Rationale: A class's virtual functions are resolved > statically (not dynamically) in its constructors and > destructor. > > Ada does not provide a direct equivalent to C++ constructors > and destructors. While this may seem a problem to a C++ or > Java programmer, It's a huge problem when a class needs initialization. Then you have to mess around with controlled types. > it does have the virtue of not providing > an avenue for the error handled by this rule. No, instead you get to deal with the problem of having objects that have been created but require further initialization before use. Or else you have to create a controlled type, which is just complex enough that most Ada programmers probably don't quite understand it, so mostly it doesn't get done. > > And the C++ multiple inheritance model provides interesting > opportunities for unsafe code: > > AV Rule 89 > A base class shall not be both virtual and non-virtual in > the same hierarchy. > Rationale: Hierarchy becomes difficult to comprehend and use. And in 10 years of C++ programming I never saw anyone even tempted to do this. > > Do not forget about all the wonders of pointers in C and C++. > For example: > > AV Rule 97 > Arrays shall not be used in interfaces. Instead, the Array > class should be used. > Rationale: Arrays degenerate to pointers when passed as > parameters. This "array decay" problem has long been known to be > a source of errors. > > Ada arrays do not decay to pointers. This problem is unknown in > Ada with or without coding standards. It's not a practical problem for C++ programmers either, because we don't much use arrays anymore, except as needed to call C libraries. > > > > > > Coding standards can help up to a point. When the coding standards are > > > oppresively complex they cease to help. > > > Compile-time checks can also help, up to a point. But they don't > > solve the whole problem. > > No, run time checks are needed for things that cannot be checked at > compile time. Ada helps is more helpful with run time checks than is > C or C++ due to the automated check writing built by the compilers. > For instance, if you define an integer type with a valid range of > values from -10 to 10, the compiler will perform all necessary > range checking for that type. > > type My_Int is range -10..10; That's perfect if it happens to be the exact thing that you need. It doesn't help much if what you need is a point inside the unit circle. In C++ the language provides neither of these things, but they are both be implemented in a few lines of code. In Ada, the implementation of the constrained point is not so obvious. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 8:13 ` kevin cline @ 2007-04-02 23:54 ` Randy Brukardt 2007-04-03 2:58 ` jimmaureenrogers 2007-04-12 16:24 ` Hyman Rosen 2 siblings, 0 replies; 167+ messages in thread From: Randy Brukardt @ 2007-04-02 23:54 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> wrote in message news:1175501602.127760.186120@q75g2000hsh.googlegroups.com... > On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net" For instance: ... > > > Ada does not provide a direct equivalent to C++ constructors > > and destructors. While this may seem a problem to a C++ or > > Java programmer, > > It's a huge problem when a class needs initialization. Then you have > to mess around with controlled types. You have that backwards: there is (almost) no reason for a tagged type to not be controlled in Ada. All new types should be declared that way, unless there is a compelling reason why the (tiny) space and time overhead matters. I don't believe that there are many (if any) such types. But if there are such types, how do you write a C++ class for them that doesn't have that overhead? > > it does have the virtue of not providing > > an avenue for the error handled by this rule. > > No, instead you get to deal with the problem of having objects that > have been created but require further initialization before use. Or > else you have to create a controlled type, which is just complex > enough that most Ada programmers probably don't quite understand it, > so mostly it doesn't get done. Are these "most Ada programmers" the same as the "most C++ programmers" that you claim don't matter? You're only willing to talk about "expert C++ programmers", so I think it is only fair that we only talk about "expert Ada programmers". And no one that doesn't understand at least the basics of controlled types (which are nearly trivial) could possibly be called an Ada expert. Randy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 8:13 ` kevin cline 2007-04-02 23:54 ` Randy Brukardt @ 2007-04-03 2:58 ` jimmaureenrogers 2007-04-12 16:24 ` Hyman Rosen 2 siblings, 0 replies; 167+ messages in thread From: jimmaureenrogers @ 2007-04-03 2:58 UTC (permalink / raw) On Apr 2, 2:13 am, "kevin cline" <kevin.cl...@gmail.com> wrote: > On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net" For instance: > > No, run time checks are needed for things that cannot be checked at > > compile time. Ada helps is more helpful with run time checks than is > > C or C++ due to the automated check writing built by the compilers. > > For instance, if you define an integer type with a valid range of > > values from -10 to 10, the compiler will perform all necessary > > range checking for that type. > > > type My_Int is range -10..10; > > That's perfect if it happens to be the exact thing that you need. It > doesn't help much if what you need is a point inside the unit circle. > That is an interesting non-sequiter. No integer type would be satisfactory to define a point within a unit circle. > In C++ the language provides neither of these things, but they are > both be implemented in a few lines of code. > > In Ada, the implementation of the constrained point is not so > obvious. You want a type for specification of a point within a unit circle. Is this really hard to comprehend: type Unit_Radius_Type is digits 15 range 0.0..1.0; type Angle is digits 15 range 0.0..2.0 * Pi; type Circular_Point is record X : Unit_Radius_Type; Theta : Angle; end record; Given any unit circle with a known center coordinate, all points can be designated within 15 digits of accuracy. Please demonstrate how you would use C++ templates to create an equivalent definition. I am most curious about the range-specified and precision-specified floating point types. Jim Rogers ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-02 8:13 ` kevin cline 2007-04-02 23:54 ` Randy Brukardt 2007-04-03 2:58 ` jimmaureenrogers @ 2007-04-12 16:24 ` Hyman Rosen 2007-04-12 18:05 ` Markus E Leypold 2 siblings, 1 reply; 167+ messages in thread From: Hyman Rosen @ 2007-04-12 16:24 UTC (permalink / raw) kevin cline wrote: > Preprocessor macros are quite out of fashion for C++ programming. Unfortunately so. They're good for quite a bit of things, especially when you want to code a little "database" table of properties to be "queried" for the implementation. #define QuotesTableData(IMPL) \ IMPL(stock, "Security Name", string) \ IMPL(date, "Quote Date", time_t) \ IMPL(bid, "Bid Price", double) \ IMPL(ask, "Ask Price", double) struct QuotesTable { #define QuotesEnumImpl(name, title, type) name, enum { QuotesTableData(QuotesEnumImpl), N }; #define QuotesMembersImpl(name, title, type) type m_##name; QuotesTableData(QuotesMembersImpl) #define QuotesPropertiesImpl(name, title, type) \ type get_##name() const { return m_##name; } \ void set_##name(const type &v) { m_##name = v; } \ string title_##name() const { return title; } QuotesTableData(QuotesPropertiesImpl) }; ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 16:24 ` Hyman Rosen @ 2007-04-12 18:05 ` Markus E Leypold 2007-04-15 0:55 ` Hyman Rosen 0 siblings, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-04-12 18:05 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > kevin cline wrote: >> Preprocessor macros are quite out of fashion for C++ programming. > > Unfortunately so. They're good for quite a bit of things, > especially when you want to code a little "database" table > of properties to be "queried" for the implementation. > > #define QuotesTableData(IMPL) \ > IMPL(stock, "Security Name", string) \ > IMPL(date, "Quote Date", time_t) \ > IMPL(bid, "Bid Price", double) \ > IMPL(ask, "Ask Price", double) > > struct QuotesTable { > #define QuotesEnumImpl(name, title, type) name, > enum { QuotesTableData(QuotesEnumImpl), N }; > #define QuotesMembersImpl(name, title, type) type m_##name; > QuotesTableData(QuotesMembersImpl) > #define QuotesPropertiesImpl(name, title, type) \ > type get_##name() const { return m_##name; } \ > void set_##name(const type &v) { m_##name = v; } \ > string title_##name() const { return title; } > QuotesTableData(QuotesPropertiesImpl) > }; Without trying to understand ypur example in depth: This is -- of course -- only necessary because C/C++ has no way to specify a constant array (i.e. a "array literal"). Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-12 18:05 ` Markus E Leypold @ 2007-04-15 0:55 ` Hyman Rosen 2007-04-15 7:55 ` Dmitry A. Kazakov 2007-04-15 15:25 ` Markus E Leypold 0 siblings, 2 replies; 167+ messages in thread From: Hyman Rosen @ 2007-04-15 0:55 UTC (permalink / raw) Markus E Leypold wrote: > This is only necessary because C/C++ has no way to specify a > constant array (i.e. a "array literal"). Not really. The preprocessor stuff is generating program code as well as data. Think about "properties" - you need to code a getter, a setter, a place to hold the value, a type, a descriptive string, and so forth. The language syntax may not allow all of this to be in one place, and that's where macros can come in handy. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-15 0:55 ` Hyman Rosen @ 2007-04-15 7:55 ` Dmitry A. Kazakov 2007-04-15 15:25 ` Markus E Leypold 1 sibling, 0 replies; 167+ messages in thread From: Dmitry A. Kazakov @ 2007-04-15 7:55 UTC (permalink / raw) On Sun, 15 Apr 2007 00:55:19 GMT, Hyman Rosen wrote: > Markus E Leypold wrote: >> This is only necessary because C/C++ has no way to specify a >> constant array (i.e. a "array literal"). > > Not really. The preprocessor stuff is generating program code as > well as data. Think about "properties" - you need to code a getter, > a setter, a place to hold the value, a type, a descriptive string, > and so forth. The language syntax may not allow all of this to be > in one place, and that's where macros can come in handy. If the language does not provide abstract member interface (primitive operations for ".Foo") that is a deficiency. I think that the idea of having tools (and meta programming) instead of fixing the language is wrong. Surely there exist border cases used rarely, which aren't worth the efforts. But getter/setter is IMO not among them. In your example type is superfluous, it should be determinable from the value. The value and the string would be a tuple used in the setter. For tuples one would also need user-defined aggregates, otherwise the string length discriminant of the tuple could not be evaluated from the string value. Maybe anonymous record types..., anyway, I think that the sugar X.Foo := (1.35, "Blah"); is solvable in a statically typed language without preprocessing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-15 0:55 ` Hyman Rosen 2007-04-15 7:55 ` Dmitry A. Kazakov @ 2007-04-15 15:25 ` Markus E Leypold 1 sibling, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-04-15 15:25 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Markus E Leypold wrote: >> This is only necessary because C/C++ has no way to specify a >> constant array (i.e. a "array literal"). > > Not really. The preprocessor stuff is generating program code as > well as data. Think about "properties" - you need to code a getter, > a setter, a place to hold the value, a type, a descriptive string, > and so forth. The language syntax may not allow all of this to be > in one place, and that's where macros can come in handy. Oooh -- don't know. In reality I found that if I really abstract of attributes of objects (or ADTs in general), the attribute has no 1:1 representation in the implementation. Getting and setting become fundamentally different then: i'd have to implement them separately anyway. And often I only want to export the attribute read-only (indeed that is the often default in base classes anyway), so I don't want to provide a setter. Some "setter functions" don't even make much sense when setting a single attribute. So overall I found I can well forgo using the pre processor like this. And custom syntax should anyway be used very sparingly and only if you do something really different or new AND know what you're doing: Else the program becomes quickly unreadable locally. And most people with a pre processor at their finger tipps don't realize that they shouldn't and -- well -- the results a regrettable. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 4:52 ` why learn C? jimmaureenrogers 2007-03-30 6:30 ` Case Crab @ 2007-03-31 11:40 ` Larry Kilgallen [not found] ` <1175236212.771445.135460@y66g2Organization: LJK Software <c82IfUV$xbi8@eisner.encompasserve.org> 2 siblings, 0 replies; 167+ messages in thread From: Larry Kilgallen @ 2007-03-31 11:40 UTC (permalink / raw) In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, <adaworks@sbcglobal.net> writes: > I cannot imagine anyone writing a column > called "Obfuscated Ada." Number_of_Genders_Encountered : Integer; Traffic_Light_Color : Boolean; Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module; ^ permalink raw reply [flat|nested] 167+ messages in thread
[parent not found: <1175236212.771445.135460@y66g2Organization: LJK Software <c82IfUV$xbi8@eisner.encompasserve.org>]
* Re: why learn C? [not found] ` <1175236212.771445.135460@y66g2Organization: LJK Software <c82IfUV$xbi8@eisner.encompasserve.org> @ 2007-03-31 18:56 ` adaworks 2007-03-31 20:10 ` Markus E Leypold 2007-03-31 19:33 ` Cesar Rabak 1 sibling, 1 reply; 167+ messages in thread From: adaworks @ 2007-03-31 18:56 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:c82IfUV$xbi8@eisner.encompasserve.org... > In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, > <adaworks@sbcglobal.net> writes: > >> I cannot imagine anyone writing a column >> called "Obfuscated Ada." > > Number_of_Genders_Encountered : Integer; > Traffic_Light_Color : Boolean; > Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module; OK. With a little effort, one can write obfuscated code in any language. However, with C++ it is far more likely than with Ada. Further, as your examples illustrate, one needs to really make an effort to do so with Ada. I recall a project I worked on many hundreds of years ago (it seems that long) where we were using COBOL. One of the programmers used the names of comic book characters as data and procedure names throughout his program. We had constructs such as, MOVE BATMAN TO BATMOBILE. The code worked fine, but it was somewhat obfuscated. Your last example is particularly interesting. In the absence of a global visibility clause (use), one would expect dot notation to disambiguate the other module. For your first example, coding standards would certainly apply. We learned a long time ago not to use type numeric types in package Standard. In Ada, we can define our own data types. This is not an option in C++ unless one jumps through hoops. Finally, using Boolean for Traffic_Light_Color is simply absurd, not obfuscation. There are three colors for a traffic light, and Boolean only covers two. This is not bad coding, nor is obfuscated code. Instead, it is bad design. The "Obfuscated C++" column, which I enjoyed while it lasted, was not always code that was tormented into a puzzle. Instead, it was code that one might actually find someone using on a project. Sometimes, I could figure it out through simple reasoning. Other times, I had to fire up my trusty C++ compiler to get to the answer. A couple of times I had to wait for the following month's installment with the published answer. In Ada, this kind of thing would be less likely. Richard Riehle ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 18:56 ` adaworks @ 2007-03-31 20:10 ` Markus E Leypold 2007-04-01 18:13 ` tmoran 0 siblings, 1 reply; 167+ messages in thread From: Markus E Leypold @ 2007-03-31 20:10 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message > news:c82IfUV$xbi8@eisner.encompasserve.org... >> In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, >> <adaworks@sbcglobal.net> writes: >> >>> I cannot imagine anyone writing a column >>> called "Obfuscated Ada." >> >> Number_of_Genders_Encountered : Integer; >> Traffic_Light_Color : Boolean; >> Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module; > > OK. With a little effort, one can write obfuscated code in any > language. However, with C++ it is far more likely than with Ada. Obfuscation is a voluntary effort, though. The word "likely" probably can't be applied then. If we're just talking about non-understandable code, I suggest that the "terse" syntax of the C/C++ language family is only a part of the problem. Choosing wrong or indecriptive identifiers (perhaps in a language one isn't fluent in -- or in a language the reader isn't fluent in ... :-)) can happen in Ada as well. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 20:10 ` Markus E Leypold @ 2007-04-01 18:13 ` tmoran 0 siblings, 0 replies; 167+ messages in thread From: tmoran @ 2007-04-01 18:13 UTC (permalink / raw) > If we're just talking about non-understandable code, I suggest that > the "terse" syntax of the C/C++ language family is only a part of the > problem. Choosing wrong or indecriptive identifiers ... As I recall, the obfuscated C examples weren't generally about stupidly chosen identifiers, but more often C code which appeared at first glance to do one thing, but on *close* parsing of the syntax, actually did something else. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? [not found] ` <1175236212.771445.135460@y66g2Organization: LJK Software <c82IfUV$xbi8@eisner.encompasserve.org> 2007-03-31 18:56 ` adaworks @ 2007-03-31 19:33 ` Cesar Rabak 2007-03-31 20:11 ` Markus E Leypold 1 sibling, 1 reply; 167+ messages in thread From: Cesar Rabak @ 2007-03-31 19:33 UTC (permalink / raw) Larry Kilgallen escreveu: > In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, <adaworks@sbcglobal.net> writes: > >> I cannot imagine anyone writing a column >> called "Obfuscated Ada." > > Number_of_Genders_Encountered : Integer; > Traffic_Light_Color : Boolean; > Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module; Well after going through MyIntenrs� Ada_Obfuscator V. XLIV it can get harder: X1 : Integer; X2 : Boolean; X3 : Y77; [1] obviously a registered mark ;-) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-31 19:33 ` Cesar Rabak @ 2007-03-31 20:11 ` Markus E Leypold 0 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-03-31 20:11 UTC (permalink / raw) Cesar Rabak <csrabak@yahoo.com.br> writes: > Larry Kilgallen escreveu: >> In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, <adaworks@sbcglobal.net> writes: >> >>> I cannot imagine anyone writing a column >>> called "Obfuscated Ada." >> Number_of_Genders_Encountered : Integer; >> Traffic_Light_Color : Boolean; >> Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module; > Well after going through MyIntenrs� Ada_Obfuscator V. XLIV it can get > harder: > > X1 : Integer; > X2 : Boolean; > X3 : Y77; Is that really harder? At least here it's evident that the names don't mean anything. But Traffic_Light_Color:Boolean really suggests something that is wrong. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 0:51 ` kevin cline 2007-03-30 4:09 ` Steve 2007-03-30 4:52 ` why learn C? jimmaureenrogers @ 2007-03-30 8:16 ` Markus E Leypold 2007-03-30 9:10 ` Georg Bauhaus 2007-03-30 19:16 ` Pascal Obry 4 siblings, 0 replies; 167+ messages in thread From: Markus E Leypold @ 2007-03-30 8:16 UTC (permalink / raw) "kevin cline" <kevin.cline@gmail.com> writes: > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > >> >> It has always seemed rather odd to me that people who are as intelligent >> as programmers, rarely question the silliness of using tools such as C >> and C++ for serious work. >> They simply take for granted that the kind >> of errors that are so common in those languages are somehow akin to >> the laws of nature. > > No, what actually happened is that expert C++ developers learned to > use C++ in such a way that those errors can not happen. While it is > possible to write unsafe code in C++, it is also possible to adopt > coding guidelines that makes it easy to find and eliminate unsafe > code, and for most applications, that's quite good enough. One reason > that experts choose C++ over Ada for performance-critical applications > because C++ templates allow compile-time type safety in high-level > code in a way that Ada generics do not. Wow. This is like looking into your gasoline tank with a cigarette lighter for illumination. Regards -- Markus ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 0:51 ` kevin cline ` (2 preceding siblings ...) 2007-03-30 8:16 ` Markus E Leypold @ 2007-03-30 9:10 ` Georg Bauhaus 2007-03-30 19:16 ` Pascal Obry 4 siblings, 0 replies; 167+ messages in thread From: Georg Bauhaus @ 2007-03-30 9:10 UTC (permalink / raw) On Thu, 2007-03-29 at 17:51 -0700, kevin cline wrote: > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote: > > "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message > > > > > It has always seemed rather odd to me that people who are as intelligent > > as programmers, rarely question the silliness of using tools such as C > > and C++ for serious work. > > They simply take for granted that the kind > > of errors that are so common in those languages are somehow akin to > > the laws of nature. > > No, what actually happened is that expert C++ developers learned to > use C++ in such a way that those errors can not happen. While it is > possible to write unsafe code in C++, it is also possible to adopt > coding guidelines that makes it easy to find and eliminate unsafe > code, and for most applications, that's quite good enough. One reason > that experts choose C++ over Ada for performance-critical applications > because C++ templates allow compile-time type safety in high-level > code in a way that Ada generics do not. Nevertheless, adherence to tradition and culture group preferences (for lack of a better word) seems to prevent several highly desirable additions or changes to C++ (and D. And Ada.). Or their integration with the very templates that turn out to achieve useful effects: A well defined and expressive base type system; case coverage in conditionals; simplified overload rules (why overloading in the first place when we have powerful templates and virtual functions?); normal treatment of the return parameter in type checking; ... For example, why is int not a template? Sure it is possible to come up with a number of templates and have the compiler answer the question whether an all C++ program is base type safe. So why not make int less C-ish? And throw out types whose existence can no longer be justified, at higher or lower level, such as short, long, and long long: class Coordinate : int<0, 4096, unsigned>, Ring { // ... }; I'm not saying that these things can't be programmed in C++. I'm saying that they must be programmed if you want them in C++. That's the point. (Likewise, Ada should have the elementary school types only on request, i.e. no predefined "Integer" with all the operations some of which are hardly ever used in an average program. (Only average programs should affect what's in a language, no?) Do we profit considerably from the presence of and, in cases, need for all of typedef *and* class *and* struct *and* typename? And a guaranteed load of rules per project? The language's historic complexities can still provide for entertaining distractions from solving the problem. C++ is not alone here, but strangely, some programmers seem to insist on old baggage even in new programs. Template programming is tricky and likely will be because templates weren't designed for using them in the useful ways which we learn now many years after their addition to the language. They are a quite interesting experimental feature of compiling technology. (If they were not, I'm sure investors would have asked for a different design. One that has less potential of affecting programmer performance in *both* directions. The work needed to understand or improve template error messages is considerable: programmers need expensive time to fix template mistakes. Witness the opportunity for tool shops to sell expert systems for the interpretations of template error messages, and all the work that goes into improving them somewhere in the tool chain.) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 0:51 ` kevin cline ` (3 preceding siblings ...) 2007-03-30 9:10 ` Georg Bauhaus @ 2007-03-30 19:16 ` Pascal Obry 2007-04-01 11:41 ` Martin Krischik 4 siblings, 1 reply; 167+ messages in thread From: Pascal Obry @ 2007-03-30 19:16 UTC (permalink / raw) To: kevin cline kevin cline a �crit : > No, what actually happened is that expert C++ developers learned to > use C++ in such a way that those errors can not happen. While it is > possible to write unsafe code in C++, it is also possible to adopt > coding guidelines that makes it easy to find and eliminate unsafe > code, and for most applications, that's quite good enough. One reason Sorry but you must live in another planet :) All the C++ code I've seen are so full of bugs that I'm not inclined to buy that! Ok it *may* be possible but how many C++ programmers are *good* enough and *wise* enough to achieve that ? That's the real question to me, and from where I stand this is close to 0% ! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-30 19:16 ` Pascal Obry @ 2007-04-01 11:41 ` Martin Krischik 2007-04-01 17:03 ` Pascal Obry 2007-04-01 18:13 ` tmoran 0 siblings, 2 replies; 167+ messages in thread From: Martin Krischik @ 2007-04-01 11:41 UTC (permalink / raw) Pascal Obry wrote: > kevin cline a ï¿œcrit : > >> No, what actually happened is that expert C++ developers learned to >> use C++ in such a way that those errors can not happen. While it is >> possible to write unsafe code in C++, it is also possible to adopt >> coding guidelines that makes it easy to find and eliminate unsafe >> code, and for most applications, that's quite good enough. One reason > > Sorry but you must live in another planet :) All the C++ code I've seen > are so full of bugs that I'm not inclined to buy that! Ok it *may* be > possible but how many C++ programmers are *good* enough and *wise* > enough to achieve that ? That's the real question to me, and from where > I stand this is close to 0% ! I am more optimistic - I put it at 1% ;-). Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-01 11:41 ` Martin Krischik @ 2007-04-01 17:03 ` Pascal Obry 2007-04-01 18:13 ` tmoran 1 sibling, 0 replies; 167+ messages in thread From: Pascal Obry @ 2007-04-01 17:03 UTC (permalink / raw) To: Martin Krischik Martin Krischik a ï¿œcrit : > I am more optimistic - I put it at 1% ;-). Yes probably :) I was just a bit upset by those *theoretical* arguments when day after day you try to understand or try to make a junk C++ code working ! So in theory there is no difference between the theory and the practice but in practice there is :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-04-01 11:41 ` Martin Krischik 2007-04-01 17:03 ` Pascal Obry @ 2007-04-01 18:13 ` tmoran 1 sibling, 0 replies; 167+ messages in thread From: tmoran @ 2007-04-01 18:13 UTC (permalink / raw) > > Sorry but you must live in another planet :) All the C++ code I've seen > > are so full of bugs that I'm not inclined to buy that! Ok it *may* be > > possible but how many C++ programmers are *good* enough and *wise* > > enough to achieve that ? That's the real question to me, and from where > > I stand this is close to 0% ! > > I am more optimistic - I put it at 1% ;-). When I was first switching from C to Ada I sometimes tried translating some existing C code (no, not necessarily mine) to Ada and that process almost invariably revealed errors in the C code. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: why learn C? 2007-03-20 17:37 ` adaworks ` (2 preceding siblings ...) 2007-03-30 0:51 ` kevin cline @ 2007-04-16 2:09 ` Brian May 3 siblings, 0 replies; 167+ messages in thread From: Brian May @ 2007-04-16 2:09 UTC (permalink / raw) >>>>> "adaworks" == adaworks <adaworks@sbcglobal.net> writes: adaworks> Unlike the C family of languages, which are generally no adaworks> help at all, an Ada compiler frequently eliminates the adaworks> need for extensive debugging of silly errors; e.g., the adaworks> kind that originate from case-sensitivity, wrong order adaworks> of arguments to parameters, improper spacing, missing adaworks> curly-braces, and the plethora of language "features" adaworks> that plague those who have chosen to use any member of adaworks> the C family of languages. adaworks> It has always seemed rather odd to me that people who adaworks> are as intelligent as programmers, rarely question the adaworks> silliness of using tools such as C and C++ for serious adaworks> work. They simply take for granted that the kind of adaworks> errors that are so common in those languages are somehow adaworks> akin to the laws of nature. Java inherits many of those adaworks> same properties and is not much better. It is taken as adaworks> an article of faith that programming involves heavy use adaworks> of debuggers. Instead of asking why this is so, they adaworks> simply believe it is a fundamental law of programming -- adaworks> mainly because the languages they have chosen make it adaworks> so. I thought the following links were interesting. http://www.mega-nerd.com/erikd/Blog/CodeHacking/autoconf_ifdef.html http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html "Rusty says the key criteria for an interface is how easy it is to use correctly or (by Murphy's Law) how hard it is to misuse. He delineates a spectrum from best to worst, which is so good I am going to shamelessly reproduce it here: 1. Compiler/linker won't let you get it wrong. 2. Compiler will warn if you get it wrong. 3. The simplest use is the correct one. 4. The name tells you how to use it. 5. Do it right or it will break at runtime. 6. Follow common convention and you'll get it right. 7. Read the documentation and you'll get it right. 8. Read the implementation and you'll get it right. 9. Read the correct mailing list thread and you'll get it right. 10. Read the documentation and you'll get it wrong. 11. Follow common convention and you'll get it wrong. 12. Do it right and it will break at runtime. 13. The name tells you how not to use it. 14. The obvious use is wrong. 15. Compiler will warn if you get it right. 16. Compiler won't let you get it right. 17. It's impossible to get right. " -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 167+ messages in thread
end of thread, other threads:[~2007-04-22 19:50 UTC | newest] Thread overview: 167+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1172144043.746296.44680@m58g2000cwm.googlegroups.com> [not found] ` <slrnetr31o.875.Marc.Boyer@localhost.localdomain> [not found] ` <1172161751.573558.24140@h3g2000cwc.googlegroups.com> [not found] ` <slrnetri6j.875.Marc.Boyer@localhost.localdomain> [not found] ` <546qkhF1tr7dtU1@mid.individual.net> 2007-02-23 8:09 ` why learn C? Marc Boyer 2007-03-20 17:37 ` adaworks 2007-03-21 8:07 ` Maciej Sobczak 2007-03-21 13:39 ` Martin Krischik 2007-03-22 7:54 ` Maciej Sobczak 2007-03-21 14:10 ` Dmitry A. Kazakov 2007-03-21 17:57 ` adaworks 2007-03-21 18:48 ` adaworks 2007-03-21 18:39 ` Georg Bauhaus 2007-03-21 20:09 ` Dmitry A. Kazakov 2007-03-21 20:25 ` Use of declare blocks Randy Brukardt 2007-03-21 20:36 ` Gautier 2007-03-21 20:37 ` Gautier 2007-03-21 20:43 ` Niklas Holsti 2007-03-21 21:29 ` Randy Brukardt 2007-03-22 1:17 ` Adam Beneschan 2007-03-22 8:34 ` Dmitry A. Kazakov 2007-03-22 1:06 ` Adam Beneschan 2007-03-22 17:59 ` adaworks 2007-03-23 2:35 ` Randy Brukardt 2007-03-23 5:23 ` adaworks 2007-03-23 5:15 ` Randy Brukardt 2007-03-23 10:20 ` Georg Bauhaus 2007-03-23 18:25 ` commenting, was " tmoran 2007-03-24 0:32 ` adaworks 2007-03-24 2:12 ` tmoran 2007-03-24 3:19 ` Randy Brukardt 2007-03-24 7:36 ` tmoran 2007-03-24 15:35 ` Simon Wright 2007-03-21 13:29 ` why learn C? Alexander E. Kopilovich 2007-03-30 0:51 ` kevin cline 2007-03-30 4:09 ` Steve 2007-03-30 4:58 ` kevin cline 2007-03-30 7:44 ` Lutz Donnerhacke 2007-03-30 9:09 ` Dmitry A. Kazakov 2007-04-02 4:29 ` kevin cline 2007-04-02 6:45 ` adaworks 2007-04-02 7:52 ` Dmitry A. Kazakov 2007-04-02 8:19 ` kevin cline 2007-04-02 12:04 ` Dmitry A. Kazakov 2007-04-02 23:37 ` Randy Brukardt 2007-04-03 12:42 ` Erasing inappropriate operations (was: why learn C?) Ludovic Brenta 2007-04-03 23:44 ` Randy Brukardt 2007-04-04 8:34 ` Erasing inappropriate operations Ludovic Brenta 2007-04-04 22:00 ` Randy Brukardt 2007-04-03 0:16 ` why learn C? Markus E Leypold 2007-04-04 16:14 ` jayessay 2007-04-05 7:14 ` Hyman Rosen 2007-04-05 15:35 ` jayessay 2007-04-06 2:02 ` Hyman Rosen 2007-04-06 5:57 ` Ray Blaak 2007-04-06 11:01 ` Markus E Leypold 2007-04-07 23:00 ` Ray Blaak 2007-04-08 19:41 ` jayessay 2007-04-09 14:08 ` Markus E Leypold 2007-04-10 15:48 ` jayessay 2007-04-08 19:44 ` jayessay 2007-04-06 18:05 ` jayessay 2007-04-06 22:00 ` Hyman Rosen 2007-04-06 23:46 ` jayessay 2007-04-06 23:59 ` jayessay 2007-04-06 22:16 ` Hyman Rosen 2007-04-06 23:52 ` jayessay 2007-04-07 0:39 ` Ray Blaak 2007-04-06 17:52 ` jayessay 2007-03-30 8:29 ` Markus E Leypold 2007-03-30 8:35 ` Markus E Leypold 2007-03-30 17:39 ` adaworks 2007-03-31 14:59 ` Steve 2007-03-31 15:59 ` Markus E Leypold 2007-04-01 14:32 ` Ed Falis 2007-04-02 7:03 ` adaworks 2007-03-31 15:14 ` Pascal Obry 2007-04-02 5:27 ` kevin cline 2007-04-02 6:04 ` Harald Korneliussen 2007-04-02 6:33 ` Shortage on C / C++ experts Martin Krischik 2007-04-02 7:07 ` why learn C? adaworks 2007-04-02 7:18 ` kevin cline 2007-04-02 13:00 ` adaworks 2007-04-12 15:28 ` Hyman Rosen 2007-04-12 18:32 ` Robert A Duff 2007-04-13 15:59 ` Hyman Rosen 2007-04-14 22:20 ` Robert A Duff 2007-04-14 22:46 ` Randy Brukardt 2007-04-22 18:53 ` adaworks 2007-04-22 19:50 ` Gautier 2007-04-03 0:26 ` Markus E Leypold 2007-04-03 0:34 ` Markus E Leypold 2007-04-03 2:22 ` jimmaureenrogers 2007-04-12 15:47 ` Hyman Rosen 2007-04-12 16:18 ` Markus E Leypold 2007-04-13 23:18 ` kevin cline 2007-04-14 9:38 ` Georg Bauhaus 2007-04-14 10:57 ` Markus E Leypold 2007-04-15 15:10 ` Simon Wright 2007-04-15 16:05 ` Markus E Leypold 2007-04-15 0:59 ` Hyman Rosen 2007-04-15 15:28 ` Markus E Leypold 2007-04-12 16:39 ` Dmitry A. Kazakov 2007-04-12 20:54 ` Georg Bauhaus 2007-04-12 20:33 ` Dmitry A. Kazakov 2007-04-12 21:40 ` Georg Bauhaus 2007-04-12 20:50 ` Dmitry A. Kazakov 2007-04-13 0:32 ` Markus E Leypold 2007-04-14 22:27 ` Robert A Duff 2007-04-14 1:20 ` jimmaureenrogers 2007-04-02 5:03 ` Brian May 2007-04-02 6:16 ` kevin cline 2007-04-03 0:00 ` Brian May 2007-04-12 15:56 ` Hyman Rosen 2007-04-12 16:19 ` Markus E Leypold 2007-04-13 23:42 ` Georg Bauhaus 2007-04-03 0:13 ` Markus E Leypold 2007-04-02 11:47 ` Shortage on C / C++ experts Larry Kilgallen 2007-04-02 12:01 ` Ludovic Brenta 2007-04-02 12:15 ` Dmitry A. Kazakov 2007-04-02 18:47 ` Alexander E. Kopilovich 2007-04-02 20:43 ` tmoran 2007-03-30 4:52 ` why learn C? jimmaureenrogers 2007-03-30 6:30 ` Case Crab 2007-03-30 6:37 ` Gautier 2007-03-30 9:17 ` Georg Bauhaus 2007-03-31 13:18 ` Peter C. Chapin 2007-04-01 1:23 ` Georg Bauhaus 2007-04-01 11:59 ` Peter C. Chapin 2007-04-02 6:37 ` kevin cline 2007-04-02 9:39 ` Harald Korneliussen 2007-03-30 17:47 ` adaworks 2007-03-30 19:25 ` Markus E Leypold 2007-03-30 20:29 ` Randy Brukardt 2007-03-31 9:52 ` Dmitry A. Kazakov 2007-04-01 1:35 ` adaworks 2007-03-31 2:41 ` jimmaureenrogers 2007-03-31 12:25 ` not NASA Ada coding standard Stephen Leake 2007-03-31 15:44 ` Markus E Leypold 2007-04-01 16:22 ` Simon Clubley 2007-04-02 10:08 ` Stephen Leake 2007-04-02 7:43 ` why learn C? kevin cline 2007-04-02 8:45 ` Martin Krischik 2007-04-02 10:54 ` Georg Bauhaus 2007-04-12 16:05 ` Hyman Rosen 2007-04-12 16:48 ` Dmitry A. Kazakov 2007-04-12 18:27 ` Robert A Duff 2007-04-13 16:21 ` Hyman Rosen 2007-04-12 21:11 ` Georg Bauhaus 2007-04-13 15:45 ` Hyman Rosen 2007-04-02 8:13 ` kevin cline 2007-04-02 23:54 ` Randy Brukardt 2007-04-03 2:58 ` jimmaureenrogers 2007-04-12 16:24 ` Hyman Rosen 2007-04-12 18:05 ` Markus E Leypold 2007-04-15 0:55 ` Hyman Rosen 2007-04-15 7:55 ` Dmitry A. Kazakov 2007-04-15 15:25 ` Markus E Leypold 2007-03-31 11:40 ` Larry Kilgallen [not found] ` <1175236212.771445.135460@y66g2Organization: LJK Software <c82IfUV$xbi8@eisner.encompasserve.org> 2007-03-31 18:56 ` adaworks 2007-03-31 20:10 ` Markus E Leypold 2007-04-01 18:13 ` tmoran 2007-03-31 19:33 ` Cesar Rabak 2007-03-31 20:11 ` Markus E Leypold 2007-03-30 8:16 ` Markus E Leypold 2007-03-30 9:10 ` Georg Bauhaus 2007-03-30 19:16 ` Pascal Obry 2007-04-01 11:41 ` Martin Krischik 2007-04-01 17:03 ` Pascal Obry 2007-04-01 18:13 ` tmoran 2007-04-16 2:09 ` Brian May
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox