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: Le Chaud Lapin on 4 Jul 2010 07:02 On Jul 4, 3:43 am, Dragan Milenkovic <dra...(a)plusplus.rs> wrote: > Le Chaud Lapin wrote: > Hm... but are you saying that people should walk the hardest path > in order to earn a proper label? If one has the attitude of wanting > "to know what's really going on", one will be much more involved > whatever language chosen. And the path will be much easier and > gains greater if one is open minded and learns many languages. > Hard work vs proper work. "I want to know" == a good engineer. I am saying that, given two subjects, S1 and S2, if one has the choice to learn both, one might choose whichever, after learning, allows a scope of understanding that is a superset of the other. Knowing Java, well, facilitates understanding of many concepts in C++. Knowing C++, well, not only facilitates understanding of almost all concepts in Java, but one might begin to write a Java interpreter in C+ +. As I have said before, it is not really possible to understand C++ well and not have a good understanding of a large number of parasitic concepts that are the foundations of software engineering. > I will only agree that understanding C++ gives a unique and invaluable > perspective. Notice how I used "understanding" instead of "learning". > You may learn as much as you like, but how will you understand > any concepts other than the ones you use to solve your problems > if not by solving a few problems in Java (maybe doing some EE), Python, > Lisp, Haskel, etc? So, if we are saying that there the problem domains are separate from the languages employed, then I would say that it is rare that I find myself in the position where I am obstructed by C++ while attacking a problem. C++, more than any other language, "gets out of my way" so I can solve the problem. I cannot say the same for other languages. For example, in my current project, I have: 1. Code that manipulates memory-mapped I/O registers. 2. Device driver code with kernel-mode primitives. 3. Several, miniature parsers/interpreters of other languages. 4. Full blown multi-threadeding code with generalized synchronization. 5. Ability to launch other executables with tight control over run- time. 6. Fast signal processing. 7. Fast string processing. 8. Database and caching. 9. Recursion. 10. Dynamic swapping of member functions in live objects. 11. Compactness. 12. Generalized serialization [no versioning though]. 13. 99.7% portability [to multiple platforms, not just the one prescribed, like Java]. What other language allows all of this without the help of a companion language? -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 5 Jul 2010 02:07 Mathias Gaunard wrote: > On Jul 3, 1:29 am, Walter Bright <newshou...(a)digitalmars.com> wrote: >> 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. > > Nothing prevents you from restricting yourself to a subset of C++ > where all data is immutable and all functions pure. That's true, except that there is absolutely no help from the C++ compiler at all for this. It's like K&R style C, where there was no checking of the types of function arguments. Sure, you could get it right by carefully doing the checking by hand, but adding in function prototypes was a HUGE win. For example, let's say you have: virtual int my_pure_function(struct S *s); And your code that calls my_pure_function relies on it being pure, and that s points to a transitively immutable data structure. How do you know the function actually is pure, without going through every line of code in it, and every line of code in every function it calls, all the way to the bottom? Now another fellow on your team adds a global state dependency somewhere deep in that call hierarchy. How are you to know? Suppose someone else derives and overrides my_pure_function with an impure one? How are you to stop that? What if, between calls, someone modifies something s is transitively pointing to? Because of this, I suspect that trying to use purity and immutability purely by convention is doomed to failure. (And also, since the compiler cannot know about its purity and immutability, it also cannot take any advantage of that information to produce better code. The compiler cannot even cache pointer to const values.) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joshua Maurice on 5 Jul 2010 02:12 On Jul 4, 10:41 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > On 04.07.2010 00:50, Dragan Milenkovic wrote: > > However, what would be really nice is something to make > > the pimlp idiom obsolete. :-D > > Yep, a module concept is IMHO badly needed in C++. Unfortunately it has > been removed from the first C++0x proposals. Can you point at any proposals or ideas? I'm not sure how "modules" would remove the need for pimpl. pimpl is an idiom whose goal is to remove headers from headers. This allows a correct incremental build to skip larger proportions of the build because there are less file dependencies. I don't see an intuitive way to have backwards compatibility, 'not require pimpl', and achieve this 'closer to minimal' incremental build. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ian Collins on 5 Jul 2010 04:06 On 07/ 4/10 08:48 PM, Jerry Stuckle wrote: > Andre Kaufmann wrote: > >> - Can I mix libraries written with different C++ compilers > > Can you do this in ANY language? C. Otherwise there would only be one compiler per platform! -- Ian Collins [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jens Schmidt on 5 Jul 2010 04:06
Andre Kaufmann wrote: > We had a lot of trouble adding Unicode support to our C++ applications. > To be binary compatible we used UTF8 for transportation and internally > used UTF16 where possible. But it happened more than once that multiple > conversions (text / xml / binary etc.) that we missed to convert the > characters at one location appropriately. Such bugs where quite hard to > find and we are not sure if we found them all already. > > Besides the subtle bugs caused by functions dealing with character > pointers and number of characters directly. There are rumors of C++ being better because of static type checking. :-) Is there any project or whatever to use that for Unicode support? Like having different types for utf8_string, ucs32_string, unicode_character (a group of base character with accents), together with useful operations and conversions? Maybe even url_encoded_string, html_encoded_string, xml_encoded_string and sql_encoded_string to prevent problems like cross site scripting and SQL injection. -- Greetings, Jens Schmidt [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |