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: joe on 5 Jul 2010 21:48 Andre Kaufmann wrote: > > Agreed, C# and Java strings are not perfect, but better than C++ > standard strings regarding Unicode. I think C# has been influenced by > Windows Unicode support. > What is wrong with fixed-width Unicode (UCS-2 or UCS-4)? If someone has put those out in the dumpster, then I'm a garbage-picker! You make it sound like fixed-width is evil. Do tell what you think/are thinking! -- [ 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 5 Jul 2010 22:08 On Jul 5, 2:06 pm, Jens Schmidt <Jens.Schmidt...(a)gmx.de> wrote: > Andre Kaufmann wrote: > > 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. Not familiar with any such projects, but I had my "make a good string class experience" about a year ago where I bit the bullet and read all essential documents at: http://site.icu-project.org/ http://www.unicode.org/ During this (somewhat painful) experience, I concluded that, in the majority of C++ coding situations, it is best to have a single, non- templated string type, and _yield_ from objects of that type various other objects as needed. The string class should be "fat", having a rich set of operations, essentially those already determined by ICU/UNICODE. For example, it should be possible to transliterate from a source string to a target string with very little programmer effort. On a controversial note, I also concluded that it is best to let the string objects be entirely responsible for their collation behavior. IOW, no compile-time fiddling with case/no-case stuff, varied languages. Put everything that is required in the string objects themselves, at run-time. This eliminates the problem of unmitigated, forced propagation of type distinction through out the type system, where, for example, a templated container that would have normally accommodated only one string type must now accommodate all the possible string types, causing a combinatorial explosion in the type space. The decision to use a fat string class has been surprisingly liberating. :D I exercised extreme ingenuity and originality in naming my string class... "String" -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 5 Jul 2010 22:08 Walter Bright wrote: [snip] > 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.) GCC provides attributes "pure" and "const" which indeed allow taking advantage. However, it seems that it doesn't verify the correctness of implementation. I don't know how easy such a feature could be added (my guess is not too hard), and whether it would be beneficial. -- 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 5 Jul 2010 22:10 Andre Kaufmann wrote: > Jerry Stuckle wrote: >> Andre Kaufmann wrote: >>> Mathias Gaunard wrote: >>>> On Jul 1, 4:14 pm, n...(a)cam.ac.uk wrote: >> [...] >> >>> - Emit code and compile on the fly - C++ scripting ? >> Who cares? > > Is that a typical "default answer" ? > >> It's an entirely different model. > > Many languages offer that. E.g. C#. > And the model is not different. Why can't I simply take a C++ code like > > double value = sin(x)/x; > > (the formula has been entered in an edit box) > > compile it in the background and let it execute instead of interpret it. > Wouldn't that be faster than just interpreting the formula ? > I can exactly do that in C#. Doesn't boost::python offer such functionality? I didn't exactly compile the code in the background, but I did write plugins and it was very easy. It works the both ways. How is security implemented in the mentioned C# feature? I'm guessing it wouldn't let just any code compile and/or execute. > Or take a complex regular expression. Why can't I simply compile it to > code. In C# I can do that. > >>> - Can you take a function as an argument and parse it's structure? >> Who cares? That's not the intent of C++. > > Why do so many try to do/simulate that with C++ meta template programming ? The two are different. With meta programming you can get compile-time diagnostics. Can you have this done in any other language? >>> - Can I interchange / directly call code written in other languages >>> without writing C wrappers ? Again boost::python... a place that ain't no got no room for wrappers. [snip] >>> - Can I mix libraries written with different C++ compilers >> Can you do this in ANY language? Isn't this more ABI related? I don't think C++ itself imposes such limitation. Unfortunately, I'm not familiar with ABI-related future improvements. [snip] >>> - Can I mix C++ code libraries compiled for different platforms >> Can you do this in ANY language? > > C# for example. Hm... Do you ever _really_ _need_ to do this? The only case I can think of is when there is only a library for one platform and no way and no source to build it for another. But this requires a kind of virtual machine or such environment, which is not the goal of C++. Should such need come, I would just use Java... > >>> - Can I write portable GUIs in C++ (e.g. with Qt but, isn't standard) >> Can you do this in ANY language? > > Better than in C++. Because after quite a few generations of failures they finally got it right... Think AWT, MFC... or did they get it right? I don't know... [snip] > >>> - Can I initialize class member objects / values directly where >>> they are defined. [snip] >> Nope, that's what constructors are for. > > Do you need are more detailed explanation about the advantages ? > > Yes I want to call the constructor of the value where I define it -> > RAII - not have to write it multiple times in different constructors. > Though C++0x addresses this problem somewhat with delegating constructors. I don't think it's "somewhat". IMHO, they really hit the nail with that one. private: foo() : value1(10), value2(10), value3(10) {} public: foo(int a) : foo() {} > Additionally static values do use this initialization scheme already: > > class a > { > static int value; > }; > > int a::value = 0; > > Huh ? No constructor involved ? And why would there be a constructor involved with a static value? I don't think that those two cases can be compared. >> [...] >> But virtually everything you want either shows no understanding of the > > Sound like you described yourself. > >> language itself, or has nothing to do with the language itself. >> Sounds like you want Java instead. > > Nope. > > I either want the D-Language or C# with RAII. Well, maybe we should lobby that C# gets a RAII? In the end, it is only one feature compared to many missing ones of C++. Anyway, to cut the silly talk... C++ has some shortcomings, most of them coming as a legacy, but these presented here are more ABI and library/environment (don't know how else to name it) related. -- 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 5 Jul 2010 22:11
Le Chaud Lapin wrote: > 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. This is true and I agree. But if I'm not mistaken, this all started by your statement that one should get there by simply learning C++. I'm saying that one will not be able to do it this way, unless being involved in a really, really, really great project with a good design and experienced team-mates. And even then, IMHO, one is better learning many languages; it will improve his C++ kung fu. > >> 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]. Nice project and a great opportunity for people to improve! But I would have to say that these are features; and could be designed both good or bad. You can (although I guess that you don't and no one should) implement all of those and still not have ever used std::shared_ptr, meta programming, etc. May I call it: what vs. how? You write from the perspective of a person that has a high understanding of C++. However, the argument was (again - unless I'm mistaken) about a person that is on the start of the journey. If I hadn't chosen a multilingual path, I would be quite a few years behind with the learning curve. Or let's agree that we disagree. I have just stated my opinion and my experience in hope it would help someone. -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |