I unexpectedly did some cpp few days ago and I was surprised that cpp standard library doesn't have string trim function! Everybody is rolling their own. What is the reason behind that?
The C++ standard library should just incorporate ICU by reference IMHO.
As far as it being a large dependency, the beauty of C++ is that if you don’t use it, it won’t affect your build.
If ICU is too large, complex, and unstable for the C++ committee, then regular users don’t stand a chance.
That's the theory. In practice, you have things like iostreams pulling in tons of locale machinery (which is really significant for static builds) even if you never use a locale other than "C". That locale machinery will include gigantic functions for formatting monetary amounts even if you never do any formatting.
> If ICU is too large, complex, and unstable for the C++ committee, then regular users don’t stand a chance.
Regular users have more specific requirements and can handle binary compatibility breaks better if those aren't coupled with other unrelated functionality.
https://doc.rust-lang.org/std/primitive.str.html#method.trim...
C++ can't manage to do this because it doesn't give its primitive types methods, it doesn't have a sensible way to talk about methods on types, and it always coerces to function pointers...
assert_eq!("123foo1bar123".trim_end_matches(char::is_numeric), "123foo1bar");
assert_eq!("11foo1bar11".trim_end_matches('1'), "11foo1bar");
1. Vocabulary. Things Everybody will want to talk about. It's easier to communicate if we all agree this is a List<Goose> than if we first have to negotiate do we mean MyLinkedList or ArrayList or HybridStorage::List, and if we can't agree do we need an adaptor layer. Vocab is a reason the stdlib should provide a string type (if the language itself does not), a growable array, a hash table, etc. With generic programming you likely want some algorithms in here too, all & any, sum, that sort of thing.
2. Shared features Everybody will find they need and might otherwise screw up. Trimming trailing whitespace, turning numbers into strings and vice versa, sorting, basic arithmetic, familiar constants.
This should be in category (2). "Everybody" will need this once in a while.
† In C++ instead the standard library functions as a way to not bother with package management, this does have amusing effects like how FreeBSD will end up with a linear algebra library required to build the OS.
Two examples:
Rust 3rd party library support is so strong, that its standard library itself is actually partially built on top of 3rd party libraries.
Python, especially in the bad old days eg 20 years, didn't have much support for (sane) package management and dependency management, so it was really convenient to have a standard library with 'batteries included'.
To add pain to the injure, imagine FreeBSD also needing a Fortran compiler to build the OS.
This is something for vcpkg and conan, not the standard library.
Trimming strings isn't hard in most real world applications, on the other hand, and not putting it in the standard library means people won't confuse the way the trim method works (i.e. the user must make a choice between copying memory or reusing memory and risking memory lifetime/consistency issues). And that doesn't even include problems like "what if the string isn't utf8".
I'm more disappointed in Go, which takes a ton of questionable assumptions in the standard library to pretend difficult problems are easy. C++ wants to be correct and knowing what is or isn't whitespace is hard when you don't know the length of a single grapheme.
Interview question(s): "Write a function to reverse a string/linked list"
Me, as interviewee: "You spend a lot of time reversing things, do you?"
I don't understand why people are so obsessed with this kind of thing. In my entire career, I don't think I ever felt the need to reverse anything - iterate backwards, perhaps.
I would rather have that question, instead of how many golf balls fit into a plane.
At least the former has something to do with programming.
Query: "how many golf balls fit in a boeing 737"
Result:
Estimating, you could fit roughly 1.5 to 2 million golf balls inside a Boeing 737, depending on the specific model and how tightly they're packed.
Here's a breakdown of the estimation: Boeing 737 Dimensions: A Boeing 737 has a cabin volume of approximately 3,000 cubic meters. Golf Ball Volume: A golf ball has a volume of about 0.000004 cubic meters. Calculation: Dividing the cabin volume by the golf ball volume (3,000 / 0.000004) yields an estimated 750,000 golf balls. However, this calculation assumes the balls are packed perfectly, which is unlikely. Practical Considerations: In reality, you'd need to account for the space taken up by the plane's structure, seats, aisles, and other equipment, which reduces the usable space for golf balls. Final Estimate: Therefore, a more realistic estimate would be around 1.5 to 2 million golf balls, which accounts for the inefficiencies of packing and the space taken up by the plane's interior.
Commentary: There are so many problems with this.
A) The actual diameter of a golf ball is 4.3 cm, so its volume is 4/3 * pi * (4.3/2)^3 = 42 cm^3. There's definitely one million cubic centimetres in a cubic metre because it's (100cm)x(100cm)x(100cm). Dividing 42 by one million gives, 0.000042 cubic metres unless I'm going crazy. So approximately 0.00004 cubic metres not 0.000004 cubic metres, out by one order of magnitude.
B) Cabin volume is 3000 cubic metres. Really? Since it's about 4m wide by 2m high, it would have to be nearly 400 metres long for that to be true! Actual length 40 metres approx, actual volume 320 cubic metres approx. Out by one order of magnitude (again).
C) 3000 / 0.000004 = 750,000,000 not 750,000! This time the AI is just doing basic arithmetic and is out by three orders of magnitude. The actual calculation should be 300 / 0.00004 = 7,500,000. The various order of magnitude errors at each stage partially cancel each other, leaving us just one order of magnitude out.
D) Finally the various practical considerations it quite correctly raises means we should reduce the number of golf balls we estimate, but the AI goes the wrong way, increasing it by a factor of 3 or so from less that a million to 1.5 to 2 million.
Conclusion: It's a hallucination raised to the fourth power.
What the world is looking for in question like that is enough to figure out if you can program. Most people looking for a job have a lot of experience but they can't show you any code.
Any sane company in the US will only confirm the dates someone worked there and they "left on good terms" - they will not tell you if the person was any good. If they must fire someone HR will often offer to let the person write a resignation letter on the spot thus meaning the the person leaves on good terms - it is to your advantage overall to accept this offer - you can't sue for wrongful termination which protects them, but in turn they will say you left on good terms instead of giving a bad reference.
As such there is often no indication someone is bad and so they can jump from job to job despite being incompetent. Questions like this exist because you can solve it (at least a simplified version of ASCII only, if you need to work with unknown character set it gets hard)
1) Present them with your database schema, give them time to read and (at least partially) understand it. Allow questions. Give them a workstation.
2) Get them to write a SELECT statement to pull stuff out of two or three tables.
3) Get them to integrate the query into a small C++ program. Have the program write data out to a text file.
You can do this fairly realistic stuff for any technologies. Or, for C++, you could use my favourite interview question: "Tell me about the copy constructor".
Why not? But if your schema is so secret, come up with a simple one for use in interviews.
> You also assume they know SQL
I specifically said this was for a c++/sql job.
> so you are fine with hiring someone who can write a select only with the help of google
No, I'm not fine with that, even if it were do-able.
> I can learn your language quickly (even C++ is not that hard - the dark corners means it takes years to become great but to be productive doesn't take very long)
Wrongo. And not just for C++.
> I don't want to force any particular language on the interview, I want something that proves they can write code.
Obviously, we want very different things.
Instead of expecting businesses to tell you domain specific things and then answer questions about them, please just understand some basic principles behind a large class of algorithms.
Almost all algorithm questions boil down to a simple principle, can you take a problem and break it down into its simplest form; the simplest linked list to reverse is the empty linked list or a linked list with 1 node.
Can you then build upon the simplest case to solve the next simplest case; reverse a multi-node linked list by reversing the tail and then appending the head to the result.
It really is unfortunate how many people, instead of trying to understand concepts, want to just memorize a bunch of hardcoded facts or trivia about programming languages or libraries. If you understand the basic principles, you can easily pick up minutia about C++ copy constructors or move constructors... but someone who has memorized a great deal of minutiae about C++ may never be able to understand some of the basic principles that broadly cover a multitude of data structures and algorithms.
Hollow laughter. And if it were true (which it isn't) how well can you explain those "minutia"?
I personally use std::string_view as much as possible especially for compile-time constants. Then you can slice as much as you want without reallocating.
Why not in ISO C++?
Welcome to the ways of ISO and committee driven development, apparently no one cared enough to submit a paper, and do the work to win the paper voting into the standard.