Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Fuck Standard C++ Containers

Name: Anonymous 2012-05-23 0:49

Do it the old fashioned way, less bloat, easier to understand.

http://codepad.org/ZVqiyIfV

Name: Anonymous 2012-05-23 1:03

Also, Linux does it the same way. If it's good enough for Linux, it's good enough for me!

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/list.h

Name: Anonymous 2012-05-23 2:42

It's also less flexible for arbitrary data types, not easily composed and generates insane code.

Name: Cudder !MhMRSATORI!FBeUS42x4uM+kgp 2012-05-23 3:13

>>3
Have you looked at the full std::list before? It's no better.
http://www.cs.auckland.ac.nz/references/c/libstdcpp-api/a01472_source.html
http://dlib.stou.ac.th/gsdl/packages/windows/stlport/stlport/stl_list.h
http://www.sadeven.net/sistemas/Visual%20Studio/vc98/include/list

(Google generates a lot of irrelevant results if I search for "std::list" including the quotes. They really need to fix that.)

Name: Anonymous 2012-05-23 3:18

>>3
It's also less flexible for arbitrary data types, not easily composed and generates insane code.
There's these things called inheritance and lambda expressions in C++11. It's better than shitting your binaries up with bloated abstractions and shitty object-models.


struct log_sink : list_node_t
{
    log_handler handler;
    unsigned int min_level;
    unsigned int max_level;
    char category[196];
           
    log_sink(char const* n, log_handler h, unsigned int min, unsigned int max)
    : handler(h),
    min_level(min),
    max_level(max) {
        ::up::list_init(this);
        strncpy(category, n, sizeof(category) - 1);
        category[sizeof(category) - 1] = '\0';
    }
};

// ...

::up::list_foreach<log_sink>(&context->sinks_sentinel, [&](log_sink* sink) {
    if ( (sink->category[0] == '\0' || !strcmp(sink->category, record.category))
        && (sink->min_level <= record.level) && (record.level <= sink->max_level)
    ) {
        sink->handler(&record);
    }
});
     
::up::list_clear<log_sink>(&sinks_sentinel, [](log_sink* sink) { ::up::destroy_free(sink); });

Name: Anonymous 2012-05-23 3:30

>>5
ur gay

Name: Anonymous 2012-05-23 3:30

From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:

When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:

 - infinite amounts of pain when they don't work (and anybody who tells me
   that STL and especially Boost are stable and portable is just so full
   of BS that it's not even funny)

 - inefficient abstracted programming models where two years down the road
   you notice that some abstraction wasn't very efficient, but now all
   your code depends on all the nice object models around it, and you
   cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.

If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

            Linus

Name: Anonymous 2012-05-23 3:34

>>6
Why? Because I made the decision to use C++ as an improved C with the lambda expressions, function overloading, default arguments, namespaces, and template functions/classes for where it makes sense? Most of the Standard C++ library is pure fucking junk compared to the Standard C and POSIX libraries.

Name: Anonymous 2012-05-23 3:54

>>7
Too bad Linus is a ranting idiot. The Linux kernel isn't even that great.

Name: Anonymous 2012-05-23 3:56

The forced inlining of code. Thread over.

Name: Anonymous 2012-05-23 3:58

>>8
C's standard library is fucking tiny dude

Name: Anonymous 2012-05-23 4:29

bampu pantsu

Name: Anonymous 2012-05-23 4:38

bampu pantsu

Name: Anonymous 2012-05-23 4:47

bampu pantsu

Name: Anonymous 2012-05-23 4:52

>>11
Exactly. That's why it's awesome.

Name: Anonymous 2012-05-23 4:57

bampu pantsu

Name: Anonymous 2012-05-23 5:06

bampu pantsu

Name: Cudder !MhMRSATORI!FBeUS42x4uM+kgp 2012-05-23 5:27

>>5
Look at the compiler output and you'll change your mind.

Name: Anonymous 2012-05-23 6:48

bampu pantsu

Name: Anonymous 2012-05-23 10:38

>>18
I already did, it's the same as my hand-rolled C code.

Name: Anonymous 2012-05-23 10:42

>>20
No it isn't.

Name: Anonymous 2012-05-23 11:44

Names ending in _t are reserved for the implementation of the POSIX standard so I would not use them, otherwise OK; when you care about the implementation of a list it probably makes sense to roll it yourself. What's the big deal?

Name: Anonymous 2012-05-23 12:12

>>20
I already did, it's the same as my hand-rolled C code.
Wait...  does >>1 think that his code is C?

Name: Anonymous 2012-05-23 12:18

>>23
I meant C++.

Name: Anonymous 2012-05-23 13:15

inline
OMG OPTIMIZED

Name: Anonymous 2012-05-23 13:49

>>25
VROOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM SOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO __attribute__((always_inline)) FFFFFFFFFFFFFFFFFFAAAAAAAAAAAAAAAAAAAAAASSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

Name: Anonymous 2012-05-24 7:24

bampu pantsu

Name: Anonymous 2012-05-24 9:55

bampu pantsu

Name: Anonymous 2012-05-24 10:08

bampu pantsu

Name: Anonymous 2012-05-24 10:18

bampu pantsu

Name: Anonymous 2012-05-24 11:12

bampu pantsu

Name: Anonymous 2012-05-24 19:11

>>1,5
ZOMG UNOPTIMIZED!

Name: Anonymous 2012-05-25 14:41

You can't get any better than STL data structures in terms of algorithm complexity. GTFO faggot.

Name: Anonymous 2012-05-26 18:51

>>33
Really? I could have sworn that a rope is faster than a string at several operations, and rope isn't part of the STL

Name: Anonymous 2012-05-26 19:25

>>5
or you could just quit fucking around and use v8 already

Name: Anonymous 2012-05-26 19:59

>>34
any attempt to improve speed of concatenation will be at the cost of the speed of random access. Although a good compromise can be reached, sometimes one operation is much more important than the other, and it can be worth it to support one well and be inefficient for the other, rarely used ones.

Name: Anonymous 2012-05-27 4:18

>>36
But you just said
You can't get any better than STL data structures in terms of algorithm complexity

Name: Anonymous 2012-05-27 5:27

>>37
that wasn't me honey. get back to stackovereddexpertsexchange.

Name: Anonymous 2012-05-27 5:40

>>35
Javascript isn't C.

Name: Anonymous 2012-05-27 6:01

>>38
Well, you're arguing for an idiot seeing as how anyone with even the tiniest knowledge of algorithmic complexity understands that there are always tradeoffs between different data structures.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List