- C++ is a complicated language? - 2 Updates
- Extended use of nullptr - 1 Update
- Bug in the C++ 2011 specifications - 16 Updates
- C++ Middleware Writer - 4 Updates
- Problem with const - 1 Update
- Extended use of nullptr - 1 Update
| David Brown <david.brown@hesbynett.no>: Aug 14 11:13PM +0200 On 14/08/16 23:01, Mr Flibble wrote: > I can only repeat my earlier reply: if you find C++ lambdas too > complicated then I suggest you use a different programming language. > /Flibble It is worth noting that in languages that have had lambdas for longer than C++, such as Python and Javascript, lambdas are a very popular way to handle events such as button presses. The don't handle every possibility, but for a good many common cases they work very well. So IMHO, using lambdas as the base for event systems in a new gui framework is a good idea, demonstrated by experience in other frameworks and other languages. |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 10:39PM +0200 Le 14/08/2016 à 22:10, Mr Flibble a écrit : > If you have a problem with C++ lambdas then I am sorry but modern C++ is > simply not your cup of tea so you should try another language. I am just insunuating very perfidiously your honor that the "old" signal/slot paradigm is a better idea for a windowing system as your extremely complicated syntax. It assumes the existence of a button OBJECT that sends signals to subscribers. This is the base of many windowing systems and is a well known paradigm. You did not show any code and I think that the new syntax doesn't bring anything new or innovative but does the same thing in a more complicated way. Specifically I asked what your new syntax brings for the application (in this case a windowing system). Please argue man, instead of throwing around completely empty sentences like <quote> modern C++ is simply not your cup of tea so you should try another language. <end quote> "Modern C++ is like that" you say. As the signal slot paradigm that is working since years perfectly is suddenly "old" and must be replaced by "modern" constructs that are smaller, and more complicated to read. You did NOT answer why this new construct is in any way better than the "old". The only thing that you said is that is an "old problem". Well yes, hanging code an events is the essence of event oriented programming, and that is in use since ages. And this is a typical case where this fanatism of the "new" and the piling up of new and newer stuff that nobody follows any more. I am still waiting for an answer: WHAT IS THE ADANTAGE of the new syntax in terms of software engineering? (Besides being more incomprehensible) Thanks in advance for your explanations. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 03:18AM +0100 On 14/08/2016 03:15, Daniel wrote: >> std::optional. > Different context, the context here is where "null" is a valid state of an > object. std::optional. /Flibble |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 09:09AM +0200 Le 14/08/2016 à 02:32, Mr Flibble a écrit : >> Minute 47 of the video. > Easy explanation: the clang guy is simply wrong. Well, if you know that he is "wrong" can you explain WHY is he wrong? Or he is wrong because some unknown compiler you are using seems to say otherwise? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 03:26PM +0200 On 14.08.2016 14:29, Mr Flibble wrote: > An lvalue can never be a null pointer constant. Are you sure that `S().x` is an lvalue? Let's check that assertion, using your own proof technique, what compilers say about it: struct S{ int x; }; auto main() -> int { S().x = 666; } <compilation> [C:\my\temp] > g++ foo.cpp foo.cpp: In function 'int main()': foo.cpp:5:11: error: using temporary as lvalue [-fpermissive] S().x = 666; ^ [C:\my\temp] > cl foo.cpp foo.cpp [C:\my\temp] > _ </compilation> Oh my, they disagree! What do you think the standard says about it? Cheers & hth., - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 04:35PM +0200 On 14.08.2016 15:51, Mr Flibble wrote: >> Are you sure that `S().x` is an lvalue? >> Let's check that assertion, using your own proof technique, what >> compilers say about it: [snip] > ... demented ... > According to the Standard it is an rvalue So, your assertion about lvalue turned out to be irrelevant: `S().x` is an rvalue, not an lvalue. > however it also has a *name*. Uhm? Cheers & hth., - Alf |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 10:52PM +0200 Le 14/08/2016 à 22:08, Chris Vine a écrit : > Every language has its corner cases. It is a necessary consequence of > writing rules. True. But most language programmers can identify those corner cases and answer a simple answer to them. Too many rules to learn but heart provoke languages that are obese. Obsesity is a consequence of a lack of restrain. > expressed is correct (although I thought your original appeal to > authority in the guise of "the chief developper of clang (sic)" somewhat > amusing). Yes the whole is very amusing. I get a kick with all that for sure. And that guy is a nobody of course. And the fact that he says (and a user in this discussion proved) that there is a problem with the rules it is of no importance since: > You are a long standing poster to this group perennially making posts > adverse to C++. Yes, I think the complexity of that language that I have to maintain is a horror. Fortunately it exists of course, I am not against c++ since it as source of revenue for me. But sometimes I post in this group because I see the whole boat go into such extremes that is... yes, amusing. That is the right word. That's fine, you have your axe to grind and you are > entitled to your opinion. C is your preferred language. Stick to it. Of course I will stick to it. There is no question about that. But at work I should maintain those horrors you see? I have to understand why that crashes now when I recompiled the code without changing anything. Then I *have* to know c++ and I start sometimes talks in this group. I even try to impromve my c++ skills by looking at c++ conferences, videos, etc. And I presented that case brought by the speaker for the clang group in that conference. Of course he is wrong, he is a nobody, and he is not a lead developer but a beginner saying nonsense. In any case that guy knows MUCH MORE c++ than me :-) jacob |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 09:28PM +0100 On Sun, 14 Aug 2016 20:58:24 +0200 jacob navia <jacob@jacob.remcomp.fr> wr > Let's make the compiler itself PROGRAMMABLE. Let's design a simpler > language but with a programmable compiler where it is easy to write > new constructs without complexifying the whole language. There is already a language group which will do that for you, namely the lisps. I prefer the scheme dialect, which has hygienic macros. It is there: instead of your talking, get coding. I will trade macros with you if you really want. C++ is not a homoiconic language, and it is pointless complexifying it to try to make it so. Neither for that matter is C, whose macro system is totally pathetic. C++ has to carry the C baggage with it, for better or for worse (mainly for worse). |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 13 12:19AM +0200 Le 12/08/2016 à 08:57, jacobnavia a écrit : > int main() { > f(S().n); > } Look I do not know c++ but anyway... I think in that language programs start in the "main" function. We start there then. We have a function call of an "f" function, where you have two possible alternatives: One that receives a void * (a pointer to "anything") and another that receives an "X", i.e. a structure that has only a constructor. This constructor receives an int as argument. To know what is being passed to "f" (data that will determine the one "f" being called) we have to simply evaluate the expression: S().n This looks like the constructor of "S" being called to make an "S", then using the result to acces its "n" member above. This is the default constructor because nowhere is a constructor for "S" in scope. And I suppose that the default constructor always initializes ints to zero. Then, the outcome of a call to an "S" constructor in this scope is fixed, since it is the default constructor: zero. The type of the expression is then the integer zero, an ambiguous value now, since can be a null pointer AND an integer. According to obscure rules that nobody really understands, an integer is an input for the constructor of "X" objects, and that can be used to build an "X", that is passed to the overloaded function in scope that prints X! I remember when I was young and naive, and started to read the rules for operator overloading in the c++ standard. They went for pages and pages of stuff like a topological sort of all classes in scope. Well they ARE C++ heads, that is for sure. But now we have since a long long time reached the level where nobody understands anything any more and a 12 line program suffices for provoking and big embarrased silence. Now, just out of curiosity... Where did I go wrong? Thanks |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 01:36AM +0200 Le 12/08/2016 à 08:57, jacobnavia a écrit : Please look at https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys In that talk, see the slide and discussion. Starts around minute 47 of the video |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 01:38AM +0200 Le 14/08/2016 à 01:24, Ian Collins a écrit : > clang++ -std=c++03 x.cc; ./a.out; clang++ --version > X! > clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) See the discussion of that in https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys Minute 47 of the video. |
| Manfred <mx2927@gmail.com>: Aug 14 05:23PM +0200 On 08/14/2016 01:06 AM, Ian Collins wrote: > On 08/14/16 10:44 AM, jacob navia wrote: >> Where did I went wrong? > There isn't any ambiguity, the constructor for X is the only fit. Agreed: the expression S().n has type int indeed. > If you change the constructor to be explicit (which it should be, no > matter what version of C++ you use), the code won't compile no matter > what version of C++ you specify. Therefore compilers which end up with Pointer! are wrong, and since they appear not to be irrelevant (my gcc always outputs X! by the way), this confirms the complexity of the language, IMHO. Meaning that the original cleanliness of the language risks to get polluted by newer "improvements" Regards |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 12 09:48PM +0100 > proclaiming, "The L-rd is upright; > He is my Rock, and there is no wickedness in Him." Psalms 92:12-15 > http://webEbenezer.net Brian, fuck off. /Flibble |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 02:10PM +0200 On 14.08.2016 09:12, Ian Collins wrote: >> Or he is wrong because some unknown compiler you are using seems to say >> otherwise? > We've already been over that. No, as I see it that's a blind assertion, an incorrect one. Jacob asks for a deduction from the official standard's rules, not examples of particular compilers' behaviors. And our inability to give him that tends to support his contention that the language, or at least the standard's way of describing the language, has become too complex. Cheers!, - Alf |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 12 11:49PM +0200 Le 12/08/2016 à 10:08, Öö Tiib a écrit : > It is unfortunately very similar with C compilers. An actual behavior > (defined or undefined) will change between versions and things stop > working. Yes, true. But I do not know how many orders of magnitude less than in c++, you will agree with me. C is VERY stable language, and software written in C stands the time test. A C beautifier program is still running in the lcc-win IDE, code written in the eighties. |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 12 11:58PM +0200 > I support law abiding citizens having guns Yes, you must live in the U.S.A. In that country, people kill themselves with their guns for nothing. Everyone has a gun and everyone is shooting around. A grand parent kills his grand daughter because he mistakenly thought it was an intruder. Mass shootings everywhere, they are the latest gun fad. Violence is destroying the basic assumptions about society but the shooting goes on and on. Yes, we should fight the shooting with... MORE GUNS. LAW ABIDING CITIZENS do not have guns in most civilized countries. Happily for us, we do not live near those "law abiding" citizens ready to shoot anyone that approaches. This sickness has contaminated the whole country and the shooting has increased, multiplied by the media and all people like you: > I support law abiding citizens having guns you said. Gun happy. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 13 12:40AM +0200 On 13.08.2016 00:19, jacobnavia wrote: > and a 12 line program suffices for provoking and big embarrased silence. > Now, just out of curiosity... > Where did I go wrong? Just a technicality: `S()` is not invoking a default constructor, because there isn't one, but is "value initialization", which reduces to zero-initalization in this case. So the outcome is as you described, just via a slightly different mechanism (unfortunately it does matter in some situations, more complexity...). The difference between C++ versions appears to be that this zero value can be regarded as a compile time integer 0, a "constant expression" 0 in C++11, but not in C++03, which has less smarts. IMO the same phenomenon, of too "smart" things, is going to hit us via appliances, the internet of things, in just some years. Watch for when your fridge is hacked by some silly teenagers who target everyone who buys a brand of beer that they don't like, via an attack vector provided by the extreme complexity of the fridge's OS. Cheers!, - Alf |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 10:42PM +0100 On Sun, 14 Aug 2016 23:17:40 +0200 > EVENTS where you can change the language by adding special syntax and > ad hoc syntax within an application context. I mentioned several > examples in my post. It is still compile time computation. I don't buy your examples at all, and I think you are just confusing yourself. This is not really a point about C++, even though you try to dress it as such: it is about a new method of generating object code at compile time. Prove me wrong: raise capital, found a start-up and make a lot of money. Begin with C, your preferred language. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 03:18PM +0100 On 14/08/2016 15:16, Rick C. Hodgin wrote: > Examine the generated assembly source code in non-optimized > mode. It will show you exactly what's happening, and what > is what. There won't be any assembly because the compilation fails (as it should). Use your brain mate. /Flibble |
| Melzzzzz <mel@zzzzz.com>: Aug 18 01:25AM +0200 On Wed, 17 Aug 2016 19:09:07 +0100 > Circular reasoning; typical of your deluded religious types trying > and failing to play the science card. > /Flibble Life certainly doesn't look designed... food chain at all... |
| David Brown <david.brown@hesbynett.no>: Aug 18 10:17AM +0200 > http://www.biologicinstitute.org/research > "Everyone agrees that life is full of systems and structures > that have an appearance of intelligent design. Sites like this have a great tendency to talk about what "everyone knows" or what scientists "disagree" on. It is almost invariably nonsense. To anyone who knows about biological systems, but is not blinded by preconceived ideas of how they came about, it is quite clear that they are /not/ the result of intelligent design. If there was a designer, then he (or she, if the term makes any sense) was - quite frankly - a bungling amateur. There is a lot of marvellous stuff in biology, but much of it is vastly over-complicated, full of mistakes, rushed "cut and paste" jobs with bits left over, sub-optimal systems, and so on. Take one of the "intelligent design" fans favourites - the human eye. The retina is connected on the wrong side, leading to a blind spot. The basic optics are more suited for use underwater. The colour detection is limited to a small patch in the centre (around the blind spot) and is far, far poorer than many other animals such as birds. It takes a vast proportion of the mammal brain to make sense of the poor quality image from our eyes, as compared to the brainpower needed for bird eyes or insect eyes. And it is highly prone to all sorts of defects, especially in the fine-tuning of genes for regulating short-sightedness and related problems - so that once the genes for short-sightedness stopped being a hinder to breeding, it has spread rapidly throughout humanity. As a school project, it would get a C-, since it works but is full of bugs, flaws, and missed opportunities. And the documentation is terrible (there is a mention of "eye for an eye", and "poke out your eyes if they offend", but very little on maintenance). Or look at DNA. Your DNA consists of several parts - instructions for creating proteins and running cells, the "recipe" for creating new members of the species, spacers and modifiers, leftovers, and junk. (Estimates of proportions change somewhat as we learn more.) Consider the leftovers - what use are they? Why should a human have the genes for making gills and a tail, which you have for a short time as an embryo? Why should a chicken have the genes for a complete set of dinosaur-style teeth? And then think about the "recipe" bit. That is only needed in two types of cells - egg cells and sperm cells. Yet you have billions of pointless copies in every other cell (except red blood cells) - it's a complete waste. And why, if humans were designed correctly in the first place, does DNA copying lead to mistakes? Why does it have to have buffer bits to reduce (but not eliminate) the risk of errors for a while? Why do these buffers run out leading to cancer? After all, in naked mole rats and lobsters, the buffers are kept intact. Or consider man's favourite organs - then brain and the penis. Both are marvellous devices - the brain is capable of extraordinary feats of rational and logical thinking. And the penis can provide the pleasure that is a key ingredient in most of our social structure. Yet the "intelligent" designer failed to provide men with enough blood to use both these organs at once. (The "user manual" seems to be strongly against using either of these organs properly - which then prompts the question of why they exist in the first place.) And just ask anyone who has had appendicitis how well designed we are. > disputes. And as with any dispute, 'careful' implies > 'fair-minded'—allowing the competing alternatives to be > properly developed and presented. Fair-minded science means finding evidence, and asking questions to see what the answers might be. Religion - including such pseudo-scientific nonsense as "intelligent design" - starts by assuming the answers, then changes the questions and evidence in an attempt to fit. |
| Daniel <danielaparker@gmail.com>: Aug 18 03:58AM -0700 On Thursday, August 18, 2016 at 4:18:14 AM UTC-4, David Brown wrote: I know I shouldn't click on the C++ Middleware Writer thread, but having done so, I have to say your post made excellent reading, thanks for that. Daniel |
| David Brown <david.brown@hesbynett.no>: Aug 18 02:37PM +0200 On 18/08/16 12:58, Daniel wrote: > On Thursday, August 18, 2016 at 4:18:14 AM UTC-4, David Brown wrote: > I know I shouldn't click on the C++ Middleware Writer thread, but having done > so, I have to say your post made excellent reading, thanks for that. When I make a post in a thread like this, it is in the hope that someone else finds it interesting, or that it provokes other interesting discussion. I don't really expect to influence the kind of fanatic who thinks that the Bible is scientific. So I am glad that someone enjoyed my post! |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 14 09:39PM +0200 On 14.08.16 18.01, Joseph Hesse wrote: > The problem is how can I give values to Values[i].d? > I probably have a bad design, nevertheless in the non-simplified version > it reflects the real problem. Maybe your const is at the wrong place. > { > private: > const Data Values[100]; // no need to use vector since 100 will never change ^^^^^ > // ... > }; > ========================================================== Of course, you still have to take some care about the initialization of const arrays. std::array might fit your needs. Marcel |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 14 11:42AM >Is this sensible? Without proper documentation (Doxygen), it's hard to say what the semantics are supposed to be and then compare this with the actual semantics. > Saves defining a null_type empty class? I can't even parse this string as English! >Or is it inappropriate semantics? This also is hard to read. Can code /be semantics/? Without documentation (Doxygen) it's little semantics. >Extended use of nullptr It uses some type »std::nullptr_t«, which is not the same as »nullptr«, and may not be the same as »::std::nullptr_t«. »nullptr« is not used as far as I can see. |
| 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