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: nmm1 on 1 Jul 2010 00:04 In article <i0f1pv$864$1(a)news.eternal-september.org>, Alf P. Steinbach /Usenet <alf.p.steinbach+usenet(a)gmail.com> wrote: >* DeMarcus, on 27.06.2010 17:27: >> >> We also know that code we write today will compile also in five years. >> Quick development of a language may be good in areas where software is >> developed and thrown out in the same pace, but where you want an >> application to live some years it's not fun to realize you can't make >> changes to five year old code just because it won't compile due to some >> CEO's business strategy decision. > >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. Portable code should work under systems and compilers that haven't been designed at the time it was written. That's what programming standards are for. Yes, that's a counsel of perfection, and we live in an imperfect world. However, to a great extent, Fortran has achieved that over a range of systems, compilers and years far greater than the totality of those for C++. It's not easy to achieve, but can be done. >In light of this, I don't think the argument quoted above holds water. Some of my code is in widespread use 37 years after it was written (not in C++, clearly!) Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 1 Jul 2010 00:14 In article <4abdacbf-7ef6-4dce-8570-3e336bc0f859(a)x21g2000yqa.googlegroups.com>, Mathias Gaunard <loufoque(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. >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. >> 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 :-) >> 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) So far, so good. >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. >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. There is therefore a visible difference between two separate identical and immutable objects and two references to the same one. >> [*] 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)? I shall stop here, but I am afraid that I need to go into lecture mode. 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. 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? 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. 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. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 2 Jul 2010 05:49 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. It supports all the features of functional languages like OCaml / ML / F# ? Does it support at least function currying ? > >> It >> doesn't do reflection. > > It does compile-time reflection., but of course not dynamic as this > would not only add significant memory overhead but also because it It would add overhead to the file to add meta data information to do reflection appropriately, but not that much to memory - IMHO. > [...] > >> Having both .h's and .cpp's >> seems redundant, both contain implementation. > > But it gives great flexibility about the building process. It's just a pain to handle separate files, additionally it adds significant complexity to IDE tools and to the compiler. So what is the flexibility ? I would call it flexible if I would have the option to use a C++ module. But you can't in C++. If you mean it's flexible that you can just generate a library file and just ship the *.h file I wouldn't call the flexibility too. I would call it flexible, if you could either choose: a) Use the C++ source module directly (single file) b) Generate and use a library but don't have to ship the header file, but directly include it in the library itself > [...] > >> Using >> unicode is painful. > > No programming language does this right anyway. C# for example has it right out of the box. There are only unicode strings. > [...] > >> The std library is full of things that must have >> at one time seemed like good ideas, like is and os. > > ? > Are you talking about iostreams that are not that good? IOStreams are a very bad example of how to do an IO library in a very slow and complex way. > [...] > I didn't realize you didn't need to do that with "easy" languages. What's so bad about doing something easy ? I like many things in C++ like RAII, but the significant overhead in time I have to invest just to fight the deficiencies (no module concept, no ABI standard, a C++ standard but every C++ compiler seems to interpret it differently) I think to pros don't outweigh the cons. I would like C++ to be more like the D-language. Don't get me (all) wrong. C++ is a very good language, I like it (not anymore the way I liked it before I have used other languages), but I have the impression it gets bigger and bigger like a dinosaur. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin B. on 2 Jul 2010 05:41 Le Chaud Lapin wrote: > On Jun 28, 3:35 pm, "Martin B." <0xCDCDC...(a)gmx.at> wrote: >> If I'm building a webapplication, I'll want the Python engineer. (...) >> >> If I'm building a numerical processing tool, I'll want the C++ engineer. >> (...) >> >> Note that I want an engineer in both cases, not just someone who calls >> herself programmer and hacks stuff together equivalent to someone using >> duct tape to build a house. > > From what I have seen, there seems to be a correlation between choice > of language and skill as engineer. (...) > > C++ has a reputation as being difficult, and some people, as a rule, > will try to avoid anything that is difficult, (...) > >> C++ is a good language with too many warts. We as C++ engineers should >> not be so foolish as to look down on other people just because they are >> proficient in something else. > > I will never look down on someone simply people they choose Ruby over C > ++. I started in BASIC, and liked it. There has to be aggravating There may be some truth in the statement that someone who's able to do decent C++ can't be that bad an engineer/programmer/technician because it's bloody difficult. :-) (And, yes, I do think it is difficult to get halfway right.) > circumstances that are a reflection of the underlying reason for which > the language was chosen: > > Let's say that a group of engineers create a system that is: > > 1. Riddled with undeterministic resource deallocation problems and > memory leaks... > 2. Filled with so-called "impedance" mismatches because of disregard > for type, requiring weird "impedance converters"... > 3. Massively bloated... > 4. Massively slow... > 5. Massively heterogeneous...[a sprawling labryinth of every IT > acronym from past 10 years] > (...) > > ~and~ > That's certainly a lot of ~and~s :-) > ...the problems would not have existed if one language, instead of > many, had been employed, > > ~and~ > > ...the optimal language, given the problems created above, would have > been C++, > I think this is an extremely hypothetical situation. C++ may be good at a lot of things, but solving heterogeneous complexity isn't among them I think. (neither is any other *language* - even if all components were written in Java (performance aside) the complexity would still be the same) > ~and~ > (...) > "Hey, we are having memory issues with our system. It runs of of > memory after 4 days. We ordered and extra 8GB of RAM, but then it ran > out in 8 days instead of 4. Could you help?" > There are too many C++ applications that will exhibit exactly this behaviour. Especially ones that started off as short-running tools and were then converted to "a service". > ~and~ > (...) > ...then yes, I frown upon this, as it stops becoming engineering and > more an exercise in obnoxiousness. > Indeed it would. I just think it's got nothing to do with C++. You can create obnoxiousness in any (mixture of) language(s) and I don't see how C++ makes this any harder. cheers, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach /Usenet on 2 Jul 2010 05:57
* nmm1(a)cam.ac.uk, on 01.07.2010 17:04: > In article<i0f1pv$864$1(a)news.eternal-september.org>, > Alf P. Steinbach /Usenet<alf.p.steinbach+usenet(a)gmail.com> wrote: >> * DeMarcus, on 27.06.2010 17:27: >>> >>> We also know that code we write today will compile also in five years. >>> Quick development of a language may be good in areas where software is >>> developed and thrown out in the same pace, but where you want an >>> application to live some years it's not fun to realize you can't make >>> changes to five year old code just because it won't compile due to some >>> CEO's business strategy decision. >> >> 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? Quoting about one of the examples discussed there: <quote> 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. </code> 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. ;-) [snip] > 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. Cheers, - Alf -- blog at <url: http://alfps.wordpress.com> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |