将 Object.GetHashCode() 转换为 Guid
我需要为对象分配一个 guid 以在应用程序启动时管理状态关闭 看起来我可以将查找值存储在字典中，
dictionary<int,Guid>.Add(instance.GetHashCode(), myGUID());
这里是否有任何需要注意的潜在问题？
注意
这不需要在执行运行之间持续存在，只需像这样
- 创建对象
- gethashcode() 的 guid，在应用程序终止之前与新或旧的 guid
关联，gethashcode() 并查找 guid 到 update() 或 insert()使用 GUID 进入持久化引擎
唯一的假设是 gethashcode() 在进程运行时保持一致
在应用程序终止之前，也会对相同的对象类型（从窗口派生）调用 gethashcode()
更新 2 - 这是更大的图景
- 创建一个状态机来存储有关 WPF 用户控件的信息（后面称为 UC）在运行之间，
- 用户控件的类型可以
- 在第一次运行中随时间变化（添加/删除），没有先前的状态，用户与 UC 的子集交互并修改其状态，这需要当应用程序重新启动时重新创建
- 此状态快照是在应用程序正常关闭时拍摄的，
- 关闭时也可以有 UC 类型的多个实例
- ，每个实例都分配有一个 guid，并与类型信息和状态信息一起保存
- 所有这些 guid也都是 重新启动时存储在集合中
- ，对于每个 guid，创建对象，存储引用/guid，恢复每个实例的状态，以便应用程序看起来与
- 用户可以添加或删除 UC 实例/类型以及
- 在关闭时与系统交互之前完全相同，再次保存状态
- 此时的选择是删除/删除所有先前的状态并将新的状态信息插入到持久层（sql db），
- 随着时间的推移进行观察/分析，事实证明，很多实例保持一致/静态并且执行不会改变 - 所以他们的状态不需要再次删除/插入，因为状态信息现在非常大并且存储在非本地数据库上，
- 因此仅保留更改增量
- 来计算增量，需要跟踪
- 当前存储为
List的引用生命周期在启动 - 或关闭时，迭代此列表和屏幕上显示的实际 UC，相应地添加/更新/删除键，
- 将增量发送到持久性
希望上面的内容能够清楚地说明。
所以现在的问题是 - 为什么不只存储 HashCode（仅用户控件的） 而不是 WeakReference 并消除对空引用的测试 迭代列表
更新 3 - 谢谢大家，最后将使用弱引用
I need to assign a guid to objects for managing state at app startup & shutdown
It looks like i can store the lookup values in a dictionary using
dictionary<int,Guid>.Add(instance.GetHashCode(), myGUID());
are there any potential issues to be aware of here ?
NOTE
This does NOT need to persist between execution runs, only the guid like so
- create the object
- gethashcode(), associate with new or old guid
before app terminate, gethashcode() and lookup guid to update() or insert() into persistence engine USING GUID
only assumption is that the gethashcode() remains consistent while the process is running
also gethashcode() is called on the same object type (derived from window)
Update 2 - here is the bigger picture
- create a state machine to store info about WPF user controls (later ref as UC) between runs
- the types of user controls can change over time (added / removed)
- in the very 1st run, there is no prior state, the user interacts with a subset of UC and modifies their state, which needs to recreated when the app restarts
- this state snapshot is taken when the app has a normal shutdown
- also there can be multiple instances of a UC type
- at shutdown, each instance is assigned a guid and saved along with the type info and the state info
- all these guids are also stored in a collection
- at restart, for each guid, create object, store ref/guid, restore state per instance so the app looks exactly as before
- the user may add or remove UC instances/types and otherwise interact with the system
- at shutdown, the state is saved again
- choices at this time are to remove / delete all prior state and insert new state info to the persistence layer (sql db)
- with observation/analysis over time, it turns out that a lot of instances remain consistent/static and do not change - so their state need not be deleted/inserted again as the state info is now quite large and stored over a non local db
- so only the change delta is persisted
- to compute the delta, need to track reference lifetimes
- currently stored as
List<WeakReference>at startup - on shutdown, iterate through this list and actual UC present on screen, add / update / delete keys accordingly
- send delta over to persistence
Hope the above makes it clear.
So now the question is - why not just store the HashCode (of usercontrol only)
instead of WeakReference and eliminate the test for null reference while
iterating thru the list
update 3 - thanks all, going to use weakreference finally
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用 GetHashCode 平衡哈希表。这就是它的用途。请勿将其用于非设计目的的其他用途；那是非常危险的。
Use GetHashCode to balance a hash table. That's what it's for. Do not use it for some other purpose that it was not designed for; that's very dangerous.
您似乎假设哈希码是唯一的。哈希码不是这样工作的。请参阅 Eric Lippert 的博客文章：GetHashCode 指南和规则 了解更多细节，但基本上你应该只做出保证行为良好的类型的假设 - 即如果两个对象具有不同的哈希码，它们肯定是不相等的。如果它们具有相同的哈希码，则它们可能相等，但也可能不相等。
编辑：如上所述，您也不不应在执行运行之间保留哈希代码。无法保证它们在重新启动时会保持稳定。目前还不清楚你到底在做什么，但这听起来不是一个好主意。
编辑：好的，您现在已经注意到它不会持久，所以这是一个好的开始 - 但您仍然没有处理哈希码冲突的可能性。为什么要调用
GetHashCode()？为什么不直接添加对字典的引用呢？You appear to be assuming that a hash code will be unique. Hash codes don't work like that. See Eric Lippert's blog post on Guidelines and rules for GetHashCode for more details, but basically you should only ever make the assumptions which are guaranteed for well-behaving types - namely the if two objects have different hash codes, they're definitely unequal. If they have the same hash code, they may be equal, but may not be.
EDIT: As noted, you also shouldn't persist hash codes between execution runs. There's no guarantee they'll be stable in the face of restarts. It's not really clear exactly what you're doing, but it doesn't sound like a good idea.
EDIT: Okay, you've now noted that it won't be persistent, so that's a good start - but you still haven't dealt with the possibility of hash code collisions. Why do you want to call
GetHashCode()at all? Why not just add the reference to the dictionary?快速而简单的修复似乎是
当然，如果尚未正确实现 InstanceType.Equals，则需要正确实现。 （或实现
IEQuatable）The quick and easy fix seems to be
Of course you need to implement InstanceType.Equals correctly if it isn't yet. (Or implement
IEQuatable<InstanceType>)我能想到的可能的问题：
注意 - Jon 说得更优雅（见上文）
Possible issues I can think of:
Note - Jon said this more elegantly (see above)
既然这是针对 WPF 控件的，为什么不直接添加 Guid 作为依赖属性呢？您似乎已经在迭代用户控件，以便获取它们的哈希码，因此这可能是一个更简单的方法。
如果您想捕获某个控件已被删除以及它具有哪个 Guid，那么订阅关闭/删除事件并仅存储 Guid 和其他一些详细信息的某个管理器对象将是一个好主意。然后，如果需要，您还可以更轻松地捕获更多详细信息以进行分析。
Since this is for WPF controls, why not just add the Guid as a dependency proptery? You seem to already be iterating through the user controls, in order to get their hash codes, so this would probably be a simpler method.
If you want to capture that a control was removed and which Guid it had, some manager object that subscribes to closing/removed events and just store the Guid and a few other details would be a good idea. Then you would also have an easier time to capture more details for analysis if you need.