Hello IQfy. Is there any alternative to C++, that still has OOP and classes, while not having separate source and header files, and with perhaps a bit cleaner syntax, especially for the templates?
Beware Cat Shirt $21.68 |
Beware Cat Shirt $21.68 |
Hello IQfy. Is there any alternative to C++, that still has OOP and classes, while not having separate source and header files, and with perhaps a bit cleaner syntax, especially for the templates?
Beware Cat Shirt $21.68 |
Beware Cat Shirt $21.68 |
yes
which one?
>having separate source and header
How is this a problem? How do you feel about c++20 modules?
It gets annoying quickly when you have to add a method to an existing class and have to edit two files. Or when you edit the function signature. It just seems much more clean to just have one file. I would love a C++ with java package system if that is possible.
>C++20 modules
AFAIK that is experimental and my compiler does not support c++20 yet. I tried building it from source, but it couldn't find some libraries or something. The distro provided g++ supports at most C++11 afaik. That's debian for you. Might have to dual boot with fedora or arch to get the newest compiler and try 20 out, it it isn't experimental
>C++ with java package system if that is possible.
You've just described C#
C# is a higher level language tho. I meant that literally, not just syntactically
literally just do header only, what's the problem?
>literally just do header only, what's the problem?
Circular dependency
>what are include guards?
>what is forward declaration?
You cannot do forward declaration in header only.
You would need to do
class A;
and declare pointers to A in the class B in B.h, then include A.h in B.cpp.
compile times blow up. Add template as well and you will spend >10s
In terms of direct replacement, D probably.
https://dlang.org/
I see that it uses GC by default and most libraries use GC as well. But it is still faster than java right? Is it about as fast as Go?
It depends how you use it. If you heavily rely on the GC you will see some slowdown, but Code that is equivalent to C++ should be similarly fast. Idiomatic D is to rely on stack allocation
Most Benchmarks I know of score it somewhere in the middle between go and C++ if you use the stdlib and not use raw pointers heavily
https://github.com/frol/completely-unscientific-benchmarks/blob/baeadaac61807f0049ad35b9282b0c27eeb6d104/README.md
yeah, beeflang fits this description
I am checking these two out. thanks!
Keep em coming tho
though, beef doesn't have template meta programming, it sports generics, comptime evaluation, mixins, code generation & comptime/runtime reflection which all together effectively amount to the same thing
D is good, Beef is for gamedev iirc, and then you have all the new memelangs like Zig, Nim etc. Or Rust if you care a lot about memory safety.
Honestly what are you gonna use it for, why not just use C#/Java/Go? Do you want to manage memory yourself?
>and then you have all the new memelangs like Zig, Nim etc. Or Rust if you care a lot about memory safety.
None of these have classes however. I worked with OOP programming languages for about 4 years and while I can see the appeal of rust, I am not willing to entirely change my ways of thinking about a program just to use these. I have tried using rust for game development, but I got frustrated when I could not avoid the error I got "SDL_Texture cannot be shared between threads safely", which I did not care about really, because I knew that my game will run on a single thread, and passing the texture array to every render call seemed like a stretch. Otherwise I also worked with C, so I technically could use langs without OOP just fine, but I prefer C++.
>Honestly what are you gonna use it for, why not just use C#/Java/Go? Do you want to manage memory yourself?
I already am using these. I use Python as my preferred scripting language, Java and C# as my preferred middle ground languages and C++ as my preferred low level language. So I was wondering if there was anything better. So far it seems like D, or C++20 might be the best options
>"SDL_Texture cannot be shared between threads safely"
I dont know any rust at all, but if you need to use something that cannot be shared between threads safely either make it single threaded or use unsafe
>C++20
Module support in 2 more weeks
Well you see, by making it unsafe, I would have to make nearly all rendering code unsafe and therefore the scene class and the game loop class and the main class unsafe as well. thread_local! requires unsafe as well afaik.
I am interested in knowing what types you were using that lead you to being forced to have to worry if SDL_Texture was thread safe, there are usually types that don't implement the Sync trait for example to avoid things like this.
The SDL_Texture itself is not thread safe. Normally the way I would do it in C++ is create a resource manager class and then either make all methods static, use a singleton pattern, or create a global of said class in a namespace. I don't remember which is the one I did in rust, but I did have a statically accessible hashmap of String -> SDL_Texture, I believe
Just wrap it with a mutex? Classes are pretty much the same as structs in Rust. The only difference is that they only allow one level of inheritance. Which isn't bad
Nothing in SDL is thread safe. If you were trying to thread it in C++, you were going to get a crash eventually, the compiler just isn’t smart enough to tell you, whereas the rust one is
Okay, but I know for a fact that my simple 2d game will be singlethreaded when it comes to drawing (literally which games have more than one threads for drawing???), so there should be a better way to do this other than #[unsafe] blocks everywhere
well, it's designed with high level ergonomics as well as lower level granularity to make it suitable both for gameplay & engine development - that said, it's not bloated with things that are only relevant to game devs
Rust
>Hello IQfy. Is there any alternative to C++, that still has OOP and classes
>that still has OOP and classes
>OOP and classes
>Rust
????????????
https://doc.rust-lang.org/book/ch17-00-oop.html
>If a language must have inheritance to be an object-oriented language, then Rust is not one.
Sounds clear cut to me.
Rust lacks inheritance, which while abused many times, it is still a viable feature and allows code sharing.
Rust also lacks proper encapsulation, access modifiers work on module level, but not on the struct level.
In the end Rust is not an OOP language, though it still allows to do 80% of what you need OOP for.
The other 20% is gui dev apparently.
https://www.areweguiyet.com/
Without complex and deep inheritance it is hard to make a good gui library. Gui is one of those things where inheritance > composition, which is why rust is bad at it
>Without complex and deep inheritance it is hard to make a good gui library
Why the hell do you think that?
Because elements have a hierarchical structure. Seriously, look at GTK for example.
>Object < Widget < TextWidget < TextBox < RichTextBox < CodeEditor
One example of gui library structure I have personally seen.
>If anything the way traits function make much more sense for making an extensible GUI than the rigidity and unnecessary complexity OOP introduces.
Then why is there no real GUI library in rust, just bindings to already existing stuff?
In all these years, Rustaceans are still expected to do the GUI in a webshit way which would void any sort of performance gain from Rust
>Then why is there no real GUI library in rust
https://github.com/iced-rs/iced
https://github.com/emilk/egui
https://github.com/imgui-rs/imgui-rs
>inb4 these are not real GUIs
Rust is still a relatively new language as are its packages, and projects like these show promise towards their future development and that Rust is perfectly capable in creating GUI libraries.
>Rustaceans are still expected to do the GUI in a webshit way
What the frick are you actually even on about
>Rust is still a relatively new language as are its packages, and projects like these show promise towards their future development and that Rust is perfectly capable in creating GUI libraries.
It's 8 years old at this point, isn't it?
>What the frick are you actually even on about
>Current approaches to building GUIs in Rust include interfacing with Electron and building GUIs with HTML (or a framework on top of it), while others have taken to using graphics APIs and various wrappers to emulate classical widgets. The cross platform parallel rendering engine Webrender, built for Servo and usable in Firefox Nightly, takes this latter approach and is multi-platform, but is more of a base for a GUI framework than one in itself.
So there are apparently classical widget libraries, but they don't even deserve to be mentioned
Gtk was released in 1998 and C was released in 1972, so what was your point again?
Why does this even matter? Do you think new projects challenging existing established ones are supposed to happen as soon as a language is released?
>Current approaches to building GUIs in Rust include interfacing with Electron...
Are you just going to ignore the GUI libraries I posted that don't do any of that? Where are you even quoting this from anyway? The ones I posted either let you target directX or wgpu which lets you target Vulkan among other backends like metal or directx.
Okay, but this is for games. Generally the general purpose ui should use either win32 api, or whatever the linux equivalent is. Software rendering anyway. Because computers that are more than 6 years old perform worse with opengl than software, at least in my experience
I don't see where these are restricted to games, you're going to have to show me an example of something that you'd think would be impossible to implement with Rust's GUI libraries AND is fundamentally unimplementable because Rust does not support inheritance (same thing with C which made libraries like GTK)
Maybe they arent, but the fact that you mentioned Vulkan made me think so. So these are basically Dear ImGui for Rust? Well, it is something so thank you for this
>GTK
Written in C, which lacks inheritance.
Instead the hierarchy you describe is forced into the toolkit, because GTK was created in a time when OOP and inheritance were considered "cool" and "good".
>Instead the hierarchy you describe is forced into the toolkit
So it does have it!
Anyhow, you still haven't proved that inheritance would be "bad" for gui, nor provided an alternative approach which would be better and easier to code
I am convinced you don't actually understand what inheritance is, otherwise you'd understand that just because there is a hierarchy like you posted for GTK (written in C that doesn't support inheritance) doesn't actually mean that it's utilizing inheritance in an OOP sense.
It does, because inheritance allows you to take elements of the parents and extending them
>Object < Widget < TextWidget < TextBox < RichTextBox < CodeEditor
show me an example of how this would look in C (not C++), either with this example or something simpler if you like. It has to respect the properties of inheritance of OOP.
Well C doesn't support OOP out of the box, so you need to emulate it like GTK does. It's not perfect, but that's what you get for stuffing shit into a language that is not built for it.
Or you can take win32 approach, where you register classes and then use class name as string in argument of CreateWindowA
>you still haven't proved that inheritance would be "bad" for gui
No one said that. I asked why you think it's apparently necessary for gui.
>an alternative approach which would be better and easier to code
In terms of API usability, there's the declarative approach, which is fairly easy to use without the need for a widget hierarchy at all.
What if you want to create a widget that would need to be extended from two unrelated types?
Say, a WYSIWYG editor that can itself contain both rich text, images, and other widgets.
How does that fit into your neat little hierarchy?
>What if you want to create a widget that would need to be extended from two unrelated types?
>Say, a WYSIWYG editor that can itself contain both rich text, images, and other widgets.
>How does that fit into your neat little hierarchy?
C++ can extend multiple classes
>Written in C, which lacks inheritance
Sadly it's not true.
The absolute state of OOP apologists. Your UI doesn't need to be OOP, look at elms UI model
no reason why inheritance is necessary for GUI development. If anything the way traits function make much more sense for making an extensible GUI than the rigidity and unnecessary complexity OOP introduces.
I'm literally making a simple gui library in rust right now. (pic rel)
>Without complex and deep inheritance it is hard to make a good gui library.
Strongly disagree. OOP patterns is not a limiting factor for how good a GUI library is.
OK, but will your gui library ever get to a scale of GTK/Swing/Win32?
literally a school project/hobby and you are comparing to enterprise solutions
I know I know, but the point is that while it is indeed possible to do widgets and ui without OOP and inheritance, it is easier to do so with, which is why almost all well known enterprise solutions do so
im dumb and replied to myself
It's not easier or better either way, OOP was only picked because it was hip at the time when UI frameworks and toolkits came out
if win32 api/gtk managed to do it with pure c, then it is possible to do it in a rust way, which is similar to c+haskell
What's the graphics API?
Whenever I see people building libraries on Rust, they do on top of C/C++ tools. It's extremely rare to see work that's 100% Rust and half the reason I haven't adopted the language(the other half being troony drama).
>they do on top of C/C++ tools
Yeah no shit. At some point you're probably gonna link to a c-lib regardless, espeically on linux. Who the frick is gonna sit down rewrite shit like xlib?
Not me, that's who.
Anyway, for graphics i'm just using opengl(for desktop) and webgl for browser.
For windowing the crate i use conditionally compiles between two windowing crates:
-glutin
-rust-sdl2
for the web browser I use:
wasm-bindgen
Not my problem. Seekbar exists for a reason.
>waited the entire webum for the n-word (Black person)
frick you anon. go back to Rreddit
Try Odin
There's the botnet's new language, explicitly designed to be C++ "but nicer".
>Hello IQfy. Is there any alternative to C++, that still has OOP and classes, while not having separate source and header files, and with perhaps a bit cleaner syntax, especially for the templates?
Yes, there is! Common Lisp!
If you just want OOP and no header files, then Java or C# should be fine.
I'm not sure why you are obsessed with header-only anyways. It's a terrible way to do things. It just means you have to recompile everything which includes that header every single time you make any changes to the code definitions inside. If you have the declaration in the header and the definition in a separate source file, then you can make changes that source file and not have to recompile anything other than that 1 file.
Plus, having the header basically serve a double function as an easily human-readable description of the API is really quite nice. I won't even attempt to try to learn someone else's project if they dump everything in one giant header. morons like that should neck themselves. I can kinda understand it as a method of distribution which caters to morons who are too stupid to figure out how to compile a source file, but that's about it.
Nim
>not having separate source and header files
you just lost the ability to load C libraries natively.
just use rust.
You want Java. Java is C++ done right. Only downside, it isn't compiled down to your language.
C# is java done right
This is the day when Sir Nagoor Babu and the German Microsoft Employee clash!!!
Sorry the Java guy is the German in this case.
But there are rumors of a fat german microsoft shill ...
Doesn't wonder me. The company which I am working for does also shill for MS and C#. I am currently doing C++, but I like Java the most of the three. Java is nicely designed in comparison to C++ and C#. Both are just bloated.
Alternatives Golang for sure, Dlang,C# and kotlin.
Rust has a really good module system and has the best tooling OOTB that i've ever used,however, its not really and OOP language. Its way more procedural than C++ and has no inheritence, no classes, and a very limited kind of polymorphism (trait objects/dynamic dispatch).
D is really good, it's like natively compiled Java with C mixed in
Is there any significant piece of software written in D? It's like 23 years old already lol
Serpent OS's package manager and other tools as well as the video game Quantum Break. Thats about it. IMO its good, it just doesn't have a league of shills like Rust.
A failed lang
C#
tard OP what lang did you pick?
looking into D right now
>meme dead lang
Rust
>perhaps a bit cleaner syntax, especially for the templates?
The only way you're likely to achieve those is by "C" wizardry ( and they'll be a fricking mess regardless of the implementation ).
Not sure of your use case but have you thought about a single translation unit and ditching templates?
what kind of homosexual uses a white background in 2022? seriously fricking have a nice day
Cross platform are pretty tricky to make. For some reason Foliate, which is built on GTK, doesn't work on Windows.
>https://github.com/redox-os/orbtk
nim
The GUI situation is an interesting one.
I am slowly coming to the conclusion, that GUI programming is really a different animal as compared to the rest of the application.
Most software systems interact with other software systems. For instance, your backend server makes use of file services provided by the OS, of network services, of perhaps computational libraries to offload heavy compute jobs. All of these interfaces have one thing in common, which is that they have very tightly constrained surfaces.
But the GUI is unique, in that the "interface" it communicates with is the human. and this is the source of all problems. The notion of "elegant" programming essentially means, that the program handles all the possible outcomes of whatever API it consumes, without any extra bloat. With system-provided API's, this is possible thanks to the small surface area of the system.
But with the human "API", the surface area of inputs is very very large, and very quickly becomes unconstrained. The human is fully asynchronous, random-input machine that can click, do keyboard input, move the mouse, press any combination of buttons at any point, and worst of all all of this happens continuously as time moves forward. And not only "time" is a variable, but "time durations" are variables too: You have to respect the human reaction time of ~80ms, if you blink a window, it must know how long to blink - not too long, not too short, and maybe you want to show a tooltip too - perhaps the tooltip should come from the UI element that the user clicked - oh and if its on the edge of the screen, it should automatically re-adjust itself, etc, etc.
so really, I don't think its possible to provide a GUI library with statically-typed languages practically. they will either be extremely convoluted, and will never be flexible enough except for the most simple apps. The other option (the most difficult, but solves the problem) is to roll a bespoke GUI framework specifically for your app.
Just create a template, stylesheets, and events. Ez. Webshit solved GUI, it just needs that someone would implement these ideas without a browser in the middle.
javascript is good, but for complex apps the HTML and CSS becomes a major bottleneck.
for simple apps, it definitely kills stuff like Qt and Java, simply because the barrier to entry and the friction is lower. but semantically, the classic desktop frameworks are just as powerful as the HTML layout engine (even a little bit more.)
Java GUIs suck. You have to make your own classes and inherit from the GUI library to modify stuff.
HTML is declarative, and CSS makes it super easy to style, and the relationship between these elements becomes much clearer and easier to see too.
You don't even have to use JavaScript. Just port these ideas to your own language. All these JS frameworks try to implement mainly a few ideas. Reactivity, creating your own html tagscomponents, and state management which usually uses some central state store
>and the relationship between these elements becomes much clearer and easier to see too.
no, i disagree. this is where it gets *harder*, and you have to use, as you correctly said, "state management which usually uses some central state store".
when one component wants to talk to another, it essentially pushes that message to the "top" of the tree (updates the central store), and the central store then ends up basically being one massive switch-case statement that dispatches that event to some element down the hierarchy. your app is still shoe-horned into a hierarchy.
It's more flexible. Stores aren't that complicated. Plus, I don't think that traditional OOP would be easier clearer to work with on big apps. How do they even manage shared state?
>Satan digits
>Java GUIs suck. You have to make your own classes and inherit from the GUI library to modify stuff.
That's how it should be done. Compare that to GTK
i hit the word limit, but i wanted to add some more thoughts.
the common theme with GUI programming, is that you essentially end up with a "many-to-many" relationship, vs. the tree-like structure of relationships that typical systems programs often fit inside of.
A good example of a tree-like code structure: parsers and lexers. There is very clear encapsulation of responsibility, and you can reach a near-perfect elegance (ofcourse, it gets complicated if you want niceties like correcting errors mid-stream and continuing to parse, etc.)
With GUIs, you end up with these dense, many-to-many relationships, that aren't really constrained in any obvious way, between all your different functional elements. e.g., you may have a paint program, with mutiple canvases, multiple different filters (and live previews for them), tooltips, etc. and they all have to be synced to their source data. some of those widgets live inside the parent window, some are independent windows, and they also need to stay out of the users way while still providing information. its a ton of heuristics with no discernable "rule" of how GUIs should be done, because the API interface (the squishy human) doesn't have any rules itself! what is a good effective workflow is 100% experimentation based.
so I think for GUI programming, its unsurprising that javascript has taken off, because its very dynamic nature hold you to no inherent structure. it readily lends itself to spaghetti-code, which is just a pejorative for many-to-many relationships that is inherent in GUI interfaces.
so I think, in the end, GUI is really its own animal that needs its own language. I would seek to "containerize" the GUI logic, sort of how electron does it, and have the GUI then make calls to the "backend" for resources.
Racket
you could do this in C/C++ already just by using macros and the preprocessor.
Dlang. Its Carbon before Carbon but actually good.
no
>I want to draw UML diagrams and think about class hierarchies all day instead of actually coding stuff
>...and when I finally code stuff, my class hierarchy becomes a hot-fixed mess anyway
I don't get you, OP. You complain about having to declare and define in two different files sometimes but you will happily re-arrange your class structure all day long when you realize expressing a motorcycle as a car with only one seat wasn't as clever as you thought in the first place.
Nah I don't do that. I don't work in corporate and I never plan ahead for longer than 30 minutes. I also never draw class diagrams lmao. I just imagine a functionality and if it involves some initialization and data bound to a datatype I use class
Unironically? Free Pascal.
this
Why
Common Lisp, unironically.
Use the grownups language, aka Forth
Nim
node-fortran
> Alternative to C++
Literally almost any language that came after it.
what exactly you do need OOP for?