marvy

the full story is in the language reference, but the short answer is: __radd__ (unless it's more complicated than I realize)

you can choose; there's an option buried in settings somewhere

Clever! I like this! I feel a bit jealous that I didn't think of it :)

It's not quite as easy as it seems, because these methods are "intrinsics". That is, the pure Java code you see is not always the one that gets used; instead, the JIT compiler can use a faster implementation that uses vectorized assembly or whatever. (That's why you see "@IntrinsicCandidate" on compress() and toBytes() in StringUTF16.java)

But I think your idea would also be possible to implement in vectorized assembly, so it still works!

The rule for most things (such as ArrayList) in the JDK is: "if you use race conditions to break this thing, that's your problem, not ours". But String is different: it's one of the few things meant to be "rock-solid, can't break it even if you try", so I think this bug in String would qualify as a potential security issue in their mind: there are many places in Java that trust Strings not to act weird, and some of them are even in native code deep in the guts of the VM.

On the other hand, String is used all over the place so having to introduce a performance regression to fix this bug would be quite painful. All of the other proposed solutions in this thread introduce an extra copy, and an extra pass over the string. Your fix is basically no extra cost, and as a bonus, can be tweaked so each char in the array is read only once.

Which means that the bug can now be fixed "guilt-free", if anyone from the JDK team is reading this thread. Though they have some pretty clever people there too, so they might have thought of it eventually for all I know.

I feel like there's two sides to this. On one hand, I agree with Zulip: don't make promises you're not sure can keep. On the other, you also shouldn't believe promises if the person making them is obviously not in a position to guarantee.

Example: suppose I offer you free email hosting "forever". Should you believe me? What if I go out of business? Well, in that case, I can at least ensure that your email address gets transferred to a different provider, so I'll still have kept my promise. So maybe this particular promise is believable.

But that only works because email is more or less a standard so there are many providers. Suppose I offer something that no one else does. Can you trust my promise that it will be "free forever"? Clearly, if I go out of business, then no.

Can I at least make a conditional promise that it will be free "as long as I'm in business"? But suppose I'm a month from bankruptcy, and my accountant tells me that getting rid of my free tier would save me. Surely, it's better for my free users to lose service rather than ALL my users losing service. So, unless you're sure I'd never be in that situation, you shouldn't believe me when I say "as long as I'm business this will be free".

Okay, how about a vague promise like "this service will keep its free tier around unless the business is in a desperate situation of some kind"? That's a promise that I could indeed keep, if I decide it's important enough... unless... how sure are you that I'll remain in full control of what is currently "my" business? What if I take my company public? I might then be kicked out by the board. (It happened to Steve Jobs, right?) So either my "free forever" promise means I'm not allowed to go public, or at least I need to do some very careful legal acrobatics to ensure that the board can't go back on my promise, even if they kick me out.

Still, if you find yourself needing to break a promise you made about "forever" a mere month after you made it, you should probably at least apologize instead of just hoping that no one remembers that you ever made such a promise. Chances are, they will indeed remember. If "it's the right thing to do" is not enough motivation, then do it for the brownie points, you'll get more of them this way. ("Who cares about brownie points?" you ask? Well, clearly, if they weren't worried about brownie points then they wouldn't be playing this weird game of "let's pretend we never said the forever".)

Thanks for the above. (nice self-restraint in the last paragraph.) Things almost make sense now. Except one problem ... this implies that there are software developers who think to themselves "given a cell phone number, how can I get the phone's location?".

And it further implies that these people don't immediately follow that thought with: "That's surely impossible, since it would be a privacy nightmare if literally everyone in the world could track everyone else in the world's every move".

Or perhaps with this alternative thought, which would lead to the same conclusion: "let's not worry about privacy, how would this even work? Does every phone company in the world pro-actively send every customer's location data to OpenCage, just in case someone queries it? Or does OpenCage wait until it gets a query, and only then query the cell phone company 'just-in-time'? Both of these sound like a lot of work for each phone company to support ... what's the incentive?"

Honestly, I'm a bit surprised that the OpenCage blog post is so calm about this, instead of just yelling incoherently "why WHY why would anyone think like this?!?"

sorry I meant it was an UNSIGNED integer back then

I thought it was settled in Version 4. Compare:

https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time....

vs

https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man2/time....

EDIT: note that back then, it was a signed integer. Turns out that people wanted to be able to represent dates from before 1970 so we lost one bit.

Thanks for explaining. I guess if you ever decide to become a foreign spy, you can point to this as "relevant experience" in THAT job interview. Or something.

How would a boyfriend or lack thereof even come up in an interview? Let alone so often as to be worth practicing such a thing? (I'm single, but I don't remember ever mentioning it in an interview. Though my memory is bad at this stuff so for all I know I've mentioned it every single time.)

New York presumably

Why does it need a champion? Suppose some legislator is drunk one night and decides to introduce a bill banning non-competes. Who would vote against it?

isn't it?

Amazing. A real, live, credible proposal for lambdas in ISO standard C.

Ooh nice! I didn't think of that! Since appending to an array is cheap, you can just move-to-end instead of move-to-front, and then iterate in "reverse" order, so from the outside everything seems to Just Work.

I think LRU does NOT work with this trick, because there's no easy way to "move-to-front" in O(1) time.

The article mentions Java's LinkedHashMap, which actually can do LRU. But as the name implies, they rely on a linked list, where move=to-front is natural.

But this superpower does not come for free: a Java-style linked hash map will use more memory than the technique described in the article.

they got rid of that in Python 3, I think

Okay now I'm curious: what IDE do you use that makes this a non-issue?

Consider the following two cases:

1. MyClass has 10 private fields, each with a trivial getter and setter.

2. YourClass has 10 private fields, of which 9 have a trivial getter and setter. The last one has a trivial getter but the setter is non-trivial.

If you use your IDE to write your getters and setters, than the two classes above will look the same at glance.

If you use Lombok, the "special" field will stick out at once.

Personally, I prefer to avoid Lombok and just use public fields. That way, the field with a nontrivial setter will also stick out, and no need for bytecode magic.

I think mh7 did not mean to hard-code intcmp into qsort. The idea is to move the definition of qsort directly into the stdlib.h header file. That way, the compiler can see the definition of qsort and intcmp at the same time.

In that case, the compiler could make a specialized qsort using intcmp automatically.

You can tweak the definition to take advantage of whatever your language DOES allow. He alludes to this during the Q&A at the end. For instance: two expression are equal if (and only if), for all possible contexts C, you have C[e1] and C[e2] send the same bytes to standard output.

In this simple script you can, but eventually you need an loop or something and you realize you're kind of stuck:

before_loop; while something: step1; step2; after_loop;

Note that after_loop is still inside the loop. Also you can't have multiple colons on the same line, so this doesn't work either:

if test: do_this; else: do_that

That gives a syntax error

Might be worth filing an issue; a glance at the repo suggests that the list is still being actively maintained.

> maybe even win with

In a U.S. court? You really think so? If you're right then in my opinion that's proof that the law needs fixing.

With Project Panama, they are finally trying to make calling non-Java code easy.

Kernel will hopefully be ready; user space is another story.

I think foo::args should be a normal struct type, so sizeof(foo::args) would follow the usual rules, just as if someone had manually written

struct foo_args{char a; short b; long c; float d; etc...}

and then asked for sizeof(foo_args).

This mostly solves the unpacking problem. Thus, there are only two problems left:

1. I need to handcraft the tuple type myself, and make sure it matches the function declaration. (In other words, I don't want to manually write tuple<char, short>. I want to write foo::arg_tuple.)

2. This provides no support for named parameters. Tuples in C++ are numbered, not named.

sorry, I meant named parameters

The title is slightly click-bait-y: C++20 doesn't have default parameters. It talks about how to fake it with structs.

It's a pretty convincing fake, but it has one problem: the person who wrote the function needs to have written it that way. What I wish more languages had (C++, Java, etc.) is the following:

Suppose I write some function that take way too many parameters:

void foo(char a, short b, long c, float d, double e){}

What I want, as a caller, is for the language to let me get a struct corresponding to the argument list, something like this:

    foo::args whatever;
    whatever.e = 3.14;
    // fill in the rest

And then add a bit of magic syntax so we can "unpack" that struct to actually call foo. (Extending this proposal to handle varargs is left as an exercise to the reader, because I have no idea.)

Why so sure? Are you saying this program probably was legal after all and this court made a mistake?