| 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 compiler is able to vectorize on int but not on unsigned - 1 Update
- istream replace - 9 Updates
| Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Dec 04 10:04PM +0100 >>> (could be also plain array so I post this to clc as well) >> A plain array would have been better, because the explanation has >> nothing to do with vectors/templates/whatnot Sorry for the late answer, I was busy. > He's already posted (nearly three hours ago) a message indicating that > the problem does not occur when using plain arrays, You're right. Some people stop reading in the middle of posts when they meet a template. I admit I did stop reading in the middle of the thread for lack of time. (I come back to plain arrays below.) > so the explanation must indeed have something to do with > vectors/templates/whatnot - to be more precise, it seems to be > connected to the use of ghs.size(). And your suggestion is? Here is mine: ghs.size() (probably) has return type size_t, which is (probably) bigger than unsigned on the target machine. (Actually size() return size_type which is typedefed inside vector, usually as size_t bt I'm not sure this is mandatory.) Therefore, the loop may never end (if k wraps around---which it is allowed to when unsigned), and this is enough for the compiler to decide *not* to vectorize (because manipulating the loop trip count in that case is tricky). The same thing does not happen when k is signed: this is explained in the link I posted earlier. So, why does it work with plain arrays? Well, it does not, but Melzzzzz's modified program was vectorized because the size was now an unsigned (not a size_t) coming in as a parameter, and the risk of overflow during iteration was gone. So why do I say it does not work with a "plain-array-like" version of vector? Because a (rough) translation of vector<int> using a plain array would be a structure like: struct vectorlike { size_t sz; int * data; }; and bam! the same would happen in C if the sz field were used as a loop bound. Also, in the version of Melzzzzz if the parameters were "real" plain arrays but the size were passed in as a size_t (instead of unsigned, as it should I think), the same would happen. (And this make the cross-posting to comp.lang.c not completely irrelevant.) I'm speculating, because I haven't looked into the respective vectorizers, but my experience with that unsigned/signed mess in compilers makes me reasonably sure the problem lies somewhere there. I maintain what I said, but of course if James or anybody else has a better explanation I would love to read it. -- Alain. |
| Christopher Pisz <nospam@notanaddress.com>: Dec 03 05:45PM -0600 On 12/3/2014 4:56 PM, Luca Risolia wrote: >> That probably should be std::runtime_error. > Not only that... > I wonder why people don't try to compile their code before posting. They do. They just don't use your compiler. |
| Christopher Pisz <nospam@notanaddress.com>: Dec 03 05:47PM -0600 On 12/3/2014 3:42 PM, Geoff wrote: > the system automatically converts them to \n in memory as the file is > read in text mode. Do streams behave differently? > Why not just do the replacement in the stream as you read it in? I don't read it in. Someone else somewhere else does. I suppose we could call it a bug in their code, but you know how it goes. Fix this crap quick, deadline deadline. All I know is I have an istream from somewhere that may or may not contain \r\n which the parser after my code cannot handle. |
| Christopher Pisz <nospam@notanaddress.com>: Dec 03 06:04PM -0600 On 12/3/2014 3:43 PM, Victor Bazarov wrote: > line you get. Call your function right after 'getline' returns a string. > If you need more information, do ask. > V Good stuff Victor. You are the man. |
| Geoff <geoff@invalid.invalid>: Dec 03 04:21PM -0800 On Wed, 03 Dec 2014 17:47:48 -0600, Christopher Pisz >quick, deadline deadline. All I know is I have an istream from somewhere >that may or may not contain \r\n which the parser after my code cannot >handle. This seems to work: (Mind the line wraps.) // Standard Includes #include <iostream> #include <sstream> #include <vector> // Function I am working on void Test(std::istream & stream) { // Verify the stream is good if(!stream) { // Error - stream was given in an error state throw std::runtime_error("Stream to be parsed was given with an error state set"); } std::string stro = "\r"; // old string to find std::string strn = "\n"; // new string to replace it std::string str; while (std::getline(stream, str, '\n')) { std::string::iterator iter = str.begin(); while (iter != str.end()) { std::string::size_type pos = str.find(stro); if(pos != str.npos) // found a match { str.replace(pos, strn.length(), strn); } iter++; } std::istringstream formattedStream(str); } // Snip the actual work } // Test int main() { std::istringstream testData( "Hello\r\nI am a Windows string\r\nBecause I like carriage returns\r\n"); Test(testData); } |
| Luca Risolia <luca.risolia@linux-projects.org>: Dec 04 02:31AM +0100 Il 04/12/2014 00:45, Christopher Pisz ha scritto: >> I wonder why people don't try to compile their code before posting. > They do. > They just don't use your compiler. To tell you the truth, there is no need of any compiler to see that your code may not compile, as it's evident you did not include the necessary header for std::exception. Not to mention the fact that std::exception(const char*) is not standard. All the above tells me you are using the VS C++ compiler. For the above reasons, I suggest that you change your compiler and try to be less arrogant next time. |
| Christopher Pisz <nospam@notanaddress.com>: Dec 04 10:42AM -0600 On 12/3/2014 7:31 PM, Luca Risolia wrote: > header for std::exception. Not to mention the fact that > std::exception(const char*) is not standard. > All the above tells me you are using the VS C++ compiler. How intuitive! > For the above reasons, I suggest that you change your compiler and try > to be less arrogant next time. I suppose I should install Linux and tell all my customers to go to hell too. I am sorry if it took you more than 0.5 seconds to figure out that #include<exception> was omitted, which somehow stopped you from understanding the code at all, leaving it impossible for you to follow the post. I am also wearing mismatching socks today. Arrogance begets arrogance. The code was compiled and ran. I am so sorry that I did not have the foreknowledge that msvc didn't require me to include the header and that it ruined your week. |
| legalize+jeeves@mail.xmission.com (Richard): Dec 04 05:54PM [Please do not mail me a copy of your followup] Luca Risolia <luca.risolia@linux-projects.org> spake the secret code >To tell you the truth, there is no need of any compiler to see that your >code may not compile, as it's evident you did not include the necessary >header for std::exception. Many C++ programmers make this mistake of getting the appropriate header by accident instead of by design. This can happen with any compiler because standard library headers include other standard library headers by virtue of their implementation. You may get the necessary header by accident and no compile error ensues. Every implementation of the standard library has this going on. That's why a team at Google created a tool called "include what you use" to alert you that you are using identifiers that aren't defined in headers that you explicitly included. <https://code.google.com/p/include-what-you-use/> I recommend using that regularly on your code base, no matter what compiler you are using. >Not to mention the fact that >std::exception(const char*) is not standard. Yeah, this has bugged me for a while[*] that the standard library that ships with VS lets you make this mistake and you don't find out its non-portable until you try to compile your code somewhere else or with another implementation of the standard library. I also recommend building your C++ code on multiple platforms with multiple compilers in order to avoid this mistake. The reverse is also true that it is too easy to write some non-portable, non-standard code that happens to compile on gcc. Compiling your code on multiple platforms (even if you never intend to ship on them), will keep you honest regardless of which platform is your preferred platform. [*] Since the late 1990s! -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Geoff <geoff@invalid.invalid>: Dec 04 11:14AM -0800 On Thu, 04 Dec 2014 10:42:59 -0600, Christopher Pisz <nospam@notanaddress.com> wrote: [snip] >#include<exception> was omitted [...] [snip] <exception> is a Microsoft header. <stdexcept> is the standard header. |
| Christopher Pisz <nospam@notanaddress.com>: Dec 04 02:25PM -0600 On 12/4/2014 1:14 PM, Geoff wrote: >> #include<exception> was omitted [...] > [snip] > <exception> is a Microsoft header. <stdexcept> is the standard header. Fair enough. I shall enter that into the noggin. MS sure does like to make me memorize nuances. Thanks. |
| 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