/c/

...

Other urls found in this thread:

port70.net/~nsz/c/
open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf
isocpp.org/wiki/faq/containers#arrays-are-evil
pastebin.com/cpAGvn8U
pastebin.com/s0jDEWfp
twitter.com/AnonBabble

lmao wtf, are these smelly neckbeards still writing C?
proc reverse(s): string =
result = newString(s.len)
for i,c in s:
result[s.high - i] = c

proc isPalindrome(s): bool =
s == reverse(s)

echo isPalindrome("FoobooF")

Is the C standard "available" somewhere, i.e. at no charge? Preferably ANSI C89 or ISO C90.

>copying the string

the drafts are free, the final copies cost like $50
here's some nice HTML formatted versions
port70.net/~nsz/c/

You don't even have to reverse the string on a palindrome checker
unsigned i, j;
for (i = 0; j = strlen(s) - 1; s[i]; i++, j--)
if (s[i] != s[j])
return 0;
return 1;

>the final copies cost like $50
Are C and C++ the only langauges with such a jewish approach standards?

>three semicolons within the parentheses
>s[i] as loop condition
the fuck

You can find the final drafts of the standard (which is basically the same as the real thing) from the openstd website.
Here is C11: open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

Many programming languages are formally standardized, not just C.

int is_palindrome(const char *str)
{
unsigned i, j = strlen(str) - 1;
for (i = 0; str[i]; i++, j--)
if (str[i] != str[j])
return 0;
return 1;
}

That's 2 semicolons.
You can have any number of expressions concatenated with the comma operator.
Only the final expression will be used as a return value in complex higher order conditional statements.

str[i] as the loop condition is the same as writing while str[i] != NULL, it'll stop as soon as it hits a null terminator and is much more concise than using the length of the string, though checking palindromes requires it anyway.

Not him but s[i] makes sense as a loop condition since c strings end in null characters. Hence, at the end of the string, s[i] = NULL, and the loop terminates.

>Many programming languages are formally standardized
They also have the final version of the standard available for free.

The draft and the final copy are basically identical though?

You don't even need to read the standard unless you're a compiler writer or autistic or both.

Still, (((final copy)))

>reversing the string
>this is how stupid anti-C shills actually are

yo pls help why doesnt this always completely copy the string?
#include
#include
#define MAX 100
unsigned i, l;
char repeat[MAX], src[MAX];
int main(int argc, char const *argv[]){
strcpy(src, argv[1]);
l = strlen(src) + 1;
src[l - 1] = '\n';
src[l] = 0;
for(i = 0; i < MAX; i += l)
memcpy(repeat + i, src, l);
repeat[MAX - 1] = 0;
puts(repeat);
return 0;
}

output:
(omited)
...
uhhhh
uhhhh
uhh

>memcpy-ing one byte at a time

i memcpy the whole string though

Step by step debug it and see what happens to the arrays. Your code code goes out of bounds by the way.

God damn, there is so much wrong with this code.
I don't have anything better to do right now, so I guess I'll nit-pick it.

>#include
-This is not being used for anything.
-You're missing #include required for using puts
>unsigned i, l;
>char repeat[MAX], src[MAX];
There is no need for these to be global variables.
-char const *argv[]
This isn't "wrong", but this does not need to be const.
>argv[1]
-You're not checking if you actually have any arguments (with argc), so this may index past the end of argv.
>strcpy(src, argv[1]);
This is an unsafe string copy, and may lead to a buffer overflow if the string is long enough. You should use a bounded copy function like strncpy or better yet, snprintf.
>l = strlen(src) + 1;
The "correct" return type for strlen is size_t, not unsigned.
>src[l - 1] = '\n';
This will overwrite the last character of your string, and I think that's not what you actually wanted to do.
>for(i = 0;
You should declare the loop variable in the loop itself when you can: for (unsigned i = 0;
>memcpy(repeat + i, src, l);
I'm not huge on using mem* functions on strings, but it's not wrong.
This might write past the end of repeat on the final iteration.

It's not wrong, but it is a pretty retarded way of going about it. Why wouldn't you just copy the contents of the char array to another char array?

not holy enoght

its a program that is designed to have arguments. there is no need to check. thanks for strlen

I didn't even try to read your code, so I rewrote it for you in proper C.
#include
#include
#include
#define MAX 100
int main(int argc, char **argv)
{
if (!argv[1])
return 1;
unsigned i, idx = 0, len = strlen(argv[1]);
unsigned final_len = MAX * (len + 1);
char *out = malloc(final_len + 1);
for (i = 0; i < MAX; i++)
{
memcpy(&out[idx], argv[1], len);
out[idx + len] = '\n';
idx += len + 1;
}
out[final_len] = '\0';
printf("%s", out);
free(out);
return 0;
}

#include

#define MAX 100

int main(int argc, char *argv[])
{
if (argc != 2)
return 1;

for (int i = 0; i < MAX;) {
i += printf("%.*s\n", MAX - i, argv[1]);
}
}

>proper C
>printf instead of puts

Most of the flaws you listed could be solved by using c++ instead of c. Arrays are evil -- there's std::string and std::vector.

Kill yourself.

>he doesn't know that you can represent a binary tree as an array, thus acing his coding interviews

No wonder you're unemployed, you dumb liberal arts dum dum

Not checking for length can happen to arrays also, mistakenly overwriting elements can happen to arrays also.

>using dynamic memory for everything
at least use std::array moron.

...

Just write a vector implementation in C, it takes all of 2 minutes.
If you want to get fancy, you can even grow the vector by 1.25x the length every time you fill the array.

>he doesn't realise k&r hello world uses printf
>he doesn't realise gcc optimises calls to single strings in printf into puts for you anyway

>std::string and std::vector.
slow working Jewish bait

how do i bit shift muh dick into generic_female?

Should Stroustrup kill himself too?
isocpp.org/wiki/faq/containers#arrays-are-evil

They're openly available in pdf form.
Not excusing the price, it's quite ridiculous. Just informing.

>Should Stroustrup kill himself too?
Definitely. That bald danish gnome pulled programming 30 years into the past.

But user, arrays ARE evil

I wouldn't mind.

>std::array vs std::vector
Is one stack and one heap allocated?
I was assuming std::vector was at least stack allocated for small sizes.

std::array is literally just a C array but without retardation like decay and some other functions defined for it.
std::vector is a pointer-size-capacity triple that uses heap allocation. There's no guarantee that there's a small size optimization like that, but such an optimization is only terribly useful for vectors of chars or bools, which is probably already done by std::string.

>that uses heap allocation
Can't you write a custom allocator that uses memory from the stack and pass it as a template parameter to the vector?

why i forced to use all this retarded abstractions if all this shit force me return back to basic C to use it?
it Jewish bait for retardeses
if you retard so use Java
if you normal - use HolyC
C++ bait for retardeses/tool for evil jews to make easy things complex

You could I guess, but what would be the point? Might as well use a VLA at that point which, while not standard C++, is supported by the only compilers which matter and much more readable.

Give me one good reason why you don't purposefully write C code so as to be completely incompatible with sepples shitters attempting to include your pure C libraries in their projects?

#include
#include

template
__attribute__((noinline)) void print(std::array &arr)
{
for (size_t i = 0; i < N; ++i)
printf("%d\n", arr[i]);
}

int main()
{
std::array a = {1, 2, 3, 4, 5};
std::array b = {9, 8, 7, 6, 5, 4, 3, 2, 1, 0};

print(a);
print(b);
}
Compiled with g++ -O3 -S shit.cc
pastebin.com/cpAGvn8U
It fucking generates two copies of the function.
How the fuck can you possibly defend that?

all auto memory mangement in C++ -> dead born feature
have not any complex software who use this and dont have memory leak/crashes

Because C++ has good features and I want to use C++ features.

I've actually done that.
I make sure to include small things like C99 VLA arguments and naming struct members things like 'class'.

>I only just found out what templates do.
Write a slice template, fag.

I know what a fucking template is.
But fucking generating a new function for every possible array size?
That's beyond retarded.

That's pretty awful. Imagine the amount of instruction fetching that'd happen.
Luckily for array specific data you're not gonna fetch that much but I share your woes friend.
Where in the standard does it say template instantiations on different types are forced to generate unique calls?
There's no reason for that here as far as I can see.

I hit post too early.
That is the "better" code that the danish meme gnome proposed.

>you're not gonna fetch that much
Per element, to be clear.

That's super obvious and expected. array and are different types, thus two different functions.

OBJ example in C
pastebin.com/s0jDEWfp

Templates were a fucking mistake.

I'm trying to convert an int to a char.

I have an int, lets say 134, then I ake that number mod 26, and I want to turn the result into a char. But my code below prints out a blank space where %c would be, any ideas?

int result = 134;
result = result % 26;
char r_c = (char) result;
printf("CHAR: %c\n", r_c);

I'm not gonna defend that. Bloating your object code with a load of redundant functions is shit.
However if the function is short enough that inlining is going to cost less than a function call, then there's no point not to make it a template.
In all other cases, use a slice like I suggested.

OBJ example in C
pastebin.com/s0jDEWfp

134 % 26 = 4.
4 is a non-printing ASCII control character (end of transmission).

std::array works that way. If there was a class template without size as a template parameter, it wouldn't generate multiple functions.

134 % 26 = 4
4 = ASCII 'end of transmission' i.e. a control character, not a visible character; ergo when printed your terminal puts a visible space but not a real character.

The alphabet in ascii starts at 0x41 for uppercase and 0x61 for lowercase.

Learn how to look up the ASCII table from time to time.

thanks im dumb

Enjoy your ungodly amounts of object code bloat, you shit-eater.

Don't say that user anyone can make a mistake.

Sometimes you want an AK-47, other times you want a scalpel.

So is the correct prototype of main
int main(int argc, char *argv[])
or
int main(int argc, char **argv)
I think the former is more semantically correct because argv is an array of strings not a pointer to a string.

>The year is 2017
>Using C

It's even better - every instance of std::array with different size generates its own pile of code.
I don't use it though.

They are both equivalent and valid.
I'm more of a fan of the first.

There still is no viable replacement for C.

It shouldn't matter. Deep down inside a compiler argv[] becomes a pointer anyway.

I prefer the latter. In general I don't use """array""" parameters.

I don't think you should think of it like that at all.
In some sense [][] or ** is better because it's a null terminated array of pointers to null terminated strings.
I think that signifies their similarity better. I don't care at all what you use though. Try to be consistent though. I use *argv[]. Mainly because I didn't understand better before I think. I thought it was required.

What is C++?

>Not using C99 static syntax
$ cat test.c
#include

void fn(int arr[static 10])
{
}

int main()
{
int arr[5];
fn(arr);
fn(NULL);
}
$ clang test.c
test.c:10:2: warning: array argument is too small; contains 5 elements, callee requires at least 10 [-Warray-bounds]
fn(arr);
^ ~~~
test.c:3:13: note: callee declares array parameter as static here
void fn(int arr[static 10])
^ ~~~~~~~~~~~
test.c:11:2: warning: null passed to a callee that requires a non-null argument [-Wnonnull]
fn(NULL);
^ ~~~~
test.c:3:13: note: callee declares array parameter as static here
void fn(int arr[static 10])
^ ~~~~~~~~~~~
2 warnings generated.

C has already been replaced everywhere outside the low-level shit, and Rust is going to replace it there.

You can't be serious.

How do you distinguish arrays from double pointers if you use ** for both?

But the perception of [][] is more that of a 2D array, which argv is certainly not. And I've always perceived ** as double pointer, i.e. for pointers that can be updated by a funciton.

Not a language you can write a kernel or UEFI program in

absolute heresy, you MUST specify void for functions without arguments.

*argv[] is only semantically different from **argv when it's not a function parameter, because it refers to a stack array of type char * and not a decayed simple pointer to pointer to char *

Since main() is a function, **argv is the most consistent usage.

>Significantly slower than C
>Doesn't even have a stable ABI
>Tied to LLVM
>Restricts the programmer massively
>SJW-infested community
Yeah, there is no chance in hell that Rust is replacing C.

The distinction is already lost when you pass them into functions. There is no such thing as an array parameter, and I prefer to be clear in my declarations than tell a comforting lie.

>Not a language you can write a kernel or UEFI program in
Why would you post something factually false as an argument?
>Significantly slower than C
False.
>Doesn't even have a stable ABI
It does, it's called C calling convention. C doesn't have a copyright on it, you know.
>Tied to LLVM
What does it matter which technology the compiler uses? There are no run-time ties to LLVM in any way.
>Restricts the programmer massively
So does static typing in general, you can go back to pre-C89 if you don't like "restrictions".
>SJW-infested community
Not an argument, unless you're a Sup Forumstard.

>Not a language you can write a kernel or UEFI program in
What makes you say that?

>strcpy

>double pointers
Well double in directed values are usually not distinguished by type for me but rather by use/name. And usually they're packed in something so I don't find it problematic.
And for chars especially I consider them a special case. I can't think of the last time I used them outside of strings/in association with strings. A double indirection
>[][] is more of a 2D array
Perhaps. I haven't found this worth putting much thought to. Treating argv especially isn't much overhead.

I'm the kind of person that does find C's type system lacking though. I don't take it as seriously as I could. Perhaps that's why it doesn't strike me as important.

I think that the kind of people that make the community making decisions for the language is important no matter what board you visit.

Opinions on JAI (I'm watching the steam)? I know we're a very conservative group but I like it. The detailed semantics I find less attractive but a compiler that exposes its innards well is very attractive to me. I haven't found C++ pleasing for many of the reasons he has mentioned (and more) and overall I find that me an John agree on a lot of design experiences aswell so it gives me faith.

the borrow checker is much more restrictive than static typing in general (which C has anyway)

the fuck is that unreadable blobby mess code you have there?

It seems interesting, but until he actually fucking releases the compiler, I'm just going to consider it vaporware.

It's not quite technically correct, but let me quote Torvalds "In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C."

C++ has changed a lot in the 10 years since that was said. So has Torvalds' opinion

Please post a link to the updated Torvalds opinion.
>C++ has changed a lot in the 10 years
All of the new garbage C++ added makes it even more inappropriate for low-level (or any level) development.

>citing Torvalds as an authority on anything outside the kernel
He's not. Also look at the kernel itself, it's full of poorly-implemented OOP and shitty attempts at generic code, something that would be much more cleaner in C++.

Fair enough. He keeps saying he's saving people's time. I watched a talk he had where he brought up how development has stagnated (very general point pointing out the massive effort of going to the moon compared to what we consider major successes today that are by that reference minor).
I think that more grand idea of the world has made him adverse to wasting people's time. As he'd certainly see other people's languages doing.

Of course if his language doesn't take off in a significant way it'd be a waste of time too. I view the current public development to be more of a PR stunt though. It's obvious he did a lot of work when he shut up about it.

Has it changed to make it more viable as a systems programming language or rather the opposite?

Is cleanliness what really matters here?

Let's say I want to write a library with a context handle struct that has lots of member functions in it.
What's the best way to write this without wasting hundreds of bytes on repeated function function pointers if I later decide to make an array of these context handle structs?
I'm not sure a vtable is the best option either, you're still wasting 8 bytes on the same pointer in every struct.