- A "better" C++ - 16 Updates
- A quick C++11 initializer list question (for set) - 4 Updates
- A "better" C++ - 3 Updates
- boost::static_visitor - 1 Update
- Deep copying - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Aug 19 08:46AM Consider this quote from Rob Pike, one of the developers of the Go programming language, which he gave in a speech in 2012: "Back around September 2007, I was doing some minor but central work on an enormous Google C++ program, one you've all interacted with, and my compilations were taking about 45 minutes on our huge distributed compile cluster. An announcement came around that there was going to be a talk presented by a couple of Google employees serving on the C++ standards committee. They were going to tell us what was coming in C++11. In the span of an hour at that talk we heard about something like 35 new features that were being planned. At this point I asked myself a question: Did the C++ committee really believe that what was wrong with C++ was that it didn't have enough features?" I'm really wondering what exactly he's suggesting there. But this is quite indicative of a rather long-running common trend. It was so in 1995, and it is still so in 2015: People just love to hate C++, and to try to create a "better" C++. They always find millions of faults in C++, and then try to create a better version with all the bad things removed, and then they pat themselves in the back for having created a language that's so much better. Of course the first thing to go is templates. Because, you know, templates are evil and stuff. And thus you have no generic data containers and no generic algorithms, and you go back to the days of C (or, as is the case with Go, back to the 90's Java, where containers have no type-safety to speak of, and you have to rely on unsafe downcasting). Of course since generic data containers are too useful to not have them, they eventually end up implementing a limited form of templates just for that purpose (which is, of course, "better" than templates. Because reasons. Perhaps because they are not called "templates", as that word is evil.) And the other thing that also obviously needs to go is multiple inheritance. Because, you know, MI is evil and scary, and an invention of the devil. But since multiple inheritance is so fundamental to OO programming, they can't remove it completely, so they provide a crippled version of it, where only one base class can have method implementations and member variables. (Which, of course, means that if an "interface" would benefit from a default implementation, you are out of luck; you'll have to resort to code repetition.) This half-ass implementation is, obviously, "better" than MI. Because reasons. (And again, because it's not named "multiple inheritance", even though it really is. That name is evil, so if we avoid it, then we are A-ok.) Of course in our "better" C++ objects can only be allocated dynamically. Because that allows garbage collection and stuff. That's nice. Except for the fact that memory is not the only resource that a class could allocate (other common examples are file handles and sockets.) Thus we end up with a C-like language where you have to manually release those other resources or they may be leaked, just like memory in C. (Then of course they will provide limited automation eg. in the form of automatic destruction at the end of a code block. Which you usually have to remember to write explicitly anyway, and it can only be used within one single code block and doesn't work with shared objects which may be destroyed somewhere else entirely. But it's still better than C++! That's the most important part.) Then of course you have some other more minor issues with refence-only objects (such as it being more difficult to swap the contents of the objects), but those are not important. And we don't mind that dynamically allocated objects tend to consume more memory. RAM is cheap, just buy more of it. And our "better" C++ compiling ten times faster than C++ is always something to brag about. Yet, somehow C++ persists. There have been probably at least two dozens of "better" C++'s during the last 20 years. A couple of them have been moderately successful, the vast majority of them have been forgotten. But they are still better than C++, dammit! --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| "Miquel van Smoorenburg" <miquels@netscum.invalid>: Aug 19 09:11AM In article <mr1fpd$30ur$1@adenine.netfront.net>, >But this is quite indicative of a rather long-running common trend. >It was so in 1995, and it is still so in 2015: People just love to hate >C++, and to try to create a "better" C++. https://www.rust-lang.org/ Mike. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 19 03:34AM -0700 On Wednesday, 19 August 2015 11:46:50 UTC+3, Juha Nieminen wrote: > But this is quite indicative of a rather long-running common trend. > It was so in 1995, and it is still so in 2015: People just love to hate > C++, and to try to create a "better" C++. It means that C++ is tremendously inspiring programming language. ;-) We ourselves create better C++ as well. We just do it differently by simply using individual favorite subset of C++ and avoiding individual disliked subset of C++. You must admit that it takes considerable amount of time to find out what details you like of C++ and what you don't and then to cut it into useful shape for your purposes like that. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 19 01:28PM > In 1995, C++95 was a different language. It was still > immature. C++14 is better than C++95, maybe even better > than C. Was there any time in history where C++ was actually worse than C? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| scott@slp53.sl.home (Scott Lurndal): Aug 19 02:18PM >myself a question: Did the C++ committee really believe that what was >wrong with C++ was that it didn't have enough features?" >I'm really wondering what exactly he's suggesting there. Rob has a long history in the Unix world (e.g. SAM), and I tend to agree with him on this point - "Did the C++ committee really believe that what was wrong with C++ was that it didn't have enough features?" |
| Bo Persson <bop@gmb.dk>: Aug 19 05:30PM +0200 On 2015-08-19 15:49, Stefan Ram wrote: > did not yet know how to write exception-safe code or did not > care. And even today, C++ is slower than C in the »programming > language shootout« (the last time I looked it up). Do you have any results newer than 2003? http://dada.perl.it/shootout/ Bo Persson |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 19 12:01PM -0500 Juha Nieminen <nospam@thanks.invalid> wrote in news:mr1fpd$30ur$1 > programming language, which he gave in a speech in 2012: > "Did the C++ committee really believe that what was > wrong with C++ was that it didn't have enough features?" Adding new features is about the only thing which can be done to a programming language without breaking back-compatibility. So that's the only thing the C++ committee could really do, regardless of what they believed in. Cheers Paavo |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 19 07:03PM +0200 On 19.08.15 10.46, Juha Nieminen wrote: [...] > of "better" C++'s during the last 20 years. A couple of them have been > moderately successful, the vast majority of them have been forgotten. > But they are still better than C++, dammit! :-)) I agree with you mostly. But I have to admit that implementing type erasure is quite inconvenient in C++, although it is an efficient solution in many cases. Of course, you can write your type independent base class and wrap it with a type safe wrapper that does the downcasts. But this is quite much of work every time and also error prone to some degree. And well, the iostream API is really crap. It looks mainly like a demonstration of operator overloading in the early 90's. But I still like C++ and especially the STL containers. RAII is really helpful, and as long as you avoid to deal with raw pointers (including char*) the code is almost as safe as in managed languages with more metadata. Looking into the future I think that the absence of a meta language between the source and the binary could be a problem for C++. The time of the homogenous and mainly compatible x86/x64 architecture are over. And C++ source code distributions are unacceptable for several reasons. First of all Maintainability of the installation procedure. Many CPU features are unused most of the time because of this restrictions. A JIT compiler in contrast could utilize almost any feature of the target hardware. This is a points win for JIT languages. So I think there is a need for common standards above the operating system and hardware layer. Marcel |
| Lynn McGuire <lmc@winsim.com>: Aug 19 12:29PM -0500 On 8/19/2015 3:46 AM, Juha Nieminen wrote: > of "better" C++'s during the last 20 years. A couple of them have been > moderately successful, the vast majority of them have been forgotten. > But they are still better than C++, dammit! All I want from C++ is a standard window based user interface toolkit that I can find on any platform. And yes, wxWidgets ( https://www.wxwidgets.org/ ) is nice but until it is released on all platforms, not the answer. Lynn |
| "Öö Tiib" <ootiib@hot.ee>: Aug 19 10:52AM -0700 On Wednesday, 19 August 2015 20:30:13 UTC+3, Lynn McGuire wrote: > > But they are still better than C++, dammit! > All I want from C++ is a standard window based user interface toolkit that I can find on any platform. And yes, wxWidgets ( > https://www.wxwidgets.org/ ) is nice but until it is released on all platforms, not the answer. Qt framework, that is technically extending C++ (but adds way less semantic garbage than Objective-C++) works on all desktops + iOS and Android. If all you need are only GUI widgets then there are tons of other classes in Qt that you don't need. Just ignore those and all remains nice. |
| Ian Collins <ian-news@hotmail.com>: Aug 20 07:16AM +1200 Stefan Ram wrote: >>> than C. >> Was there any time in history where C++ was actually worse than C? > It depends on what one wants to do with it. Early C++ had destructors. If that had bee all it offered, it still would have been a better C! -- Ian Collins |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 19 09:31PM +0100 On Wed, 19 Aug 2015 08:46:39 +0000 (UTC) > myself a question: Did the C++ committee really believe that what was > wrong with C++ was that it didn't have enough features?" > I'm really wondering what exactly he's suggesting there. He is suggesting by implication that it did not need more features. It is a shame - having to acquire new knowledge can be uncomfortable - but unfortunately he was wrong: it did need them. It needed move semantics, variadic templates, syntax for inline anonymous functions (lambdas) and a memory model for multiple threads of execution. In consequence of the inclusion of these in C++11/14, C++11/14 has been a significant success. [snip] > limited form of templates just for that purpose (which is, of course, > "better" than templates. Because reasons. Perhaps because they are > not called "templates", as that word is evil.) C++ templates are a strange beast and I can understand people's aversion to them. They are almost unbuggable when used for compile-time programming. C++ can never match the macro systems of the homoiconic languages but the introduction of type classes (concepts) is essential and will be delivered, and combining that with an extension of constexpr for compile time computation would certainly help. Chris |
| woodbrian77@gmail.com: Aug 19 02:03PM -0700 On Wednesday, August 19, 2015 at 3:46:50 AM UTC-5, Juha Nieminen wrote: > myself a question: Did the C++ committee really believe that what was > wrong with C++ was that it didn't have enough features?" > I'm really wondering what exactly he's suggesting there. He's fighting for his own vision of things. I don't blame him for that. He has some ideas and has spent time working on them. Probably he's looking for some people to drop C++ and use Go. That's fine, but I don't think Go is perfect and people may find that C++ has advantages over it and encourage others to quit using Go. > faults in C++, and then try to create a better version with all the > bad things removed, and then they pat themselves in the back for having > created a language that's so much better. I find many faults with C++ to this day. > Yet, somehow C++ persists. There have been probably at least two dozens > of "better" C++'s during the last 20 years. A couple of them have been > moderately successful, the vast majority of them have been forgotten. It's normal part of business to try to knock off the king of the hill. Thankfully C++ keeps doing fine. Brian Ebenezer Enterprises - "We few, we happy few, we band of brothers." http://webEbenezer.net |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 19 11:30PM +0200 Le 19/08/2015 10:46, Juha Nieminen a écrit : > like 35 new features that were being planned. At this point I asked > myself a question: Did the C++ committee really believe that what was > wrong with C++ was that it didn't have enough features?" It is actually not the compilation time what is infuriating from this situation. No, not at all. It is the fact that in this newsgroup, when confronted with a piece of code nobody knows how to read it and the only advise is to.... compile it, of course. What does gcc say? There are so many variables and algorithms behind each symbol, token, in the C++ code that it is completely impossible to do it without a machine. For instance, the specifications for the interactions of classes and operator overloading and overload resolution go for PAGES and PAGES in the last edition of the C++ standard that I have read. You need to do a topological sort of the classes and other characteristics of the given types/objects. You need to have all those pages of specifications in your mind when making the overload resoluton. No wonder, even expert C++ programmers just *think* that they understood what piece of software will be called when writing their code, but some times you just did not saw an interaction between the types in some situations and you end calling the wrong overload. This type of problem is difficult to solve. Specially when appears after the guy that wrote that went away, and the whole system was running smoothly until this wrong overload appeared in this header file inclusion, in that new class that was added after the author went away, etc. Or worse, gcc changed its mind and what you wrote changed meaning or was deemed obsolete. C++ is a moving target and the upgrade of the compiler brings always new surprises. Mostly benign, yes, but not always... Yes, new features are nice to have and anyway, evverybody is *adding* stuff, writing new code etc. The committee also. And they do their job and write new specs. Is this justified? I wrote a clone of the STL in C. A generic clone, using C macros. Yes, everybody told me that doing that is impossible but actually... C macros can take you quite far. I added vectors, lists, hash tables (C++ added that shortly afterwards), implemented the visitor pattern, you have iterators, etc. All in C. This is an interesting fact. I repeat: Is this complexity justified? What is nice about C is that the risk of ambiguity is much reduced. C is much easier to debug and very stable. And please, there is no free lunch... C has its drawbacks too. |
| Christopher Pisz <nospam@notanaddress.com>: Aug 19 05:00PM -0500 On 8/19/2015 4:30 PM, jacobnavia wrote: > What is nice about C is that the risk of ambiguity is much reduced. C is > much easier to debug and very stable. > And please, there is no free lunch... C has its drawbacks too. Because debugging C macros is even more fun... -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 20 12:03AM +0200 Le 19/08/2015 22:31, Chris Vine a écrit : > homoiconic languages but the introduction of type classes (concepts) is > essential and will be delivered, and combining that with an extension of > constexpr for compile time computation would certainly help. That is a big step in the wrong direction. That means that a new "concepts" hierarchy is created that complexifies the compiler yet a bit more. What is needed is a programming language for types that is event-driven. Instead of putting everything in the compiler, you put the decisions back to the people that know what they are doing: The programmers. You open up the compiler and standardize its compile-time environment. You can write programs in the meta-language and debug them with the compiler debugger. And what is this "meta-language"? Well obviously... C. One of the advantages of using that language for the meta-language is that all C++ programmers know it. :-) The compiler is a stream of tokens, symbols, and grammatical EVENTS. Remember GUI programming that brought this event-driven programming, where you just sub-class a feature and add your stuff to it. When, for instance, an event like "Function begin" is detected by the stream reader (gcc/msvc/whatever) , a C routine is called that the user specifies. It can access to all compiler data in all active scopes at the point of call. This compile time function, written in C++ can generate C++ code that is inserted at that point, or injected later in the token stream. Or it can directly call a set of APIs to do things like add a local variable, or create a new data type. This would be *really* something new. The list of compiler events is fixed, and the compiler provides a standardized API. --> Function/Method entry or exit --> Statement begin or end --> Function call and others. This way you can also implement team POLICIES that are explicitely formulated. The templates offer a programming language but it is a very cumbersome and difficult language. Much better would be writing meta-programs in C, with all the information about the source code that you need to adapt the library template into a specific situation. Of course there are a myriad of problems that could arise, like security of the compiler (the OS can be taken down by a device driver, as we all know), debugging of meta-programs, specifying too much environment, etc. For instance you can sub-class the syntax error event. Then you can write whatever you want between some markers that you define and C++ can be outdone by writing code that is in some language some programmer wrote. That would be worst than the templates that we have now! I am aware of those dangers, but, as always, with more power to the programmer comes more possibilities for catastrophic errors. This idea means that each C/C++ programmer could just subclass the compiler itself and adapt the language to his/her needs directly. If the interface is restricted and standardized, it would be much safer to use. C++ reloaded. :-) P.S. Why C? Because when writing meta-programs we do not have meta-classes of types. Maybe they could be added later, when we start screwing everything up again. |
| JiiPee <no@notvalid.com>: Aug 19 09:49PM +0100 I have all these books and read most of it, but this one cannot find on what page it is. So maybe somebody can help. I have this struct: struct Coordinate { int x; // row int y; // column }; and then if I do: Coordinate c; c = {2,7}; it correctly and as expected sets x and y to 2,7 for c. But am interested to know what happens here exactly. My guess is that it creates a temporary Coordinate object like this: Coordinate temp{2,7}; and then does a copy: c = temp; Because Coordinate does not have a inilizer list constructor and nor a normal constructor Coordinate(int, int) it just sets the members to 2 and 7 in that order. I am right? |
| red floyd <no.spam@its.invalid>: Aug 19 02:14PM -0700 On 8/19/2015 1:49 PM, JiiPee wrote: > Because Coordinate does not have a inilizer list constructor and nor a > normal constructor Coordinate(int, int) it just sets the members to 2 > and 7 in that order. I am right? Isn't this just C-style struct initialization? |
| Melzzzzz <mel@zzzzz.com>: Aug 19 11:21PM +0200 On Wed, 19 Aug 2015 14:14:26 -0700 > > nor a normal constructor Coordinate(int, int) it just sets the > > members to 2 and 7 in that order. I am right? > Isn't this just C-style struct initialization? It looks like assignment. |
| JiiPee <no@notvalid.com>: Aug 19 10:49PM +0100 On 19/08/2015 22:14, red floyd wrote: > Isn't this just C-style struct initialization? I don't think it is (its not an initialization, its an assignment). And for example: class Coordinate2 { int x; // row int y; // column public: Coordinate2(int j, int l) {} }; Coordinate2 o{4,4}; o = { 3,4 }; this works. But if you take out the constructor Coordinate2(int j, int l) {} then it does not compile. So it cannot do it for private members, but if x is public then works without a constructor. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 19 11:47AM >Consider this quote from Rob Pike, one of the developers of the Go ... >myself a question: Did the C++ committee really believe that what was >wrong with C++ was that it didn't have enough features?" The benefits might outweight the cost of enlarging the language in this case. >I'm really wondering what exactly he's suggesting there. Are you also wondering what Bjarne Stroustrup was suggesting, when he wrote: |C++ is already too large and complicated for our taste in this very newsgroup here in 1992? >It was so in 1995, and it is still so in 2015: People just love to hate >C++, In 1995, C++95 was a different language. It was still immature. C++14 is better than C++95, maybe even better than C. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 19 01:49PM >> immature. C++14 is better than C++95, maybe even better >> than C. >Was there any time in history where C++ was actually worse than C? It depends on what one wants to do with it. Early C++ did not yet have the STL or possibly not even it's own string class, and when exceptions first came up, people did not yet know how to write exception-safe code or did not care. And even today, C++ is slower than C in the »programming language shootout« (the last time I looked it up). |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 19 03:46PM >>care. And even today, C++ is slower than C in the »programming >>language shootout« (the last time I looked it up). >Do you have any results newer than 2003? I can't remember the date of my last visit and I can't remember possible dates given on that page. |
| Christopher Pisz <nospam@notanaddress.com>: Aug 19 10:15AM -0500 On 8/18/2015 5:07 PM, Öö Tiib wrote: > // handle windows api error ... > } > It might do the trick. ;) You the man! Works great. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Paul <pepstein5@gmail.com>: Aug 19 12:34AM -0700 A question asked in a job interview on deep copying is available here: http://www.careercup.com/question?id=6304195600711680 I will repeat it here: BEGIN QUOTE Write a function called deepCopy that takes an object and creates a deep copy of it. var newObj = deepCopy(obj); (can't use JSON, can't use prototype) END QUOTE I realise that this was not intended as a c++ question, but I can't see a way to do this in c++ because of the huge generality of the question, even though I have a basic understanding of deep copying. Can anyone help me get an answer in c++ (or help me understand the answers that are already provided.)? Below is the URL that I use to understand deep copying. If you feel that there is anything wrong or incomplete about it, please comment so that I am not misled. I understand that this is intended to cover earlier versions of c++. I'm just trying to understand the basics, rather than worrying about c++ 11 improvements. Clearly, it's not intended to be c++ 11. For example, 0 is used in place of nullptr. http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/ Thank you very much for your help, Paul |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment