Why should I have written ZeroMQ in C, not C++ (part II)

Re:Why should I have written ZeroMQ in C, not C++ (part II) by luriel on Thursday August 30, 2012 @12:42PM (#4455464)

No, but in other languages there seems to be much more consensus about what features one should use, how and when.

In C++ it seems everyone has completely different views.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by aidenn0 on Thursday August 30, 2012 @12:54PM (#4455529)

I agree its a problem with C++, but IMO it is an inevitable consequence of its strengths: namely that it is regularly used across a very wide range of domains than other languages. I've sen it used on 16-bit microcontrollers, where templates and exceptions were considered harmful, and in large applications, where those features were considered essential.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by rumcajz on Thursday August 30, 2012 @01:20PM (#4455675)

How would you implement an O(1) list without breaking encapsulation then?

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by tptacek on Thursday August 30, 2012 @01:21PM (#4455678)

What do you mean, "O(1) list"?

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by tg3 on Thursday August 30, 2012 @01:55PM (#4455841)

I assume he meant "a list from which an element can be removed in constant time."

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by mpyne on Thursday August 30, 2012 @03:15PM (#4456255)

Perhaps I'm being dumb, but doesn't std::list<T> already do exactly this?

From SGI's STL docs:

"A list is a doubly linked list. That is, it is a Sequence that supports both forward and backward traversal, and (amortized) constant time insertion and removal of elements at the beginning or the end, or in the middle"

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by malkia on Thursday August 30, 2012 @04:10PM (#4456494)

As others have said - yes, as long as you keep the iterator not the object itself. e.g. from T itself you cannot find where it was stored, so with std::list<something>, and then only from something you can't find where it is (you can have to look for it in the list).

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by eklitzke on Thursday August 30, 2012 @03:31PM (#4456315)

The idiomatic way to access and manipulate STL data structures is through iterators. In this case, an iterator for a std::list is basically a pointer/reference to the person container in the article, so if you're referring to the list objects via their iterators there's no need for O(n) list traversal.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by tedunangst on Thursday August 30, 2012 @02:03PM (#4455887)

The question doesn't make much sense. Your C example totally breaks encapsulation.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by rumcajz on Thursday August 30, 2012 @02:22PM (#4455994)

Well, what kind of problem is that in C? It's C. It has no public/private keywords. Nobody expect struct in C to be well-encapsulated.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by scott_s on Thursday August 30, 2012 @03:31PM (#4456308)

It's also not a problem in C++ if you don't care. Just because C++ gives you the means to enforce encapsulation doesn't mean you have to. And, as I said below, when your goal is performance and you need to break abstractions, it makes sense not to enforce encapsulation.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by ahupp on Thursday August 30, 2012 @02:27PM (#4456026)

http://www.boost.org/doc/libs/1_35_0/doc/html/intrusive/usag...

Not sure if this qualifies as not "breaking encapsulation" but it's as close as you're going to get.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by peterwwillis on Thursday August 30, 2012 @12:45PM (#4455479)

He never mentioned other languages, so no, I don't think that was his point. I think his point was that C++ makes it hard to make good choices about C++.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by tptacek on Thursday August 30, 2012 @12:50PM (#4455506)

I'm saying Java programmers make inappropriate data structure choices about Java programs, and boy do Ruby programmers ever make bad decisions in Ruby.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by peterwwillis on Thursday August 30, 2012 @02:15PM (#4455949)

I got that. Not very nice to say his point was dumb because you wanted to make a different one, though. I think we can all agree that C++ is annoying and leave it at that.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by tptacek on Thursday August 30, 2012 @02:57PM (#4456177)

Huh? I was sticking up for C++ (in this one context).

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by hythloday on Thursday August 30, 2012 @01:22PM (#4455685)

To an extent, they're forced to - when all you have are dynamic arrays and hashtables (I'm thinking of python here), it's hard to go very far wrong. (Isn't it? Am I being naive?)

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by Someone on Thursday August 30, 2012 @02:39PM (#4456089)

Naive? I do not know, but your logic surely is :-)

Consider the similar "if you have only one kind of string, it's hard to go wrong". If you need Unicode, but your only type of string is ISO-8859-1, or if you need to cramp many strings in memory, but your only string class uses UTF-32 internally, it's almost unavoidable that you go wrong.

The advantage of having only few data structures is that the developers of the system have only few places where they have to spend effort on optimization. So if, like Python, your platform is popular, chances are that those few basic structures have been optimized to death.

That does not necessarily make them optimal for every use case, though. The big advantage of C++ is that, if the need arises, you can (see below) make a special-case data structure that beats even the most optimized general-purpose one.

Of course, that 'can' is relative. It is really hard to make a robust special-case data structure.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by JoachimSchipper on Thursday August 30, 2012 @02:25PM (#4456017)

From yesterday's bug hunting session: sets (okay, not exactly hash tables) are not ordered data types, so do not use a set for intermediate values when order matters. (My fault - I'm just pointing out that it's not that hard to get Python wrong either.)

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by dkersten on Thursday August 30, 2012 @05:00PM (#4456784)

Well, sets are the canonical unordered collection, after all.

[ Parent | on HN ]

Re:Why should I have written ZeroMQ in C, not C++ (part II) by btilly on Thursday August 30, 2012 @04:18PM (#4456531)

It is rather hard (though I believe not impossible) to find a use case where dynamic arrays and hashtables are not within a constant factor of the best possible data structure.

Admittedly, that constant may be fairly large.

[ Parent | on HN ]