I've been reading that ComputingMap only supports identity equality and not the equals(). Can someone clarify why?
As for all concurrent maps built using MapMaker, equals() is used for strong references and identity equality is used for weak and soft references.
See softKeys, weakKeys, softValues, weakValues.
Related
In am using PKCS11Interop in C#, i got CKR_MECHANISM_INVALID error while trying to use method Sign. The key object i am using is of mechanism type CKM_EC_KEY_PAIR_GEN . but at signing time, i use mechanism CKM_ECDSA_SHA512 .
I tried to define key mechanism as CKM_ECDSA_SHA512 at key-pair generation time, but it seems that this key type needs some attributes that i don't know. The attributes i am using is similar to the correct version of this question, but it seems using hash algorithms need some thing more.
Please guide me how should i use SHA512 hash algorithm with ECDSA elliptic key.
Your unmanaged PKCS#11 library most likely does not support CKM_ECDSA_SHA512.
By returning CKR_MECHANISM_INVALID error your unmanaged PKCS#11 library is telling you that "An invalid mechanism was specified to the cryptographic operation". You can use GetMechanismInfo() method to check whether the mechanism is supported:
if (!slot.GetMechanismList().Contains(CKM.CKM_ECDSA_SHA512))
throw new Exception("Unmanaged PKCS#11 library does not support CKM_ECDSA_SHA512 mechanism");
However CKM_ECDSA_SHA512 (hashing and signing) mechanism is used rather rarely. It's much more common and efficient to compute SHA512 hash in your application and then sign it with CKM_ECDSA (just signing) mechanism.
I want to know the use of KVO in swift as I read in Apple Doc or any other online articles it states that it provides indirect access to properties and addressable via string. I have a set of doubts.
If I can set the property directly via person.name = "John" they why to use a Set Value for key name = "John" indirectly
Apple doc says key-value coding compliant can participate in a wide range of Cocoa technologies like Core Data. Why it's used and not in other frameworks
It is used during runtime or dynamic to set value. How it is?
Is it TypeSafe and how?
Its an Objective - C feature then why still used in Swift 4 with latest improvements with ./Type.property access and set
If I can set the property directly via person.name = "John" they why
to use a Set Value for key name = "John" indirectly
Please read “What is the point of key-value coding?”
Apple doc says
key-value coding compliant can participate in a wide range of Cocoa
technologies like Core Data. Why it's used and not in other frameworks
It's used where appropriate. It's used where it is helpful and the performance is acceptable. If it's not useful, or if its performance is too low, it's not used.
It is used during runtime or dynamic to set value. How it is?
Key-Value Coding uses the Objective-C runtime to look up getter and setter methods, and to find the types and locations of instance variables if the setters don't exist. See Friday Q&A 2013-02-08: Let's Build Key-Value Coding for a detailed analysis.
Apple documentation briefly describes the implementation of Key-Value Observing here. It's short enough to quote entirely:
Automatic key-value observing is implemented using a technique called
isa-swizzling.
The isa pointer, as the name suggests, points to the object's class
which maintains a dispatch table. This dispatch table essentially
contains pointers to the methods the class implements, among other
data.
When an observer is registered for an attribute of an object the isa
pointer of the observed object is modified, pointing to an
intermediate class rather than at the true class. As a result the
value of the isa pointer does not necessarily reflect the actual class
of the instance.
You should never rely on the isa pointer to determine class
membership. Instead, you should use the class method to determine the
class of an object instance.
Mike Ash gave a more detailed analysis in Friday Q&A 2009-01-23.
Is it
TypeSafe and how?
It's not particularly type safe. For example, it doesn't stop you from storing a UIView in a property that's declared as NSString, or vice versa.
Its an Objective - C feature then why still used in
Swift 4 with latest improvements with ./Type.property access and set
It's still used because most of Apple's SDK is still implemented in Objective-C, and because it lets you do things that you cannot do in Swift without much more “boilerplate” (manual, repetitive functions). The trade-off is that Objective-C is lower performance. In many, many cases, the lower performance of Objective-C (compared to Swift) is not a significant problem, and the increased dynamism is very helpful.
The Rust standard library has the std::mem::uninitialized function, which allows you to manually create an undefined (and possible invalid) value of any type. This essentially maps to LLVM's undef. I was wondering if Swift had an equivalent, as I haven't been able to find one skimming through the standard library documentation.
Motivation
The primary use for this is to bypass the compiler's normal memory initialization checks when they prove imprecise. For instance, you might want to initialize some members of a structure using methods (or in Swift's case, property setters), which the compiler usually would not allow you to do. Using dummy values works, but that's potentially less efficient (if the optimizer cannot prove that the dummy is meaningless).
In Rust, uninitialized values are treated as initialized by the initialization checker, but as uninitialized by LLVM, leading to more reliable optimization. Since the Swift compiler is also built atop LLVM, it seems like something the Swift compiler should also be able to support.
My Specific Use Case
I have a struct which encapsulates a set of bit fields compacted into one machine word (an unsigned integer type). The struct type provides a safe and convenient interface for reading and modifying the individual fields, through computed properties.
I also have an initializer that takes the relevant field values as parameters. I could initialize the underlying machine word using the same bitwise operations that the computed properties use (in which case I would be repeating myself), or I could initialize it simply by setting the values of the computed properties.
Currently, Swift does not support using computed properties before self has been fully initialized. It's also unlikely Swift will ever support this case, since the computed property setters modify the existing machine word, which would require it to already be initialized, at least as far as Swift is concerned. Only I know that all my setters, in concert, will fully initialize that machine word.
My current solution is to simply initialize the machine word to 0, and then run the setters. Since a constant 0 is trivially absorbed into the bitwise | chain that combines the fields, there's no CPU time lost, but that's always going to be the case. This is the kind of situation where, in Rust, I would have used an uninitialized value to express my intent to the optimizer.
What has replaced the method toUIntMax() and the method toIntMax() in Swift 4 ? The error occurred within the FacebookCore framework.
Any help would be appreciated
The concept of IntMax has been completely removed as part of SE-104.
Converting from one integer type to another is performed using the concept of the 'maximum width integer' (see MaxInt), which is an artificial limitation. The very existence of MaxInt makes it unclear what to do should someone implement Int256, for example.
The proposed model eliminates the 'largest integer type' concept previously used to interoperate between integer types (see toIntMax in the current model) and instead provides access to machine words. It also introduces the multipliedFullWidth(by:), dividingFullWidth(_:), and quotientAndRemainder methods. Together these changes can be used to provide an efficient implementation of bignums that would be hard to achieve otherwise.
In this specific case FB SDK should simply use the UInt64($0) initializer which is now available for any BinaryInteger type thanks to the new protocols.
You can also for now, can select Swift 3.2 under Pods -> Targets -> ObjectMapper -> Swift language version option
I am looking at this language from the Swift GeneratorType documentation and I'm having a hard time understanding it:
Any code that uses multiple generators (or for...in loops) over a single sequence should have static knowledge that the specific sequence is multi-pass, either because its concrete type is known or because it is constrained to CollectionType. Also, the generators must be obtained by distinct calls to the sequence's generate() method, rather than by copying.
What does it mean for a sequence to be "multi-pass"? This language seems quite important, but I can't find a good explanation for it. I understand, for example, the concept of a "multi-pass compiler", but I'm unsure if the concepts are similar or related...
Also, I have searched SO for other posts that answer this question. I have found this one, which makes the following statement in the C++ context:
The difference between algorithms that copy their iterators and those that do not is that the former are termed "multipass" algorithms, and require their iterator type to satisfy ForwardIterator, while the latter are single-pass and only require InputIterator.
But the meaning of that isn't entirely clear to me either, and I'm not sure if the concept is the same in Swift.
Any insight from those wiser than me would be much appreciated.
A "multi-pass" sequence is one that can be iterated over multiple times via a for...in loop or by using any number of generators (constructed via generate())
The text explains you would know a sequence is multi-pass because you
know its type (perhaps a class you designed) or
know it conforms to CollectionType. (for example, sets and arrays)