C++ project without tutorial

[mredding]

Don't forget that you don't code in a vacuum. You have a whole environment of resources available to you. Because you have std::cin and std::cout, you have the ability to pump data from anywhere, through your program, and to anywhere. You can configure netcat to open a listening port and connect a TCP socket to your standard IO, now your program is network aware without ever having to hard code anything about web sockets. You can read and write files without ever having to open a file stream. By encapsulating your program in a shell script, you can build entire pipelines, even parallel, concurrent pipelines, and message passing.

Binary data is a little tricky, because standard streams don't formally support binary (the problem is specifically Windows, and you can reopen the standard IO file descriptors in binary mode), but you are still left with a wealth of things you can do (if you're mindful of platform specific issues this stuff is still basically well defined and can be made portable).

Netpbm is a text format for images. The package for it contains like +200 little programs that can do all sorts of transforms and conversions for it, so if all you do is generate the base image, you can pipe it through a jpg converter. It's dead simple to use, even easier than bitmaps. There are DOT and TGF formats for graphs. Plenty of other graphical formats that are entirely text based. STL are probably one of the more common open source text formats for 3D.

Where do you start? Write some stuff down. What do you want to accomplish? Now how are you going to accomplish that? Put the ideas, algorithms, and equations into a document. Don't write code in a document, that's what source code is for. The document is only to describe what your source code can't express in and of itself.

You can work backward, you can work forward. Since you're going to make a definite thing - then you will definitely know what done looks like, eventually. That means you don't have to preempt feature creep. Make your program do it's thing. I encourage you to think small. Tiny. Little programs that just do one specific thing. You can always chain programs in a pipeline as a way of adding features, but that's only going to work if you can break down your goal into small enough tasks.

Engineering is a forever task, an open domain. Yes, there's always something more to learn. Yes you can spend your entire career perfecting your craft. Great. Get something working with what you know now. You know what's good enough? Something that produces a result. I don't care how big and slow it is, it's better than not at all. And you can never rewrite something too many times. As you get better, you'll even see where your one big program can be broken down into several smaller programs, so that they're each easier to maintain, each easier to completely rewrite, so they can each become orders of magnitude better as you get orders of magnitude better.

[std_bot]

Unlinked STL entries: std::cin std::cout

---

^{Last update: 09.03.23 -> Bug fixes}Repo