Is it wrong to write Unix command line tools in C++

>one function from the c standard library written 30 years ago is slower than a recently updated STL function
woah...

explain

Doesn't matter, write them in Python if you want.

>Is it wrong to write Unix command line tools in C++
No, it isn't. If you know C++, then write it in C++. Remember to use a free license.

Attached: kuroneko.jpg (1920x1080, 146K)

Why not use sed, awk and grep? Posix, portable and work.

Standard C++ can do more things in a portable fashion than standard C. For example C++ has threads in the stdlib starting from C++11 (C11 has them too, but no one supports them because they're badly specified and incompatible with pthreads).

youtu.be/tr4-sdK2vXg

typical Jow Forums conversation with your pops

Attached: Terry-Davis-Astronauts-Space-Alien-Humor-2018-05-13T17-38-18-400x270.jpg (400x270, 15K)

In my experience, it actually is. Compilers have come a long way.

What exactly would be wrong? Sure, the language itself may be bloated, but if you use it smartly, the binaries you eventually get are fast and lifhtweight, albeit slightly larger than executables compiled from C, from what I've seen.

>Is it wrong to write Unix command line tools in C++?
Yes, you should write them in Rust instead.

>Yes, you should write them in Go instead.
ftfy

Attached: gopher_monitor.png (398x460, 82K)

>command like tools
>a language with GC
Besides, you should never use Go for anything at all.

Attached: e55.png (800x800, 155K)

>I want it to be portable
>write it in rust
>meanwhile rust can't compile itself on a 32bit system

Nor can you build 32bit firefox on 32bit system, 4Gb RAM just isn't enough, how is it a problem for portability tho? You can cross-compile for 32bit systems just fine, or you can use pre-built 32-bit version of the compiler.

Does GC somehow prevent you from interacting with the command line?

>text processor for extracting and reporting data
use actual Perl if it's not super complex

text processing is where it shines

GC makes the performance hard to reason about.

>text processor for extracting and reporting data

Is this for a hobby project or a real need?

Bash can get you there 99% of the time if there's just a need to produce something. If it's a hobby project, do something that you think sounds interesting as a learning experience.

Yes. Write them in PHP.

That's because Firefox is written with a lot of rust at this point :^)

You don't need top notch real-time performance for command-line utilities. Safety and expressiveness without being a slave to the borrow checker are more important.

>doing actual coding in Bash
I'd just kys myself

the other day I tried to use 'for f in $(...)' to iterate through filenames returned by a command, all went great until there were filenames with spaces

bash is ancient and retarded

>implying Chrome is any different
But Go is neither safe (nil pointers) nor expressive(lacks generics, pattern matching, sane error handling, etc.).

i can write it for you
and string storage library
but im to lod and depressed
send me Adderal please

GCC and Clang are written in C++ anyway, so yes, every Unix system has C++. You should write tools for yourself, not for anyone else: if someone else likes what you write for yourself, that's still a success. It's even a success to write a tool you like, if it works for you.
So you should simply do what you want.

You're an idiot, is all. You're supposed to do
for WOOH in "$(prog)"
Notice those quotation marks?

Alternative, leave $(prog) unquoted, and quote WOOH as "$WOOH" later in the script. It's not hard.

If the platform is powerful enough to run Linux then writing it in C++ probably won't be a problem.

thats not how your supposed to do that.

Libraries

no, that doesn't work, neither works

"$(prog)" just gives you one big string glued together and "$WOOH" changes nothing, since it breaks at every space earlier

bump

It's wrong to write in C++, period.

> Hurr durr write the coreutils in bash
The literal state of this thread

use python