Off topic generic design discussion [Was: Thread local storage API]

[Off topic generic design discussion]

Yes, and it’s fault is exactly in being too generic to end up
promoting a feeling of being good at any job one can think of throwing
at it. Who’s going to dive into allocators and the whole other
gazillion of template parameters when all the books say “you’re fine
with default one”?

Allocators were a design error. Not aware of any other parameters.

It’s Easier to just blame the implementation for
the slowness,

STL isn’t slow. It is very fast. One of the benefits of templates.

It is fast only if one knows the implementation one uses and uses it
according the implementation’s intended use case.

If one doesn’t, well, it’s std::map, not the programmer’s ignorance
what’s usually blamed.

For example, std::map is an R-B tree in GCC at least, but what if that
doesn’t fit the needs? Use another library? Write your own? No,
std::map will have to do.
And std::unordered_map has a template parameter for the hash function,
but hey, how does one profile it? Yeah, could be done duplicating the
default implementation, and building up a hash profiler of one’s own,
but who’s going to bother.

I guess the Boost grew out of such cases, but it brought its own
dependency hell, undebuggability and compile time explosion.

There was one

It’s not so easy to design a language that provides appropriate
facilities. Certainly C is nowhere close. [if you want to look at C
with a proper type system have a look at ATS]

Bare C’s not getting in the way part much outweighs its deficiencies
in facilities,
but that might be just be me having wasted too much time on unnecessary hacks.

Thus I fully support what you argue about Uint32 and friends, but
dropping TLS … phew.

I’m not saying SDL should drop TLS, I claim the need for it is due
to bad design. Actually you presented a very good example that
doesn’t fit that model – where you want to “invade” some code without
disturbing it: profiling and debugging are good reasons to have TLS
support in the environment to keep them out of the “normal control

I prefer explicit things, even though that means disturbing the code.

Thing is, any such invasion will disturb the picture, with explicit stuff as in
logging, one at least knows exactly where it skews stuff. Otherwise one risks
to misunderstand the result.

That is, unless valgrind doesn’t help one first, and its approach has
no need for TLS.

Actually software is a combination of both, and it’s how they’re
coupled that characterises things. IMHO. Wirth said Programs =
Algorithms + Data structures, which is control flow plus state.
And one of the key insights is that control flow is lazy evaluation.

In fact I have trouble seeing how does this apply to data flow analysis in
any meaningful way. It does, at the lower lever, so to say, but the
control flow itself
is being more and more segregated to something like “execution units”, while
data flow between them and latencies of that are that is getting more attention.
See the rise in message-queue systems, and coroutine-like things just like you
mentioned somewhere else lately (about widgets using “blocking read()”).

In that context, TLS gives one nothing, all execution unit’s state is
confined to them anyway. Just might as well store it at stack, and if
get’s too big and unwieldy, it’s time
to split the unit, or maybe do some other redesign to keep it understandable.

The problem is that application programmers are the market for
libraries, and if they want crap through ignorance, the libraries end
up being crap too, and then new programmers use them and their
applications are crap, and the cycle continues with neither party
willing to sacrifice market for quality.

This cycle is unfortunately unavoidable in market conditions - it’s
not limited to programming, look at all the chinese-made crap that
even if designed mostly right, was then cut down to the bare minimum
the buyer will accept.

I spent a lot of my time trying to get better stuff into the major markets
which may have been a mistake ;(

Might have been a mistake in market terms, but feeling good about
own’s work is a major motivator.On Thu, Jul 11, 2013 at 3:09 AM, john skaller wrote:

On 11/07/2013, at 6:07 AM, Alexander Sabourenkov wrote: