/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

Canary has been updated.

Build Back Better

Sorry for the delays in the BBB plan. An update will be issued in the thread soon. -r

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


Have a nice day, Anon!


C++ General Robowaifu Technician 09/09/2019 (Mon) 02:49:55 No.12
C++ Resources general The C++ programming language is currently the primary AI-engine language in use. isocpp.org/get-started https://archive.is/hp4JR stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list https://archive.is/OHw9L en.cppreference.com/w/ https://archive.is/gt73H www.youtube.com/user/CppCon https://archive.is/QGynC BTW if you're new to C++ and you're stuck on Windows (either you can't or won't upgrade to Linux) then you can at least incorporate a good, open shell into your system to begin with so you can follow along. Start at this link, and if you have any questions just ask ITT: www.msys2.org/ https://archive.fo/p3EUc >=== -julay-era fmt'g post
Edited last time by Chobitsu on 04/04/2024 (Thu) 23:25:55.
>>10791 >same for files. Apologies, I missed that. Yes, that's a pretty easy addition and I had already planned to incorporate that soon. Be aware, it would only be a filename search, not some type of AI-context analysis relying on huge globohomo cloud datacenters. So, if an anon posted a well-named file, you might get lucky that way. OTOH, if it's just a SHA or other type of hash name, then probably not so much. One feature I want to add into Bumpmaster is crowd-sourced tagging of posts & other content, including images. We potentially could conceivably even tap into the work the Hydra community has done in this area.
>>10794 >>10795 Sounds all very good, thanks. I probably could get all inks out of the json archives and also download them this way, including the description.
>>10809 Yep, and there are a few of them here too: waifusearch> youtube OR youtu.be . . . ' youtube | youtu be ' = 476 results waifusearch>
>>10812 Yeah, if it's possible to build on Waifusearch, it's probably better to do it that way.
just leaving this here for future reference. https://github.com/adobe-fonts/source-code-pro
New talk by Sean Parent https://www.youtube.com/watch?v=NO5wHzI_oug Turns out, he's finished all the talks for his book, and is now just doing the writing. Also, he's starting the STLab at Adobe back up, and David Abrahams will be joining him there. This is great news ofc. We probably will get a very polished implementation of an efficient, scalable & robust continuations library out of this collaboration. This is great news for /robowaifu/ and should make things like anon's IPCNet (>>2418) and anon's RPCS (>>11018) doable on very lightweight hardware, and relatively quite simple to write the underlying 'fabric' software itself.
What would be the fastest way to do matrix multiplication in C++? With compiler optimizations, profiling and everything. I wanna implement a transformer with raw, absolute speed. No fluff or usable code, just pathological maximum efficiency, running on a Raspberry Pi 4B. The matrix operations in the self-attention layers will also be a key part to optimize: # query: (batch_size, query_length, heads, heads_dim) # key: (batch_size, key_length, heads, heads_dim) # energy: (batch_size, heads, query_length, key_length) energy = einsum("nqhd,nkhd->nhqk", (query, key)) # attention: (batch_size, heads, query_length, key_length) # value: (batch_size, value_length, heads, head_dim) # out: (batch_size, query_length, heads, head_dim) out = einsum("nhqk,nvhd->nqhd", (attention, value)).view(batch_size, query_len, self.heads * self.head_dim) Einsum is just a way to describe multiplying and adding matrices and transposing axes. How can these three things be done most efficiently?
Open file (4.05 KB 80x84 armadillo_logo2.png)
>>12422 >The real heavy-lifting will come from libraries like mlpack & Armadillo (>>8565) You won't be able to outperform the pure-template libraries of Armadillo lad. And since you're interested in doing this type maths for ML work, you may as well ride with mlpack to utilize it with. Besides, we already have AI researchers here working with both, so you'll be right at home with it, /robowaifu/ speaking. https://mlpack.org/ http://arma.sourceforge.net/
>>12422 >>12424 If you just want to cut to the chase, this lad has already hatched together a tensor contraction algorithm you can tinker around with for starters. https://github.com/romeric/Fastor I'm sure you'll have your hands full getting all this to work well on wee hardware like the RPi, but of course that's a serious and fundamental goal for the Model A robowaifu prototyping stage, so go to it you madlad! :^)
>>12425 >I'm sure you'll have your hands full getting all this to work well on wee hardware like the RPi I've been doing some tests and the RPi is roughly 1/10th the speed of my PC. Full-attention layers are probably out of the question but it should be able to handle linear attention. Fastor looks amazing. I hadn't heard of this. >>12424 Armadillo might have some issues with it: https://romanpoya.medium.com/a-look-at-the-performance-of-expression-templates-in-c-eigen-vs-blaze-vs-fastor-vs-armadillo-vs-2474ed38d982 But I don't think the norm function is needed for inferencing, only clipping the gradient during training. I'll test them both and see which is faster.
>related crosspost (>>12439)
Do the C++ anons here have this channel on their radar? Dave's garage: https://youtu.be/B9DouAlkZlc
>>12739 Thanks for the heads-up Anon, but something titled > 'New! Stupid C++ Tricks - Most Dangerous C Functions (E02)' doesn't sound like something I'm really interested in spending the bandwidth to download. Mind spelling out why you linked that particular one, is there something I'm missing? So-called 'C-with-classes' that so many C developers are prone to is absolutely the worst of both worlds and something no self-respecting C++ developer, nor the same for C developers would give two pennies for. Standard, straight modern C++ is superior in every way imaginable from the professional software engineer's perspective, and teaching newcomers circa mid 1980's software techniques is something only worthless college """professors""" who never slung a line of professional code in their lives would think of abusing doing tbh.
I still can't use Bump to reliably backup the forum. Even if a delete a whole subfolder from the folder with threads, and the catalog json+html it do recognize that something is missing. It doesn't remember failed downloads of pictures or files, so it won't try again. Before that it looked good, it updated some thread and downloaded all the old pictures with it. I don't know why. This would at least helpd a little.
>>13034 Hey Anon, sorry you're having trouble with BUMP. I'd suggest you try this command (note the 2 separate, extra '1' at the end): build/bump alogs.theГунтretort.com robowaifu 1 1 That should hopefully rebuild the special .archbot.config file for you, walk all the threads and all your local directories, and patch up anything missing. I added the two 'undocumented' flags to the program to deal with just such issues. Let me know if you still have issues, I'm usually around the board every few days like today.
>>13064 >that Гунтed link AUUUUUUGH ROBI U BASTARD Got me again. :^)
>>8823 How do I install/run this?
>>13537 meson build meson -C ninja cp cxxchanConfig.example.json cxxchanConfig.json cp config.example.json config.json build/cxxchan then uncomment the 0.0.0.0:80 listener in the config.json file, and you should be able to access localhost/sys/login in your browser *depending on your gcc version you might have to edit some const c-string declarations (const char* -> constexpr char*, constexpr char x[] -> constexpr char* x)
>>14626 ninja -C build*
Open file (97.52 KB 611x469 waifudev.jpg)
>>8823 God, what the fuck is wrong with whoever wrote that library you used? In libcaptcha.c: void makegif(unsigned char im[70*200], unsigned char gif[gifsize]) { // tag ; widthxheight ; GCT:0:0:7 ; bgcolor + aspect // GCT // Image Separator // left x top // widthxheight // Flags // LZW code size memcpy(gif,"GIF89a" "\xc8\0\x46\0" "\x83" "\0\0" "\x00\x00\x00" "\x10\x10\x10" "\x20\x20\x20" "\x30\x30\x30" "\x40\x40\x40" "\x50\x50\x50" "\x60\x60\x60" "\x70\x70\x70" "\x80\x80\x80" "\x90\x90\x90" "\xa0\xa0\xa0" "\xb0\xb0\xb0" "\xc0\xc0\xc0" "\xd0\xd0\xd0" "\xe0\xe0\xe0" "\xff\xff\xff" "," "\0\0\0\0" "\xc8\0\x46\0" "\0" "\x04",13+48+10+1); int x,y; unsigned char *i=im; unsigned char *p=gif+13+48+10+1; for(y=0;y<70;y++) { *p++=250; // Data length 5*50=250 for(x=0;x<50;x++) { unsigned char a=i[0]>>4,b=i[1]>>4,c=i[2]>>4,d=i[3]>>4; p[0]=16|(a<<5); // bbb10000 p[1]=(a>>3)|64|(b<<7); // b10000xb p[2]=b>>1; // 0000xbbb p[3]=1|(c<<1); // 00xbbbb1 p[4]=4|(d<<3); // xbbbb100 i+=4; p+=5; } } // Data length // End of LZW (b10001) // Terminator // GIF End memcpy(gif+gifsize-4,"\x01" "\x11" "\x00" ";",4); } He could've assigned that huge-ass string at the start to an array with a nice name like "header" and memcpy()ed the array, as well as taken its size with the sizeof operator instead of calculating it by hand. After making that mistake, he then goes and copypastes his complicated length calculation when initializing the variable *p, and makes the same mistake all over again at the bottom of the function. It's literally the first function in that file I read and a first impression like this usually means the entire program is rotten. He also got his MAX macro wrong. #define MAX(x,y) ((x>y)?(x):(y)) Notice how (x>y) doesn't parenthesize x and y. Just skimming further down I see memmove() used for no reason at the end of the filter() function (its source and destination don't overlap, the source is an auto array, the destination is one of the function's parameters). I also see a load of repeated small read() calls that would've been better done with readv() and which have no error checking inside captcha(). Then there's also the buttload of globals which in all likelihood are global for no reason, of which Clang says lt4 and lt6 aren't used. t. C programmer who wouldn't touch C++ even at gunpoint.
>>14738 Thanks for the constructive critique Anon, it's appreciated. Yes, memory-management is a very tricky issue, and one that few in life master. I strongly prefer to figure something like this out 'one time only', then encapsulate it all behind a simple-to-use interface I can stumble through successfully during a bleary eyed 3AM coding session. >t. C programmer who wouldn't touch C++ even at gunpoint. Kek. BTW, would you like to write robowaifu software with us here? I can tell you (well in advance) that we'll be needing many, many device drivers for our robowaifu's electronics & hardware systems. Literally hundreds of different drivers to adopt to our HALs. C programming will obviously play a very strong role in the devising of all these. It's certainly a man-sized task, and your help would be welcome if you'd care to assist us with it. We certainly have a big, big collection of things to do on our plate, and this will be a vital one. Cheers.
>>14738 >t. C programmer who wouldn't touch C++ even at gunpoint. Nice bait. Though its true that the majority of his globals are unnecessary and should be creatable in an array function as needed to take advantage of C++’s dynamic memory allocation. Optimization is truly a dark art these days.
>>14743 The constants that make up those globals have to be somewhere in memory, using a C++ feature for them won't improve anything. If anything it might create an undesirable situation where some memory is allocated and then the values are unnecessarily copied into the memory when the values could be used directly from where they already are in memory at the start of the program. They should be inside a function that calls the functions that need them, and then passed on as arguments. The compiler will place them in some region of memory and they won't be copied around if the compiler can prove they're never written to or if you explicitly give them static storage duration. The issue with the globals is semantics. Computers do what we tell them to do. That C programmer told the compiler he needs a number in a specific place that can be read and written in any way possible by anyone and that he wants the latest state of the number every time he uses it, when what he actually wants is a number that is always known and always the same and that will only ever be recalled in the current source file, gifsize should've been an enum which is what provides these semantics. Heck, thanks to POSIX the compiler doesn't even know if those globals will be executed, because POSIX has functions for making a place in memory executable. There is no such thing as self documenting code, but there is code about which there is less to know. One has to look at the entire program to tell if the global gifsize is modified and then find out why and when, even if it's const qualified, because const variables can be modified in C (and probably C++). If at least it had internal linkage, you'd know its only uses were in that ~240LoC file, and suddenly it's also easier to put faith in the "const" qualifier. The semantics of globals prohibit compiler optimizations. Inside a linkable library or without LTO, the compiler is forced to assume that the broadest set of operations is performed on the globals, as all it knows is that code other than the code it can see has read/write/execute access to them, and because of that gifsize & its friends can't resolve into immediates in assembly and the operations performed on them can't be resolved at compile time or anything like that, they have to be a place in memory that the processor has to fetch with a pointer and every single operation on them has limited range of possible optimizations. This isn't so much of a premature optimization as it is a nice little side effect of just getting the semantics right, correct code is both easier to understand and faster.
>>14758 Naicu insights, Anon. Thanks! >correct code is both easier to understand and faster. Lol, you clearly saved the best bit for last. :^) I would go further and add that the closer you fashion a solution in code to one that a domain expert themselves immediately recognize as good one, then the more likely it is to be efficient in both time and space after compilation. I hope you help us all with the drivers Anon. We'll probably start with the Arduino Nano (which is amply documented already) and move out from there. Cheers.
>>14759 Sure. But I haven't done drivers. Never touched an Arduino either.
>>14765 Neat! That's good to hear Anon. Welcome aboard! >But I haven't done drivers. It'll be easy. You just need to devise a standardized way to talk to the device's pins. As you might imagine, pin numbers can be all over the place, and may also require small amounts of preamble ceremony beforehand. We just need to turn that into easy to remember interfaces, standard across all the devices we'll use in our robowaifus. I'd suggest you have a look at Derek Molloy's videos for a starter Anon. https://www.youtube.com/c/DerekMolloyatDCU/playlists >Never touched an Arduino either. You might want to pick up a handful then, they're quite inexpensive (for the power they bring). Here's but one of hundreds of possible sources, 3 for ~ US$ 20 www.amazon.com/REXQualis-Board-ATmega328P-Compatible-Arduino/dp/B07WK4VG58 >=== -fix missing greenquote
Edited last time by Chobitsu on 12/23/2021 (Thu) 12:41:36.
>>14738 kek, feel free to email the libcaptcha author (kefeer@brokestream.com). that library has some problems indeed, I noticed that various things were wrong when I used it for the ib, I even felt tempted to rewrite it entirely, or at least partly, or at the very least fix the compiler warnings, but got scared by the copyright notice (points 1 and 2 in particular). and didn't want to waste time writing my own. I ended up doing things like avoiding the gifSize "constant" entirely and the declare my own ("constexpr int gifSize = 17646"; constexpr is a C++ specifier for expressions that are known at compile time). to avoid some of the semantic problems that you mention. you're wrong about the internal linking tho. g++ uses internal linking by default for symbols marked as "const" (and static, obviously). I never #include the libcaptcha.c file, so the compiler would throw an error (even before linking) if I tried to use those symbols anyway. the C++ part (my code) is even worse. from the hard-coded queries to the obscure orm (which needs it's own compiler to generate implementation files), blocking queries everywhere, and non-threadsafe globals in a multi-threading context. it nonetheless work. I might try to write something better in zig or C++ in the distant future
>>14826 >blocking queries everywhere, and non-threadsafe globals in a multi-threading context. We'd certainly be interested in seeing solutions to these issues Anon. BTW, do you know of Apple's libdispatch ?
Realized I was being kinda silly devising my own convoluted logging system out of concern for performance latency, once it suddenly dawned on me the C++ standard library already sported a perfectly-serviceable buffered logging system--which can lazily write to files. Here's a little RAII-compliant hack for doing just that. [1] >main.cpp #include <cstdlib> #include <fstream> #include <iostream> #include <string> class File_clog { public: File_clog() = delete; // no default ctor // globally-redirects all std::clog output into the given filename instead explicit File_clog(std::string const& name) : log_nm{name}, log_file{log_nm} { // assign this log file's buffer into std::clog : auto log_buff = log_file.rdbuf(); std::clog.rdbuf(log_buff); } ~File_clog() { // restore the original clog buffer std::clog.rdbuf(clog_buff); } void flush() const { std::clog.flush(); } void exit() const { this->~File_clog(); } private: std::string log_nm; std::ofstream log_file; // preserve clog's original buffer for restoration during this class' dtor std::basic_streambuf<char, std::char_traits<char>>* clog_buff = std::clog.rdbuf(); }; //------------------------------------------------------------------------------ // use a disk file named test.txt to write log entries into int main() { using std::clog; clog << "Foo, Foo, Foo\n"; // capture all std::clog output into logfile instead : File_clog const logfile{"test.txt"}; clog << "Test, Test, Test\n"; clog << "Bar, Bar, Bar\n"; logfile.exit(); // note: class' ofstream member flushes on destruction std::system("cat test.txt"); clog << "Baz, Baz, Baz\n"; // note: std::clog is working normally again here } --- 1. https://coliru.stacked-crooked.com/a/e9564f03168681f3 >example command line + possible output: g++ -std=c++20 -O2 -Wall -pedantic main.cpp && ./a.out Foo, Foo, Foo Test, Test, Test Bar, Bar, Bar Baz, Baz, Baz >=== -fmt, prose edit -reworked example
Edited last time by Chobitsu on 04/04/2024 (Thu) 21:48:40.
>>14826 well, I decided to finally write that zig imageboard, 2 years later. I'm still not 100% happy with the results, but it's an improvement over the previous attempt. this one is easier to setup too, and it only has two dependencies besides the zig compiler: sqlite and imagemagick. no libcaptcha this time (just imagemagick) and even less javascript (none) https://codeberg.org/cirefl/yutai (sorry for the necrobump)
>>28906 >(sorry for the necrobump) NONSENSE! :^) We here on /robowaifu/ don't believe in any such thing! :D BTW, if you do create a site, please allow for Torposting of files. Also, a post 'move' feature (such as the one supported by JSchan server software) would be very nice. And lastly, I may say that having a JSON API for your pages would be very welcome, since it would allow tools like our BUMP (and soon, Bumpmaster) to effectively access/archive your site's boards. Good luck with your project, Anon. Cheers. :^) >=== -add 'JSON' cmnt
Edited last time by Chobitsu on 04/04/2024 (Thu) 21:44:08.
>>28906 That's great. Can it import backups of boards via json? You probably just use the database, so is it documented where what belongs or is it only in the code? Also, did you share it in other places, so people who know Zig look at the code?
Just a heads-up that I've picked back up work on the PPP2 project to support our C++ Classroom thread : (>>19777) , and as a direct part of our accompanying /robowaifu/ C++ Textbook thread : (>>18749) . Here's an early peek at the new files layout. I hope to be ready and pick the classroom back up around late May/early June. [1] We'll see. Cheers. >main_p415.cpp : // filename: ./ch_12/main_p415.cpp // Code derived from Bjarne Stroustrup's PPP2 book // § 12.3 A first example // -and beginning on p415 // -Instead of using the recommended Meson project way, this file can be built // and run standalone (from the root directory of the overall PPP2 project) : /* g++ ./ch_12/main_p415.cpp ./lib_src/all_srcs.cpp \ `fltk-config --ldflags --use-images` \ -I./lib_include/ -std=c++20 -O2 -Wall -pedantic -o p415 ./p415 */ // --=^=-- #include "Graph.h" // get access to our graphics library facilities #include "Simple_window.h" // get access to our window library //------------------------------------------------------------------------------ /** */ int main() { using namespace rw::Graph_lib; // our graphics facilities are in Graph_lib Point tl{100, 100}; // to become top left corner of window Simple_window win{tl, 600, 400, "Canvas"}; // make a simple window Polygon poly; // make a shape (a polygon) poly.add(Point{300, 200}); // add a point poly.add(Point{350, 100}); // add another point poly.add(Point{400, 200}); // add a third point poly.set_color(Color::red); // adjust properties of poly win.attach(poly); // connect poly to the window win.wait_for_button(); // give control to the display engine } // --=^=-- // Copyright (2024), the anonymous collective // License MIT (Expat) https://opensource.org/licenses/MIT --- 1. Planned schedule cancelled. cf. : (>>31023) >=== -minor edit -patch crosslinks -minor code patch -add cancel notice
Edited last time by Chobitsu on 04/26/2024 (Fri) 17:30:28.
Great good Sepples news -- particularly for /robowaifu/ ! (>>31023)
Open file (861.06 KB 600x620 2b dancing.gif)
Hello, I've posted on this board pretty much on and off since 8chan. I'm glad to see a lot of the familiar faces here, especially chobitsu. remember that time we all thought he was dead? Anyways, I came here primarily to ask a question. Should I devote more time to learning C++ or python? I feel more comfortable with C++ but it's a lot more complicated than python. Python on the other hand, is much more simpler however a problem with it is I dislike how the loops and if statements work, you know how you have to have everything perfectly indented. I am almost done with my computer programming AS degree, as in at the end of July is the end of my final class, coincidentally which is python. I want to take things further but I'm not sure which one is more useful.
>>32122 Most of the open-source AI stuff is done in python. There's some editors that can help with the indenting thing (thonny not being one of them)
>>32122 Depends what you want to work on. If you want to do robotics, you should focus on C++. If you want to do AI, then focus on Python. Or you can do both, writing C++ and calling it from Python to enjoy the ease of Python and raw performance of C++. There has been rising interest lately in CUDA and C++ to squeeze the maximum performance out of hardware while training and to put models into production. A few years ago I would say you only need to know Python for AI but you should know both now, starting with Python first and moving onto C++ to optimize when you're ready to deploy. You do not want to ship your product with 10 GB of bloated Python libraries and hope it runs well on systems running at 1/20th the speed and using HDDs instead of NVMe.
>>32122 Hello, Anon. Welcome back! >we all thought he was dead? Eheh, sorry 'bout that Anons... :P >C++ or python? Long story short, my answer is obviously C++ . We have far more need of -- and far fewer of -- C++ devs here on /robowaifu/ . For more info, see: -All AI programming is done in Python. So why are you using C & C++ here? (>>21057, >>21091, >>27167, >>29994) BTW, JetBrains (the company) makes world-class IDEs for both languages. And CLion (their C++ IDE) in particular, currently stands alone apart from all the rest in the field IMHO. ABTW, as full-time students, we get free access to their entire product line for at least a year. I recommend you take advantage of this before you graduate, Anon. https://www.jetbrains.com/store/?section=students&billing=yearly Good luck, Anon! Cheers. :^) --- One other thing: the well-known Tiobe Index has C++ moving into the #2 position -- surpassing C for the first time in history! Interesting times ahead. The Robowaifu Age dawns soon, I'd wager. :^) https://www.tiobe.com/tiobe-index/ >=== -fmt, minor edit -add Tiobe cmnt
Edited last time by Chobitsu on 07/11/2024 (Thu) 02:10:14.
>>32122 >C++ or Python Chobitsu likes C++ and seemingly doesn't like Python. That should be obvious. Programmers tend to always be biased toward certain languages so here I go as a non programmer (but i have done a little C++ ages ago). Julia may be a better language to use in case of autonomous robotics since it is a data science language including ML and AI and doesnt require a license like MATLAB which is unfortunate since MATLAB has libraries for humanoid robots. Julia uses a Python like syntax but i recall reading it removes the space sensitivity i see so many get troubled over with Python. It is also able to call on C/C++, R, Python, Rust, Fortran. It has been claimed it may solve the issue of having to use two languages for robotics because it is fast enough to operate in real time while Python is less than ideal even though pretty much all the recent ML stuff is written in Python. Since Julia is similar enough in syntax you possibly could more easily language migrate programs written in Python than you could going Python to C++ but that is just an assumption. https://ieeexplore.ieee.org/document/8793875 https://juliarobotics.org/tutorials/ But since this is for a degree you should just focus on Python so you can avoid confusion mixing up Julia and Python code while in your final class.
>>32178 >Chobitsu likes C++ Quite true, and for one reason alone: it's simply the single best language selection currently for robowaifu systems programming. No other language choice will afford us such good odds for success at devising appealing & effective, totally-Globohomo-unencumbered, secure, private & disconnected DIY waifus at home. C will be important as well for smol <=32K devices; things like tiny onboard microcontrollers & sensors, which will communicate data back & forth with the robowaifu's core systems. We'll likely even need a tiny bit of ASM before all's said and done. >and seemingly doesn't like Python. Heh, I'm almost fully self-taught in programming. The single exception to this is the one programming class I've had in college. Namely, Python. I made perfect scores on every assignment in the class that semester: 4.0+ . So yeah, IMO Python's fine...as long as it's used for what it's intended for. To wit (and in a word): scripting. But it's essentially useless to us all for the highly-critical systems programming areas of robowaifu development. Both will be needed in the end. But the basic fact is that we have a glut of Python devs here, and a dearth of Modern C++ devs. Until we get on top of the realtime-systems design & engineering needs for DIY robowaifu creation, being able to script them is of little utility -- basically a 'company bikeshed'. Simple as. Cheers, Anon. :^) >=== -fmt, prose edit
Edited last time by Chobitsu on 07/12/2024 (Fri) 18:27:36.
>>32182 what would you need asm for? even the most obscure devices have a c compiler and trying to write better code than the compiler is almost impossible when they use every trick youre probably not even aware of like xor %rax %rax which seems like a pointless inefficiency sprinkled in the code for no reason except its just a register renaming trick to get rid of false dependencies even vectorising isnt that bad but c++ already has intrinsics for that
>>32185 It's a fair question, Anon. Short answer: Hopefully we won't. But this is frontiersman's work in many respects. I don't consider it at all unlikely that we'll need to devise custom hardware & the electronics to go with. This is going to also require new drivers to be written in the event. Since some of these custom boards are likely going to be venturing deep into the hard-realtime time domains, it's not at all impossible that ASM turns out to be the only feasible choice. But again, hopefully we can solve the majority of all cases at the highest levels -- in this order: >1. C++ >2. C >3. ASM Then Python/Lua for scripting everything. Cheers.
Got bored and tried some C over past few days and it is pretty annoying how easy it is to write code that executes without mention of an error but is bad code or something that follows same pattern that works say for an integer, float or character but doesnt work when you use a string in same place which seems illogical to me. But i also dont have a working machine to code on so just using an online compiler to play around with simple things.
>>32342 by design, warnings are optional you have to enable them, in gcc its -Wall -pedantic -Werror i think youre confusing datatypes with an array of that datatype ( char / char[] ), theres no string type in c because theres no such thing really it doesnt make sense, its string as in literally a string of characters as in an array of chars, writing "asd" is just for convince for not having to write (char[4]){'a','s','d','\0'}
>>32342 If you're annoyed by that, then it's possible that C or C-style C++ might not be your thing. The opus of such devs has always been "Trust the Developer!" :^) OTOH, if you're still keen on doing systems work (as opposed to say, scripting, where Python is a clear choice), then Modern C++ should fit the bill. For example, regarding this complaint: >or something that follows same pattern that works say for an integer, float or character but doesnt work when you use a string in same place which seems illogical to me. These types are actually consistent in their behavior in C++, with only the char type having a caveat : >operators.cpp #include <iostream> #include <string> using namespace std; int main() { int a{1}, b{2}; float c{3.}, d{4.}; char e{'e'}, f{'f'}; string g{"foo"}, h{"bar"}; // each of these types has an '<<' operator defined already : cout << a << ' ' << b << ' ' << c << ' ' << d << ' ' << e << ' ' << f << ' ' << g << ' ' << h << '\n'; // each of these types also has a '+' operator defined already : auto ab{a + b}; auto cd{c + d}; auto ef{e + f}; // operator+ for char will decay into an int-based-ASCII value, so use as string efs{e, f}; // a string init-list of elements to preserve them concatenated instead auto gh{g + h}; cout << ab << ' ' << cd << ' ' << ef << ' ' << efs << ' ' << gh << '\n'; } >output: 1 2 3 4 e f foo bar 3 7 203 ef foobar --- With C++, you can define your own custom operators, so something like this is doable as well : >robowaifu_FKIK.cpp class RW_elbow_joint { //... }; // one type class RW_wrist_joint { //... }; // one similar, but distinct type // both types can work with a special custom operator+ that you would devise : bool precheck_forearm_FK_solve(RW_elbow_joint const& ej, RW_wrist_joint const& wj) { //... auto FK{ej + wj}; // the new, custom operator+ in action return FK.is_valid(); } >=== -minor edit -add FKIK snippet
Edited last time by Chobitsu on 07/24/2024 (Wed) 06:26:48.
>>32343 What I did was take this lesson #include <stdio.h> int main() { char chr; printf("Enter a character: "); scanf("%c",&chr); printf("You entered %c.", chr); return 0; } Then I realized this seems similar to a messaging system so I tried to see what happens. I was able to replace it for integers and that ran so then I tried to see if I could make it give me all the characters I type in a sentence. #include <stdio.h> int main() { char chr; printf("Enter a message: "); //%s short for string scanf("%s",&chr); printf("You wrote %s.", chr); return 0; } I know this is wrong since I get a segmentation fault but the logic of the syntax structure doesnt follow the same pattern as I would expect. >>32346 Maybe. Nothing drew me to the language, just it being so common I thought I should look at C and then C++ To be familiarized with it.
>>32351 Here's a couple of operator>> examples : >char_str_inputs.cpp #include <iostream> #include <string> using namespace std; int main() { char foo{' '}; string bar; // as with operator<< , these types each already have operator>> defined cin >> foo; // example input: 'Z' cin >> bar; // example input: "Robowaifus" cout << "You input '" << foo << "', and \"" << bar << "\"\n"; } >output: You input 'Z', and "Robowaifus" As before, both types are consistent in their usage. String type also supports getline() operations. https://en.cppreference.com/w/cpp/string/basic_string/getline
>>32352 I was focusing on C first since C++ is technically an extension of C so I wanted to see the barrier. That code must be C++ because it wouldnt run as C but did for C++ but I put in "test words" and it gave me "you input 't' and 'est' " which is different from what I was going for though interesting to see if I put multiple words separated by a space it behaves that way different from one word and enter then another and enter. Tried seeing if changing it to string bar and removing all foo references which still only output a single word. Then when I look up how to do it, it's totally different setup for a getline...bleh #include <iostream> #include <string> using namespace std; int main() { string usr_str; getline(cin, usr_str); cout << "You input: " << usr_str << endl; return 0; }
>>32354 Good job, Anon! Way to do research on your own. Yes, you've found the way to do regularized input for a char (your first 't'), string, and whitespace-separated string collections. As your example shows, it's both simple to do, and pretty much bulletproof from unintentional crashing (since the resources are properly managed through the type's handle (ie, std::string).
>>32354 >>32355 Also, filestreams (in or out) work the same as textstreams do. >fortune_cookie.cpp #include <fstream> #include <iostream> #include <string> using namespace std; // given: a multi-line textfile named 'fortunes.txt' in the project path, containing : /* you will be singled out for promotion good ideas will spring forth naturally from your mind in the coming week good health will be yours for a long time you will be spending time outdoors in the mountains near water you will soon take a very pleasant and successful trip you will be blessed with longevity your secret desire to completely change your life will manifest */ // demo: that filestreams work just like textstreams do : int main() { // similar to cin & cout, but for input files ifstream ifs{"fortunes.txt"}; // streams also have an operator bool() return value, that lets us write this code in C++ : for (string line; getline(ifs, line);) cout << line << '\n'; } >output: you will be singled out for promotion good ideas will spring forth naturally from your mind in the coming week good health will be yours for a long time you will be spending time outdoors in the mountains near water you will soon take a very pleasant and successful trip you will be blessed with longevity your secret desire to completely change your life will manifest >=== -sp, minor edit
Edited last time by Chobitsu on 07/24/2024 (Wed) 17:51:46.

Report/Delete/Moderation Forms
Delete
Report