/dpt/ - Daily Programming Thread:

old thread: What are you working on, Sup Forums?

Other urls found in this thread:

media.blackhat.com/bh-ad-11/Drake/bh-ad-11-Drake-Exploiting_Java_Memory_Corruption-WP.pdf
pastebin.com/FiJvLu7G
twitter.com/AnonBabble

First for women in coding!

A comfy, metaprogramming-friendly and language-agnostic syntax. Something (subjectively) nicer than Lisp's paren soup that mostly retains the usefulness of homoiconicity.

Is the K&R book still worth using in the current millennium or should I just stick with the more modern book I'm using that covers C89 and C99?

C strings are the result of brain damage.

Your post is a result of brain damage.

Don't learn or let alone use a deprecated language that was created before memory protection was invented and therefore is buffer-overflow-prone.

>Anyone who insults C strings m-must be a newfag!
No user, we are simply more experienced than you, and know better than you.
C strings are appropriate nowhere.

Hey guys, CS undergrad student here. How important is it to understand File System implementation in C? basically simulating a disk and file system using inodes and whatnot

It's for an OS class and its my last project but ive procrastinated and its due in 2 days and im thinking of just taking the 0 and putting my time into studying for the exam. But if it's important i might reconsider.

I asked in last thread, but its dieing

>he thinks the language causes buffer overflows
>he doesn't understand the language just does what he says
>he doesn't understand that his and personal incompetence are responsible

>t. mentally handicapped fizzbuzzer
Again, you don't understand the design decision behind C strings.

Can this hash function for strings be improved?
I'm getting about 20% collisions in 1000 words.
int hashCode = 13;

for(int i = 0; i < word.length(); i++)
{
hashCode = hashCode * 23 + word.charAt(i);

if(hashCode < 0) //Ensure hash is not negative.
hashCode *= -1;

return hashCode % tableSize;
}

>strlen a """string"""
>It segfaults
Lmao.
Good languages don't have this problem, and actually end up being more efficient.

Go ahead and justify those "design decisions", I'm waiting.
The truth is that those "design decisions" were rushed and poorly thought out, and were also the result of C having basically no abstraction capabilities.

Which design decision?

How important for what? For the exam?

You sound like an American CS student.

so, std::vector is a special case of vector
since it literally store the state as a bit.
Is there any way to easily take the data from a std::vector and store it to a char bit-wisely?

I have a huffman tree that need to be stored to a file, and std::fsteam only support char as the smallest datatype.

Is std::vector::data() really going to point to the first char address?

using std::vector is a mistake

>he needs a function to get the length
>length and sizeof aren't properties for every literal

It is the language's fault when no other language has that problem. Stop rationalizing bad design just because you're too lazy to learn a new, better language. I've seen time and again competent, experienced engineers writing C code with buffer overflows. It happens all the time, to this day, even on high quality projects like the Linux kernel. It's time for you to move on from C, user.

Not the exam, for a job and general knowledge. Yes I'm American

>It is the language's fault when no other language has that problem.
There have been buffer overflows plenty languages, from C++ to Java.

media.blackhat.com/bh-ad-11/Drake/bh-ad-11-Drake-Exploiting_Java_Memory_Corruption-WP.pdf

>even on high quality projects like the Linux kernel
>Linux
>High quality
AHAHAHAHAAHAHAHAAHAHAHAHAHA
Have you ever looked at the linux kernel source code? It's utter trash.

There's no reason for a low-level programming language to impose a constant overhead for every string and an arbitrary limit on its length. You can get the length of any string you care about in your program from its source. From there on, you can manage it in whatever way is appropriate for your application. In many cases, you don't have to use strlen or store and manage any lengths at all, because you can get them on the fly while iterating over the strings in the course of processing them. Why should programs where string manipulation consists mainly of such operations suffer from unnecessary overhead in storing and recomputing string lengths? To appeal to people like you who can't program? Just make your own string wrapper around strn... functions. C will do nothing to stop you.

>It is the language's fault when no other language has that problem.
It's not the language that has a problem. It's you who has a problem, so switch to a "safe" language with a lower cognitive load.

No where near as much as C. C is the number one language in the world in terms of how many exploits and memory errors it has caused.
Also, most of the buffer overflows that happen in C++ is due to C. If you write idiomatic C++ and avoid C as much as possible, it's very difficult to accidentally cause a buffer overflow, as is with most languages.

>it's a "Cfags pretend they couldn't possibly make a mistake" episode

Newbie here...
Should I free my member variables that are just simple datatypes such as:

class Thing {
public:
int m_myint; //

>No where near as much as C. C is the number one language in the world in terms of how many exploits and memory errors it has caused.
Baseless hyperbole based on a handful of anecdotes. I don't care to comment of this.

>Also, most of the buffer overflows that happen in C++ is due to C. If you write idiomatic C++ and avoid C as much as possible, it's very difficult to accidentally cause a buffer overflow, as is with most languages.
As is if you write idiomatic C and use counted string functions, your argument has been all the way that the language should protect you in the cases where the programmer make a mistake. You can't just suddenly turn around and make the opposite argument.

>impose a constant overhead for every string and an arbitrary limit on its length
What fucking overhead? What fucking limit?
There's literally less overhead because you don't have to iterate over the "string" like a dumbfuck to find it's length.
And what's this about limits? Why the fuck would there be a limit on the string length? If you store the string size as a size_t like any sane person, there's no fucking limit.

>recomputing string lengths
C strings have to make sure it ends with a null terminator, upholding that promise causes about as much overhead as having to increment or decrement a size field.

>storing
An extra 4 to 8 bytes is nothing, and well worth it.

For string literals, you do not need to store the length as an additional value. The compiler will know the start and end address based on references to surrounding symbols.

>it's a "Cfags pretend they're embedded software developers who need to save every single byte they can" episode

Except writing idiomatic C doesn't protect you from C string retardation.

No. I'm pretty sure if you called "delete m_myint" that would be a compile error.

Your point?

How about free(m_myint) ? I just feel like I should tell the system that I'm not using it anymore..

> What are you working on, Sup Forums?
Just started a tetris clone using OpenGL and the only decent language available, Java.

>I'm too lazy to learn a modern language
>so I'll ridicule everyone who has progressed

Storing a number is a waste for unmodifiable string literals.

It does. Idiomatic C coding standards tells you to use counted string functions for user input.

Please stop. No. It's a part of the object. You're not using it when you're not using an object. It's impossible to be in a state where you are still using the object but are not using its member.

You misspelled Kotlin.

Again no. m_myint is allocated along with the class. free and delete are used with pointer types.
If you called free(m_myint) it will most likely try to free random memory address and crash the program.
Also m_ thing is redundant garbage.

Which one is Sup Forums's preferred writing style?
int foo (int arg){
int returnValue;
//do stuff
return returnValue;
}

or
int foo (int arg)
{
int returnValue;
//do stuff
return returnValue;
}

or
int foo (int arg){
{
int returnValue;
//do stuff
return returnValue;
}}

So, Tcl?

Okay, Thanks! That cleared up a lot!

>Storing a number is a waste for unmodifiable string literals.
You don't need to store length for literals.
But as soon as you pass that to a function that wants a string, it should convert to a sized string (literally just taking the pointer and a size known at compile time).

>It does. Idiomatic C coding standards tells you to use counted string functions for user input.
It still has to loop you fucking retard, and the size is part of the string contents.
The size should never be part of the string contents.
Thanks to null terminators, they can't be used as views into other strings.

it's saving space, bloatwarefags

>What fucking overhead?
The overhead of storing and recomputing string lengths when it's unnecessary.

>What fucking limit?
The limit imposed by whatever you pick as the datatype to store the sting length.

>There's literally less overhead because you don't have to iterate over the "string" like a dumbfuck to find it's length
So you're basically telling me you were unable to comprehend my post? Not surprised.

>upholding that promise causes about as much overhead as having to increment or decrement a size field.
Got any solid reasoning to back up this assertion?

>An extra 4 to 8 bytes is nothing, and well worth it.
That's purely your subjective opinion, though; one that clearly wasn't shared by some systems level programmers back when C was conceived. As a low-level programming language, C doesn't need to be opinionated on this. You want strings that store their own length? It'd take you 20 lines of code to achieve that.

>You don't need to store length for literals.
That was my point, yes.

>But as soon as you pass that to a function that wants a string, it should convert to a sized string (literally just taking the pointer and a size known at compile time).
Except in a lot of cases it isn't known, C++ for example will in this case actually do strlen() on the string and make a deep copy.

>It still has to loop you fucking retard, and the size is part of the string contents.
Of course. Even a wrapper needs to loop, see above.

>waste time learning yet another language that won't bring anything new besides nicer syntax
I'll pass, I already know plenty of languages I never use. But if I have nothing better to do someday I'll check it.

>implying i don't know many more "modern" languages than you do
>implying i'm ridiculing you for "progressing"
No, you tard. I'm ridiculing you for using the wrong tool for the job (and probably a tool you're too stupid to be trusted with) if compiler hand-holding and having abstractions shoved down your throat is acceptable for your application.

struct STREAMFORMATTER {
template
STREAMFORMATTER& operator

>it's a "Cfag thinks storing length introduces any noticeable overhead without any kind of benchmarks to back it up" episode

int
foo(arg)
int arg;
{
int returnValue;
//do stuff
return returnValue;
}

The tool isn't suitable for large systems anymore. Newer languages allow for faster and safer development thus should be used over C. This isn't the 80s anymore, the world has moved on.

Server? Elixir
Android? Kotlin
Desktop? Any of the desktop oriented languages
Systems? Rust
and so on

>it's a retards thing their purely subjective opinions are relevant
>they also seem to think C is about their age of 12
When will /dpt/ learn?

>Work in software development
>Literally no women on my floor of 50 dev/test engineers
Heaven.

>The tool isn't suitable for large systems anymore
Nice opinion you've got there.

>Newer languages allow for faster and safer development thus should be used over C
Nice opinion you've got there.

>Systems? Rust
I take that back. Opinions discarded.

>some guy defending C and manual memory management in 2017
>other guy offering some meme languages nobody uses as alternatives
>both keep arguing without knowing both are wrong
Never change, /dpt/

>rustfags shilling yet another thread
Can't you go shitpost back to hackersnews?

your post is utter trash

anyone know some cool patterns for stateful interaction with a dynamic environment e.g robotics? have tried (hierarchical)state machines and behavior trees so far

>Systems? Rust
Well memed user, well memed

>some tard can't even make an argument
>muh current year
>muh memes
>let me just post mindless greentext
Typical /dpt/.

>The overhead of storing and recomputing string lengths when it's unnecessary.
Compared to the overhead of strlen?

>The limit imposed by whatever you pick as the datatype to store the sting length.
There is literally no limit that wasn't already there if you store it as a size_t like any non-retarded person.

>Got any solid reasoning to back up this assertion?
Null terminated strings waste a single byte, and you also have to set that byte to zero.
Do you really think using 3 mores bytes really fucking matters in 2017 considering the huge benefits you get from it?

The design decisions made back then are no relevant in 2017, there's no reason to keep using null terminated strings anymore.

>Except in a lot of cases it isn't known, C++ for example will in this case actually do strlen() on the string and make a deep copy.
Only if you use std::string like an idiot.
if you use std::string_view, it will never make a deep copy, and it will only strlen if the string is being taken from a char* or const char* (which is all the fault of C anyway). String literals are of type const char[n] and C++ can template over those, so string literal lengths can be known at compile time in C++.
If you need to use std::string (as in you are taking ownership of the string), then you SHOULD be deep copying it.

>Of course. Even a wrapper needs to loop, see above.
It ONLY needs to loop if the source is a C string with unknown size.
In a language with no C strings, you literally never have to loop, the size will ALWAYS be known at either compile time or run time.

Keep freeing these pointers my friend!

What did he mean by any of this

concatenate instead of addition

this might be a good place to seek help
I created a thread last night and asked for the largest rectangle in a binary matrix using C# and the simplest brute force method.

A helpful user made me this pastebin.com/FiJvLu7G which works perfectly with only one problem. It uses a jagged array (array[*][*]) instead of a multidimensional one (array[*,*]) And I have no idea how to tweek the code to work with a multidimensional array. If someone would be as kind to help me out with fixing the code or just writing a new one that works with multidimensional arrays I would be very thankful.

The full code I have to hand in on friday needs the following:
There is a text file containing coordinates of "stars" which are represented by zeros and the task is to find the largest area rectangle of only 1s. Sounds simple enough and yet I can't seem to make it work...

I don't know what you're talking about.
I'm arguing for sensible sized strings and string views in C++.

>being gay

So you get nervous around women? What, were you raised by a single mom and always got rejected?

You could give them at least a few (You)'s for their trouble.

>ITT Ctards think it's still 1980

>Compared to the overhead of strlen?
Failure to read the posts you're responding to is not an argument. Try again, please.

>there's literally no limit except the limit
Uh okay?

>Null terminated strings waste a single byte, and you also have to set that byte to zero.
Okay, but I asked you to back up your claim.

>Do you really think using 3 mores bytes really fucking matters in 2017
Maybe on some platforms. C wasn't conceived in le current year, though.

>there's no reason to keep using null terminated strings anymore
I'm just trying to help you understand that there were good reasons for C having been designed this way. If the design decisions of C make no sense in the context of your application, don't use C. Why are you bitching and moaning about it?

Writing web services or working on large code bases outside of systems programming is not for C. C tends to end up being a mess due to changes made from late requirements, most developers not knowing how to handle strings properly, and so on.

It's aimed at systems programming. I could have thrown other languages in which aim for safety but since rust fits the domain I'd rather not list the full 30+ languages built for the same thing.

>Uh okay?
So C strings are these magical things that can go beyond the address limit of your machine? Okay I guess.

>AAAAA LEAVE YOU'RE MAKING ME SO MAAADD AAAAA THIS IS MY SAFE SPACE
Pathetic.

>Only if you use std::string like an idiot.
Explain to me how the following signature, idiomatic sepples, will not create a deep copy when called with a string literal.
void foo(const std::string& str);

your memes are stale and you post like a faggot

>If the design decisions of C make no sense in the context of your application, don't use C. Why are you bitching and moaning about it?
Except plenty of people still use C where C is not appropriate (which is everywhere).

feeling pretty comfy

Try reading my post.
Your function signature should only look like that if you're taking ownership of the string, in which you should be deep copying it.

If you only need to look at the string, this is what your function signature should look like:
void foo(std::string_view str);

This will not deep copy.

>So C strings are these magical things that can go beyond the address limit of your machine? Okay I guess.
Who said the entire string resides in memory? Maybe you're just iterating over chunks from a file.

user you're depressed aren't you

>CS
>circuit analysis
>shit ton of math
>programming
>first study visit to local company
>literally bunch of chads with no degrees working as consultants and market shit
>only two actual developers
>all work is outsourced to 3rd worlds shitholes
I understand that all companies are diffrent but making a study visit to complanly like that is retarded. Nobody there even knows what circuit analysis it, if you listen to them you don't even need degree or tech skill just social skills and you're set.
Is this the state of the industry?

I could see your tears rolling and hear your voice hiccupping as you said that lol

>mfw socket programming

What the fuck is happening

>Except plenty of people still use C where C is not appropriate
That is their problem, and from the sound of it, you are one of them (otherwise why are you screeching about C strings?).

>(which is everywhere).
You know, that's just... like... your opinion, man.

lots of guesswork and if it works dont try to change it

>Who said the entire string resides in memory? Maybe you're just iterating over chunks from a file.
Strings stored in files wouldn't have the same format as strings stored in memory.
If they're stored in files, you'd use a u64 or something. Most file formats used sized strings.

>You know, that's just... like... your opinion, man.
No, it's objective fact.

>Strings stored in files wouldn't have the same format as strings stored in memory.
Says who? You can very well store a plain null-terminated strings in a file and read them back.

>If they're stored in files, you'd use a u64 or something
Why are you telling me what I'd use having no idea what my hypothetical requirements are?

>my opinions are facts
Then prove them, faggot.

>Says who? You can very well store a plain null-terminated strings in a file and read them back.
Yes but it wouldn't be anywhere near efficient as a sized string.

>Why are you telling me what I'd use having no idea what my hypothetical requirements are?
Because you don't seem to understand that you can usually get a type that spans the entire address space, be it memory or storage.

How about coroutines? Does Java have them?

>Yes but it wouldn't be anywhere near efficient as a sized string.
Based on what?

>you don't seem to understand that you can usually get a type that spans the entire address space
No. The problem here is that you don't seem to understand that 64 bit ints weren't a thing when C was designed, my tardalicious friend.

>
Or you could've said the most practical and widely used one, C++. But ofc you didn't, your ideologies wouldn't let you do that.

hows this

I agree but really am I gonna convince someone to not use dynamic allocation in this day and age? No.
I still regard dynamic allocation as niche. Because now if you don't care about performance you could just allocate your footprint and be paged out. You could also leave it to GC if you don't care of course. Equally simple.
If you do care the motivations provided are enough.
It's difficult to construct situations where dynamic allocation is a valid strategy really. It's if you've got very high requirements on memory size for some reason and can't deal with waiting for memory to be paged in.

>tfw my job is writing kernels for systems with 2 bytes of memory and fags are telling me to waste a whole THREE bytes
Pathetic

Protip: You are are never going to be able to make one of those epic gaymez by yourself.