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 30 Jun 2010 23:24 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 doesn't do OO well. It's not any worse than all popular OO languages that also lack multi- methods. At least C++ offers alternatives. > 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 doesn't quite fit in the language (how would it work with templates unless they could be instantiated at runtime?). The compile-time reflection is also quite limited in that you can test whether a member exists or an expression is valid, but you cannot iterate members. There is not an universal way to iterate members anyway, and the only application I can think of that really needs this is serialization. You can add this info pretty easily in any case with a couple of macros. > It's not elegent. A matter of taste; a lot of people find it so. > Having both .h's and .cpp's > seems redundant, both contain implementation. But it gives great flexibility about the building process. > There's no date clss in > the standard library (second most useful class after string.) Not the end of the world. Also there is one in Boost proposed for TR2. > Using > unicode is painful. No programming language does this right anyway. And it's only painful because there is no standard way to do it, and that is because no one has come up with a good enough way yet. (Note: I'm the author of a Unicode library proposed to Boost) > 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? > It seems to be > difficult even for experts to write good classes, witness the posts on > std::string. It's not particularly difficult to write good classes. What is difficult is to write classes that fits the needs of everyone; and in C ++ more than in any other language the needs of everyone can be quite diverse. > It can be painful getting stuff to work. Libraries > often don't work, I tried using boost ublas, and band matrices don't > work. Yes, sometimes you have to read the manual and documentation, or even ask for help with things you don't understand. I didn't realize you didn't need to do that with "easy" languages. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Le Chaud Lapin on 30 Jun 2010 23:39 On Jun 30, 2:51 am, Daniel <danielapar...(a)gmail.com> wrote: > On Jun 27, 11:05 am, Francis Glassborow<francis.glassbo...(a)btinternet.com> 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. > > It _is_ hard and confusing :-) You're not seriously suggesting that > it isn't? Well, there are probably a lot of people in this group who think that it is neither hard nor confusing. I think perception of difficulty is influenced by period of exposure to C++. Many C++ fans were born during a "good period for knowing C++." I started learning C in 1988, and C++ in 1996. People who started programming significantly before then, say, in 1970, and significantly after, say, in 2005, might think C++ is hard. Those from 1970 might have learned FORTRAN, COBOL, had their honeymoon with PL/1 or Pascal. Then maybe Prolog, a few other languages, then C. But there comes a point where propensity for intensity and determination to focus wanes, and some of these people might have finally said, "Ok, enough is enough...C is good enough; it's my stopping point." Those from 2005 enters a world where the WWW is taken for granted. Anything that you might want to know that is known to man is just a few keystrokes away. State of the art compilers/interpreters in C++ and many other languages are free, online, readily downloadable [this is incredible IMO]. Computers are so cheap, many kids have several to themselves. An entry-level "engineering" job, with suprisingly-decent salary, can be had without a degree after spending maybe a few months with a $25.00US book. Now, in this forgiving environment, someone tells you that knowing how virtual functions work, or how to invoke assembly language from high- level language using _asm keyword, is good for you. Or maybe it's not just the language, but principles of data structures and algorithms disguised as language, like the red-black tree employed by STL set- like structures. One look and..."Yuck! I'm not learning that!" So what we have now is a core of engineers, in roughly a certain age bracket (there are many exceptions of course), who were born at the "right" time, and have earned the title of professional, making cool apps; and people born siginificantly earlier, who are near the end of their careers who might be amused at all the new activity, and people born significantly later who are saying, "This doesn't seem fair..there is so much to learn...where do I start?" But there is one caveat that makes the world of software engineering, in 2010, interesting...[see below] > The language is hard, but not hard in the sense of a functional > language, where understanding theory is required to understand the > language, and the effort taken to learn it has its rewards. Rather, > in C++ there's just a lot of scattered stuff you have to know to write > reliable code, from case conventions for constants, to notions of > exception safety, to details of memory management, to implications of > default generated constuctors and operators. I think it takes most > programmers a couple of years to pick this up. Even so, most C++ > programmers won't know the answers to most of the questions posted on > this newsgroup. Multiple "paradigms"? It doesn't do any of them > well. It doesn't do functional well. It doesn't do OO well. It > doesn't do reflection. It's not elegent. Having both .h's and .cpp's > seems redundant, both contain implementation. There's no date clss in > the standard library (second most useful class after string.) Using > unicode is painful. The std library is full of things that must have > at one time seemed like good ideas, like is and os. It seems to be > difficult even for experts to write good classes, witness the posts on > std::string. It can be painful getting stuff to work. Libraries > often don't work, I tried using boost ublas, and band matrices don't > work. [Hmm...I would have to disagree with not elegant, does not do OO well, .h/.cpp, etc. but...] What is so interesting about software engineering in 2010, and C++ in particular, is that we are in the very midst of figuring out "how things should be". Take your std::string class for example. You're right, it's a bit funky, and not what you might call UNICODE-ready. A couple of years ago, I tried to make a string class myself, and floundered, while a reader in this group amused himself at my obvious ignorance. :) I tried again a few months later, same thing. Then I tried again a year later, and now I have a String class that feels "right". This process of discovery is going on right now, not just with popular libraries like Boost, but in general. Take for example the current state of the art string class from International Components for Unicode (ICU): http://site.icu-project.org/ This premier string class has a member function, Ubool unicode_string::isBogus(); ....that tells whether the object is in a bogus state, and implicit violation of one of the most fundamental notions of C++, that the language itself should be used to prevent objects from assuming an inherently defective state. Note also that it uses UBool instead of bool. [I mention this, not to berate the work of ICU programmers, but to illustrate that we do not yet have a fully-cooked string class.] So the "regular set" of primitives in C++ have not yet been devised, despite STL, and I think we are extremely fortunate to be engineers at this particular point in time, to have the opportunity to find them, and C++ is the Big Green Light that says, "Go find them!" Unlike other popular languages before it, like COBOL, or after it, like Perl, C++ says, "Ok, we all know that most computers follow a von Neumann architecture more or less, and this is not going to change for the mainstream anytime soon. If you be an engineer, I am going to give you a language of liberation. I am going to give you a language that allows reachability to almost every conceivable point in the system space of software engineering. I am not going to tell you how to reach these points, of course, but I will allow them to be reached, with great facility, almost entirely dependent on your skill as an engineer." Of course, there are exceptions to this claim, like lack of lambda expressions, and more importantly, there is the assumption that the C+ + script will be compiled into a physical, von Neuman architecture, where the CPU itself is the agent of interpretation. But despite these relatively minor assumptions, C++, like no other language, allows reachability into the entire system space, from the primitive to the frighteningly complex. And that is why C++ is so interesting. It's a bit like taking armed fighters, where they can choose any weapons that they can carry, and throwing them on a battlefield, and letting each fighter fight to his best abilitity, dismemberment and death included. By contrast, other languages restrict which weapons can be used, restrict the types of enemy to be fought, and during every battle, the fighters are must be housed in a giant, roving tank, fighting the enemy indirectly using joysticks (Java interpreter). Wherever the fighters go, so must the tank (JVM or other interpreter), and when there is a special kind of monster that requires a special kind of stroke to be slain, it becomes hard, because the slayer, no matter how skilled, is stuck inside a tank. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Le Chaud Lapin on 30 Jun 2010 23:37 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. She's > much more likely to be effective in a heterogeneous environment, > probably she has done some other scripting languages as well. She might > also be a lot better and more disciplined when it comes to practises > such as unit testing etc. > > If I'm building a numerical processing tool, I'll want the C++ engineer. > She'll know how to use C++ or D or C to her advantage and she'll be more > aware of performance pitfalls. > > 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. Note that I am not saying that somone who knows Python is less of an engineer. Knowing Python is useful. But if Pythong was chosen to avoid C++...actually that still says nothing. It depends on what the engineer does after making the choice [see below]. C++ has a reputation as being difficult, and some people, as a rule, will try to avoid anything that is difficult, while still being a participant in whatever activity is under consideration, so there are a lot of people who have title of engineers, but the systems they make...ahem...let's just say if they were making airplanes, you would problably not want to be a passenger. :D > 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 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] 7. So unwieldly that programmer who wrote it must fiddle with it on weekly basis after deployment...[engineer becomes part programmer, part customer support representative because system is always crashing] 8. Lacking in structural integrity... 9. Expensive to maintain, requiring tools that check the tools that check the tools to see if the tools are working... ~and~ ....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++, ~and~ ....the original creators rejected C++ on the grounds that it was "too hard" or "prone to memory management problems", ~and~ ....after that fails, they come to C++ programmer and says something like... "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?" ~and~ .... the C++ programmer discovers that it is the very lack of determinism in the chosen language that is causing the problem ~and~ ....the original creators of system attempts to solve the (resource allocation) problems by gluing globs of C++ to their mismash of code, but only in the area where they want determinism, ~and~ ....this fiddle-with-it-as-you-go method fails because the system is already well beyond the boundaries of sound engineering principles, ~and~ ....the original creator disregard as untrue this last statement, ~and~ ....they want the C++ engineer to leave the realm of C++, enter the realm of [their favorite non-C++ language], and show them how to get the benefits of C++ without using C++... ....then yes, I frown upon this, as it stops becoming engineering and more an exercise in obnoxiousness. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Paavo Helde on 30 Jun 2010 23:50 Daniel <danielaparker(a)gmail.com> wrote in news:f5b45ab5-5b14-4502-92f2- fd3faad39f49(a)d8g2000yqf.googlegroups.com: > On Jun 27, 11:05 am, Francis Glassborow > <francis.glassbo...(a)btinternet.com> 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. >> > It _is_ hard and confusing :-) You're not seriously suggesting that > it isn't? Reworded, it is hard and entertaining ;-) [long rant about shortcomings of C++ snipped] Of course there are shortcomings, nobody is perfect! > But C++ is useful. It is useful when it is necessary to write low > level code. It is legacy. There is an existing base. Strangely, I find it most useful for writing high level code. Low level code could be done in C as well. What C++ adds is an ability to build abstractions, and layers of them, without sacrificing any efficiency, and to write high level code in terms of those abstractions. Of course this is hard, but it is doable, unlike in many other languages. Regards Paavo -- [ 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:04
In article <gqSdnRiVqZME277RnZ2dnUVZ8rednZ2d(a)bt.com>, Francis Glassborow <francis.glassborow(a)btinternet.com> wrote: >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. Er, Francis, you know better than that! To quote ISO/IEC Directives Part 2: Rules for the structure and drafting of International Standards: The objective of documents published by ISO and IEC is to define clear and unambiguous provisions in order to facilitate international trade and communication. To achieve this objective, the document shall * be as complete as necessary within the limits specified by its scope, * be consistent, clear and accurate, * take full account of the state of the art, * provide a framework for future technological development, * be comprehensible to qualified persons who have not participated in its preparation, and * take into account the principles for the drafting of documents. In particular, principles 1, 3, 4 and 5 all make it clear that you should NOT rely on hidden assumptions that are not part of the ones held by almost all the IT community. I am afraid that C++ doesn't do all that well compared with the other formal language standards I know (except, of course, compared to C). This thread demonstrates that fairly clearly. >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. I agree, though that's what most people do. But you know me, and you know that C is only about the 8th imperative language that I claim to know or have known extremely well. I am NOT a person who prefers to think in C - God forbid! Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |