[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


Why are C++ boomers like this? Can they get anything right?
>>
>>106956287
I have never used <ranges> and I don't plan to. What is wrong with the code?
>>
>>106956287
Holy shit, C++ and Rust are the same language.
>>
>>106956287
List processing without using lisp or scheme. LOL, get educated.
>>
The sad thing is I don't even know what's wrong with the C++ one, but I'm also not surprised. Most new C++ features are pure garbage that are unusable. I don't know why people seethe about Rust so much. It basically just works, even if it lacks some minor meme features that C++ has that maybe let you get a few hundred nanoseconds or some shit in performance.
>>
Amazon Web Services:
>switches to Rust
>outages
>>
and i thought rust looked terrible. wow
>>
>niggas ignoring the C++ code segfaults
I'm not the only one who noticed, right?
>>
>>106956287
also keep in mind the rust program is only 12 lines of code while the c++ program is 13
>>
File: image.png (78 KB, 1112x328)
78 KB
78 KB PNG
>>106956287
Skill issue.
>>
>>106956545
So why is to_rvalue causing memory unsafely? It's being moved into the new array right? wtf is going on?
>>
>>106956545
C++ in white hands always looks good. The problem isn't so much the language (although it is rough) but the current crop of programmers.
>>
>>106956682
So are you brown? Why is no one explaining this shit? The rust shit makes perfect sense and it works. What the FUCK is the C++ shit doing?
https://en.cppreference.com/w/cpp/ranges/as_rvalue_view.html

The examples don't help either.
>>
>>106956287
Any C++ programmer who writes code that looks anything like that deserves death anyway.
>>
>>106956750
That's what modern C++ looks like
>>
>>106956663
Strings own memory, so don't cast them to rvalues unless you want memory to be pilfered when objects are constructed/assigned from it. C++ ranges avoid copying as is, so you're messing with the lifetimes of non-owning references and getting surprised when it blows up on you.
In this case, why convert to a vector at all? You can just use std::views::filter(large) | std::views::reverse.
>>106956740
Learn what an rvalue is, xister.
>>
>>106956740
The segmentation fault occurs because std::views::as_rvalue causes the program to move strings from the original cities vector while the filter view is still iterating over it. As each string is moved, its internal state is altered (e.g., its size becomes zero), which violates the assumptions of the filter view that is trying to find the next element based on the original string sizes. This leads to invalid iterator behavior and an attempt to access invalid memory, causing the crash.
>>
>>106956939
>you can create iterator invalidation with this "new" ranges feature
Tell me again why C++ isn't a meme?
>>
>>106956939
But moving strings doesn't invalidate iterators of the original vector.
>>
>>106956956
as_rvalue, combined with the final conversion to a new vector, moves the content out of the strings in the original cities vector while the filter view is still conceptually iterating over it. Because the filter predicate depends on the string's size, moving a string changes its size to zero, which corrupts the logic of the filter's ongoing search for the next matching element and leads to undefined behavior.
>>
File: 2025-10-13 064137.png (12 KB, 498x224)
12 KB
12 KB PNG
>>106956287
1. C++ shit
2. use python
>>
File: wtf.png (88 KB, 1157x740)
88 KB
88 KB PNG
>>106956287
so i'm a nocoder, here's my coomtribution
>>
>>106956983
This explanation makes no sense. First, filter must process element before it is passed to the next layer, so moving it shouldn't affect the logic at all. And even if it does, the size will be zero, so the output might be wrong, but it should not cause segfault. And iterators should not be invalidated anywhere in this code.
>>
>>106956807
no one sane writes modern C++
>>
>>106957009
the fact that you're even engaging in this conversation is just proof this functional style retardation is extremely niggerlicious and you should just write it out the normal way
>>
>>106957046
Never used ranges and never cared about them. But I feel like this is a bug in the implementation. Not surprising, given that nobody uses ranges...
>>
>>106957046
Or maybe Rust heems C++ so badly all you have left is a mockery of what you wish you could be. It's literally a fucking strawman feature, "um we couldn't do it right so obviously no one can." So people go back to writing ass like >>106957008
>>
>>106957081
>i just like, cast things to rvalues for no reason
>idk like, i saw it one time in some other context
>OMFG IT SEGFAULTED I NEED TO CUT MY COCK OFF NOW REEEEEEEEEEEEEEEEEEEE
so rustrannies really are like this...
>>
>>106957081
C++ is a mess for sure, but all of this shit is full retard. god forbid people write things in the most simple and sane way that makes flow control as obvious as possible
>>
>>106956287
considering they're the same ones who supported having a prez that is now indulging in his scat fetish via ai videos?
no. no they cannot.
>>
>>106957117
How is the Rust example hard to read? The rust example extends to all monadic types as well, like Result and Option, etc.
>>
>>106957128
>scat fetish
Very hinduphobic sir. He was merely unloading his bowels on the designated shitting street.
>>
>>106957188
Scat fetish.
>>
>>106956287
That C++ main function is UB. Fix the return value before any further analysis.
>>
>>106956287
std::for_each(std::rbegin(cities), std::rend(cities), [](auto const& c) { if (c.size() > 5) printf("%s\n", c.data()); }); fuck off
>>
>>106957173
sarrr().please().do_the_needful() will always be more difficult to read, understand what is actually happening and predict what the compiler is going to output than just doing a fucking for loop like a normal person
>>
>>106957204
Gcc injects return 0 automatically
>>
>>106956287
Still on C++17, so I'd probs go for something like
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>

int main() {
std::vector<std::string> cities{"Amsterdam", "Berlin", "Cologne", "LA"}, sub;
std::copy_if(cities.rbegin(), cities.rend(), std::back_inserter(sub),
[](const std::string &s) { return s.length() > 5; } );

for(const auto &s : sub) { std::cout << s << '\n'; }
}
>>
>>106956287
This shit is more unreadable than APL
>>
>>106956287
Usecase for having to learn some random trannies personal FSH to get a simple program written?
>>
>>106956413
Not really. Rust iterators are lazy. They don't do anything until you call a function that uses them or you loop through them.

That means instead of collecting a reversed list into a vector or doing doing in place operations before passing the data, you can just pass an reverse iterato. It's super cheap and it's a 4-8 byte copy.

Rust is lazy, which is why it's fast. It does nothing until you actually need to use the data.
>>
>>106956287
ranges are awful. but this can be fixed by putting reverse first.
why? i dont know.
>>
it doesn't need to be complicated

#import <stdio.h>
#import <string.h>

int main() {
char* cities[] = {"Amsterdam", "Berlin", "Cologne", "LA", ""};

for (int i=0; cities[i][0]; i++) {
if (strlen(cities[i]) > 5)
printf("%s\n", cities[i]);
}
}
>>
File: file.png (91 KB, 856x346)
91 KB
91 KB PNG
>>106956287
I like how nobody noticed this
>>
godbolt threads on /g/ are the equivalent of console wars or steam charts threads on /v/
nothing good will ever come out of them
>>
>>106958833
>O(N) strlen
Actual clown
>>
const std = @import("std");

pub fn main() void {
const cities = D: {
comptime var cities: []const []const u8 = &.{};
inline for (&.{"Amsterdam", "Berlin", "Cologne", "LA"}) |city| {
if (city.len > 5) cities = cities ++ .{city};
}
break :D cities;
};
for (cities) |city| std.log.info("{s}", .{city});
}

Just filter the cities out compile time
>>
>>106956413
Pretty much. The only thing rust gets credit for is that it's initialization doesn't require 10 years of study to understand. But otherwise they are both kitchen sink languages.

c++26 will look even more increasingly rust:
https://brevzin.github.io/c++/2024/09/30/annotations/
https://brevzin.github.io/c++/2025/05/02/soa/
>>
>>106956287
>as_rvalue
play stupid games nigger
>>
That's not how let works, that's a chinese ripoff let

Also rust is slow as molasses, I gave a rust program a try and it took half a minute or something to load whereas the C equivalent loaded almost instantly

They say rust is almost as fast as C but that's nonsense
>>
>>106956954
cope harder you retarded ass brainlet
>>
>>106956287
>auto main() -> int
wtf is this? you let the compiler deduce the return type but you also hint it's int? i hate modern c++ so much it's unreal
>>
>>106956287
Why the fuck did you include as_rvalue? Your Rust version has no equivalent. You are deviating in C++ with an unnecessary move that is asinine and retarded, and then trying to make it seem as through it's the languages fault that you fucking stupid. Delete this thread, faggot.
>>
>>106959134
It's not a hint you fucking retard. It's a universal syntax and it even solves longstanding issues that plagued C++ going back to C called the most vexing parse. Pretend "auto main() -> int" is "fn main() -> int" because it means the same fucking thing you god damn drama queen.
>>
>>106956287
Why are c++ and Java boomers always using light mode? Do they know something we don’t know?
>>
>>106959164
why not just... int main()? op doesn't even return shit
>>
>>106956287
No C++ boomer writes a cpp code like you did. Your pic showcases how zoomernoobs do it.
>>
import sequtils
let cities = ["Amsterdam", "Berlin", "Cologne", "LA"]
let sub = cities.filter(proc (s: string): bool = s.len > 5)

for s in sub:
echo s


With some added sugar it becomes
import sequtils
import sugar
let cities = ["Amsterdam", "Berlin", "Cologne", "LA"]
let sub = cities.filter( (s: string) => s.len > 5)

for s in sub:
echo s
>>
>>106959178
you parse text better on light backgrounds.
why do you think physical books have them?
>>
>>106959393
you can use `filterIt` to avoid having to manually define your inner proc.
https://nim-lang.org/docs/sequtils.html#filterIt.t%2Cuntyped%2Cuntyped
import sequtils
import sugar
let cities = ["Amsterdam", "Berlin", "Cologne", "LA"]
let sub = cities.filterIt( it.len > 5)

for s in sub:
echo s
>>
File: cpp.png (37 KB, 968x420)
37 KB
37 KB PNG
>>106956287
I dunno OP. it works on my machine when I don't try to deliberately break it.
>>
>>106959432
Nice, Also saves the sugar import.
import sequtils
let cities = ["Amsterdam", "Berlin", "Cologne", "LA"]
let sub = cities.filterIt( it.len > 5)

for s in sub:
echo s


The only downside I see is that when you change cities to an array of something else with a .len, like a nested array, it still compiles.
>>
>>106956287
in Clojure this is just
>>
>>106956939
C++ is a fucking meme lmao.
>>
>daily "retards filtered by C++" thread
>>
>>106956925
>>106956939
So basically, OP did some pointless niggerlicious garbage in a language he didn't understand, and got burned for it. I fail to see how this is C++'s problem.
>>
>>106959395
It's cheaper
>>
File: 1739732249058397.png (643 KB, 756x684)
643 KB
643 KB PNG
>>106959395
huh?
>>
I swear 99% of C++ jeets don't know what basic principles such as memory ownership or scopes mean.
>>
>>106956287
>taking sepples seriously in 2025
>>
>>106957952
Sepples fags will tell you this is a high level language.
>>
>>106958983
It's replaced by sizeof - 1 for compile-time constant strings.
>>
>>106960127
it literally is, according to every single conceivable definition of the term.
>>
>>106959164
C never had the most vexing parse, it's 100% Sepples-exclusive insanity.
>>
>>106959279
Because there are a few cases that require trailing return type, and it's better to use the same syntax everywhere. So you should just use trailing return type.
>>
>>106960141
>literally creates problems that don't exist at lower levels
I'll stick to low level code then.
>>
>>106957081
Oeople who don't know what an rvalue is won't be converting to rvalue for no reason.
>>
File: maxresdefault.jpg (43 KB, 1280x720)
43 KB
43 KB JPG
>>106958833
Wait! So this is ALL that the code in OP is trying to doing? For real?
Why so much complexity, then? Why are modern languages re-inventing the wheel, for the worst?
>>
>>106960203
Why do you hate the economy?
>>
Sirs

package org.example;

import java.util.ArrayList;
import java.util.List;

public class Main {

private static final CitiesPrinter citiesPrinter = new CitiesPrinter();

public static void main(String[] args) {
List<City> citiesList = new ArrayList<>();
citiesList.add(new City("Berlin"));
citiesList.add(new City("Amsterdam"));
citiesList.add(new City("Cologne"));
citiesList.add(new City("LA"));

citiesPrinter.printCities(citiesList);
}
}
package org.example;

import java.util.List;

public class CitiesPrinter {
public void printCities(List<City> citiesList) {
for(City city: citiesList) {
if(city.isAtLeastFiveLettersLong()) {
System.out.println(city.getCityName());
}
}
}
}

package org.example;

public class City{
private String name;

public City(String name) {
this.name = name;
}

public String getCityName() {
return name;
}

public void setCityName(String name) {
this.name = name;
}

public boolean isAtLeastFiveLettersLong() {
return name.length() >= 5;
}
}
>>
>>106960203
OP's code is also putting it in a new vector, in reverse order.
>>
>>106960235
Where's your AbstractFactoryFactory? You're fired.
>>
>>106957008
that looks fine to me.
very readable.
>>
>>106960239

How about classic C++ ??

 
#include <iostream>
#include <string>
#include <vector>
#include <algorithm>

using std::cout;
using std::endl;
using std::string;
using std::vector;

int main(){

vector<string> cities = {"Amsterdam", "Berlin", "Cologne", "LA"};
vector<string> cities_out;

for (size_t i = 0; i < cities.size(); i++){
string city = cities[i];

if (city.size() > 5){
cout << city << endl;
std::reverse(city.begin(), city.end());
//cout << city << endl;
cities_out.push_back(city);
}
}

return 0;
}
>>
>>106959395
> why do you think physical books have them?
Because ink consumption will increase by several orders of magnitude, stupid jeetger
>>
>>106960239
>>106960443

my bad:

#include <iostream>
#include <string>
#include <vector>

using std::cout;
using std::endl;
using std::string;
using std::vector;

int main(){

vector<string> cities = {"Amsterdam", "Berlin", "Cologne", "LA"};
vector<string> cities_in_rev;

for (size_t i = 0; i < cities.size(); i++){
string city = cities[i];

if (city.size() > 5){
cout << city << endl;
cities_in_rev.insert(cities_in_rev.begin(), city);
}
}

return 0;
}
>>
>>106960466
>you have to use black ink to make black paper
>>
File: 1759863262066.png (63 KB, 1144x356)
63 KB
63 KB PNG
>>106956287
>I can't code and I hekin love Pust!
why are Pust shills like this?
>>
File: Gigacones.gif (2.02 MB, 400x355)
2.02 MB
2.02 MB GIF
you have to use black ink to make black paper
>>
>>106957952
Probably more-efficient as well. You should probably use a const container + const iterators for your source container for better compiler optimizations. Obviously trivial in this example, but can make a big difference in realworld code. Cheers.
>>
>>106960527
All technologies and production chains are built around the production of white paper, even printing white on black will cost you ten times more, which is not commercially viable, nigger
>>
>>106958449
Ah yes, lazy evaluation. The idiot's choice.
>>
>>106958983
Are you telling me the s.len() or s.size() is any different?
>>106960203
In one interview Bjarne admitted one of the reasons of making C++ was to keep programming elitist by making it overly complicated. Ironic since a common criticism of rust is that it's overly complicated.
Quite the niggerlicious twist of irony.
>>
>>106956287
I use c++ as in a better c, not for the c++ pajeetware you present here. look at this code, fucking retarded, just use a for loop
>>
>>106958983
worse, it doesn't even create a new list with the results, also doesn't reverse either, kek.
>>
>>106960749
>Are you telling me the s.len() or s.size() is any different?
yes? do you know how C even works retard?
There is a reason everyone does Pascal Strings circa, 1980.
>>
>>106959134
this is the practice recommended by Herb himself and has been in the language since C++11.
the biggest plus with it is it avoids having to specify the qualified path twice, one for the function decl and the return decl.
>>
>>106960152
I see. Never used it myself, I'm still stuck in the C++14 timeline. Any good resources on the new stuff, besides the official docs/drafts?
>>
>>106956954
>use the language wrong
>waaaaaaaaagh why is the language not working
>>
>>106960859
how is it being used wrong? actually show a detailed analysis or a plausible, testable in gdb, hypothesis. The Rust compiler will tell you if you're doing something wrong, so it isn't even possible to fuck this up there, no matter where the reverse filtering occurs in this range/iterator/whatever you want to call it.

you can't, because you're just another incompetent DEI Jeet who seethes about Rust superiority and can't accept that you might not know a whole lot.
>>
>>106960203
C++/rust are academia / commitee driven design, the sort of slow this creates is "having a cute idea and forcing it into everything".

For maximum productivity I recommend just sticking with a chosen subset C++, make the code look like C for the most part. That is assuming you need a systems programming language, typescript java are all fine options also.
>>
>>106960885
>I recommend just sticking with a chosen subset C++, make the code look like C for the most part.
Objectively worse than just using C.
>>
>>106960613
That's cost, not ink consumption.
Different metrics.
>>
>no warnings either
kwab the language

~/.l/tmp> g++ -std=c++23 -Wall -Wpedantic -Wextra x.cpp
~/.l/tmp> ./a.out
fish: Job 1, './a.out' terminated by signal SIGSEGV (Address boundary error)
>>
>>106961009
forgot to mention, it took a gorillion years to even compile.
>>
>>106956287
So many "std"s.
>>
>>106956435
Rust is way better than c++ unless you have to work with raw pointers.
>>
C++ version doesn't look so bad, but it could be formatted better with some line breaks. It's basically shell syntax.
>>
>>106960809
Press X to doubt. As if my compiler can't figure out I'm running a standard function on a constant string.
>>106960239
>>106960489
it still doesn't need to be complicated.
#import <stdio.h>
#import <string.h>

int main() {
char* cities[] = {"Amsterdam", "Berlin", "Cologne", "LA"};

for (int i=sizeof(cities)/sizeof(cities[0]); i; --i) {
if (strlen(cities[i-1]) > 5)
printf("%s\n", cities[i-1]);
}
}

This thread made me realize modern language developers are the nuancebros of the programming world.
>if things were different they would, indeed, be different
>if our usecase was different our implementation should, indeed, include a solution for it
>>106960885
>For maximum productivity I recommend just sticking with a chosen subset C++, make the code look like C for the most part.
This. Take the good parts of C++ so you don't come off as an absolute autist, but also don't get lost in the sauce.
>>
>>106961091
>sizeof(cities)/sizeof(cities[0])
>i as loop condition
>indexes with i-1
>is too retarded to realize why no one cares about his compiler optimizations for the baby shit easy const char* literal case
>still doesn't build an intermediate vector of the results of his smelly shit code

Cniles are literally the dumbest niggers on /g/
>>
>>106961083
it honestly isn't the worse and it adds the flexibility that Rust's iterator traits offer without a lot nested function call cancer you'd see with the old <algorithms> approaches to the samish problems.
the problem is, it segfaults because it's hard to use correctly.
>>
>>106960749
>In one interview Bjarne admitted one of the reasons of making C++ was to keep programming elitist by making it overly complicated
Rustroon, pls. My guess is you weren't even aware that was a parody. Bjarne even addressed that specific caricature during an interview.
>>
>>106960836
It also has a general, 'unifying the syntax' benefit (similar to auto).
>>
>>106960839
Tour++.
>>
>>106961230
I agree. I use auto literally everywhere because it's more readable anyway.
>>
>>106961236
auto keyword (the new one, ofc) was a real godsend for complex types -- typically iterators of specified containers. And of course for unnamable types (basically, lambda results) it's essential.

I've found that it occasionally also benefits code maintenance in downstream code if I need to change some type upstream.
>>
>>106961091
Guess you could do something like this:
#import <stdio.h>
#import <string.h>

int main() {

char* cities[] = {"Amsterdam", "Berlin", "Cologne", "LA"};
char* cities_in_rev[sizeof(cities)] = {0};
int size_of_rev = 0;

for (int i=sizeof(cities)/sizeof(cities[0]); i; --i) {
if (strlen(cities[i-1]) > 5){
printf("%s\n", cities[i-1]);
cities_in_rev[size_of_rev++] = cities[i-1];
}
}
}

This potentially allocates a lot of unnecessary stack memory, of course.
>>
>>106961700
char* cities_in_rev[ sizeof(cities)/sizeof(cities[0]) ] = {0};
>>
>>106956807
if you remove the "std::" and the shitty "::" syntax it would've been more readable by a long shot
a quick glance to C++ code is always a fucking headache, you always need few seconds to readjust to the extra garbage
what a fucking waste of resources
>>
>>106957008
why can't you iterate in reverse order in the first place and avoid the sorting? for loop doesn't have reverse mode?
>>
>>106961032
one can say the language is ridden with stds
>>
>>106961966
Functional programming was a mistake.
>>
>>106961929
With big codebases, it becomes irrelevant background, and explicitly specifying the namespace is very valuable during maintenance.

That said, it's traditional form to use shortened names within the scope of function bodies. Thus >>106957952 becomes:

#include <algorithm>
#include <iostream>
#include <string>
#include <vector>

using std::back_inserter;
using std::copy_if;
using std::cout;
using std::string;
using std::vector;

int main()
{
vector<string> const cities{"Amsterdam", "Berlin", "Cologne", "LA"};
vector<string> sub;
copy_if(cities.crbegin(), cities.crend(), back_inserter(sub),
[](auto const& s) { return s.length() > 5; });

for (auto const& s : sub)
cout << s << '\n';
}


With such a short function body, it hardly matters. But for complex function a screen or two in size, such tweaks improve readability significantly.
>>
>>106961182
Larping nocoder award
>>106961700
I don't get why we have to rebuild cities when it's processed the same way.
This is why I'll never get a job in tech. I don't need a liberal college student or H1B visa breathing down my neck to make an inferior product to justify their interests.
>>
>>106962329
>I don't get why we have to rebuild cities when it's processed the same way.
You don't. Particularly with ranges, you can simply compose the original in the chain for the output you want, with no intermediaries. OTOH, it's a traditional form to follow the source->target containers, and much easier to reason about in complex situations -- if less-efficient memory-wise.
>>
>>106962390
>if less-efficient memory-wise.
That said, such a source->target containers scheme generally executes faster, vs. a bunch of pointer-chasing necessary to do things the """efficient""" way.
>>
>>106962213
>copy_if
>>
>>106962572
Yes? It exactly matches the algorithm needs to solve the problem, and does so concisely in this case.

https://en.cppreference.com/w/cpp/algorithm/copy.html
>>
File: 1572816054901.jpg (16 KB, 400x400)
16 KB
16 KB JPG
>>106956287
>.iter()
>.rev()
>.len()
>>
>>106962390
>>106962533
I'm not too concerned about memory usage desu. It's kind of hard to use an insane amount of memory when working with plain C. I'll just use whatever method works best for what I'm trying to do.
Is it a list of names to be filtered by roles? A multidimentional array will do.
Is it a file listing that needs to be sorted by name, size or date? Let's build an array of pointers for each case.
>>
File: chad.png (130 KB, 1275x1275)
130 KB
130 KB PNG
>>106962637
>len(rev(iter(x)))
>>
File: moar.png (121 KB, 1162x990)
121 KB
121 KB PNG
>>106961966
aye, afaik for with auto doesn't have the reverse mode
>>106960256
this problem does not need fp imo, it's just too basic
it isnt a tree walker, isnt recursion, isnt math and isnt lambda calculus, it also isnt expressed better by a bunch of pipelined transformations
t. same anon
>>
>>106956287
Just use Python if you're making worthless meme scripts
>>
>>106962884
also i think i got filtered by a normal for loop, the condition seems iffy
>>
>>106962962
>>106962884
and also i think there's an issue with dynamic allocation by 1 unit of memory in a loop. i've heard it's costly. so small container copies get allocated the full size of their parent container, and then get resized to actually required capacity. iirc
>>
>>106960555
/thread
>>
>>106962213
Jesus Christ.
>>
>>106960555
checked
anyway, now i want to write more stuff like this. how do i get started anons?
>>
>>106958983
oh no, an O(n) for a simple as hell function where N doesnt realistically grow larger than 10 (unless you are interested in Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch, for whatever reason), it's the end of the world, let's hope our City Name Parsing as a Service (aka CNPaaS) doesnt go down because of this
>>
>>106959178
yeah, light mode is superior :)
>>
>>106962667
>Chad keeps an eye on Niger
>>
>>106964408
Why do people get so hung up over O(xyz) when a single cache miss can make your perfect algo slower than the most dump step by step approach?
>>
>>106964672
I can see it being a useful metric sometimes, but treating it as something sacred is idiotic, as it is not a measure of speed but a measure of time growth
>>
>>106961009
C++ in a not a safe language
>>
>>106956287
what programming to learn for embedded stuff but also allow me to extended beyond just piece of code?
C? Rust? Zig? Go?
I don't like C++ I used it years ago, python is shit, I like rust that you can also make front ends but open to suggestions
>>
>>106967246
Zig's looking pretty good. Rust is also strong due to having stackless coroutines, but everything else about rust kinda sucks.
>>
>>106962894
With such a meme example as OP's, thats fair enough. At an industrial scale, C++ is the White man's choice.

>>106963553
Is Lord of all?
>>
>>106968304
The r*st community is the worst thing about the language. The obtuse syntax is a follow-on second worst thing.
>>
>>106967246
>for embedded stuff
No matter what hardware you're working on a C compiler is always available.
>>
>>106964074
Like what? Useless code by a dumb OP?
LeetCode is a better waste of time.
>>
>>106967246
C is universal.
People complain because people want to just have to import the solution.
>>
>>106968304
thanks
>>106968716
I like C but it's limited beyond having a c code, you will always have to learn another lang to build a platform.
For example, a couple years ago I built a platform to do stuff with drones, but the code was cluster fuck, the embedded stuff in C++, and had to compile it as a binary blob called by the server side code I did in nodejs, I also had some golang/python for some payload, plus all the front end work. So I am trying to have one lang or max to to rebuild the whole thing again. so I don't mind converting C++ to rust and make the whole codebase rust.
like I converted this code >>106962213 to rust using AI and gave me this
 use std::collections::HashSet;

fn main() {
let cities = vec!["Amsterdam", "Berlin", "Cologne", "LA"];
let mut sub: Vec<&str> = Vec::new();

sub.extend(cities.iter().filter(|&&city| city.len() > 5));

for city in sub {
println!("{}", city);
}
}
and it did compile and worked great, if I can convert what I did before and it does 80% of the job and manually do the rest I will be happy
>>
>>106956287
There is an intersection between C and C++ where everything is right, but it's a painful and difficult.

Then moving in between assembly does provide additional benefits.
>>
>>106956287
Your watered down language is nowhere near where it needs to be to be useful. You need to escape the programming paradigm you are locked into. Return to notepad and compiler, that way you can keep, organize and review your own code.

Next you need to stop jumping between languages.
>>
>>106956287
Some C++ designs are terrible, the vector is just terrible. It's not good for anything, using basic datatypes is better, there is better complex designs.

The practicality of the vector is that it is just there and it can get around the limited datasize of arrays as the type is dynamic. So you may use it simply to get around that issue.

It is however only useful as a beginner datatype to simplify things.
>>
The thing is about starting off with the vector, is that you will grow accustomed to use the vector datatype, this may shunt your ability to design more complex systems in the future as the vector is just comfortable, easy but not scalable.
>>
>>106956287
how does that look like in a modern langauge like Beef or zig?
>>
>>106956287
Just add using namespace std::views and std::ranges, then the code is very similar:
std::vector<std::string> cities{"Amsterdam", "Berlin", "Cologne", "LA"};
auto sub = cities
| filter([](const auto& s){ return s.size() > 5; })
| reverse
| to<std::vector>();
>>
>>106961700
"Allocating" more than required stack memory is far more efficient than allocating a vector so its still better
>>
>>106970501
zig doesn't have functional programming concepts in the standard library nor in the language
>>
>>106964408
these are the retards that made GTA V loading screens longer than necessary. take notes everyone. Cniles are so unhinged.
>>
>>106970501
>>106972119
This is how it would look like in zig. Its regular procedural code similar to C.
>>
>>106956287
Having coded in pyhton as well. C++ is the best language, you actually declare what your integers or floats are, visible on the code
>>
>>106968921
What exactly is wrong with std::vector?
>>
>>106972235
it's clearly too simple for him.
only thing immediately obviously bad is vector<bool>, but we don't talk about vector<bool>
>>
>>106956287
>no c++ experience

so you have to import standard lib vector and import standard string for usage in variable citites which is a vector, wtf is a vector?
wtf is auto???
so array large.. wtf is this const auto& s, but only return if string size is larger than 5?

phew okay lets continue
another auto shit, cities, but now you start piping shit?
so pipe standard::views, wtf is standard view used for?`so you somehow filter city names that size is larger than 5, then you pipe a reverse? and then as_rvalue?

wtf is r_value?
and now its pipe into range to empty standard vector

i will not even try to understand wtf the last for loop does.
>>
>>106970501
no idea if this is good odin or not https://godbolt.org/z/7Yb6McY31
package main
import "core:slice"
import "core:fmt"

example :: proc(arr: []string ) -> []string {
res := slice.filter(arr[:], proc(i : string ) -> bool { return len(i) > 5;})
slice.reverse(res[:])
return res
}

main :: proc() {

cities := []string{ "amsterdam", "berlin", "tokyo"}
res := example(cities)
fmt.println(res)
}
>>
>>106972235
Won't use realloc. Even a 10-line DIY implementation is more efficient.
>>
>>106972552
That will only work for POD types though, won't it? No improvement is possible here for non-POD types.
>>
>>106956925
Learn what an xvalue is, ruster.
>>
>>106972187
you're braindead, who let you out of the special ed class? your handlers will get angry if they see you on this basket weaving forum
>>
>>106974679
eat a fucking bullet, you cnile piece of shit.
https://news.ycombinator.com/item?id=26296339
>>
>>106972552
No allocator ever implements realloc. They always implement realloc in terms of malloc, memcpy, and free. How exactly does this help with when a vector class can do the exact same thing? It doesn't. Now explain how you expect any type paradigm to cope with dynamic addressing whereby non-trivial objects can be secretly moved via some dumb cunt c allocator that doesn't even know what an object is.

You're actually retarded, much like the rest of this thread. At least when retarded children used to brag about "knowing cpp" and shit 5, 10, 15, 20 years ago, they'd get roasted for it. You and everyone around you are so shelted they cannot validate how much of an utter spastic you and your "10-line DIY implementation" are without getting banned by some pedophile jew janny. You're pathetic and should consider hanging yourself.
>>
>>106958954
A lot of stupid discussion on /g/ about performance and language differences could be resolved simply by looking at the assembly output.
>>
>>106975012
>They always implement realloc in terms of malloc, memcpy, and free. How exactly does this help with when a vector class can do the exact same thing? It doesn't. Now explain how you expect any type paradigm to cope with dynamic addressing whereby non-trivial objects can be secretly moved via some dumb cunt c allocator that doesn't even know what an object is.
nta
and i never done that so i might be talking out of my ass
BUUUUT
doesnt mmap allow you to choose the virtual addresses you get?
that way you dont even need to copy upon resizing
>>
File: same-same.jpg (22 KB, 321x300)
22 KB
22 KB JPG
>>106975012
>>106975114
chud gpt says it can be done

imagine if you memelang-lets get your way and this know how disappears?
that would actually be pretty based now that i gave it a fink, any semi competent C-ultists will then be worth an upper 6digit salary
>>
>>106972654
Correct, but in practice std::vector is used with POD types 99% of the time. A template specialization could have done it, considering the mess they did do with the bool specialization.

>>106975012
Peak Dunning-Kruger. Please keep posting, never write code and never actually learn anything.
>>
>>106975234
>A template specialization could have done it, considering the mess they did do with the bool specialization.
Can you make a specialization for POD in general? Or only for a few particular cases?

>Correct, but in practice std::vector is used with POD types 99% of the time.
I don't think that is true at all. It may be true in particular applications, but across the broader C++ codebase I would be surprised if it was more than 50%. Vectors containing structs that contain strings, smart pointers, or further containers are all very common.
>>
>>106975067
I have a boomer at work that keeps spouting retarded shit about "muh performance" and never even learned to read a single assembly instruction in any ISA.

>inb4 le zoomer who cares about that shit
Assembly (or for pedantic fags, its binary representation) is what the CPU ultimately accually executes.

No matter how fancy your language and compiler are, if the generated assembly is shit, performance will be shit. Which is why, if you *actually* care about performance, it is important to inspect the generated code.

If you don't really care that much about performance, you're wasting your time with Sepples or Rust. Use simpler language and get something done.
>>
How do C++ programmers even read this shit?
They claim Rust generic code is unreadable, but if I want to look what eg Iterator::copied() does I look at iterator: https://doc.rust-lang.org/std/iter/trait.Iterator.html
fn copied<'a, T>(self) -> Copied<Self> 
where
T: Copy + 'a,
Self: Sized + Iterator<Item = &'a T>,

and it's pretty clear this function exists on an iterator of references for any type that can be copied. I can click at Copied to check what I get and see:
impl<'a, I, T> Iterator for Copied<I>
where
T: 'a + Copy,
I: Iterator<Item = &'a T>
{
type Item = T

And I learn that this method takes an iterator of references to T and returns iterator over Ts, presumably by copying them.
But with C++, you always /* unspecified */ fucking /* see below */ until /* undefined behaviour */
>>
decided to start learning c++. I nearly got filtered just trying to get shit to compile on vs code. Jesus christ.
>>
>>106975310
>Can you make a specialization for POD in general? Or only for a few particular cases?
You MIGHT be able to do it with some TMP fuckery in later Sepples revisions (see std::is_pod), but admittedly I haven't tried myself.
>>
>>106956287
That's great go rewrite another library in your toy language.
>>
>>106975333
c programmer here
sepples is as unreadable as rust is to me
sepplets have no leg to stand on when readability is concerned

and by unreadable i dont mean i cant read it, but its tough to read compared to c
think: how hard is it to read when youre at your 14th hour of the day and the only things that keep you alive are adrenaline from a coming deadline, and caffeine
>>
>>106972552
>Won't use realloc. Even a 10-line DIY implementation is more efficient.
Except it's not because under the tight, non-deterministic circumstances in which reallocation in-place is even viable doesn't make up for the fact that your piece of shit 10-line implementation is going to make no use of constexpr meaning terrible inlining and absolutely no SBO or constant folding. Nice handrolled turd you fucking moron.
>>
>>106975345
most of that is because microsoft's toolchain is absolutely fucking terrible and designed to be exclusively used through Visual Studio proper.
>>
>>106975389
I do not have problem with syntax per se, I don't care about such superficial things.
What I have problem with are all these hand-wavy /* whatever */ blanks in documentation that require reading text to figure out what are they trying to accomplish.
Rust has everything specified formally. I can see the concrete types, arguments, generic bounds, etc. Even if a function doesn't specify a concrete return type, it will be declared as
fn name() -> impl Trait + Trait + Trait
which still precisely defines which (exclusively) kind of operations will be supported by the returned, instead of just being "whatever, figure it out yourself and pray the compiler will reject your code if you assume something wrong". Which is exactly what happened in OP code. I honestly doubt you can figure out what went wrong solely by looking at function definitions, without reading all the small print on each page.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.