sicp-enjoyer

Now you're talking about financial burden again. I don't wish the situation you are describing on anyone, and I am sympathetic to making choices to avoid that happening. I don't think that is inconsistent with my other comments.

Just to add, here are a few other things that also limit your day to day freedom and add some risk of legal nightmares:

- operating a business

- owning a home or other building

- running for political office

- raising a child

- using a professional license (medical, law, civil engineer, etc)

Your comment cautioned against marriage for its "cost". Now you are talking about lifestyle preferences.

> the failure rate is too high

The rate dramatically changes with demographic, for example many of those were married young and did not complete education.

> who you pick to marry

The quote doesn't say whether :) Married men also tend to make more money and work for longer periods of time. There is a cynical view of whether that's good or not, but 40-50 year old single men don't seem to be a particularly successful demographic.

I have noticed that Phd holders usually advise buckling down and dealing with whatever abuse or bureaucratic nightmares are required to finish.

I think I agree with 1 year out, but I would be surprised if this hasn't been going on for longer.

You are correct. Sorry if I am being pedantic. I was also trying to suggest it could be a b-tree but others have pointed out that it doesn't quite fit the spec.

This person is already putting sets inside vectors, so I don't think they are worried about storage.

But yes, you either need to stop occasionally and remove the duplicates or use a set, if the storage is prohibitive.

Otherwise in terms of performance, sorting and unique is much faster than inserting one element at a time in a set.

Yes, and eventually you start computing another hash of the buffer of the concatenated members. I'm not saying it can't be done, I'm just comparing it with recursive memberwise comparison.

This is quite unfortunate. The way to get a really good hash table is by enforcing a bunch of simplifying assumptions (power of 2 sizes, sentinel values, etc). But the C++ committee has to make the "one true table" for everyone.

std::map actually seems to fit this role better. It works reasonable well for many workloads and types without tuning a bunch of parameters.

All of <algorithm> uses ordering operators as well. If you have a "regular" type with proper comparison and assignment operators, it works for everything, container keys, sorting, etc, etc.

> so hash map will generally be faster in this regard.

Complexity is not a measure of runtime. The performance drawbacks for std::map have to do with cache, not O(log) vs O(1). log(billion) is 30. And that's exactly how many comparisons you have to do, not a constant multiple of that.

With an open addressing hash table, who knows how many steps you will need to find an element. It's even more questionable if it does linked list chaining.

> binary search tree.

It's usually a red black tree and maybe could be a b-tree? "Search tree" is accurate.

Do you know about std::unique? Generally sets are a poor tool for removing duplicates.

Can many hashes be combined quickly in a uniform way? This is another benefit of `<`, it composes.

You need both access patterns (otherwise you do a double-lookup to insert a default value) and C++ already provides both.

> developer time is a significantly more expensive resource than compute

This also presupposes that making a fast program is a lot more work. However poor performance is usually due to negligence rather than a lack of optimization effort. All you need to write reasonably fast code by default (without micro-optimizing) is:

1. a good knowledge of available algorithms 2. a good understanding of the problem

1. Is a one-time investment on the programmers part that benefits all future programs they write. There is no marginal cost to being familiar with what's available in <algorithm>. 2. Has a marginal cost, but it's probably a time saver anyway. Measure once, cut twice.