C style strings or C++ style strings?

and only bad programmers would unironically defend c-strings (and optionally go the extra length to program around the inherent security flaws), so that makes perfect sense.

What sane person would use C strings.

Imagine if you had to keep up with how many digits long an int was going to be.
Think of how much slower ALL of your code would be.

Attached: what (2).jpg (198x200, 9K)

memory is cheap

2^32 = 4294967296 = 10 digits + null = 11 chars

>memory is cheap
sounds like you sir went to a coding camp kek

>he thinks disk space and memory is used efficiently by ANY program
sounds like I know how computers work and how to write readable & maintainable software.

Imagine not using C strings and having memory leaks.

Pascal arrays

what kind of limp wristed code-artisan uses strings in their code anyway? heh fuckin' front end wwwebshit losers

Attached: 1519765111084.jpg (690x460, 62K)

Unix was born to process strings

Are ropes any better?

nope, a rope is a data structure for manipulating a string in a certain way

A lot of strings used in programs are constants (user displays, field labels, stuff you have to write out) and ropes are not useful in that case

>zhang
into the gulag you go

lol

my neger

I run into amateurs likes you all the time when hiring developers. Bloated code, inefficiencies, and the arrogance. You sir wouldn’t even make it passed the phone screening.

>Don't use something because it has a risk of memory leak
Right, so stacks, queues & linked lists should all be thrown out the window yeah?

>he thinks disk space and memory is used efficiently by ANY program
Just because you're a lazy fuck doesn't mean people in very technical jobs are.
The military doesn't write software that just compiles, they write software that executes faster than the guys they wanna blow up, or else you know they will be the ones that blow up.

Had to do some assembly work on an 8bit CPU and C-style strings were clearly superior there in terms of performance and data size. In fact, it's how all the old documentation that pre-dates C suggested you handle strings. If you tried to do something like a character count in an 8bit assembly languge, you'd be either limited to 256 characters or forced to use multiple bytes for the count value which would take a lot more cycles to check for the end of the string after processing every character. Plus, they're easier to write if you're entering them manually.

I'd guess on a modern CPU any implementation using character counts, iterators, or whatever would all be about the same in terms of performance, and probably better from a modern programming standpoint since the string can be checked to make sure it has a valid size before actually processing it.

C style.
Also printf > cout

anyone else love having to convert a sane string format to C strings every time you interface with a library

>they write software that executes faster than the guys they wanna blow up
yeah i'm sure it's hard writing code that reacts faster than a stupid arab with an ak47

anyone answering C-style is a massive contrarian retard

this, also anyone slinging around raw bytes instead of working with a better abstraction better have a real good excuse, like embedded

You are now aware that F-35 software is written in JavaScript. Enjoy.

I prefer Python style strings

helo sir yes sir C style very bad and racist because causes overflows to poor pajeets like me sir.
please sir do the needful and use botyfull C++ style while showing bubs and vagina

you literally don't

b"suck" rf"\m\y" u"dick"

also the Unicode handling (especially with the transition from 2 to 3) makes me want to end it all, and no they sure as hell didn't fix it with the bytes datatype

I'd like to interject for a moment. What you call AK47 is in fact AK chambered in 7.62. There are also AKM with improved design chambered in 7.62 and AKS with foldable stock chambered in 5.56. What's called AK74 is simply an old design AK but in 5.56 caliber. Using the "year" suffix to identify specific model is a huge misnomer.

The more you know.

>He only writes code that isn't future proof.
Six weeks of code camp wasn't enough for you.

Six years of concentration camp should be enough though.

> memory leaking a stack
How the fuck exactly do you plan to pull that one off, genius?

Jai does something pretty cool by having its strings be 0-terminated while also storing the string's length in the struct. Makes interop with C-style strings a non-issue without losing any of the benefits of using the saner modern style of strings.

>bad programmers use c
>good programmers use java
Jow Forums is full of surprises. You learn sonething new every day.

Recursive function without tail call optimization as the core functionality routine.

bad programmers defend C strings, but by all means please keep being an intellectually dishonest retard

std::string sucks because of backward compatibility and the ever-present null terminator.

All you need is this.
struct str
{
size_t size;
char data[];
};

>actual data resides separately from the struct
m8

So is this standardized now?

Dumb nigger, don't you know what flexible array members are?

In c99 sure, in C++ never.

When are you ever getting the length of a string.

>Passed in externally
Something has to get the length sometime.
>Available at compiletime
Length is already known and heap allocation is more costly even if you did have to count at runtime. There is no reason for heap allocation for a const static.
>Allocated on the heap at runtime
This is where it depends. Generally strings are allocated to be used. If they're just going to be printed character by character, it doesn't really matter. Most standard algorithms have clever ways of still operating at full register size and detecting the null terminator regardless of its position. Generally the loss of efficiency in doing that is less than counting once and storing it.

Short string optimization can help here. Having the size known can be much faster if there'll be any kind of transformation of the data. The biggest problem with the C++ STL is it doesn't use realloc. The performance deficit is fairly large on some platforms.

They do malloc for you. It will reside outside of struct. The fucking thing you defined there is a pointer, go see if &data == &size+8.

I fucked that up but you get the idea.

no u

This.
>size at the beginning
>str[1] is the first letter, as per fucking logic
>money shot: NT uses it internally

>so triggered you click over and over
The only thing you'll ever hire is a psychiatrist.

You don't know C. In particular, it's obvious that you don't know C because you think pointers and arrays are the same thing.
onlinegdb.com/BkoH3WX37

b-but muh 0-based arrays!..

Array is memory block hooked up to a pointer. It's a concept, not a thing.

They remain distinct concepts in C. Check the behavior of this code if you don't believe me.
int *ptr;
int arr[10];

printf("%zu %zu", sizeof ptr, sizeof arr);

>Array is memory block hooked up to a pointer
No, it's not to a pointer, it's a literal memory reference.

You can not reassign an array because it's not a pointer.

It reports array size because this information is available at compile time and (properly) reporting size as that of a pointer would be needlessly obtuse. It is however is handled the same way as a pointer, because that's what it is. Try these fun experiments at home, kids!
data[foo]==*(foo+data)

>It is however is handled the same way as a pointer,
No, it decays to a pointer, but it isn't a pointer.

int a = 2;
int b = 3;
int arr[10];
int* ptr;

// both of these are fine
ptr = &a;
ptr = &b;

// you can't do this
arr = &a;

>
It reports array size because this information is available at compile time and (properly) reporting size as that of a pointer would be needlessly obtuse
What's your point? If the behavior is different, that means they are different concepts. Quit being obtuse.

>It is however is handled the same way as a pointer, because that's what it is.
You are incorrect. The C standard specifies very clearly what the behavior of an array is.
>C11 6.2.3.1.3
Except when it is the operand of the sizeof operator or the unary & operator, or is a
string literal used to initialize an array, an expression that has type ‘‘array of type’’ is
converted to an expression with type ‘‘pointer to type’’ that points to the initial element of
the array object and is not an lvalue.

Arrays are not pointers, they convert to pointers.

>Try these fun experiments at home, kids!
>data[foo]==*(foo+data)
Next thing you'll be telling me that int is exactly the same thing as long because of integer promotion.

github.com/facebook/folly/blob/master/folly/docs/FBString.md

to the sides, peasnts.

Well of course your can't overwrite address of a variable in program "ROM". Anyway, that's not how the struct was defined: it had empty brackets, thereby making it a pointer, so the memory would need to be allocated for it in runtime, and it will not be in the same location by default.

Stop user you're embarrassing yourself.

>An automatic variable is placed in ROM.
Christ user, quit embarrassing yourself.

>Well of course your can't overwrite address of a variable in program "ROM
What, it's not in ROM? What the fuck are you talking about.

>Anyway, that's not how the struct was defined: it had empty brackets, thereby making it a pointer
It's not a pointer, it's a flexible array. You can not reassign the address.

struct muh_flexible_array
{
size_t size;
char data[];
};

char* string = "you're retarded";
struct muh_flexible_array* ptr;
ptr = malloc(sizeof(struct muh_flexible_array) + strlen(string) + 1);
ptr->data = string; // does not compile because data is not a pointer, it's an array

variadic template printf > printf

>Array is memory block hooked up to a pointer.
This is exactly wrong. An array is a block of memory without a pointer.

Stack overflow isn't just a website where you and your stupid Indian co-workers copy and paste code that you don't understand into your project until it builds, you inbred street shitter.

I meant "ROM" as in """"""""ROM""""""", sorry if insufficient amount of quotation marks obscured the intended meaning.

Yes youre right my bad. But they, the way I use them they look like pointers and act like pointers, to me finding a difference is splitting hairs. I don't overwrite pointers to data structures and to that end arrays would be functionally identical.

That begs the question: does data resides in the same struct or elsewhere?

It begins exactly where the fixed size structure elements end (plus alignment if necessary). Size and the data array exist in contiguous memory.

>But they, the way I use them they look like pointers and act like pointers, to me finding a difference is splitting hairs.
You're missing the point. An array is the same as a pointer VALUE (aka the pointee). It may be passed to a function expecting a value just like you may pass an int to a function that expects a long. But it's not a pointer type, it is a memory reference.

To expand on this, let me give you an example:

void foo(int* p);

int main()
{
int arr[] = {2, 3, 4, 5, 0};
int val = 2;
int* ptr = arr;

foo(ptr); // passing the pointer value (pointee)
foo(&val); // passing a memory reference (to value)
foo(arr); // passing a memory reference
return 0;
}

In all of these cases, you're actually passing a memory reference, and not a pointer. In the first case, you're taking the value of a pointer (memory reference) and passing it.

In the second case, you're taking the address of a variable and passing it (also a memory reference).

In the third case, you're passing the memory reference itself (array).

BASIC style strings

Attached: CPM_CLUB11.png (1066x554, 27K)

Sauce

For what? Null terminated strings are a pretty low level detail that you shouldn't be concerned with unless you're working close to the hardware level. If you're using C++ you should probably just stick to using the standard library unless you have an exceptional reason not to.

c++ style with short string optimization implementet.
actually surprised this doesn't happen ootb.

Doesn't foo(ptr) pass in the pointer and not the pointee? You'd have to dereference it in foo to get the value that it points to, right?

It’s a pass by value, where the value is a memory address.

>When are you ever getting the length of a string.
~ $ rg --stats -q "strlen" linux-master

4528 matches
4382 matched lines
1662 files contained matches

I wonder

Superb post desu

Bad programmers use C
Bad programmers use Java
Bad programmers use C++ like it's C with classes
Good programmers use modern idiomatic C++.

to bad that doesn't apply with cpu caches, aka all actually remotely fast cpus

Fun fact: Nothing of value has ever been written in C++.

Ignorant question: is the index the same as the offset? afaik offsets start at 0, but maybe indices start at 1?

You could have the best of both worlds.

>keep character count and string together
>use character count as offset and check for \0
>if the string is null terminated, use the standard C method
>if not, then the string is malformed and you fall back to a slower method

Attached: 1540421371183.png (490x941, 167K)

Is there ever a case when the null terminator is supplied automatically in C? Like i know if you make a char array you need to stick one on the end but i've heard if it's a const char then it does it automatically. is that not correct?

That's correct.

string literals are always automatically null-terminated. char arrays can be initialized in any way you want, or left uninitialized, so there are no general guarantees.

char user[] = "lil faggy";
//same shit as
char user[] = { 'l', 'i', 'l', ' ', 'f', 'a', 'g', 'g', 'y', '\0' };

Did you just call me a homosexual?

using double quotes automatically adds a null terminator on the end.

If a string needs a null terminator and is not utf-8 by default, it's garbage and anyone who defends it is a retarded fizzbuzzer.

What happens if you add more than one null terminator? does the universe implode or something?

No I said you're a character array containing lil faggy.

For purposes of C string operations, the first null terminator is the end of the string. std::string otoh can contain null characters since the length is stored separately.

Your array would have two null terminators at the end.

And it seems to me, You lived your life like a null terminator on the end. Never knowing. What string to cling to, When the stack set in. And i would've like to have known you, But i was just a string. Your core dumped long before. Your buffer ever did.

Attached: wireimage-539297990.jpg (618x410, 79K)