/dpt/ - Daily Programming Thread

What are you working on, Jow Forums?

Previous thread:

Attached: dpt_in_a_nutshell.jpg (499x249, 16K)

Other urls found in this thread:

github.com/Co-dfns/Co-dfns
pastebin.com/MtJy1qS5
docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines
yegor256.com/
lazyfoo.net/tutorials/SDL/index.php
learnopengl.com/
twitter.com/SFWRedditGifs

>Don’t be seduced by the methods System.gc and System.runFinalization.
They may increase the odds of finalizers getting executed, but they don’t guaran-
tee it. The only methods that claim to guarantee finalization are System.runFi-
nalizersOnExit and its evil twin, Runtime.runFinalizersOnExit. These
methods are fatally flawed and have been deprecated [ThreadStop].

Java is a good language

I have a girlfriend, hairy legs, facial hair, and I'm 6'3". Can I still be a pretty, pretty C programming princess?

why did u make a new thread now the kind anons who were going to help me with sprite pools might not reply anymore

Attached: daicon.jpg (268x188, 12K)

that should be a LISP or Hasklel book desu

Nth for Haskell

I want to write code like this.
github.com/Co-dfns/Co-dfns

Does someone have a good website/tutorials for learning this following two things:
>learning oop
>programming patterns in c++
>c# from beginner to good

>learning oop
the best strategy is not to learn oop
and stay the fuck away from their "principles"
which are just a bunch of apologist patches to their terrible programming paradigm

why do you think they need all those verbose acronyms for various kinds of unfucking themselves and all those books talking about "dont do this pls, do this ideal thing which will never happen"? because deep down OOP, at a fundamental level, is completely fucked in the ass

Udemy is a pretty good website for programming tutorials in general. For design patterns i can recommend the book: design patterns explained by alan shalloway. The website: refactoring guru is also pretty good for OOP and design patterns.

In C#, suppose I have something like:
private int _id;
public int Id{ get{ return _id;} set{ _id = value; } }

Should I just set _id to public and skip the whole process of creating accessor methods? If I'm not doing any additional processing with how a value is set or accessed, what's the point of using a property?

No worries.
The code below is more ilustrative than anything. And it's not tested/compiled.
pastebin.com/MtJy1qS5

I took a linked list approach. You can just as well do this with a ring buffer or stack. But the linked list version is more obvious.

I'm thinking maybe I should have considered pretending there's a linked list implementation.
Also it's important to note that the update code at the bottom still needs to check if the sprite they index into is_used or not. The peakCapacity just avoids walking over all the sprites that haven't even been used once.
Tell me if you're confused.
You can just google freelists aswell, this was just me trying to explain for fun. Freelist is a concept that comes from allocators but it's useful for any type of resource management.

>The website: refactoring guru is also pretty good for OOP and design patterns.
that´s a great website, wish they would also have implementing of the pattern in c++. Because I must admit I need most of this for university.

C# is more like for me and portfolio.

OOP can indeed be tricky. If say an object A needs to use object B, then object A depends on object B. This can sometimes lead to problem if not implemented well. This is why certain patterns and standards are realy important. It keeps your code maintainable.

You can just write

public int Id { get; set; }

Instead. It's called an auto-implemented property.

The advantage of using a property over a public field here is that if you decide to control how it's accessed later, any code that is already using that field won't break, since it's already going through accessor methods.

Changing from field -> property and vice versa can also break reflection code, so keep that in mind too.

thank you bro.
good luck to me
i still havent implemented sprite-sprite collisions lol

Attached: inhocsignovinces.jpg (900x506, 80K)

>The advantage of using a property over a public field here is that if you decide to control how it's accessed later, any code that is already using that field won't break, since it's already going through accessor methods.

Ah, that is a very good reason, and is something I'm actually currently struggling with as I try to change my public fields to properties during my refactoring.

The other advantages are rather helpful as well: properties allow you to control accessibility (you can write protected or private before the get/set, or omit them entirely for read/write-only properties).
Additionally, an interface can require a type to have a property, but not a field.
Also note that the JIT compiler will often optimize simple properties such as the one in your example (and auto-implemented properties) into direct accesses to the underlying field, so you won't pay a performance cost in the majority of cases either.
Hope that helps explain the reasoning behind why many people recommend using public properties over fields.

Yeah. You've convinced me. Thanks.

One more question. Is the style I chose for my field and property correct? That is, naming my field with an underscore _id, and my property with a capital letter?

It's up to you, really. It's your code.

Personally I dislike the underscore prefix that tends to get used, and instead opt for just naming my private fields in camelCase. The reason people use the underscore is generally so that the names of function parameters and variables don't conflict with field names, so you'll have to decide for yourself whether you use the prefix or not in your code.

As for your property, that's correct. Generally the naming scheme for C# stuff is to use PascalCase for anything that's public, protected or internal, and use camelCase for private stuff and variables.

Microsoft themselves offer documentation on this subject: docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines

Is there a way to do this without new btw? Using only static memory? I wont be running out of space in the pool because sprites leaving the screen are freed.

Or rather killed, disabled etc.

I'm trying to learn C as well as use the ncurses library. What's going on with my code? It doesn't print anything


void moving()
{
int row = 0;
int col = 0;
char message[] = "Hello, World!";

curs_set(0);

for(int i = 0; i < strlen(message); i++) {
move(row++, col++);
char c = message[i];
// printf("%c", c); works fine
addch(c);
// addch(c) does not
refresh();
}

sure, you could use a builtin data structure like vector and pop() from one and push_back() to the other

and this is just a snippet; i did include the library, close the brace, and call moving(); from main.

>Is there a way to do this without new btw? Using only static memory? I wont be running out of space in the pool because sprites leaving the screen are freed.
Yes. You could just have a normal stack. It'd have to be at least as big as the original buffer to cover the case of everything being dead. Or alternatively you could clear the freelist and switch to O(n) in that case, you could even add a scan function that stores where it saw that there weren't any free slots. Which can then be dirtied by taking the min index between that scan and the element which was removed.
You could also just have the linked list be backed by a normal buffer of nodes. But that's a bit silly. The stack is better in this case, less memory footprint but easier to use.

There's so many ways to do this user, I couldn't possibly explain it all to you like this. I'm sure you'll manage to find some solutions when you put your mind to it. I think this is a great problem to try and solve for a new programmer.
This still implies memory allocation though. It's not gonna hurt at all but I'm thinking user here was intent on avoiding that.

Also I forgot to say in earlier posts. You said you have 64 entities, it's never going to be a real problem however you do it. You can just look through the array for the first empty slot no problem.

>good website for learning OOP
yegor256.com/

why that dildo has a lock on it?

>>learning oop

Attached: not strong enough.gif (342x192, 1.98M)

>le OOP hate meme
Love this meme.

For videogames?

Take this advice: don't
Tons of works and it will only make the game frustrating and inconsistent to play

Out of all languages I can unironically only tolerate C# and JS, even though I've been programming for nearly 10 years in various languages. Anyone else in the same spot?

Probably not, but I dont want to be unnecessary lazy.

Yes. It will be just rect — rect intersection tests. Enemies wont even be able to collide with each other.

Is there something like an actual hash map for Excel (VBA)?

I need to keep track of 10+ integers associated with a column name.
It works, but either I have to pass a ton of arguments to every function or use an array and add comments regarding which index stands for which column, which is not very "elegant"

Can someone explain how to hook up glsl shaders to my c++ program in visual studio?

use some sort of graphics library like SFML
then you can load your shader with one line of code

Lisp is the most powerful programming language.

Attached: gttyty.jpg (600x800, 381K)

somebody is unemployed

I think I know what you mean. I would place the indices of the unused sprites on a stack and then pop when needed? Then all I need is to make sure that the stack is rhe same size as max_sprites ?

I actually am, and I should kill myself.

Cringe

>mfw I just realized console.writeline means you call a predefined method called writeline and pass an argument into it

Attached: 41889675_346474882756821_79519893556297728_n.jpg (720x710, 34K)

>replying to a bot

>pop when needed
>make sure that the stack is the same size as max_sprites
Yes that's it. The linked list I did was basically a stack in the form of a linked list.

lazyfoo.net/tutorials/SDL/index.php
This is pretty alright.
learnopengl.com/
This is a more raw approach than SDL. Uses glfw and opengl directly instead. You'll write the compile bind etc yourself.
SDL does that for you normally.

you load the shader source in as a string and then you compile it using openGL commands

>Hasklel
is pic related
now put on your cock cage and go write C, you need to leak at least as much memory as your gaping anus leaks in a day

Attached: _yakumo_yukari_touhou_drawn_by_mefomefo_5fdfe2a7587ac3217802c4388fe4da4a.jpg (999x999, 288K)

Ok I think I got this down.

Now when iterating over those sprites which are IN USE I have to keep a separate stack?

Attached: spritestack.png (340x262, 11K)

You can store a linked list inside the sprite objects themselves so it requires no extra allocations at all
I posted an example in the last thread

You say printf works fine. Not sure what addch does, maybe adds it to a buffer? Which you need to print at the end?

>Haskell programmers unironically think they're math wizards

kek'd hard that this.

This stack is just indices into the normal sprites. For just iterating and using the sprites you do that normally.

bullying AND fucking trannies AND ruining their clothes what a guy
>you're not a she
>you're a he
>*cums on dress*
>HE
>*goes home and is a family man*

>implying i'm a haskell programmer
hep-th gods > CS monkeys > SE niggers > nu/g/ šoibois
the haskell monkies are still miles ahead of any other CS pejorative term for homosexual male specimen of homo sapiens, at least when it comes to math

what?

But what if I want to iterate over only the sprites which are not in the stack? Is this what the linked list thing fixed?

Do the sprites have to be stable?

stable? I dont know what you mean.

>sequential functional specification
>refined into concurrent functional specification
>refined into imperative implementation

Attached: 4772795__e188297988ce060ed77289f0d306731a.jpg (1058x705, 111K)

why are you even making a pool for sprites? There isn't much point unless you're uploading them a vertex shader all at once

Does their address or index need to be constant?

...

no bully pls, their draw calls are batched, though they will have different shader parameters for indexed color using a texture lookup once I get to writing the shader
I am not sure.

What's wrong with that?

in that case you don't need to iterate through them, you just need to upload the entire vertex array to be drawn, so you only need a free list for keeping track of where free sprite slots are

OH NO NO NO NO NO NO NO NO

Attached: haskell guidelines.png (424x176, 8K)

>have to write a small program that extracts data from pdfs
>find a library that lets me turn them into string
>however the result is different depwnding on the version of Adobe you use, ranging from precisely delimited to garbled mess, making me rewrite the algorithm for each version and having to find out how they each differ
>it's not even a commercial program, my boss is just a lazy asshole

Sometimes I wish I had studied sucking dick instead

Is there any way to make error checking less of an eyesore?

I need to iterate over the used sprites for other stuff. Like updating their AI, animations, doing collisions, checking if they left the room/died and should be disabled etc.

that haskell programmers certainly have the right to call themselves math wizards, among the CS folk

You did.

Use a language with good error handling, like Haskell.

-->

The data for non-rendering operations doesn't need to be batched. If you are batching render calls, seperate out your rendering data. Otherwise just use free objects to represent everything. Batching rendering calls for sprites isn't realistically neccessary in the first place, so if you're still a beginner you can safely just forget about it and do a draw call for each one

Please delete this, thank you

Check out Rust and other languages with the same style of error handling.

Don't the pdfs themselves have version numbers embedded in the pdfs?

>*cums on your dress*
>*guidelines you*

Line 50 & 40-42 of is only a cheap way of ensuring we don't loop over parts of the sprite array where we know there's no sprites.
If we keep track how many new slots we're using (and the only way to get a new sprite slot is through the case on line 40-42) we can guarantee that there's no used sprites above that index because we've never given them out.

In your implementation you now added all the unused sprite indices to the stack. Now we won't know how many of the slots in the sprites array we've given out because any of them could be given away by now.
Your way makes for very nice and clean code at the expense of not knowing (right now). If we want to get the same ability we can just fill sprite_stack_data in reverse order:
[MAX_SPRITES-1, MAX_SPRITES-2, ... 3, 2, 1,0].
Then when you do pop stack the first index you will get is 0, then 1 then 2 etc.
When you delete one of those indicies you add them back on to the front. So if we deleted index 1 the stack would look like
(MAX_SPRITES-1, MAX_SPRITES-2, ... 4, 3, 1).
As you can see we won't get back any higher indicies than we already have unless we use more sprite slots than our previous peak.
So what we can do in our PopSpriteStack() function is
int PopSpriteStack(){
int ret = sprite_stack_data[sprite_stack_top--];
peakUsage=peakUsage>ret? peakUsage:ret; //max(peakUsage, ret);
return ret;
}
Then when we loop we know that we don't have to check indicies beyond peakUsage. Not sure what to call peakUsage to be descriptive. But it is just the biggest index we've given out. So because of that we know we don't need to go looking for sprites that are alive beyond that, anything beyond that was never initialized.
This code is much cleaner than newSpriteIndex() from despite being the same thing essentially. You're not checking if sprite_stack_top is negative, if that's the case in your code you've run out of sprite space.

kek

Rust errors are just more complicated exceptions

>I am not sure.

Well if not, then you don't need the extra stack, you just need an index of the last sprite. Whenever you "add" a sprite, you put it in that index and increment it. Whenever you "remove" a sprite, just copy the last sprite into that slot and then decrement it. That way your live sprites are always contiguous at the beginning of the container.

Rust errors are simply values that can be manipulated like any other value.

So are C error codes.

Yep, and they're better than exceptions too. But Rust is better at manipulating values in general, since it has first class sum types with pattern matching.

public static long millionSum() {
Long sum;
for(long i=0; i < 1000000; i++) {
sum += i;
}
return sum;
}

Attached: 1539442393785.jpg (850x800, 65K)

*teleports behind you*
*closes the form of your expression*

Attached: 1542930262773.gif (311x360, 136K)

And Java exceptions are Objects that you can pack whatever data you want into, but I have never heard anyone call Java's error handling good

>Rust is better at manipulating values in general
Why are you sucking Mozilla's cock so much? Rust is just another language, it's not automatically better at anything

Exception handling (in Java but also in general) is a different world with a different set of rules. It introduces new control flow mechanisms that essentially make every method you call a wildcard in terms of whether or not it'll pull you out of the current context and put you somewhere else.
As regular values, error codes and error monads just don't do this. They behave predictably like everything else does.

I know it's
>Java
but what's the point where StringBuilder is no longer worth using?
For instance I should clearly use an append in a loop, but is it still faster to make one for
string1 = string1 + string2;?

I like exceptions better simply because I don't have to check and rethrow them for every function call. I catch and handle them when and where I'm ready to do so.

a string builder isnt any faster for a single operation

>fill sprite_stack_data in reverse order
hmmmmmm... this is interesting
but this peak will never decrease right?

Please help me Jow Forums.

I've been a hobby programmer for many years (started QBasic and TI) did a few simple games, the usual. Quit for a long time, kinda want to play with programming again. I thought up some things to do and I tried Java but Java seems to be a complete mess. I got some prototypes working but I felt like I was spending about 80% of my time trying to find ways to cleanly (Interfaces to kinda multiple inheritance that half-works, streams versus loops, and all the crap around boxing numbers, etc.) do things that I expect today's computers should do for me, especially in the GUI stuff. The more I refactored things to do them the clean or "right" way, the harder it got to keep track of everything. (And then there's apparently a Java version 7 that sucks, 8 that has cool stuff kluged in that I've been using, 9 that maybe got deprecated fast, and a 10, 11, and 12 all of a sudden.)

Then I heard about Kotlin. It makes a really appealing promise about not needing so much typing and letting the computer do the repetitive stuff for me. And it sounds like it plays nice with Java so stuff I've already done that works I guess I can keep, and I really like the promise that I can write for PC and my phone together. But does Kotlin offer good GUI stuff and complete the things that are missing in Java (like math after C99 so I don't have to do trivial but annoying things like bring my own asinh) or is it really just the same as Java with sugar and I'll have the same dragons to slay after learning a different syntax?


Also, taking alternative recommendations for making simple multimedia/game/math projects.