| 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. |
- Why is this - 13 Updates
- C++ and Web Services (OT maybe?) - 2 Updates
- Announcement of new C++11 library to handle measures - 6 Updates
- :vector<bool> - 1 Update
- I don't understand how this code compiles. - 3 Updates
| Bint <bint@ign.com>: Oct 01 12:29PM -0500 Can someone explain why I get this result? In the 'if' statement below, I'm evaluating (0 - (384 % 64)) and it is passing the greater-than-zero test. int A = 0; int B = 64; unsigned long C = 500; if ((A - (C % B)) > 0) C += (A - (C % B)); // it gets to here -- why? 500 % 64 is 52, and 0 - 52 is not greater than zero. Is it somehow because of the an unsigned long? Thanks, B |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 01:41PM -0400 On 10/1/2014 1:29 PM, Bint wrote: > C += (A - (C % B)); // it gets to here -- why? > 500 % 64 is 52, and 0 - 52 is not greater than zero. > Is it somehow because of the an unsigned long? Likely. Have you tried declaring C just 'long'? Does it make a difference? V -- I do not respond to top-posted replies, please don't ask |
| Justin Bates <jwigh3@deenwatt.com>: Oct 01 05:45PM Victor Bazarov wrote: >> unsigned long C = 500; >> if ((A - (C % B)) > 0) >> C += (A - (C % B)); // it gets to here -- why? Makes no sense adding a negative to an unsigned. It would be converted/ inverted if this were the case. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 01 12:51PM -0500 > C += (A - (C % B)); // it gets to here -- why? > 500 % 64 is 52, and 0 - 52 is not greater than zero. > Is it somehow because of the an unsigned long? Yes, an unsigned type will turn the whole subexpression unsigned, together with all the nice misfeatures like legalized wrap-around and type tainting. Better to avoid mixing signed and unsigned in such expressions. And look up boost::numeric_cast<>. Beware that there are two parties in this group, ones who think that unsigned types are the Right Thing, and others who think they are Real Evil. I predict another 500 posts in this thread ;-( Cheers Paavo |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 02:07PM -0400 On 10/1/2014 1:45 PM, Justin Bates wrote: >>> C += (A - (C % B)); // it gets to here -- why? > Makes no sense adding a negative to an unsigned. It would be converted/ > inverted if this were the case. Please consider replying to (and attributing) the original post next time you wanted to comment on the original post. Thanks! V -- I do not respond to top-posted replies, please don't ask |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 01 07:41PM +0100 On 01/10/2014 18:51, Paavo Helde wrote: > Beware that there are two parties in this group, ones who think that > unsigned types are the Right Thing, and others who think they are Real > Evil. I predict another 500 posts in this thread ;-( If a value can never be negative as it represents a "size" or a "count" for example then using an unsigned type to represent it is perfectly fine. std::size_t pervades the Standard Libray thanks to std::allocator and it is unsigned. /Flibble |
| Bint <bint@ign.com>: Oct 01 03:05PM -0500 > fine. std::size_t pervades the Standard Libray thanks to std::allocator > and it is unsigned. > /Flibble Boy, that makes no sense to me. I mean, I understand that an unsigned value can never be negative, but if you throw it into a calculation with signed values then it should just be treated as a positive value. Let the left side of the equation determine whether the result can be negative or positive. I can't believe that's how C works, that it forces the whole expression to be unsigned! That's crazy, man! |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 04:22PM -0400 On 10/1/2014 4:05 PM, Bint wrote: >> and it is unsigned. >> /Flibble > Boy, that makes no sense to me. Which part? > I mean, I understand that an unsigned value > can never be negative, but if you throw it into a calculation with signed > values then it should just be treated as a positive value. And it is. > Let the left > side of the equation determine whether the result can be negative or > positive. And in your case what is the "left side"? > I can't believe that's how C works, that it forces the whole > expression to be unsigned! That's crazy, man! Are you in jest? I can't believe you can't believe it. There are old rules about promotions and conversions of arithmetic types (integral and floating point) in both C and C++, they are essentially the same. There is nothing to believe, really, you just need to learn them. And as you learn them you might just understand the logic behind them. Eventually. V -- I do not respond to top-posted replies, please don't ask |
| Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl>: Oct 01 01:29PM -0700 On Wednesday, 1 October 2014 19:51:52 UTC+2, Paavo Helde wrote: > Beware that there are two parties in this group, ones who think that > unsigned types are the Right Thing, and others who think they are Real > Evil. I predict another 500 posts in this thread ;-( The problem is not with the unsigned types. The problem is the conversion of mixed signed/unsigned expressions to unsigned that C++ inherited from C. In practice, unsigned types don't behave so nice in arithmetic expression where they often lead to unexpected wrap arounds. Consider the difference of two unsigned values. The result will also be unsigned whereas the arithmetic result can be negative. I use unsigned for bit manipulation only and convert between unsigned and int on API boundaries like container's size(). This has kept my code free of mixed signed/unsigned trouble. |
| peter koch <peter.koch.larsen@gmail.com>: Oct 01 01:33PM -0700 Den onsdag den 1. oktober 2014 22.05.42 UTC+2 skrev Bint: > side of the equation determine whether the result can be negative or > positive. I can't believe that's how C works, that it forces the whole > expression to be unsigned! That's crazy, man! No it's not. Some rule (inherited from C, so it is not going to change) has to be there. C++ does not overload based on "what is on the left side". For one thing, "what is on the left side" does not always exist - e.g. void f(unsigned); void f(int); unsigned i; int j; f(i + j); Which f do you call? You have learnt a lesson: do not mix signed and unsigned integral values. If I were you, I would avoid the unsigned types. I use them mostly for low-level stuff - e.g. working with "raw" data and bits. It is an open debate whether the standard library should have used signed or unsigned types e.g. when indexing a std::vector. Today I believe that signed types would be a better choice, but back then with the segmented architecture used for the popular x86 processors then, I would also have chosen an unsigned value. /Peter |
| Barry Schwarz <schwarzb@dqel.com>: Oct 01 01:53PM -0700 > C += (A - (C % B)); // it gets to here -- why? >500 % 64 is 52, and 0 - 52 is not greater than zero. >Is it somehow because of the an unsigned long? You should note that your assumption that the code evaluated 0-52 is wrong. It evaluated 0-52UL which is something different. When at least one of the operands of an arithmetic operator has rank greater than int, the expression is evaluated at the highest rank present. So C%B is evaluated as unsigned long. Then A-(C%B) is also evaluated as unsigned long. Since C%B is not 0, the difference is not 0. Since unsigned cannot be less than 0, the only remaining option is greater than 0. If you change C to unsigned int, a different set of rules would produce the same result. -- Remove del for email |
| Martijn Lievaart <m@rtij.nl.invlalid>: Oct 01 11:41PM +0200 On Wed, 01 Oct 2014 13:29:39 -0700, Gert-Jan de Vos wrote: >> Beware that there are two parties in this group, ones who think that >> unsigned types are the Right Thing, and others who think they are Real >> Evil. I predict another 500 posts in this thread ;-( Seems you were right. > The problem is not with the unsigned types. The problem is the > conversion of mixed signed/unsigned expressions to unsigned that C++ Right. > inherited from C. In practice, unsigned types don't behave so nice in > arithmetic expression where they often lead to unexpected wrap arounds. And such wrap around is defined, unlike signed types, which also suffer from wrap around. > Consider the difference of two unsigned values. The result will also be > unsigned whereas the arithmetic result can be negative. Consider the sum of two signed positive vales. The result can be negative whereas the arithmetic result should be positive. What you are probably trying to say, is that the difference between two unsigned integers, lets say indexes into an array, can wrap instead of becoming negative. On a twos complement machine, this will give the correct result if assigned to a signed integer of the same size. However, this behavior is not guaranteed by the standard. Or in other words, the difference between two unsigned integrals may not be represented correctly, even when that difference is cast to a signed type. > I use unsigned for bit manipulation only and convert between unsigned > and int on API boundaries like container's size(). This has kept my code > free of mixed signed/unsigned trouble. Absolutely sound advice. M4 |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 01 10:26PM On Wed, 2014-10-01, Martijn Lievaart wrote: > On Wed, 01 Oct 2014 13:29:39 -0700, Gert-Jan de Vos wrote: ... >> and int on API boundaries like container's size(). This has kept my code >> free of mixed signed/unsigned trouble. > Absolutely sound advice. But like someone mentioned upthread, opinions on that differ in c.l.c++, and there have been several long flame wars about it. Disclaimer: I'm in the other camp. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Christopher Pisz <nospam@notanaddress.com>: Oct 01 03:41PM -0500 It looks like I can't ignore it any longer. Everyone wants to talk to my C++ clients using web services. I can no longer just make a socket and define my own protocol or XML schema. I understand web services are just REST and SOAP. Where would we start in C++ land without handy IDE code generators and frameworks those .NET guys have? Did boost have anything built in that I should look up? I tried GSoap and failed at it after 3 days of trying. Any others to look into? |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 01 10:19PM On Wed, 2014-10-01, Christopher Pisz wrote: > It looks like I can't ignore it any longer. Everyone wants to talk to my > C++ clients using web services. Out of curiosity, what's a C++ client? Clients normally want to talk to servers, not the other way around ... Or a more precise question: what is your code doing, when it attracts web service people? What area are you working in? (Personally, I'm waiting for web services to go the way of CORBA ...) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 01:23PM -0400 On 10/1/2014 12:40 PM, Wouter van Ooijen wrote: > But it would be peculiar if you state both > - that you don't know Bar > - that the reason for writing Foo is that you are dissatisfied with Bar Not really. One of the reasons to write Foo is so you don't have to spend time figuring out Bar. Simple explanation is that Bar is too complex to easily figure out. Besides, "I don't know Bar" and "I don't *really* know Bar" are two different statements, don't you think? V -- I do not respond to top-posted replies, please don't ask |
| Wouter van Ooijen <wouter@voti.nl>: Oct 01 07:44PM +0200 Victor Bazarov schreef op 01-Oct-14 7:23 PM: > spend time figuring out Bar. Simple explanation is that Bar is too > complex to easily figure out. Besides, "I don't know Bar" and "I don't > *really* know Bar" are two different statements, don't you think? Dunno, I think that's beyond my grasp of English. But knowing (not just guessing without looking) that Bar is too complex to use counts as knowledge about Bar for me. And I still think that it is peculiar to start designing something non-trivial as a units library without first looking at what is laready there (which btw is more than just boost.units). Wouter |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 02:27PM -0400 On 10/1/2014 1:44 PM, Wouter van Ooijen wrote: > Dunno, I think that's beyond my grasp of English. But knowing (not just > guessing without looking) that Bar is too complex to use counts as > knowledge about Bar for me. Knowing about something and knowing something are two different things, trust me. Also, knowledge that something ("Bar") is too complex does not necessarily mean knowing it ("Bar") in depth (or, like some might put it, "really knowing" it). > non-trivial as a units library without first looking at what is laready > there (which btw is more than just boost.units). > Wouter I agree with you that it is peculiar to start designing something without looking at what is already there. I do not see how it can be said about Carlo's work, however. Seeing that it's not the first time you disclaim knowing English to grasp some obvious and elementary stuff, I think it is peculiar that you *judge* other posters statements written in English without putting any effort to understand it enough. Your alleged weak grasp of English does not preclude you from denying the benefit of the doubt to others. Carlo *evidently* looked at what was "already there" if you care to see what he stated in his second post. He knows how to use at least some mechanisms of Boost.Units. He gives measurements of the size of the resulting executable and the time it took to compile... Does this not present itself like "looking at what is already there"? V -- I do not respond to top-posted replies, please don't ask |
| Wouter van Ooijen <wouter@voti.nl>: Oct 01 09:11PM +0200 Victor Bazarov schreef op 01-Oct-14 8:27 PM: > without looking at what is already there. I do not see how it can be > said about Carlo's work, however. > Seeing that it's not the first time you disclaim knowing English to I don't recall many instances of me doing that here, but you might have a better memory. > grasp some obvious and elementary stuff, I think it is peculiar that you > *judge* other posters statements written in English without putting any I did not mean to judge, I meant to express my surprise at the scentence a responded to. I think the fragment is > but here are some apparent differences. >Eh, you really don't know B.U yet at the same time you are not >satisfied by it?? For me (but note again that I am not a native english speaker) "don't really kown' and "really don't know" are close, but I might be totally wrong here. Anyway, what I wanted to express was that I though the combination of "not satisfied" and "don't really know" strange. It was not meant as judgement, except maybe about the combination of those two scentences. For me being "not satistfied" enough to embark to "implement my own" means that I have looked at the alternative(s) more than just passingly, even if only to know what not to do. I suspect that Carlo has done so, and for me that doe snot match "I don't really know Boost.Units". > mechanisms of Boost.Units. He gives measurements of the size of the > resulting executable and the time it took to compile... Does this not > present itself like "looking at what is already there"? Indeed he does lateron, but that does not change my surprised reaction to the two sentences I responeded to. I do not claim that he has no knowledge of B.U., or that he went on his work unprepared, on any other jusgement about his work or his preparation, just that I thought that combination of two scentences strange. Wouter van Ooijen |
| c.milanesi.bg@gmail.com: Oct 01 02:04PM -0700 Öö Tiib wrote: > tools for most electronic devices around us catch up slowly > so supporting only few latest compilers may narrow target > audience down too lot. You are right, but I target mainly engineering and scientific (but not theoretical physics) software, not small micro-controllers, for which C is generally preferred to C++. And I found very useful the "decltype" keyword, that I used a lot. > > although many examples will be available in documentation. > Maybe it makes sense to do like boost, standardized systems of > dimensions like SI or CGS do not change too often. Many engineers and scientists use units not belonging to standardized systems. Never heard about energy measured in electron-volts, or force (not mass) measured in kilograms? In addition, having all magnitudes and units application-programmer defined keeps small the code base. > > point1<fahrenheit> T1p(32); > Names like "quantity absolute" and "quantity" feel bit > more intuitive than "point1" and "vec1" but YMMV. I feel that, after you have learned that "point1" means "one-dimension absolute measure" and "vect1" means "one-dimension relative measure", the latter expression is more understandable than the former one. But as my library is still in development, I accept suggestions for a renaming. > values library it might be worth considering seeking > interoperability with one of those. Two good things that > play together often result with great outcome. If you want to represent the position (X=10", Y=12") of an object in a plane, and move it by (X=3", Y=8") to reach position (X=13", Y=20"), using Cpp-Measures you can write: point2<inches> p(10, 12); p += vect2<inches>(3, 8); cout << p << endl; // It outputs: 13 20" How can you do that using Boost.Units or another units library combined with a vector algebra package? Cpp-Measures can perform unit checking on 2D and 3D measures, while interfacing it with other libraries, you lose unit checking, as other libraries sometime perform unit-forbidden operations. However, you can interface Cpp-Units with other libraries. For example, to compute the cross product between two 3D measures using both Cpp-Measures and Eigen, you can write: // Define and initialize the two 3D measures. vect3<inches> v1(12, 13, 14); vect3<inches> v2(15, 16, 40); // Output their cross product as: // 296 -270 -3"2 // where '"2' means 'square inches'. cout << cross_product(v1, v2) << endl; // Pass to Eigen the address of the measures. Map<Vector3d> v1e(v1.data()); Map<Vector3d> v2e(v2.data()); // Output their cross product without unit as: // 296 // -270 // -3 cout << v1e.cross(v2e) << endl; -- Carlo Milanesi |
| c.milanesi.bg@gmail.com: Oct 01 02:26PM -0700 Wouter van Ooijen wrote: > > but here are some apparent differences. > Eh, you really don't know B.U yet at the same time you are not satisfied > by it?? I'm sorry for the misunderstanding, but I meant that I don't know *well* it. Four years ago, I just installed it, read four or five screens of documentation, and I wrote a program of few tens of statements to test it. Now I just redid that. I meant that perhaps I may have overlooked some of its features, but I am not satisfied of what I have seen. > > requires, and takes advantage of, the parts of C++11 available > > in GCC and VC++ 2012. > Does that mean anything for me as user of either package? Sure. If you want to use a C++ compiler released before 2012, you cannot use Cpp-Measures. That's a plus for Boost.Units. > > Yes, .. > Nice. I assume that adding points is not possible, substracting points > yields a vect, etc? Exactly. > already, why would one of those yet-some-other-types not work out of the > box? That means that a numeric type that I write will likly suffer the > same fate. Cpp-Measures needs to apply the "%" operator to integer types, and the "fmod" function to floating-point types, selected using type traits. The user-defined numeric type should instantiate the appropriate type trait. In addition, Cpp-Measures now does not work with unsigned types and with "signed char", "signed short". I will go on to support some user-defined types. Do you have any suggestions? -- Carlo Milanesi |
| "AP" <unixpronospam@verizon.net>: Sep 20 07:45PM -0400 > std::vector<bool> has a relaxed specification relative to a vector of any > other type, so that the implementation can store each element as a single > bit. vector<bool> bl={true, true, false, false, true, false}; auto head = bl.begin(); decltype(*head) BL; for ( auto i : bl ) cout << i << endl; BLref = *( bl.begin() ); g++ compiles without a problem - even the last line (which crashes at runtime). CC chokes on the first line with determine_type: type is 19 cg: assertion failed in file ../src/translator/sunIR.cc at line 294 cg: determine_type -- unexpected tword cg: 1 errors CC: cg failed for lam.cc --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Chairman Mao <maotse30million@gmail.com>: Oct 01 09:54AM -0700 On Wednesday, October 1, 2014 11:55:51 AM UTC-3, Victor Bazarov wrote: > V > -- > I do not respond to top-posted replies, please don't ask "If the compiler were required to inject the name 'B' into the scope of the class where it was first encountered, then the declaration of the argument of the function 'f' would contain an unknown symbol 'B', making your code ill-formed." Of course, in this case the declaration of function `f` would be rewritten with `void f(const A::B&)` instead of `void f(const A&)`. But IMHO this alternative would be clearer for the user, than the one adopted by the implementers. I'm just wondering if there isn't some other stronger reason to inject the declaration of the elaborated-specifier-sequence in the surrounding namespace. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 01 10:22AM -0700 On Wednesday, October 1, 2014 12:54:45 PM UTC-4, Chairman Mao wrote: > Of course, in this case the declaration of function 'f' would be rewritten > with 'void f(const A::B&)' instead of 'void f(const A&)'. I assume you mean 'void f(const B& b)'. Why would you want it written as A::B? There is no reference to A in that function. f() is designed to handle only B. It should have no knowledge or requirement of A existing because it doesn't reference anything in A. Best regards, Rick C. Hodgin |
| Chairman Mao <maotse30million@gmail.com>: Oct 01 10:27AM -0700 On Wednesday, October 1, 2014 1:22:37 PM UTC-3, Paavo Helde wrote: > this is specified in some obscure back-alley in the standard. > Cheers > Paavo Paavo, I think you have already answered my question about the decision the implementers have taken, by deciding to inject the elaborated-type-specifier in the surrounding namespace, instead of in the class (struct): compatibility with C. I'm pretty satisfied with the answers. Thanks to all and specially to Victor Bazarov and you for the valuable inputs. |
| 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