I suspect the title may not be perfectly clear, but I mean to ask if it's possible to find the actual code that implements some of the functions built into the language? I tried looking through headers and following definitions through VS, but always come to a dead end.
I was trying to find old C-style string code for things like strcmp, strcat, strcpy and whatnot, but I just cannot for the life of me locate the actual code the compiler uses for them, which is a shame because I'm being asked to do it as I work through textbooks (both C++ Primer 5E and Programming Principles and Practice asked to create these functions freehand) and I want to see if there's anything I can learn from them. At best I'm finding references to them, or pseudo-code, but not the actual, hard code.
EDIT: And the reason is largely that, yes, I DO want to check my code against actual/"official" implementations, because what I have here is something that seems to work, but looks grotesque as all hell:
1 2 3 4 5 6 7 8 9 10 11 12 13
int jstrcmp(constchar* a, constchar* b)
{
if (!a && !b) return 0;
if (!a) return -1;
if (!b) return 1;
while (!(*a == '\0' && *b == '\0')) {
if (*a < *b) return -1;
if (*a > *b) return 1;
++a;
++b;
}
return 0;
}
I tried looking through headers and following definitions through VS, but always come to a dead end.
That's because those routines are implemented in assembler and precompiled into libraries. MS does not make the source to those libraries available. If you want to see the actual assembler code, try looking at an open source implementation, such as GNU.
As for your code:
Lines 3-5: AFAIK, supplying a null pointer to strcmp is undefined behavior, so I wouldn't bother to check.
Lines 3-5: AFAIK, supplying a null pointer to strcmp is undefined behavior, so I wouldn't bother to check.
Haha XD Yes indeed! I blame Stroustrup for this! His heavy insistence on error checking - particularly with regard to pointers - has left me paranoid and with my own insistence that run-time errors don't exist lol!
But I just thought the code looked... bloated? I mean, I know I could do it all in a for loop and testing for null was optional (and not what the real version does), but honestly? I hear a lot about, "premature optimization" being a bad habit, and I get that, but code to me is typically rather boring, and one thing I do have interest in is doing it in the smallest, fastest way possible, usually with the least amount of effort required. I really do enjoy code when I can take something I made that spanned 30 lines, and see if/how much I can condense it and remove redundancy, without compromising readability and functionality, naturally ;)
It's unfortunate though that most of the code I want to see is assembler made and doesn't have a C++/C higher-level I can look at. I always appreciate seeing new tips and tricks I can learn from to make life easier, and possibly a program better!
has left me paranoid and with my own insistence that run-time errors don't exist lol!
Personally, I would check the pointers for null and throw an exception. In my view, a null pointer should never be passed to strcmp and doing so is a programming error. Throwing an exception is going to catch errors in testing that returning a value (-1,0,1) would not catch in the event of a null pointer. Does comparing a null pointer with something even make sense?
Does comparing a null pointer with something even make sense?
Not really, no, but I really just wanted something that would survive a nullptr passed intentionally (I did pass it a nullptr in all three possible ways) without encountering a run-time error. I hate those far more than compiler/linker errors.
Also, I guess it KIND OF made sense, but only if you set yourself back a few years to being a noob and the mindset I had of, "well comparing something to nothing would make something bigger, and two nothings would be equal, I guess..." I suppose I have an improper mindset of nullptr being an actual "thing," even though I should be treating it as the error it likely is or will be.
You''ll possibly be pleased to know when I rarely use pointers (I don't if I can avoid it) I only ever use nullptr in things like function calls, and even then it's probably redundant, since I initialize pointers straightaway, and when I use them in a function and don't plan to return them for reasons (like copying into from a const pointer for iterative purposes) I usually declare the pointer null when I finish with it. I don't know why I do that... I guess even though I know scope will destroy it, I don't like the idea that it could even have a chance surviving the function call?
Neat little trick that is. I've never been a fan of the post-increment operation (even though it's often useful) but this is neat as all hell! I'm trying to make out line 16, and I see it's returning the value as an integer of the first instance of a character (positive or negative depending on where it is) of the difference between characters that don't match?
In any case, I bookmarked the hell out of that site! I don't like to "cheat" and look up answers, but sometimes I get stumped, and it surely has better tricks than I know.
The sign of the result is the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the strings being compared. http://en.cppreference.com/w/cpp/string/byte/strcmp
At line 16, s1 and (s2-1) point to the first pair of characters that don't compare equal.
Note: (s2-1) because s2 was incremented on line 13.
I'm not even going to lie to you, for some stupid reason I thought strcmp was to return -1, 0, 1. I don't even know why. Well, I do know why, and it's the same reason I've read sections over and over and over and still come here with stupid problems:
This happens time and time again where I miss a key word or phrase and spend hours trying to figure out what the hell I'm doing wrong. This is the time I spent a solid day trying to understand an insert function for a linked list, after which it was pointed out, "You know it's inserting an element BEFORE something, right?" and cleared it up 100%.
I spend all this time reading trying to understand it and little time actually programming anything, and maybe twice actually making something worthwhile. You'd think some 6 months later I'd try to get into a habit of doing something like 80% time programming, 20% book learning, but no, I never learn lessons until much frustration and time lost.
The worst part? If I hadn't concocted this nonsense about -1, 0, 1 I would have probably rather easily said, "Well sure, just return the difference of the two at the first discrepancy and be done with it." Admittedly, (s2 - 1) would have almost certainly tripped me up far longer than I care to say, but eventually...