| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- Instead of writing getter and setter methods, could a g/setter template be used? - 9 Updates
- Peculiar g++ warning ?? - 12 Updates
- Opposite of emplace - 4 Updates
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 09:07PM -0700 I was able to get the non-breaking-space ability added to my parser and IDE tonight. It now allows me to have non-breaking-spaces added to every variable name, function name, table field, etc., in an XBASE language. The same will be introduced into RDC. It uses Shift+spacebar to insert the nbsp character, which internally is stored as ASCII-255 in the text file. http://snag.gy/QjtXc.jpg I will probably change the formatting somewhat. Right now I'm using a 1 point size smaller font size so the space looks normal with the smaller text. I'll probably put it back up to normal size and go with my original half-space idea. I'm also using only a fixed dark blue background with a 15% opacity over white. I think it's still too "in your face" and will work on the presentation. Best regards, Rick C. Hodgin |
| Robert Wessel <robertwessel2@yahoo.com>: Oct 31 12:00AM -0500 On Thu, 30 Oct 2014 21:07:08 -0700 (PDT), "Rick C. Hodgin" >my original half-space idea. I'm also using only a fixed dark blue >background with a 15% opacity over white. I think it's still too "in >your face" and will work on the presentation. And in the process you've broken every tool, other than yours, which someone might want to use to look at or manipulate a source file. Heck, you can't even display a page of source code on a web site anymore without heroics. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 05:00AM -0700 > Heck, you can't even display a page of source > code on a web site anymore without heroics. "Heroics." Hmmm. Interesting. "Come and visit LibSF.org, where developers code more like people, and our web server's are heroic." Best regards, Rick C. Hodgin |
| Daniel <danielaparker@gmail.com>: Oct 31 05:53AM -0700 On Friday, October 31, 2014 8:01:04 AM UTC-4, Rick C. Hodgin wrote: > "Come and visit LibSF.org, "There's a man I've met on an online forum. He is negative and hurtful in his comments, ... he's being led by false spirits seeking to do harm ... I pray that this man will humble himself before the Living God, believe, repent, and be saved." - Rick C. Hodgin I think he's talking about you, Mr Flibble. Daniel |
| Daniel <danielaparker@gmail.com>: Oct 31 05:55AM -0700 On Friday, October 31, 2014 8:01:04 AM UTC-4, Rick C. Hodgin wrote: > "Come and visit LibSF.org, where developers > code more like people, and our web server's > are heroic." Pride, Mr Hodgin, pride goeth before destruction, and an haughty spirit before a fall. |
| scott@slp53.sl.home (Scott Lurndal): Oct 31 01:31PM >> I'd never willingly develop code in an editor that hides the >> difference between two distinct characters. >I would not use the default font's character for this, but instead I A language where one cannot use their favorite editor is pretty close to useless. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 06:33AM -0700 On Friday, October 31, 2014 8:55:55 AM UTC-4, Daniel wrote: > > are heroic." > Pride, Mr Hodgin, pride goeth before destruction, and an > haughty spirit before a fall. Agreed. Proverbs. One of the wisdom books. http://biblehub.com/proverbs/16-18.htm (1) I was being silly, attempting humor. (2) God does not want us to be without pride, nor without a view of ourselves. He just does not want it artificially inflated, as with yeast, but only insomuch as is correct. A person can be proud of their accomplishments, but they must recognize that the reason they had any such accomplishment in the first place was because God gave them the abilities and opportunities to do so. Have you considered this verse? http://biblehub.com/romans/12-3.htm "For I say, through the grace given unto me, to every man that is among you, not to think of himself more highly than he ought to think; but to think soberly, according as God hath dealt to every man the measure of faith." The man who focuses his life upon the Lord, for example, can take pride in his work because it is a right work. The man who strives with great effort to live a holy life can take pride in the fact that he is living a holy life. But he must not become conceited or prideful in himself, but in all ways acknowledge first the Lord. What is wrong is the, "Hey, I'm all that and a bag of chips" attitude about oneself. Jesus taught us to first remove the beam from our own eye, and then we will see clearly to remove the speck from our brother's eye, meaning it is okay to reach out to guide another, provided you are first taking care of yourself. Ours (Christians) is a communal effort. We are not practicing our faith in isolation, but as part of a community, His community. We remind each other continually of the things we should be doing, because the enemy is real and is actively prowling around seeking whom he may devour with temptation and culmination in sin. I am proud of the work I've done with regards to LibSF. It has been an ongoing, continuous battle against all other people, including my own family. Everyone has told me to set it aside and conform to the more conventional ways of the world. I have persisted through it all, and when I look at myself in the mirror, apart from the standard degree of self-examination where I always look at myself and think, "You could've done more, Rick," I am pride, and even humbled at the fact that I have been able to continue because there have been times it has been so very very hard to proceed. Times I've even laid in bed crying because of what I was having to endure as I moved forward for my Lord. But, I persisted. And I have been very proud of that, because it is a right thing to do that is not centered upon myself, but upon Him, and devotion unto Him. Best regards, Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 06:40AM -0700 On Friday, October 31, 2014 9:31:49 AM UTC-4, Scott Lurndal wrote: > A language where one cannot use their favorite editor is pretty > close to useless. (1) No one is forced to use spaces. Use your favorite editor and use only underscores or some type of case like camelCase. However, if you want to use spaces, then it's now available (or soon will be, James 4:15). (2) No one is forced to use RDC. People will use it because they want to, and for no other reason. There are lots of other compilers with all of their favorite stand-bys. (3) A person could easily parse and type in the ASCII-255 character. In Windows it's Alt+numpad 255. I'm sure it's possible in Linux too. (4) If your editor is proprietary and you cannot get the source code to go in and make an easy way to accept Shift+Spacebar, and alter the display to in some way mark off the single variable with the nbsp character ... then perhaps you should switch to an open source editor? Just a thought... (5) Hi. :-) Best regards, Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Oct 31 02:44PM +0100 On 31/10/14 13:53, Daniel wrote: > be saved." - Rick C. Hodgin > I think he's talking about you, Mr Flibble. > Daniel He may be talking about many people, including me. I've been declared to be someone Rick will not answer, though I actually am not sure why. Given all the useful advice I have posted for him, it is very much his loss, not mine. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 04:52PM -0700 On Thursday, October 30, 2014 6:27:10 PM UTC-4, Christopher Pisz wrote: > and you can see by his responses to why he didn't pass it by reference > and why he returns (0) instead of returning 0, that he is a C style > programmer.... I am a C-style programmer. I am currently working on development of a new compiler somewhere between C and C++ called RDC (Rapid Development Compiler). I asked this in the C++ groups because I was using g++ to compile my project. I was surprised by your response. You could've answered my question by replying: "The order of precedence is causing the pointer to be updated, and not the value being pointed to." That would've been singularly helpful. FWIW, the example I gave was a minimally contrived example to demonstrate the issue I was having. It was not intended to be fantastically beautiful, but to demonstrate the same warning I was getting. And I do appreciate your help. It's obvious in retrospect. :-) Best regards, Rick C. Hodgin |
| Melzzzzz <mel@zzzzz.com>: Oct 31 01:03AM +0100 On Thu, 30 Oct 2014 13:42:51 -0700 (PDT) > Why does g++ generate this warning? It is useful. clang issues exactly same warning, too. -- Manjaro all the way! http://manjaro.org/ |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 05:10PM -0700 On Thursday, October 30, 2014 8:03:50 PM UTC-4, Melzzzzz wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > > Why does g++ generate this warning? > It is useful. clang issues exactly same warning, too. :-) It is useful. FWIW, Visual Studio 2008's C/C++ compiler did not generate a warning. It compiled the code, and the disassembly showed the same operation as g++ as the above GDB output. Thanks, Microsoft. :-) But, the blame rests solely on my shoulders. I should've known better. And, I actually do... it's just sometimes that things happen. :-) Best regards, Rick C. Hodgin |
| jacob navia <jacob@spamsink.net>: Oct 31 02:38AM +0100 Le 30/10/2014 23:26, Christopher Pisz a écrit : > (good)C++ programmers don't use #include <stdio.h>, (most)C programmers do. Maybe, but that is completely irrelevant to this bug. > (good) C++ programmers don't usually pass raw pointers to public methods > or global functions, (most) C programmers do C++ doesn't use pointers? Yes, they do. Yes, C++ will let you have all kinds of abstractions about pointers, smart ones, not so smart ones and stupid ones, that are just that: pointers. But that has nothing to do about the bug! > before using it, (most) C programmers rely on foreknowledge and would > say, "Well, we just know the pointer has to be initialized before using > it", that's the way this API works. No. Any reasonable C programmer in production code tests its inputs for NULL, when that is required: a global function in this case. But the bug would STILL be there if it was hidden in a completely local environment { char *p = buffer; *p++; } The bug is a misunderstanding by a programmer of how pointers work, what is normal, since it is one of the most difficult things for newcomers to C OR C++ to grasp. > This was a very good example of how C style code creates unexpected > errors. There is no error at all! It is just that the value of an operation is not used. It is the SAME as in C, by the way. C++ and C are exactly the same with respect to this problem. If he has passed the int by reference or by one of the many C++ > constructs to manage pointers, then the error would have never occurred. And if he wouldn't have used any pointers at all the error would disappear also. But you are looking at a SAMPLE CODE sent by the programmer to ask a question about a warning he did not understand. It is not production code! > programmer, because he chalks it up to his personal preference and as is > the case all too often with C style code, that personal preference made > the code more error prone. What makes his code go bad is a basic misunderstanding of pointers and what dereferencing is. If he would have used any of the C++ methods you point out, he would have never had this bug and would have never learned how pointers work and why that construct is wrong. What bothers me again in your answer is the implicit pejorative tone before a simple error question. Only the people that can't learn laugh at questions, be they so "stupid" or "C like" as you want. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 07:03PM -0700 On Thursday, October 30, 2014 4:43:04 PM UTC-4, Rick C. Hodgin wrote: > 03: *tnX++; // Changes only the pointer > 04: ++*tnX; // Changes the thing pointed to > 05: } I've been thinking... I don't think *tnX++ should do what it does in current C/C++ compilers. I think this reveals a flaw in the expression parsing mechanism which exists for pointers, and its dereferencing on stand-alone statements like this. Consider that on line 03: above, the * operation is completely and silently lost. GCC does not give any sort of warning about unreachable code in the pointer operation, or of having an operation which has no effect (with regards to the * part of the code), but only that the altered parameter value on the stack was not used. When changed to the form above, even that warning goes away. This reveals a flaw that is a separate issue to the original warning, one which, to me, is far more important. The pointer operation is being totally and completely ignored. Silently. I believe this code should actually act on the thing and not the pointer value itself. I'll have to consider this, and may make this a special case exception in RDC that when there is *tnX++; as in a stand-alone form, the operation is actually the same as ++*tnX, and actually to update the thing pointed to, rather than the pointer. Best regards, Rick C. Hodgin |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Oct 30 08:46PM -0600 On Thu, 30 Oct 2014 19:03:42 -0700 (PDT), "Rick C. Hodgin" >to, rather than the pointer. >Best regards, >Rick C. Hodgin Don't do it. If you make an exception to the operator precedence rules, you'll have programs breaking in surprising and mysterious ways. Think of what will happen when somebody changes the expression to: n = *tnX++; If tnX is suddenly incremented while before it wasn't, and *tnX is unchanged while before it was incremented, you'll have violated the Principle of Least Astonishment. If you don't like the way current C/C++ compilers work, then you should probably question how much you really like C or C++, and you might want to make your new language look like something else. Lots of people are not fond of C, and more people are less than thrilled by C++. There are other languages out there to investigate or to be used as models. Louis |
| Richard Damon <Richard@Damon-Family.org>: Oct 30 07:50PM -0700 On 10/30/14, 7:03 PM, Rick C. Hodgin wrote: > expression parsing mechanism which exists for pointers, and its > dereferencing on stand-alone statements like this. > Best regards, Rick C. Hodgin The typical use for *p++ is in expressions (in loops) like *p++ = 0; /* Clear a buffer */ or *p1++ = *p2++; /* Copy a buffer */ In this case it make a lot of sense to have the priorities the way they are. Basically, having pointers into buffers you want to manipulate is more common than a pointer to a simple variable you might want to increment. (or that *++p would be more common than ++*p) You always have the option to write it as: (*p)++ to modify the object pointed to by the pointer. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 08:51PM -0700 On Thursday, October 30, 2014 10:46:50 PM UTC-4, Louis Krupp wrote: > On Thu, 30 Oct 2014 19:03:42 -0700 (PDT), "Rick C. Hodgin" > >in RDC that when there is *tnX++; as in a stand-alone form... ^^^^^^^^^^^^^^^^^^^^^^^^ > ways. Think of what will happen when somebody changes the expression > to: > n = *tnX++; I did say "as in a stand-alone form" ... meaning it exists only on a single line of source code by itself (as per my original example). Your example would work properly in my compiler. The other example posted after would work properly. I'm just saying ++*tnX would work the same as *tnX++ when that is all that's on the source code line, as being that one special case. Best regards, Rick C. Hodgin |
| Nobody <nobody@nowhere.invalid>: Oct 31 08:20AM On Thu, 30 Oct 2014 19:03:42 -0700, Rick C. Hodgin wrote: > in RDC that when there is *tnX++; as in a stand-alone form, the operation > is actually the same as ++*tnX, and actually to update the thing pointed > to, rather than the pointer. Special-case exceptions are almost invariably a dumb idea, falling into the category of "it seemed like a good idea at the time". Even more so when the only reason for having it is that the developer once made a mistake and would prefer to believe that the mistake was the language's fault rather than his own. |
| David Brown <david.brown@hesbynett.no>: Oct 31 11:41AM +0100 On 31/10/14 02:38, jacob navia wrote: > same with respect to this problem. >> If he has passed the int by reference or by one of the many C++ >> constructs to manage pointers, then the error would have never occurred. Yes, there was an error - Rick had written code with an error because he misunderstood the precedence of the "*" and "++" operators. It is common enough to make such mistakes, even for experienced C or C++ developers - personally, I am a fan of extra brackets or splitting up the calculation in order to avoid such risks. The best solution, IMHO, is to write "(*tnX)++;". But if he had used a reference (as is common in C++ code), rather than a pointer (which is common in C, and uncommon though still legal in C++), then he could not possibly have made the same mistake. Using C++ style coding in a C++ program would have avoided this error. Now, it is fine for Rick to say he prefers the C style, even in C++ code. It is also fine to say using C++ style could have increased the risks of other errors (such as the one Christopher made in his C++ examples). But /this/ particular error would have been avoided if Rick had used C++ references. |
| David Brown <david.brown@hesbynett.no>: Oct 31 02:01PM +0100 On 31/10/14 01:10, Rick C. Hodgin wrote: > Thanks, Microsoft. :-) But, the blame rests solely on my shoulders. > I should've known better. And, I actually do... it's just sometimes > that things happen. :-) Check that you've got all warnings enabled, and also at least basic optimisations - many compilers give better warnings when optimising code (since they can track data flow better). |
| David Brown <david.brown@hesbynett.no>: Oct 31 02:10PM +0100 On 31/10/14 03:03, Rick C. Hodgin wrote: > This reveals a flaw that is a separate issue to the original warning, > one which, to me, is far more important. The pointer operation is > being totally and completely ignored. Silently. If you just have "*tnX", gcc will warn about that too. There is always scope for more warnings in the compiler, but gcc gives quite a number (when enabled). > in RDC that when there is *tnX++; as in a stand-alone form, the operation > is actually the same as ++*tnX, and actually to update the thing pointed > to, rather than the pointer. Re-consider it - you don't want the same expression to mean different things when it is written alone, or part of another statement. It makes a lot more sense to make sure you give a warning when something like that expression is used on its own, rather than silently translating it into something else. And if you like, make such warnings permanently enabled rather than optional (as in gcc or clang). |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 31 02:15AM +0100 With C++11 the standard containers like vector, deque etc. got a new function emplace to construct new objects in place. Very useful, from my point of view. I almost do not use anything else anymore. But what about the other direction? How to remove objects with move semantics? pop_back does not return anything, and there is no new function which returns an rvalue reference. Did I miss something? Marcel |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 30 11:08PM -0500 Marcel Mueller <news.5.maazl@spamgourmet.org> wrote in news:m2uns8$ohk$1 > But what about the other direction? How to remove objects with move > semantics? pop_back does not return anything, and there is no new > function which returns an rvalue reference. Did I miss something? std::move()? |
| woodbrian77@gmail.com: Oct 30 09:24PM -0700 On Thursday, October 30, 2014 11:08:13 PM UTC-5, Paavo Helde wrote: > > semantics? pop_back does not return anything, and there is no new > > function which returns an rvalue reference. Did I miss something? > std::move()? Maybe use ::std::move on back() and then call pop_back(). Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| JiiPee <no@notvalid.com>: Oct 31 12:12PM > Brian > Ebenezer Enterprises - In G-d we trust. > http://webEbenezer.net Yes it sounds logical the libraries should work this way. Or maybe they should have a new method: move_back which moves the object to caller :). But then too many member in class maybe :) |
| 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