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: Mathias Gaunard on 2 Jul 2010 06:19 On Jul 1, 4:14 pm, n...(a)cam.ac.uk wrote: > In article <4abdacbf-7ef6-4dce-8570-3e336bc0f...(a)x21g2000yqa.googlegroups.com>, > Mathias Gaunard <loufo...(a)gmail.com> wrote: > > >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++. > > Oh, really! All of Algol 68, Fortran, Genstat, Lisp, Haskell, PL/I > and most of the others I have used or helped with have fundamental > concepts that have no equivalent in C++ - and conversely. Note I said "basics", and I meant the basics of *programming* in those languages, not that of technical knowledge of the mechanisms that define how they work. Also, I cannot see a truly fundamental programming concept from those languages (ignoring Genstat that appears offtopic, albeit I don't know it) that C++ is completely lacking. > >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. > > Only in the sense that every language does. There are lots of things > that can't be done without programming primitives from scratch. C++ allows you to define any domain-specific embedded language by analyzing the type of an expression at compile-time and generating C++ code for it; that's hardly what "every language does". This is the most high-level you can get. At the same time, it provides very low-level primitives inherited from C. To me, low-level access with very high abstraction possibilities pretty much means "you can do whatever you want with it". > > >> If you > >> know several different language approaches to the same issue, you > >> will have hell working out which ones C++ permits. > > >All of them. > > Try Fortran argument association or Algol 68 dereferencing and > deproceduring :-) Those are not approaches to programming, problem solving or software design; they don't even seem to be concepts you really manipulate in those languages, but rather rules about how they work. (I acknowledge I don't know or understand what those things are, but didn't look too much into it due to lack of interest) > >For the second semantics, there are subtleties in C++ due to ownership > >and lifetime issues, which do not exist in garbage collected > >languages. > > They do, indeed, they do! They just expose themselves differently. I'm talking about designing objects that follow those semantics. In garbage collected languages; lifetime management is not even part of the design process. (which is a bad idea; a garbage collector doesn't prevent logical leaks) > >Of course, it the object can't be modified, both semantics end up > >being the same. > > Er, no. You can take the address of objects in C++ and compare them. Actual physical comparisons of objects are irrelevant, since they're a low-level thing outside the scope of high-level object modeling. > I shall stop here, but I am afraid that I need to go into lecture > mode. I find that -- along with your condescending, paternalistic and nitpicking attitude -- hardly appropriate, given I had went out of my way to offer you my personal insights to help you see differently things that appeared to have frustrated you in C++. > Deep versus shallow copying is an important issue with any > language that has either mutable objects or address comparison, > and where objects can contain objects. Not merely does it make > sense, it is one of the fundamental issues. You're missing the point I tried to make. What the object is modeling dictates what the copy should do. The same object with "deep" or "shallow" copying is simply a different entity altogether. Deep or shallow is only something that makes sense when you consider the object as bytes rather than as a logical entity. > > Consider a container A, which contains objects B, C, D etc. When > A is copied, does it copy B, C, D etc. or take references to them? You said it yourself: A contains B, C and D, i.e. they're part of A. If the copy is "shallow", then a copy of A doesn't contain B, C and D. You break the invariant that defines A. > C++ is clear what happens, until it comes to the STL. The problem > there is that the STL states that there are constructors for the > container A, but not exactly what they do. They should do what logically makes sense for the object. A copy should make a logical copy of whatever the object is modeling, a move a logical move. Everything is simple and clear. The algorithms of the standard library intentionally manipulate high- level abstractions; if you don't map the abstractions right to your objects to do what they're supposed to, then the high-level operations the algorithms perform don't translate into something meaningful for your objects, obviously. > And, because you can program all of the methods I described, it > isn't clear which ones the standard allows an implementation to > choose. It is THAT class of problem I am referring to. Again, I fail to see what your problem is. A copy must exhibit the properties of a copy. The implementation you choose is irrelevant. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 2 Jul 2010 06:25 Francis Glassborow wrote: > C++ is an exceptionally large language that allows you to express > problem solutions based on several different paradigms but many find > that hard to grasp, they just think C++ is hard and confusing. C++ is a multiparadigm language, but that's not what makes it hard and confusing. What makes it hard and confusing are seemingly arbitrary rules, such as how name lookup works is very different from class scope, to template scope, to other scopes. Then there are things like in some cases adding ( ) around an expression changes the expression's meaning, sometimes it doesn't. The tag name space which is sometimes visible in the regular name space. The quirky way you sometimes have to add in "helper" keywords to aid the parsing of templates. The strange handling of > tokens. Learning all those little rules takes a long time, and doesn't reward you with any useful insight. Learning the different paradigms, on the other hand, does reward you with insight. Having been around C++ for 25 years, I know most of the reasons for why things are the way they are, and the justifications. But those justifications aren't of much interest for the new programmer, he just sees it as it is. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 2 Jul 2010 09:29 Mathias Gaunard wrote: > On Jun 30, 8:51 am, Daniel <danielapar...(a)gmail.com> wrote: >> It doesn't do functional well. > It does it pretty well, even if C++0x lambdas are disappointing. Functional programming requires data immutability and function purity. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 2 Jul 2010 09:27 DeMarcus wrote: > We also know that code we write today will compile also in five years. My experience is that C++ code untouched for 5 years is not likely to compile without changing something, due to: 1. language changes 2. compiler changes of one form or another 3. header changes 4. compiler switches changing 5. compiler warnings changed 6. target system changes (like single => multicore broke some of my stuff) 7. implementation defined details changing 8. subtle changes in the behavior of floating point, like how floating point literals are processed (just recently there was a change in gcc that influenced the last bit). [Erratic, inaccurate and sloppy implementations of the floating point functions in the standard library and compiler's lexer have caused me enough problems that I just bring along my own versions :-)] I use a very old text editor, microemacs, that I've been porting everywhere I go. It always needs one tweak or another when rebuilding it after years. The last problem I had was the term library disappeared. Granted, these are easily managed issues, but let's not pretend they aren't there! -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 2 Jul 2010 09:30
In article <i0igia$35f$1(a)news.eternal-september.org>, Alf P. Steinbach /Usenet <alf.p.steinbach+usenet(a)gmail.com> wrote: >>> >>> C++ code can become stale so that it will not compile, so called /code >>> rot/, just because the libraries that it relies on have changed, and/or >>> the compilers have changed. And this is not uncommon. For a concrete >>> example with entertaining discussion, see<url: >>> http://wordaligned.org/articles/code-rot>. >> >> If the code was intended to be portable, that's either bad code or >> poor quality of the C++ standard. > > Uhm, did you read the blog entry that I linked to and that you respond to? Yes. > Quoting about one of the examples discussed there: > > What�s interesting here is that this code is pure C++, just over a page of it. > It has no dependencies on third party libraries. Hubert Matthews is a C++ expert > and he acknowledges the help of two more experts, Andrei Alexandrescu and > Kevlin Henney, in his paper. Yet the code fails to build using both ancient and > modern compilers. In its published form it has the briefest of shelf-lives. As I said. Without inspecting it, I cannot comment on whether the code or the standard is deficient in portability. > I prefer to think that when Hubert Matthews writes some code /intended/ to be > portable, and has the code reviewed by Andrei Alexandrescu and Kevlin Henney (at > least that's my impression from the above), then it's not bad code. > > Nor is it about poor quality of the C++ standard. > > It's just normal code rot. ;-) 30-40 years ago, when the term "bit rot" started to become widespread (though I think it was older), it was used to describe the failure when the hidden assumptions of a program failed because of changes in the environment. It was pointed out then and since that this is NOT normally an inevitable state of affairs, but is due to sloppy coding and specifications - though it isn't always clear which. In particular, if a program relies on something that isn't specified by the language standard (i.e. is defined behaviour), then it should (a) document the fact and (b) check it as far as is possible and diagnose the problem. Similarly, language standards should ensure that their specifications are complete enough that that is possible, precise enough that most changes in interpretation are clearly changes, and document all incompatible changes. Some do that fairly well; others badly. EXACTLY what change caused the failure, and why do you claim that it was an Act of God and therefore nobody's fault? >> Some of my code is in widespread use 37 years after it was written >> (not in C++, clearly!) > > It's possible to do better in C, or for that matter Cobol, yes. No, it's not possible to do better in C, but let that pass. Cobol is a good example, but it was actually Fortran (which is another). Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |