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: George Neuner on 3 Jul 2010 07:56 On Fri, 2 Jul 2010 15:19:09 CST, Mathias Gaunard <loufoque(a)gmail.com> wrote: >On Jul 1, 4:14 pm, n...(a)cam.ac.uk wrote: >> >> 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. > >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. Runtime generics (Lisp), coroutines (PL/I), closures (Lisp, PL/I and Haskell). Don't have a clue what Genstat might contribute. C++0x will have threads and poor excuses for anonymous functions, but it's still lacking real closures and runtime generics. YMMV. George -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 3 Jul 2010 07:55 Mathias Gaunard wrote: > On Jul 1, 4:14 pm, n...(a)cam.ac.uk wrote: > [...] > > To me, low-level access with very high abstraction possibilities > pretty much means "you can do whatever you want with it". The same applies to all languages, in some way you can do whatever you want. The point is how elegant it is and how much time do I need. Surely I can travel by car, but will that be faster than by plane ? Yes, depends on the car, the streets, traffic - but commonly not. Some points: In/with Standard C++ can you: - Emit code and compile on the fly - C++ scripting ? - Can you run it in the browser ? - Can you take a function as an argument and parse it's structure? - Can I interchange / directly call code written in other languages without writing C wrappers ? - Can I mix libraries written with different C++ compilers - Can I mix C++ code libraries compiled for different platforms - Can I write portable GUIs in C++ (e.g. with Qt but, isn't standard) - I want to write binary data, e.g. a set of integers. How can I do that, that every platform and C++ compiler can read it ? (no fixed size types with defined binary layout) - Can I initialize class member objects / values directly where they are defined. In the context of RAII then it would make sense if I could simply write class foo { int m = 88; } I can do that all in C++ (in some way), but I can't do it out of the box. > > [...] Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 3 Jul 2010 07:50 Andre Kaufmann 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. > > It supports all the features of functional languages like OCaml / ML / F# ? > > Does it support at least function currying ? This would be my opportunity to learn more. Could you provide a real-world example for the usage of function currying? I looked it up briefly, and there are only examples for example sake, nothing useful. No need to explain if you can provide a link. >> 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. For each and every structure? Unlike in Java, in C++ I write many more or less significant structures. Maybe a compromise - enable reflection only if a class is marked with an attribute? [snip] > 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 IMHO, this is outside of the scope of the language. While it may or may not require an amendment to the Standard, a special compiler/linker could handle the integration of header+library and then name it a "module". However, what would be really nice is something to make the pimlp idiom obsolete. :-D [snip] > > 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. What lacks is a good teaching method. At least I didn't have one and had to go through almost everything myself. Basic C++ concepts are not that hard to grasp, but you need someone to teach you which exactly those are ... now... I wonder what has become of rvalue-references and move semantics, as I have lost track back quite a while... Hope it has become more logical and simple. -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 3 Jul 2010 07:54 Alf P. Steinbach /Usenet wrote: > * 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? And did you? "checked_int.cpp:45: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)" With addition of #include <stdexcept> and one using directive (and also without is using the flag offered by the compiler), the code compiles with G++-4.5 and works even 6 years later. [snip] -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joshua Maurice on 3 Jul 2010 07:54
On Jul 2, 1:49 pm, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > Mathias Gaunard wrote: > > On Jun 30, 8:51 am, Daniel <danielapar...(a)gmail.com> wrote: > >> 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. It depends. Java, and from what I can quickly google C#, both handle Unicode about the same way. Both Unicode support appears to have been written in the good ole days of UCS-2 encoding. However, with the advent of the new Unicode standards, UCS-2 is insufficient. Java and C# both took the weasel way out and just hacked their UCS-2 encoding strings and renamed them as UTF-16 strings. Their "char" is no longer a Unicode code point, but a UTF-16 encoding unit. Java and C# do a lot better than C++ standard strings, which are all but worthless relative to std::vector<char> for proper Unicode handling. Let's look at possible operations one might want to do with Unicode strings: - Read and write strings to and from files and other data sources and sinks. C++, Java, and C# do well here. No manipulation or interpretation is required. The string is just a collection of bytes (or other opaque encoding units). - Normalize UTF-8, UTF-16, and UTF-32 strings portable for collation, and portable collation. Standard C++ (including C++0x as far as I know) simply does not support portable collation or normalization. Java and C#, as far as I can tell, do a pretty good job here. - Convert strings portably from some encoding to some other encoding. Standard C++ (including C++0x as far as I know) simply does not support portable translation between encodings. Java and C#, as far as I can tell, do a pretty good job here. - Various forms of find, substring, and concatenation, including splitting, regular expressions, etc. Standard C++ (including C++0x), Java, and C# do not support this well at all. C++ because it lacks any understanding of Unicode. Java and C# do a lot better, but are still much less than satisfactory because they're inherently UCS-2 masquerading as UTF-16. (The C++ ICU also falls prone to these problems: it's a UCS-2 encoding "spruced up" to be UTF-16.) It's up to the programmer to actually track Unicode code point boundaries. All indexing and string substring-ing is done by UTF-16 encoding unit, not by Unicode code point. It's quite easy to chop a surrogate pair in half, or do a bad substring because the code does substring by UTF-16 encoding units but the intent was to do substring by Unicode code points. (There's also the problem that C++ ICU is incredibly slow out-of-the- box. My company had to modify it to remove the virtual function calls per UTF-16 encoding point to get decent performance.) There's also the point that C++ ICU, Java, and C# force an encoding on you, UTF-16, which may not be optimal for your data. UTF-8 tends to outperform UTF-16 for most Latin-based languages in terms of memory footprint, and thus also execution time. Preferably the string abstraction would be independent of internal encoding of UTF-8, UTF-16, and UTF-32, (and perhaps each such string encoding would have a different string of different type in the programming language type system). Then there's also the issue of grapheme clusters, aka user perceived characters, which none of standard C++, Java, and C# even attempt to handle (as far as I know). (Ex: encoding Latin letter e with accent acute, �, can be done with a precomposed form, aka a single Unicode code point, or it can be "encoded" as the Unicode code point Latin letter e followed by the Unicode code point combining character accent acute.) A big problem here is that grapheme cluster identification is locale dependent. Most times, when performing substring operations by number of "characters", such as inputted by the user with a GUI (which is a common operation in my company's product), the usual intent is for the substring indexes to be grapheme clusters, not Unicode code points, and most certainly not UTF-16 encoding units. (Substring-ing a string by user given indexes all too commonly does a substring of indexes of UTF-16 encoding units. This can result in split surrogate pairs - an invalid string, split grapheme clusters - a string leading with a combining character, aka invalid, and otherwise unexpected substring-ing output from the perspective of the user.) IMHO, any good Unicode string abstraction should provide for indexing, iteration, and substring-ing based on encoding units, based on Unicode code points, and based on grapheme clusters. (Word iteration would be nice too.) I know of no standard programming language string which actually has that in a usable form. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |