|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On October 26 2014 19:55 Cynry wrote:I thought that char str[] = "hello";
ft_strclr(&str[0]);
would be equivalent to char *str = "hello";
ft_strclr(str);
would be the same except that I would be able to modifiy the string in the first exemple, avoiding the error that brought me here in the first place because of the second exemple.
Logically it makes sense, I'll give you that, but, the only reason to start doing this address of index 0 of str business is, if you want to skip characters in general - otherwise, just pass the pointer. Makes for easier code to understand and test.
On October 26 2014 19:55 Cynry wrote:Show nested quote +And here is a case of an array not being the same as a pointer.
One way to view the use of a string literal, is that it will be expanded into something like this
char[6] str = {'h', 'e', 'l', 'l', 'o', '\0'};
That's where your char[6] comes from.
Why do you think that where the while loop stop holds any significance? I misinterpreted the error. Thought that char[6] pointed to the 7th character (starting at char[0]) and that the while loop was responsible for the error, trying to go too far or something like that (would have been another segfault I guess). Now if I understand correctly, char[6] simply is an array of 6 char, \0 included, and the error comes from the fact that ft_strclr returns a char *. Correct ?
Yes - you can't assign a pointer to a char (char *) to a char[6] as the error states ;o)
(Unless you do evil things... Don't do evil things!)
|
On October 26 2014 20:06 bangsholt wrote:Show nested quote +On October 26 2014 19:55 Cynry wrote:I thought that char str[] = "hello";
ft_strclr(&str[0]);
would be equivalent to char *str = "hello";
ft_strclr(str);
would be the same except that I would be able to modifiy the string in the first exemple, avoiding the error that brought me here in the first place because of the second exemple. Logically it makes sense, I'll give you that, but, the only reason to start doing this address of index 0 of str business is, if you want to skip characters in general - otherwise, just pass the pointer. Makes for easier code to understand and test.
But then I'd be back in square one with the segfault, wouldn't I ?
|
On October 26 2014 20:16 Cynry wrote:Show nested quote +On October 26 2014 20:06 bangsholt wrote:On October 26 2014 19:55 Cynry wrote:I thought that char str[] = "hello";
ft_strclr(&str[0]);
would be equivalent to char *str = "hello";
ft_strclr(str);
would be the same except that I would be able to modifiy the string in the first exemple, avoiding the error that brought me here in the first place because of the second exemple. Logically it makes sense, I'll give you that, but, the only reason to start doing this address of index 0 of str business is, if you want to skip characters in general - otherwise, just pass the pointer. Makes for easier code to understand and test. But then I'd be back in square one with the segfault, wouldn't I ?
No, because you've changed the way that the "string" is allocated. Before it was put into the read-only section of the binary, which is... read-only and therefore not modifiable.
Now it's in a stack variable instead - basically, by using
char * str = "hello";
You're telling the compiler that you will not modify it, and therefore the compiler can put it into read-only.
By instead doing
char str[] = "hello";
You're telling the compiler that you might want to modify it. The string will most likely still be stored in the read-only, but it will now be copied into a stack variable so that you can modify it, if you want to.
|
Oooh ok. I understood what you said the first time, but didn't realise that once declared that way, I could still use the pointer syntax when passing str to the function. Many thanks for your time and patience !
|
On October 26 2014 20:44 Cynry wrote:
Oooh ok. I understood what you said the first time, but didn't realise that once declared that way, I could still use the pointer syntax when passing str to the function. Many thanks for your time and patience !
You're welcome =)
|
On October 26 2014 19:55 Cynry wrote:I thought that char str[] = "hello";
ft_strclr(&str[0]);
would be equivalent to char *str = "hello";
ft_strclr(str);
would be the same except that I would be able to modifiy the string in the first exemple, avoiding the error that brought me here in the first place because of the second exemple. Show nested quote +And here is a case of an array not being the same as a pointer.
One way to view the use of a string literal, is that it will be expanded into something like this
char[6] str = {'h', 'e', 'l', 'l', 'o', '\0'};
That's where your char[6] comes from.
Why do you think that where the while loop stop holds any significance? I misinterpreted the error. Thought that char[6] pointed to the 7th character (starting at char[0]) and that the while loop was responsible for the error, trying to go too far or something like that (would have been another segfault I guess). Now if I understand correctly, char[6] simply is an array of 6 char, \0 included, and the error comes from the fact that ft_strclr returns a char *. Correct ?
str[6] would point to the 7th character, char[6] is a type. You might want to perhaps make some more descriptive variable names, this way you won't confuse them with other things while reading error messages.
|
On October 26 2014 21:02 Manit0u wrote:Show nested quote +On October 26 2014 19:55 Cynry wrote:I thought that char str[] = "hello";
ft_strclr(&str[0]);
would be equivalent to char *str = "hello";
ft_strclr(str);
would be the same except that I would be able to modifiy the string in the first exemple, avoiding the error that brought me here in the first place because of the second exemple. And here is a case of an array not being the same as a pointer.
One way to view the use of a string literal, is that it will be expanded into something like this
char[6] str = {'h', 'e', 'l', 'l', 'o', '\0'};
That's where your char[6] comes from.
Why do you think that where the while loop stop holds any significance? I misinterpreted the error. Thought that char[6] pointed to the 7th character (starting at char[0]) and that the while loop was responsible for the error, trying to go too far or something like that (would have been another segfault I guess). Now if I understand correctly, char[6] simply is an array of 6 char, \0 included, and the error comes from the fact that ft_strclr returns a char *. Correct ? str[6] would point to the 7th character, char[6] is a type. You might want to perhaps make some more descriptive variable names, this way you won't confuse them with other things while reading error messages.
Well, to be honest, as much as your advice is sound, this was pure stupidity on my end. There were no variable named char in my code, should have been obvious... Thanks anyway 
|
That's how I learned to stop using variable names like "str", "arr" etc. 
And it's still oh so tempting...
|
On October 26 2014 21:46 Manit0u wrote:That's how I learned to stop using variable names like "str", "arr" etc. And it's still oh so tempting...
Haha, a good programmer is a lazy one they said, I guess the saying has its limits ^^
|
reading vague variables from another person's code can kill a man
|
On October 26 2014 22:09 Cynry wrote:Show nested quote +On October 26 2014 21:46 Manit0u wrote:That's how I learned to stop using variable names like "str", "arr" etc. And it's still oh so tempting... Haha, a good programmer is a lazy one they said, I guess the saying has its limits ^^
Actually that's still true for variable names. Choose them wisely now and save yourself hours later on when you have to change/fix the code. Being lazy doesn't imply being shortsighted.
|
You haven't really worked with legacy code if you haven't had to fix code containing variables called "temp" that were reused 5 times in the same block of code and contained crucial data at various points.
My favorite line of code concerning variable names was still:
global $allowASDFXYZ1234 // IMPORTANT: Do not delete
|
On October 26 2014 22:20 Morfildur wrote:You haven't really worked with legacy code if you haven't had to fix code containing variables called "temp" that were reused 5 times in the same block of code and contained crucial data at various points. My favorite line of code concerning variable names was still: global $allowASDFXYZ1234 // IMPORTANT: Do not delete
At least that's a pretty unique name. I was once updating some really bad code written 20 years ago with a lot of variables named a, b, c and so forth... Trying to find all occurrences of a given variable was a lot of pain, especially that there were hundreds of functions in each file and many were reusing those variable names.
What made it a bit easier was the fact that I could simply delete 70% of the code since it was using deprecated methods that were made obsolete 10 years prior to me working on it.
|
On October 26 2014 22:16 spinesheath wrote:Show nested quote +On October 26 2014 22:09 Cynry wrote:On October 26 2014 21:46 Manit0u wrote:That's how I learned to stop using variable names like "str", "arr" etc. And it's still oh so tempting... Haha, a good programmer is a lazy one they said, I guess the saying has its limits ^^ Actually that's still true for variable names. Choose them wisely now and save yourself hours later on when you have to change/fix the code. Being lazy doesn't imply being shortsighted.
Very good point !
Just wondering, is there any standard concerning variable naming ? Or some sort of guideline, compendium of common sense, anything that I could try to apply in my early coder life ?
Coding standards in my school strongly encourage using explicit names, unfortunately it's not enforced. As I'll have to correct and be corrected by our peers, I'd rather start coding in a readable manner from the get go. And if it's something that I can share with said peers, all the better.
|
On October 26 2014 23:23 Manit0u wrote:Show nested quote +On October 26 2014 22:20 Morfildur wrote:You haven't really worked with legacy code if you haven't had to fix code containing variables called "temp" that were reused 5 times in the same block of code and contained crucial data at various points. My favorite line of code concerning variable names was still: global $allowASDFXYZ1234 // IMPORTANT: Do not delete At least that's a pretty unique name. I was once updating some really bad code written 20 years ago with a lot of variables named a, b, c and so forth... Trying to find all occurrences of a given variable was a lot of pain, especially that there were hundreds of functions in each file and many were reusing those variable names. What made it a bit easier was the fact that I could simply delete 70% of the code since it was using deprecated methods that were made obsolete 10 years prior to me working on it.
No syntax-aware search? Or whatever you'd call that.
As for naming guidelines... Do you need a comment or read more than a single line of code to make it clear what the variable does? Then it's named badly.
|
the real question is why the school forbids for loops but allows while loops.
At least they should be consistently retarded and force goto.
|
On October 26 2014 23:33 Cynry wrote:Show nested quote +On October 26 2014 22:16 spinesheath wrote:On October 26 2014 22:09 Cynry wrote:On October 26 2014 21:46 Manit0u wrote:That's how I learned to stop using variable names like "str", "arr" etc. And it's still oh so tempting... Haha, a good programmer is a lazy one they said, I guess the saying has its limits ^^ Actually that's still true for variable names. Choose them wisely now and save yourself hours later on when you have to change/fix the code. Being lazy doesn't imply being shortsighted. Very good point ! Just wondering, is there any standard concerning variable naming ? Or some sort of guideline, compendium of common sense, anything that I could try to apply in my early coder life ? Coding standards in my school strongly encourage using explicit names, unfortunately it's not enforced. As I'll have to correct and be corrected by our peers, I'd rather start coding in a readable manner from the get go. And if it's something that I can share with said peers, all the better.
If it is code that only really you, or you and one other person will ever read/have to make sense of, name it whatever you want (1 character names are for the lazy).
If it is code that will have to be maintained for a long time, it should be 100% clear what the variable is/does by the name.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Naming is a reference that will do you well to follow.
|
you never know how long you need the code or how many people will need to read it.
|
On October 27 2014 00:31 LaNague wrote:
the real question is why the school forbids for loops but allows while loops.
At least they should be consistently retarded and force goto.
To quote them about the for/while : "it landed on tail." Yup. Goto is forbidden too. If I can get a hold on an english version of the school standard's, I'll post them here, it should give you guys a good laugh.
Edit : Doesn't seem to exist, so here are the good bits :
No more than 25 lines per functions, excluding the starting and ending {}.
No more than 80 characters per line. A tabulation is 4 characters.
1 instruction per line.
1 variable declaration per line.
No declaration and instanciation (? not sure about the english translation) on the same line.
Declarations are to be placed at the beginning of functions.
No more than 4 parameters per functions.
No more than 5 variables declared per functions.
For, do...while, switch, case, goto are forbidden.
No more than 5 functions per .c
No wildcards in Makefiles.
These are the ones that seems the most restricting to me. There's plenty of stuff outside of how we should write our code that is equally as fun as those...
Still, this method has been in use for many years in one of the best french programming school (epitech), so I wouldn't label that as retarded straight away. It's definitely different, but it's exactly what they were aiming for... And for a complete beginner like me (and many other students), it's not that bad.
As for the gotos, if I understood correctly, we'll get plenty of that when we'll use the Assembly langage...
To the one that gave a link to some naming standards, thank you !
|
I was once working with someone else's code. His variable naming was very helpful and consistent (even more helpful than good names). Every input and output was in the name, so was the variable type (e. g. "s_somestring_in", "i_someint_out", "f_somefloat" - variable with local scope that's neither function param nor is return value etc.). Makes it really easy to follow, the only problem is when you want to change the variable type, as you then have to rename all occurances.
Was nice to work with it since at all times you knew exactly if you're dealing with variable that has been passed to the function, a variable that will be returned or something temporary.
|
|
|
|
|
|
EPT
