C was a mistake

>>60015356
Anon, you was a mistake. Sure, modern hardware allows you to write shit without thinking about performance much, but C (or at least C++) will allow you to have a drastically higher level of optimization when you'll really need one, without being ASM.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gcc&lang2=java

>>60015356
You are writing an assignment.
You are supposed to write basic wheel reinventing functions.

>>60015390
>>60015420
My point is, that such function doesn't exist *ANYWHERE*, so you have to write it yourself even when working on complicated project for your work, if you need the program to be portable. It should be part of standart library

>>60015356
That took you a whole hour?

> line of dynamic size

Uwotm8?

Let me just make this clear -- for you and anyone who thinks your bait looks tasty -

YOU are not a programmer.
YOU know jack shit about how a computer works.
You know jack shit about languages and have no business commenting anything other than the weather.

/thread

>>60015356
>spent the first hour coding function for removing leading and trailing whitespaces
Are you joking, anon?

If it truly took you an hour then that alone is the very reason this was a very much needed assignment.

Not all tasks are solved by pulling in 24 MB libraries.

>>60015356
>Do C programmers keep reinventing the wheel again and again?
No, we use well-known libraries.

>We are forced to use C99, so now I have to write a function that reads line of dynamic size from file.
That's because you're learning C in a C class, you fucking pleb. It's not like learning Java in a Java class makes you an expert on modern software development.

>>60015506
See above. When you work on real life projects you use libraries that are portable between the platforms you target.

If you need universal portability, you shouldn't be using C at all. C is a programming language intended to be a human readable and portable assembly, so you use it for low level stuff and not as some generic multipurpose tool.

Oh, and btw. Skilled C programmers implement trim() in 5 minutes or less. You are a beginner, and the restrictions in your class aren't representable for real life C development.

>>60015595
Not OP, but but of curiosity can you show your implementation? Would you scan each letter in the string and build a new string? How do you handle different encodings like UTF8 vs ansi?

>>60015650
>Not OP, but but of curiosity can you show your implementation?
No need, there is one in K&R second edition.

>Would you scan each letter in the string and build a new string?
Either that, or you can do it in-place (but mind the consts).

>How do you handle different encodings like UTF8 vs ansi?
For multibyte strings (such as UTF8), I only consider ASCII whitespace as whitespace to be removed. Thus you don't need to handle it any particular way (at least not with UTF8).

For wide chars, you'd need to implement a different version for them because of a different datatype, but the logic would pretty much be identical.

>>60015595
C99 is shit. Use only C89.

>>>/pythonista/

>>60015685
Do you have to look at the head of the string to know if it's multi byte? Can you mix encodings of strings in a C program?

I haven't done C code in something like 20 years when I used to do mixed c and objective c on NeXT. It would be pretty embarrassing if someone asked me to write a trim function.

>>60015356
you need to get some libraries

https://developer.gnome.org/glib/

>>60015750
>Do you have to look at the head of the string to know if it's multi byte?
There's no way of determining if a string is multibyte or not by simply looking at it, no. Of course, you can look for stuff like byte order mark and UTF8 escape sequences and things like that, but generally when using multibyte strings you need to know what kind of format it is yourself.

>Can you mix encodings of strings in a C program?
Yes, but like anything else in C, it's generally a pain and you'd like to use a library to do stuff like that.

>>60015595
are you the same guy posting on my ubuntu thread?

> see above

>>60015750
For example, would a half-space character in Farsi be trimmed? I guess it probably shouldn't be at the head or tail of the string in the first space, but a half-space changes how a string is displayed based on what's next so it probably isn't trimmed...

I think as I gain more experience in life I become less sure of myself and think things through too much.

>>60015800
If there are chars >= 0x7F, you know that it's not a ascii string. That's the only easy information to extract.

>>60015825
Yeah, that's pretty much it.

>>60015801
Maybe? Which post.

>>60015356

>>spent the first hour coding function for removing leading and trailing whitespaces (trim()) from string because it doesn't exist in any standard C library
I mean, it can't be that hard can it?

char* start = raw_string;
while (is_whitespace(start))
    start++;

// Initialise end to point to null terminator
char* end = start;
while (*end)
    end++;

while (is_whitespace(end))
    end--;

// Copy the substring you want to a new string
char* trimmed_string = malloc((end - start + 1) * sizeof(char));
memcpy(trimmed_string, start, end - start);
trimmed_string[end - start] = 0;

I don't really know C but would something that looks like that work?

>>60016436

oh fug, I forgot to dereference start and end in the while conditions

>>60015356
>spent the first hour coding function for removing leading and trailing whitespaces (trim()) from string
Behold the Rust programmer who gets shit done with his quality language and knows exactly why other languages suck!

>>60015356
>>writing assignment in C
I'd rather use ASM. C is pure garbage

>>60015356
> hour