|
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 30 2014 01:48 Morfildur wrote:Show nested quote +On October 30 2014 01:14 LaNague wrote:
you are free to write in assembler if you dont like prose.
But most workplaces will use other languages where you can be more productive with. The reason why languages won't become much closer to prose is because spoken language has a huge amount of ambiguities, which simply don't work in programming languages. A programming language has to be precise, so while you can change "{" to "begin" or indent several lines, it's still simply a different syntax for a very precise concept. If you just want words instead of symbols, there are C preprocessor macros that can do it for you.
#define begin {
#define end }
#define is =
#define is_not !=
...
I'd say that functional languages are the closest to spoken language because they work directly with concepts instead of abstraction, e.g. "let x be y and do z with it", even though they have a lot more "syntax" than e.g. python. However, even they are bound by the precision required to turn it into something the computer can work with. While computers can "understand" spoken language, i.e. prose, it's not usable for the actual programming.
No, that's the reason programming languages aren't currently closer to prose. As natural language understanding becomes better, there will be a time when it's worth it to just talk to your computer about what you want your program to do, and it will be called "coding".
Otherwise you're right, functional languages are the closest to prose, albeit an overly formal one ;D
On October 30 2014 03:07 Blisse wrote:Show nested quote +On October 29 2014 22:02 Morfildur wrote:On October 29 2014 10:11 Blisse wrote:
Do you think the future of coding will be 5K to 8K monitors? :3 Programming probably benefits a lot more from additional monitors compared to bigger or higher resolution monitors. The physical separation really helps a lot, e.g. when making changes and watching them on the second monitor or when having the documentation *cough*or stackoverflow*cough* on one screen and the code you are writing on the other. I'd say that any programmer working with just one monitor, whether it's 1k, 2k, 4k, 8k or 128k is hurting his own productivity (and enjoyment). I just don't understand why you guys think that using 4K means you'll see less. Using the shitty 4K 39" Seiko or good 32" Dell, 4K is still 4x more space than 1 1080p screen, so even with 3 1080p screens you're still only approaching one 4K screen. You can have more than one browser or code editor open at the same time on one 4K screen so I don't understand the argument against it.
There is no possible argument against more pixel density, assuming your OS has a good UI scaling framework and your computer still has the same power consumption and overall performances.
The thing is, there is no argument for either, in the case of reading text. Increasing pixel density helps us display smaller details. While it's all cool for a movie, pictures and video games, it's completely useless for fonts. Higher pixel density simply means that you can fit more text in a square inch of your screen. But past a point, a font needs to be of a certain minimal physical size to be readable. We just want to fit on our screen the maximum amount of characters we can read comfortably with our naked eye. And we're already there.
Edit: And by the way, there will come a point (we're probably not far at all) where we can't distinguish with our naked eye a certain pixel density from a higher pixel density. This is true for movies or pictures or whatever you display on your screen. Currently you can certainly distinguish text displayed on a 720p screen from one displayed on a 1080p screen, but you don't really read them any easier/harder.
Edit2: I understand that it may seem like I'm making a confusion between pixel density ("300 ppi") and resolution ("4K"). I'm not :D. Advertising and marketing are making this confusion for consumers though. Today when we talk about how "4K" and how amazing it looks, we're really talking about monitors with the same size as before but with more pixels, hence a higher pixel density. We're not talking about screens that are 4 times larger because it doesn't make any sense and it's not that interesting. Do I have any use for a 45 inch desktop monitor? Hmm probably not. But sure, if you like theater screens to code, you damn sure need your 4K, go ahead.
|
Hey guys !
Yet another segfaulting function that I can't seem to figure out...
#include <stdlib.h>
#include <string.h>
char *ft_strjoin(char const *s1, char const *s2)
{
char *result;
unsigned int length;
unsigned int isrc;
unsigned int ires;
isrc = 0;
ires = 0;
length = ft_strlen(s1) + ft_strlen(s2) + 1;
result = NULL;
result = (char *)malloc(sizeof(result) * length);
while (s1)
{
result[ires] = s1[isrc];
ires++;
isrc++;
}
isrc = 0;
while (s2)
{
result[ires] = s2[isrc];
ires++;
isrc++;
}
result[ires] = '\0';
return (result);
}
int main(void)
{
const char s1[] = "hey ";
const char s2[] = "'sup ?";
char *result;
result = (char *)malloc(sizeof(result) * 11);
result = ft_strjoin(s1, s2);
ft_putstr((char const *)result);
}
Guess it's obvious, but strjoin is supposed to join 2 string together into a third one that I malloc and return. I suspect there's much better way to do it but that's what I came up with. And well, it doesn't work.
Halp ?
|
If you can code on a 14" 1080p laptop screen, then you can code just as perfectly well on a 28" 4K monitor. I don't know about you guys, but I'm not blind... you're acting like 4K at 27-32" screens makes your text minuscule. It doesn't.
@cynry,
1. in main, you allocated an array using malloc and then replaced it with a pointer. what's up with that?
2. your while loop ends when s1/s2 hits a \0. but you never actually increment s1/s2. you probably want
while (s1)
{
result[ires] = *s1;
ires++;
s1++;
}
edit: shoot, is sizeof(char) in c/c++ not sizeof(char*)? err, that as well then
|
On October 31 2014 18:51 Blisse wrote:If you can code on a 14" 1080p laptop screen, then you can code just as perfectly well on a 28" 4K monitor. I don't know about you guys, but I'm not blind... you're acting like 4K at 27-32" screens makes your text minuscule. It doesn't. @cynry, 1. in main, you allocated an array using malloc and then replaced it with a pointer. what's up with that? 2. your while loop ends when s1/s2 hits a \0. but you never actually increment s1/s2. you probably want
while (s1)
{
result[ires] = *s1;
ires++;
s1++;
}
1. Forgot to remove it, thought I might as well try to malloc the result in case it was what caused the error.
2. Very. Good. Point. ><
Edit : Tried your solution and still segfault.
So I did that :
while (s2[isrc])
{
result[ires] = s2[isrc];
ires++;
isrc++;
}
And it works.
Still wondering why your solution didn't. From the little I know about pointers it shouuuuuld ?
|
You should only malloc once - otherwise you leak those bytes.
Also, consider the diffence between sizeof(result) and sizeof(char).
But you should check your while loops, that's where the issue starts - a small hint - when do they terminate?
|
On October 31 2014 19:00 Cynry wrote:
And it works.
Still wondering why your solution didn't. From the little I know about pointers it shouuuuuld ?
it should be a while(*s1) not while(s1)
check your mallocs as well though, you're over-malloc-ing.
|
On October 31 2014 19:01 bangsholt wrote:
Also, consider the diffence between sizeof(result) and sizeof(char).
Oh I wanted to ask about that. Not the fact that I did a sizeof a pointer instead of a sizeof a char (now corrected), but about the differences between
sizeof(*result)
and
sizeof(char)
If I understood correctly, it's the exact same for the computer, both point to a char and should return 1. But I heard some people say the first one is better for portability. Can't pretend to understand exactly why, so I'd like to hear some thoughts about it.
Edit : Ok, it works with while(*s1). Much cleaner looking, thanks !
|
I don't see a call to free, isn't that missing as well? Sure, the program terminates right after so it doesn't really matter, but that's not a good reason to not free your resources.
|
On October 31 2014 19:20 spinesheath wrote:
I don't see a call to free, isn't that missing as well? Sure, the program terminates right after so it doesn't really matter, but that's not a good reason to not free your resources.
Would freeing right before the return of ft_strjoin work ?
I'm not too familiar with memory stuff yet, free "unlock" the memory but the data is still there, right ? So as long as nothing writes over it, I can still point to it and have the same result ?
Edit : This is where I'm at. Now with free, malloc check (I think ?) and an ending \n !
#include <stdlib.h>
#include <string.h>
char *ft_strjoin(char const *s1, char const *s2)
{
char *result;
unsigned int length;
unsigned int i;
i = 0;
length = ft_strlen(s1) + ft_strlen(s2) + 1;
result = (char *)malloc(sizeof(*result) * length);
if (!result)
return (NULL);
while (*s1)
{
result[i] = *s1;
i++;
s1++;
}
while (*s2)
{
result[i] = *s2;
i++;
s2++;
}
result[i] = '\0';
return (result);
}
int main(void)
{
char const s1[] = "heeeeeeey";
char const s2[] = " sexy lady !\n";
char const *result;
result = ft_strjoin(s1, s2);
ft_putstr((char const *)result);
free((char *)result);
}
|
It's better for portability but you don't really have to worry about it for the most part.
Using malloc(sizeof(*result)) is a lot more friendly to changes in code.
If you change the type of result (from char* result to int* result), you aren't forced to go find and change the now broken malloc(sizeof(char)) code to malloc(sizeof(char*)). sizeof(*result) handles that for you.
sizeof(*result) is also easier to type if you don't want to think about the malloc.
however, because it seems like you're writing a library of string formatting functions, you could totally make the case that you should use sizeof(char) here instead.
edit:
you need* to free the malloc at some point in your program before it ends. don't free it before you actually use it though, then you get unexpected results. the compiler decides whether it will zero/obfuscate free'd memory or leave it untouched, so it's a coinflip.
* you don't really need to do it but it's a good practice.
we talked about this in a previous page but it might be a good idea to prefix the pointer name if it's a malloc'd pointer. this makes sure it's clear that you malloc'd it, and that you need to free it at some point.
finally, it's a bad practice to use malloc in a different scope than where you would free it. this is because you can't tell the difference between a char* pointing to malloc'd memory or stack memory. we can circumvent this with good naming conventions but it's still a big problem. that's a reason why sometimes you'll see "void join(char* s1, char* s2, char* output)" rather than what you have. can't help it in assignments but good to think about.
edit final:
i'm not sure if you have the const correctness totally right (but i have no clue)
http://www.possibility.com/Cpp/const.html
nevermind this is C not C++
http://en.wikipedia.org/wiki/Const-correctness
|
On October 31 2014 19:12 Cynry wrote:Show nested quote +On October 31 2014 19:01 bangsholt wrote:
Also, consider the diffence between sizeof(result) and sizeof(char). Oh I wanted to ask about that. Not the fact that I did a sizeof a pointer instead of a sizeof a char (now corrected), but about the differences between sizeof(*result) and sizeof(char) If I understood correctly, it's the exact same for the computer, both point to a char and should return 1. But I heard some people say the first one is better for portability. Can't pretend to understand exactly why, so I'd like to hear some thoughts about it.
Have you tried to make a simple main that runs sizeof(char*) and sizeof(char) and looked at the result?
A pointer on a "newer" machine would usually be 4 or 8 bytes, when it's desktop.
A char is usually 1 byte.
So, no, both are not 1 byte.
On October 31 2014 19:24 Cynry wrote:Show nested quote +On October 31 2014 19:20 spinesheath wrote:
I don't see a call to free, isn't that missing as well? Sure, the program terminates right after so it doesn't really matter, but that's not a good reason to not free your resources. Would freeing right before the return of ft_strjoin work ? I'm not too familiar with memory stuff yet, free "unlock" the memory but the data is still there, right ? So as long as nothing writes over it, I can still point to it and have the same result ?
"So as long as nothing writes over it", yes.
But by free'ing you're allowing that memory to be used again - so it can be overwritten.
The solution is easy - don't free until you're done with what you've malloc'ed.
|
@bang, he has sizeof(*result) so he's dereferencing the pointer already
|
Changed a bunch of stuff that I edited in my previous post.
int main(void)
{
char *wtv;
ft_putnbr(sizeof(char));
ft_putnbr(sizeof(char*));
ft_putnbr(sizeof(*wtv));
ft_putnbr(sizeof(wtv));
}
This returns 1, 4, 1, 4. So you're right about char and char* being different but it's not really what we talked about.
|
Poll: What do you do? (and why)return result; (9) 90% return(result); (1) 10% 10 total votes Your vote: What do you do? (and why) (Vote): return result;
(Vote): return(result);
|
On October 31 2014 19:25 Blisse wrote:finally, it's a bad practice to use malloc in a different scope than where you would free it. this is because you can't tell the difference between a char* pointing to malloc'd memory or stack memory. we can circumvent this with good naming conventions but it's still a big problem. that's a reason why sometimes you'll see "void join(char* s1, char* s2, char* output)" rather than what you have. can't help it in assignments but good to think about.
So, because free is coin-flippy (so no free before the return of strjoin) and what I quoted, there's no clean way to free what I malloc-ed in this case ?
Especially considering that I musn't include the main when I return the assignment...
Edit : return (result) for me, and I don't know why :D
|
The only time I ever have parentheses around my return value is when I had a complex statement as a return value that requires parentheses at some time, modified that statement and forgot to remove the now pointless parentheses.
Return is not a function and I doubt it's a good idea to make it look like one.
|
Referencing Manitou's post in the funny pictures thread :
The two states of beginners in C
"I am a God" || "segfault"
....
Soooo here's another one. Don't worry, once I'm actually in school (I'm just getting ahead in work right now, school year still hasen't started) I'll have plenty of students to bother with my questions.
strtim, removes ' ', '\n', '\t' at the start and the end of a string and returns a copy of the result. But that doesn't matter, the error seems to come from my strlen or something around it. Way before the actual algorythm anyway, which should have plenty of other surprises...
#include <stdlib.h>
#include <string.h>
char *ft_strtrim(char const *s)
{
unsigned int isrc;
unsigned int ires;
unsigned int len;
char *res;
isrc = 0;
ires = 0;
len = ft_strlen(s);
/** while (s[isrc] == ' ' || s[isrc] == '\n' || s[isrc] == '\t')
isrc++;
while (s[len] == ' ' || s[len] == '\n' || s[len] == '\t')
len--;
res = (char *)malloc(sizeof(*res) * (ft_strlen(s) - (isrc + len) + 1));
while (isrc <= len)
{
res[ires] = s[isrc];
isrc++;
ires++;
}
res[ires] = '\0';
return (res);
**/
}
int main(void)
{
char const test1[] = " ha ha ha ";
char const test2[] = "ho ho ho . \n ";
char const test3[] = "nothing here";
char const test4[] = "\t what is \t I don't even know...";
char *result;
result = ft_strtrim(test1);
ft_putstr(result);
ft_putchar('\n');
/** result = ft_strtrim(test2);
ft_putstr((char const *)result);
ft_putchar('\n');
result = ft_strtrim(test3);
ft_putstr((char const *)result);
ft_putchar('\n');
result = ft_strtrim(test4);
ft_putstr((char const *)result);
ft_putchar('\n');
**/
My strlen :
#include <string.h>
size_t ft_strlen(char const *s)
{
size_t length;
length = 0;
if (!s)
return (0);
while (s[length])
length++;
return (length);
}
Behaviour :
If I remove either call to strlen from strtrim or its main, it works. Both, and segfault.
If I comment the while loop of strlen, it works with both call to it.
If I comment the call to ft_putstr from the main, it works with both call to strlen. putstr also has a call to strlen, but I can't really comment it.
Sooo... Waddafuck ?
Edit : just in case, I now know what is \t, so disregard that.
|
|
|
Your strlen can't deal with an empty string.
|
On October 31 2014 23:47 Alzadar wrote:
Your strlen can't deal with an empty string.
if (!s)
return (0);
Thought that would do the trick, is that wrong ?
Are you sure that the problem isn't the fact that you're not returning anything in ft_strtrim?
EDIT: Instead of giving this thread one doghunt with snippets of code and stuff every day, this is the ideal time to learn how to use a debugger... when you're still making a lot of mistakes
EDIT2: Question to the C wizards in this thread. If nothing is returned in a non-void function (like in this case), no compiler warnings seems to be given. Why? And what does it return, null?
There is actually a warning for that, but I think it doesn't display by default with gcc. Some flag makes it treated as an error.
Indeed, un-commenting the return of strtrim makes it better. Thing is, with the whole program I got segfault, and I assumed it was the same error I got when commenting most of the code. Silly me :D
Now, debugger, that sounds great ! Didn't even knew it existed...
|
|
|
|
|
|
EPT
