They will also often work with lower-level abstractions, such as threads, so that the higher-level developers need not think about them in their own designs.

I think you might be arguing that the object itself does not include the set of functions/methods/operations that act on it, whereas I see them as another attribute of the class/type which is an attribute of the object.

You have a class/type of objects, and you have a set of functions or operations which are associated with (loosely or tightly) and operate on that type of object.

For example, I would say that file descriptors are a handle to a type of object. They encapsulate the thing that they represent (file, DRM buffer, eventfd, whatever), and some of the functions that operate on them are polymorphic. For example, read, close, ioctl, etc., don't care if the file descriptor is a file, a queue, or whatever.

You use syscalls to interact with file descriptors, but they are just as much object handles.

Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.

So,something like: Please count the number of words in the following sentence. "What is the number of words in the sentence coming before the next one?"

edit: Which might be an artifact of the training data always being in that kind of format.

Comments URL: https://news.ycombinator.com/item?id=34954729

Points: 1

# Comments: 0

At the very least I am unable to construct a counter-example so I concede this point

It's just that the generated code may not do exactly what you expect it to do because the presence of undefined behavior allowed the compiler to make assumptions which may surprise you.

edit: It seems that I am incorrect

The compiler can't know that an arbitrary part of a function is unreachable if, for instance, that code path is controlled by a parameter or global state since that equates to solving the halting problem.

https://blog.llvm.org/2011/05/what-every-c-programmer-should...

Just because I've not had the center nub break in any of my USB-C devices that doesn't mean it's not a problem for someone else.

Similarly, I've had the springs in a Lightning port give out so that no cable worked and the port needed replacing.

I still think that having the springs in the cable connector is a more durable design but the USB-C center nub is probably too thin.

(edit) Here is the chief FireWire architect talking about the same design rationale for the FW400 connector http://www.johasteener.com/what-is-firewire.html#Why_the_4-p...

This means that for USB-C you replace the cable when the springs wear out, but for Lightning you need to replace the port.

Cleaning lint out of a USB-C receptacle with a toothpick is safe, but sticking anything into a Lightning port could damage the springs.

But, to be fair, if your measure of a fertile landscape is a forest then those are relatively few and far between. Personally I tend to feel a bit claustrophobic when there are trees boxing me in on all sides and I can't see the mountains. :)

Another part is the trademark and certification fee. https://www.opengroup.org/openbrand/Brandfees.htm

https://slideplayer.com/slide/4470263/

https://gamesfromwithin.com/managing-data-relationships

This video springs to mind as one example: https://www.youtube.com/watch?v=tfAnxaWiSeE