future of the C++
in [C++]
|
Prev: Generating a derived class from a base class
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: Francis Glassborow on 24 Jun 2010 09:46 nmm1(a)cam.ac.uk wrote: > In article <4c21fa3e$0$2366$4d3efbfe(a)news.sover.net>, > Peter C. Chapin <pcc482719(a)gmail.com> wrote: >> SG wrote: >> >>> If you want to be >>> a good programmer you might want to learn more than one programming >>> language anyway. >> I want to echo this sentiment. Learning multiple languages is a must. Learning >> certain languages can change the way you think about programming and that's >> useful no matter what language you focus on. Even if you want to become a C++ >> master (maybe especially if you want to become a C++ master), you should also >> spend some time learning a dynamic language (Python?), a functional language >> (OCaml? Scala?), and maybe even a logic language. I've been spending time >> lately working with SPARK/Ada, a language designed for the construction of >> ultra-reliable software. It's definitely changed the way I think about >> programming... and that's a good thing. > > Unfortunately, that makes it extremely hard to learn C++ :-( > > Part of the reason is that there are a lot of hidden assumptions, > which are neither specified clearly in the standard (or in some > cases, at all) nor even mentioned in books and Web pages. If you > know several different language approaches to the same issue, you > will have hell working out which ones C++ permits. I do and I am > not finding it easy. And I know C extremely well. > That is like saying that English is a difficult language because it is so hard to work out which Chinese idioms it will support. Sometimes the value of other languages is not in importing their idioms but in understanding the whole topic at a deeper level. For example it is inconceivable that someone who only knows Mandarin Chinese would invent a crossword puzzle but once they came across one in English they might come up with some ideas for Chinese word puzzles (perhaps based on the different parts of a Character. Whilst Japanese very much lends itself to writing Haiku, once you have experienced good Japanese Haiku you may find it possible to write good English Haiku. (I was once giving and evening class on Haiku writing and the work of one Student reduced another to tears. I knew both students very well and know that the event sketched had never happened but I also understood the reasons for the extraordinary emotional impact of what was a pure Haiku -- and was itself unemotional) Sorry to have drifted -- but I do think breadth is very important if you wish to become a skilled programmer. Knowing C extremely well would actually make learning C++ harder rather than easier, there would be a strong tendency to write C++ as if it were just a more complex form of C and that would be a major mistake. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 24 Jun 2010 09:49 On Jun 24, 12:02 pm, n...(a)cam.ac.uk wrote: > In article <4c21fa3e$0$2366$4d3ef...(a)news.sover.net>, > Peter C. Chapin <pcc482...(a)gmail.com> wrote: > > >SG wrote: > > >> If you want to be > >> a good programmer you might want to learn more than one programming > >> language anyway. > > >I want to echo this sentiment. Learning multiple languages is a must. Learning > >certain languages can change the way you think about programming and that's > >useful no matter what language you focus on. Even if you want to become a C++ > >master (maybe especially if you want to become a C++ master), you should also > >spend some time learning a dynamic language (Python?), a functional language > >(OCaml? Scala?), and maybe even a logic language. I've been spending time > >lately working with SPARK/Ada, a language designed for the construction of > >ultra-reliable software. It's definitely changed the way I think about > >programming... and that's a good thing. > > Unfortunately, that makes it extremely hard to learn C++ :-( I think it's the opposite. If you truly know C++, then you know the basics of all object/ functional/imperative/array languages. Knowing all those languages also helps grasping C++. C++ allows you to do whatever you want, that's why there are so many rules and coding standards about it of how you should do things. > If you > know several different language approaches to the same issue, you > will have hell working out which ones C++ permits. All of them. > There are at least > four common, sane, approaches to object copying in a class-based > language, and several uncommon or insane ones. There are two semantics for copying: - copying creates another object, and modifying it doesn't modify the original (the object is a value) - copying creates an object that is really just an alias, and modifying it affects the original (the object is a view) For the second semantics, there are subtleties in C++ due to ownership and lifetime issues, which do not exist in garbage collected languages. Of course, it the object can't be modified, both semantics end up being the same. > [*] Deep copying, as a value. Shallow copying, as a value. Reference > counting, without replication. Reference counting, with replication. The whole idea of "deep copying" vs "shallow copying" doesn't make sense. Either the object can be copied or it cannot, and if it can, the copy is what makes sense for what the object is modelling (are we modelling a matrix or a view of a matrix)? COW (what you refer to by reference counting with replication I suppose) doesn't affect semantics, it's merely an implementation technique for lazy copying (that is discouraged, by the way -- it was only popular due to lack of move semantics). > Common insane ones include patchy support for copying, without reliable > detection of the cases that don't work; that is what I seem to have. Reasoning about ownership is part of C++ programming. This is obviously what you're lacking. You're using new and pointers everywhere, not even calling delete, it's just nonsense. There is a simple rule: if you've got one of these three defined, then you need the two others: copy constructor, assignment operator and destructor. Your code allocates memory in its constructors and doesn't ever release it. If it did, it would do so in the destructor, meaning you need the two others. The basic idea to C++ programming is to acquire resources in the constructors, release them in the destructor, and not share ownership with other objects: the object owns the resources exclusively, meaning it can take care of releasing them when it doesn't need them anymore. This is what is known as RAII. Nice, clean, isolated, automatic, exception-safe and deterministic. Then there is the technique known as reference counting that allows to share the resource ownership with other objects while still making destruction work correctly in a RAII style. It's very popular, in particular since it's versatile and easy to mix with legacy code and it does allow an easier/lazier programming style, but it's something that should be avoided. Sharing state is bad enough; shared ownership is not something that I would recommend outside of the flyweight pattern (where objects are immutable and all owned by a global factory). Of course, that is a whole debate. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 24 Jun 2010 09:42 Peter C. Chapin wrote: > SG wrote: > >> If you want to be >> a good programmer you might want to learn more than one programming >> language anyway. > > I want to echo this sentiment. Learning multiple languages is a must. Learning > certain languages can change the way you think about programming and that's > useful no matter what language you focus on. Even if you want to become a C++ > master (maybe especially if you want to become a C++ master), you should also > spend some time learning a dynamic language (Python?), a functional language > (OCaml? Scala?), and maybe even a logic language. I've been spending time > lately working with SPARK/Ada, a language designed for the construction of > ultra-reliable software. It's definitely changed the way I think about > programming... and that's a good thing. > > Of course learning other languages takes time away from C++ and if you want to > really master C++ a lot of time studying it is required. One must balance > one's time. > > And yes, I agree with what others are saying: C++ is not going anywhere > anytime soon. It is very much worth getting to know. > I am a lifelong advocate of learning multiple languages (both human and computer ones) because that broadens your understanding. In view of the way that C++ template metaprogramming works I would put a functional language (Haskell would be my first choice) very near the top of a list of languages to learn. In addition, because it definitely chnages the way you think I would add a threaded Interpreted Language such as Forth to the list. It might give you some useful ideas about designing special purpose languages which you might implement in C++. Logic languages are fascinating but I do not know of any really good text on one (but programming in a locic language definitely broadens your thinking -- or you give up) In all cases you need to come at these language with an open mind rather than try to make them work the way of a language that you have already mastered. The best C++ programmers are multi-lingual. And I remember Andrew Koenig telling me about an early effort of his to develop support for Snobol type programming using C++. Now my bet is that most readers here do not even know what Snobol is :) Oh, and mastery of Lisp can add even more to your skill set. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrew on 25 Jun 2010 17:23 On 25 June, 00:42, Francis Glassborow <francis.glassbo...(a)btinternet.com> wrote: > > I want to echo this sentiment. Learning multiple languages is a must. Learning > > certain languages can change the way you think about programming and that's > > useful no matter what language you focus on. Even if you want to become a C++ > > master (maybe especially if you want to become a C++ master), you should also > > spend some time learning a dynamic language (Python?), a functional language > > (OCaml? Scala?), and maybe even a logic language. > I am a lifelong advocate of learning multiple languages (both human and > computer ones) because that broadens your understanding. In view of the > way that C++ template metaprogramming works I would put a functional > language (Haskell would be my first choice) very near the top of a list > of languages to learn. Top of my list of functional languages to learn is Erlang. This is starting to be used more and more in financial circles due to the good support for parallel processing. These financial circles also tend to be the major users of C++ today where they use it to interface to the quant libraries. Quant libs are typically coded in C++ (which started off in C and then grew). IMO the quant libs will stay in C++ for many years since programming is not the main skill quants have (programming- wise they stick with what they know). But further out from the quant libs people are using other languages. Java is probably the most popular but erlang is very up and coming. Regards, Andrew Marlow -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Rui Maciel on 26 Jun 2010 05:16
joe wrote: >> C++ is one of few internationally _standardized_ programming languages. > > You say that like it is a good thing! And it is. Do you believe it isn't? If so, why? >> You should be more afraid of the lifetime of languages owned by a >> company. Look what happened to Visual Basic 6.0. It's now deprecated! >> > > So what you are basically saying, C++ isn't the worst of 2 evils (?). It isn't nice to put words on other people's mouths. The issue which was pointed out is, in essence, who has control over a language and what assurances do we have that the language will remain useful in the future and if/how it will be developed. The Visual Basic 6.0 example is an excellent example to describe the issues at stake. It was a programming language which was controlled by a single corporation and which was strongly pushed at a time. Meanwhile that corporation had a change of heart and in effect killed the language, an action which in essence meant that all those poor fools who invested their time and effort to develop their skills in that platform have been, truth be told, wasting their time. Moreover, those countless LoC which have been written in Visual Basic have been forced to lay to waste from software rot. > The > PL landscape is much larger than C++ vs. proprietary languages. No one besides you has claimed that this issue is one of C++ Vs proprietary languages. > IMO, C++ > will morph or fork or become increasingly uncompetitive (chosen less and > less by programmers, projects and organizations). I suspect that your opinion wasn't formed after a thorough investigation on this subject. Nevertheless, could you please point out what leads you to believe in that? Rui Maciel -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |