/dpt/ - Daily Programming Thread

Oddly enough I think Rust itself will become a compiler output format once the language stabilizes a bit. Languages that "compile to C" usually end up linking against Boehm-GC or similar. Using Rust as the intermediate language could be a big win.

Compiling to rust would be completely fucking retarded.
Compiling to most other programming languages are retarded; use a proper IR.
C sort of gets a "free pass" because it's so damn ubiquitous, but I think compiling to C is pretty retarded most of the time too.

transpiled language are always shit. If you're incapable of writing a frontend to LLVM or GCC don't bother. Transpiled langauges always boast about how they get the same performance as C, but in reality the shit they shit out with their transpiler is garbage code and does horrible.

>a frontend to LLVM or GCC
Why not just directly to Intel Assembly? /dpt/ used to complain about homemade langs that didn't go all the way and compile to Assembly.

just learning some new golang concepts

In the days before LLVM there was no standard IR other than C. Also the "Charlie on the MTA" function pointer in Chicken is cool.
more-magic.net/posts/internals-gc.html

Because people actually want their compilers to be portable, and it's easier to do certain optimisations on a more abstract IR.

Because you're not an imbecile and realized IR are there for a good reason. Plus a frontend for LLVM and GCC means you get to benefit from the eons of optimizations both will do on your IR.
>before LLVM
GCC existed long before LLVM and you could always write front ends to it.

Because LLVM IR assembles to any target architecture that it's been ported to. GHC is an LLVM frontend but nobody would argue Haskell doesn't make native binaries.

citations? benchmarks?

>GHC gains an LLVM backend as late as 2010
>GHC "is an LLVM frontend"
it's really not even worth it to push back against transpiling FUD.

>GHC
>LLVM
>not GNU Haskell Compiler
disgusting

And it's been the default since at least 2011.

The proper term is that GHC is an LLVM frontend. GHC has nothing to do with machine code output

To claim that something is a front-end to it implies almost a core level of importance--everything around LLVM exists to support it.

Which is obviously and patently false.
It's a misnomer to call anything a front-end to LLVM, because LLVM is not consumed or produced by humans--it is effectively invisible and no one would be harmed by not knowing of its existence.

assuming you have terabytes upon terabytes of memory on a standard laptop/desktop, how many
text documents can you write and maybe rewrite before the computer dies?

Like, is there wear and tear on the processor or the ram sticks by writing copious 10 kilobyte text files?

can the damage be lessened if instead of creating new text files, it just edits 1 existing file for the remainder of its lifespan?

Sorry but you can't dispute facts.

Attached: file.png (558x206, 21K)

yes, but the hard drive will get damaged more than anything else

>can the damage be lessened if instead of creating new text files, it just edits 1 existing file for the remainder of its lifespan?
anything-sync-daemon, CoW filesystems, etc.

Has anything benefited from the hardware rtm of tsx?

>is there wear and tear
if you carve a statue out of stone, and put it outside, there will be wear and tear on it.
we live in a universe where a even a literal hunk of rock sitting around doing literally nothing will eventually be unrecognizably altered by the elements (and within a human timeframe, depending on where it is)
so yeah what happens to everything also happens to your computer.
as for how much this matters for RAM, in practice, I dunno. Look into how many writes a Rowhammer attack takes.

Suppose for some godawful reason you wanted to write firmware that is extremely slow because it actually builds a complete graphical OS, on the level of GNU/Linux with icewm and a browser, into RAM from source code stored in firmware ROM as data at some offset after the main firmware program. Suppose the size of your firmware ROM is unbounded. Suppose as well that you are not allowed to use a preexisting compiler or assembler at any point in generating the ROM image.

My question is this.

What is the absolute smallest possible amount of raw binary code you could write for this project?

Obviously to minimize raw binary you'd want to write a minimalist pure binary bootstrap assembler. So I guess really my question effectively amounts to what's the smallest possible bootstrap assembler.

>and within a human timeframe, depending on where it is
Usually not unless there's some kind of human activity influencing the rate of erosion like acid rain or something.

>raw binary code
You're a dumbass.

How so?

Binary is a number base. You don't "write binary".
The far more accurate and correct term you're referring to is machine code.

Even then, nobody writes machine code. Use an assembler.

>Binary is a number base. You don't "write binary".
>The far more accurate and correct term you're referring to is machine code.
Doesn't matter, the fact is machine code files are called binaries. That was the sense I meant it in.
>Even then, nobody writes machine code. Use an assembler.
Obviously, but you can't, because the question stipulates that you're not allowed to use an assembler to generate the ROM image. The whole idea is you should be able to write a small enough amount of machine code that the fact that it's machine code doesn't grow tiresome, and use it to bootstrap everything else, which you write in increasingly abstract source languages.

>What are you working on, Jow Forums?
unironically merge sort in c

Sup faggots? I'm getting ready to go to work.
Just kidding I'm sipping my coffee to the comfy sound of my neighbors getting ready to go to work.

Anyway, I had to phrase it that way because if I'd just asked what the smallest amount of machine code you could write for it was, someone surely would have assumed I must have meant assembly, since you don't write machine code. I had to clarify that I was actually asking how much numeric non-ASCII code you'd have to manually hand-assemble.

i don't see many thank yous given, i mainly just lurk, but thank you guys. i think i know what to do now.

Clean Architecture is a meme.

Agreed, I prefer my architecture to be dirty.

what are you going to do user?

Vertical slices is where its at.

K&R C user here, I think I've learned enough C to embark on a shitty shell as a learning exercise. I'm looking at documents online, and it seems like the three main parts are

1) The Parser

2) The Executor

3) Subsystems (whatever this means)

So now I'm writing the parser, and I think I'd like my syntax to be bash compatible. Since I know nothing about shell design, it seems like I'll be writing massive switches and if-else-if decision trees to determine what commands mean. Is it really that easy (or not)?

Read up on lex and yacc

i'm going to take care of my parts.

>it seems like I'll be writing massive switches and if-else-if decision trees to determine what commands mean
Pretty messy/ugly. Start out with having a list of string:function pairs and do a strcmp or something until you find a fitting one and then run that associated command.

Thanks, I didn't really know what these were until now.

Lex and YACC appear to be better implemented versions of the program I was thinking of writing. I'm basing that conclusion off of what I've read so far (parser will wait for input, read input one character at a time, if it sees a character in a given switch, fall through until a case is matched, and go through the rest. Thinking through every possible combination seems... retarded. And I would intentionally want to make my program's syntax terse and easily implemented. It always seems like there's a less retarded way of implementing my programs.

Help me Jow Forums, I have a basic understanding of OOO and whatnot but don't know shit about how memory works.
>in game dev
>coding an inventory system for my game
>inventory is an array of references to an Item object(for display purposes)
>the item's "name" is an integer because string operations will be too slow
>will probably have maybe 200-400 items when game is done
I just have a few questions:
>1) Should I store each item's description in the item class? Will this take up a lot of memory? These strings will be quite long. The alternative is to have a hardcoded get_description(itemnum) function with a huge switch statement but I don't even know if doing it like this makes any kind of difference. Wouldn't the function just be loaded into memory anyway?
>2)Should I use some kind of big dictionary with {itemnum:itemname} for readability? Is this what enums are for? Is it acceptable to have like 200 fucking enum declarations at the start of a script?

I'm an intermediate programmer but I'm mostly self-taught and my compsci knowledge is iffy. Thank you for putting up with my autism.

Attached: 1556145211868.jpg (835x998, 480K)

> it seems like I'll be writing massive switches and if-else-if decision trees to determine what commands mean
just hide that bit in another module and never look at it. problem solved.

>parser will wait for input, read input one character at a time, if it sees a character in a given switch, fall through until a case is matched, and go through the rest.

No wait, that's retarded. That's why we have tokens. Tokens drastically simplifies implementation of a parser - no waiting around on single characters. Strings can be tokens, and strings can contain one literal.

If you want any semblance of expandability and l18n, you'll keep items as something that gets parsed and loaded and not hardcoded into the game.

Don't really get what you're saying but whatever
>Should I store each item's description in the item class? Will this take up a lot of memory?
You don't store things inside a "class". Constant strings go into something called the Read-Only Data section of your executable. To reference such a string you just need a pointer to it which will be just 8 bytes on 64-bit no matter what. If your strings somehow need to be unique per item you'll need to make new strings per item.

Not following the meme doesn't mean you can't make respectable architecture. See for an example.

Yay, I can sort.

$ ./a.out
(val: 4, num: 1) (val: 6, num: 1) (val: 42, num: 1) (val: 2, num: 2) (val: 3, num: 2) (val: 5, num: 2) (val: 1, num: 3)
#include
#include
#define NUM_VALUES 256

typedef struct {
unsigned int num;
uint8_t val;
} byte_item_t;

void merge_sort(byte_item_t *values) {
byte_item_t tmp[NUM_VALUES];
unsigned int width = 1;
unsigned int i = 0;
for (width = 1; width

You're using classes wrong.

Is this a binary sort? I'm still fuzzy on algorithms so I don't quite know what I'm looking at.

merge sort

You can tell by the name in there which says merge sort. Merge sort works by making sorted pairs of first 2 elements like (1,3) and (2,4) and then merging 2x2 into 4 like (1,2,3,4) and so on until you have a complete sorted set

Not sure if helpful but all RPG games I've played treats items as a number, and said number is the index in a huge table, displaying information for different fields in that index. Consulting the table on demand would save memory, but that will cost you a wee bit of CPU power (should be insignificant though). You could just add pointers inside the class, one for Name, another for Description, etc., each displaying the info associated with the index number of that item.
Item # Name Description Attrib 1 Attrib 2 . . .
1 Sword Cuts stuff Ice Unbreakable
2 Shield Defends Against fire 9 hits max
3
4
5
6
7
8
9
10
11
12
13
14
.
.
.

Yeah it would help if I could fucking read, my bad

Expanding on what this nigger is saying.

Create and Item Class, give it an ItemID, ItemName, and DescriptionID properties.

For your inventory, Assuming you don't plan on creating different variations of the same items. Use a list/array of your class item.

Now, if you don't plan on loading your descriptions all at once in your memory. Save it to a file/databse of your way of choosing. Indexed by a DescriptionID.

Now, you can selectively load descriptions.

Your variable naming really sucks.

Currently reading Perl 6 docs. Attempting to write a feature equivalent clone of Pandoc in a single .p6 file because fuck Haskell and its 800MB compiler toolchain.

I like that he has a struct where the two integer members are "num" and "val"

80 column max user :^)

I'll take it.

I'm going to use Huffman Coding and getting this sorted array is the first step to building a huffman tree.

void encode(void *src, unsigned int src_len)
{
// Calculate weights
byte_item_t byte_weights[NUM_VALUES] = { 0 };
unsigned int i = 0;
uint8_t *p = (uint8_t *)src;
for (i=0; i

reeee

I guess I accidentally the whole sentence. I wanted to say that it's amusing that he did that

Typically for inventories you use the flyweight pattern: You have a big "def" class that contains all the properties of an item and you have a smaller item class that contains a link to the def, that is actually instantion when you're dealing with the item

Class ItemDef{

field IsConsumable
field ConsumableRestoreHealth
field ConsumableRestoreStatus

field IsWeapon
field WeaponDamage
field WeaponElement

//an so on

}

Class Item{
field def //pointer to the ItemDef
field x,y //location in your inventory
field StackSize
}

the ItemDef would contain all the properties an item can possibly have. You can subdivide this and turn different areas like Weapon, Consumable, whatever into sub-objects
ItemDef classes should be loaded in via external text files or defined in-program

Also forgot to add, the ItemDefs are stored in a global map, index them by an id number or a name string or whatever, not that important really seeing the only time you need this identifier is when you create/serialize/deserialize items, most of the time you're dealing directly with the pointer

C++ question
Say I need to store a variable in a class, but I can't initialise it right away.
Should I make it a pointer instead, and initialise it to nullptr?

Let's say I do that and the variable is private. I have a setter function that accepts an argument of the pointer type I want to initialise my variable to.

But I can't point to an object that is being created in a different scope and will be destroyed automatically, right? So I assume I have to allocate memory using the new operator? The new operator creates a pointer iirc but it's dynamic so won't ever be destroyed.

Is this correct?

Look up tables are good to know about, but if you are already creating a class for an item, it's probably unnecessary. You might want to stick with a more OO centric approach in that case.

enum ItemType {
WEAPON,
ARMOUR,
CONSUMABLE,
MISC,
};

// Item interface
class Item {
public:
virtual std::string GetName() = 0;
virtual std::string GetDescription() = 0;
virtual std::vector GetAttributes() = 0;

ItemType GetItemType() { return m_item_type_; }
};

// Weapon Base Class, methods can be overwritten
class Weapon {
public:
Weapon() : m_item_type(WEAPON) {}
Weapon(const std::string& name, const std::string description)
: Weapon(), m_name(name), m_description(description) {}
// Other constructors ... ?
// GetName, GetDescription, GetAttributes

// Entity is an interface, could represent a monster, door, etc
// Should have stuff like health, dodge chance, resistances, etc.
// Ideally, some other class should be in charge of determining
// If a weapon actually hits an entity, this only handles
virtual void HitEntity(Entity *entity);
};

// Do the same for weapon, consumable, etc

// Lazy implementation of inventory, internally you should be storing
// items in some kind of container though (could also be a pointer to the item)
typedef std::vector Inventory;

// ...
for (const auto& item : inventory) {
std::cout GetName()

seems to work. Did it with a shared pointer instead tho

>unironically suggesting oo in 2019

I should probably mention that I'm not working in C and have no idea what half of any of this code means, but thank you. I guess I really should go with a .txt file, for moddability and foriegn languges if nothing else. Ruffles my autism to have to loop through it every time I need to create an item but it can't be helped.

A shared pointer is a much better idea. In modern c++ (e.g. c++11 and higher) you should never need to delete on a pointer yourself. You should always be wrapping new in some form of smart pointer.

It's probably a good idea to learn the difference between std::unique_ptr and std::shared_ptr too. unique_ptr is little more unwieldy to use, but it has less performance implications than shared_ptr, so you should use it when it makes sense. It seems like for your use case a unique_ptr would work.

I just wrote an example in pseudocode it's not C
how is that hard to understand
Load your text file into a group of classes in RAM and store them in a map or hashtable or whatever your language uses

Is that really psuedocode? I couldn't read it, I have no idea what the fuck virtual std:: means. I'm already pretty much doing what you said anyway, though.

The post I linked to, not the garbage C++ OOP mess

Oh, right, not sure how I missed that. But yeah I pretty much had that.

An Inventory is literally an object which contains other objects.

I know this board of full of die hard anti OO people, but, OO is actually a clean implementation in this case because it's actually what is happening with an inventory.

OOP isn't neccessary for this case because it can easily be represented as entirely data and introduced methods and inheritance to the equation doesn't actually give you anything but a more complicated implementation

>it can easily be represented as entirely data

I think the problem is that people are making too many assumptions about the data. Assuming you have a lookup table, for a weapon entry, how do you represent it? Let's say all weapons have a weapon damage, attack speed, hit chance. Okay. So you push all of that into some lookup table / struct thing.

But now we just have 12 variants of swords. We want to spice it up. We want to have a 10% chance of inflicting poison. Okay, how should we represent that? We could add two more fields to our data, like status effect, and percent chance to inflict it. Okay, sure. That's nice. Maybe we need to update our old tables now. What if we want to deal double damage to skeletons? Sure, let's add more fields. Let's make a potion that polymorphs you.

See, the list goes on, and if you storing this all in one place, you now have struct where 90% of the fields are literally going unused, and to actually use an item you are stuck doing a long chain of if statements. If there is a chance to inflict a status effect, is there bonus damage against this monster, etc. It's inefficient and inelegant.

OO Let's you avoid that. You want to create a weapon that has a special effect? Subclass the weapon, and add that effect to it's attack method.

>OO Let's you avoid that.
>class PointedWeapon
>class PoisonedWeapon
>class SharpWeapon
>class SharpPointedWeapon
>class PoisonedPointedWeapon
>class SharpPoisenedWeapon
>class SharpPoisonPointedWeapon
inb4 muh decarators

>now have struct where 90% of the fields are literally going unused
That's actually fine in this case because you do not have many item definitions. a few hundred in your project. I am making assumptions in this case, having designed games with inventory systems and I think the best way is "large chunk of data", optionally divided into components when you need them. Introducing inheritance is a bad idea in this case because inheritance is mutally exclusive. Weapon dervies from Item, Consumable derives from Item, it can't be both. You should use composition here. Also better to define code and logic to other systems rather than include them in your item defintions, because you probably want these item definitions to be simple, easy to write and loaded from a text file because it's game content

what language do i learn when i hate OOP, dynamic typing, and bloated/inconsistent design?

JavaScript

so what's the opposite of javascripts

>Having neighbours
lol

C

Based code monkey. Look into interfaces, no, not graphical interfaces.

How

Attached: xmpp.jpg (221x228, 10K)

Interfaces don't contain data though

>interfaces
It's not OO if they aren't virtual methods user

Hurr.

>IPoisoned, IPointed, ISharp
>Sword : ISharp, IPoisoned
>Spear : IPointed
>AnonsDick : IPoisoned

They aren't supposed to.

Which do you hate more, dynamic typing or bloat?

Yeah so interfaces are a pretty shit solution for a data storage problem aren't they?