关于C编程语言......
C/C++结构偏移的部分问题表明"&并不总是指向结构第一个字段的第一个字节"
但是查看http://www.lysator.liu.se/c/rat/c5.html上的"ANSI基本原理",它在第3.5.2.1节"结构和联合说明符"中指出"开头可能没有漏洞".所以我不确定"理由"是否具有确定性,但它似乎与那个非常明显的问题的那一部分相矛盾.
那么,这是什么？ C结构的第一个字段是否始终保证偏移为0？
struct A
{
int x;
};
struct B
{
struct A myA;
int y;
};
B myB;
为&myB 保证是同&(myB.myA)在一个可移植的方式？
(更具体地说,Libev中的libev用户数据技巧,如何将参数传递给相关的回调和许多其他地方确实假设结构中的第一个字段位于0的偏移处......是否真的可移植？)
出于调试目的,我经常使用这样的代码将数据写入iOS上的文件...
NSString *docsPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject];
NSString *filePath = [docsPath stringByAppendingPathComponent:testName];
FILE* resultsFile = fopen([filePath UTF8String],"w");
...然后通过Xcode下载容器获取数据(通过在"Window-> Devices"屏幕上选择应用程序,然后从下面的"little gear"弹出式菜单中选择"Download container ..."应用列表.)
我记得这适用于iOS 9和之前的版本,但是在iPhone 6上的iOS 10上尝试这个,我发现它不再适用了.调用fopen返回成功,/var/mobile/Containers/Data/Application/[uuid]/Documents/testname但下载时文件不在容器中.
该文件不应该在容器中吗？在其他地方吗？或者是否根本无法将数据转储到文件中并将其从手机中取出？
在实践中,Observer模式的实现如何避免由于重入而导致的不良行为？
为了澄清"不良行为",请考虑模式中的Subject在单线程同步实现中具有方法MethodA()和MethodB(),事件OnMethodA()和OnMethodB()以及一个或多个Observers的情况:
此时,我们正在为所有观察者调用OnMethodB(),即使我们仍处于OnMethodA()通知的中间.这意味着列表中Observer1之后的任何观察者都会在"OnMethodA()"之前看到"OnMethodB()" - 这是不好的行为.
现在你要溢出堆栈.这是不好的行为.
如果您从一开始就设计了基于队列的异步通知,或者在通知期间对Subject调用抛出异常,则可以避免这种情况,并且这很容易理解.困扰我的是我几乎从来没有把这提到作为实现模式的最佳(或真正的,唯一的)实践.你必须已经意识到谷歌"观察者模式可重入"的问题,并且搜索中的结果似乎只是遇到问题的人,而不是关于模式的书中的警告.
我错过了什么吗？ 在实践中,Observer模式的实现如何避免由于重入而导致的不良行为？
libc ++是否维护一个进程范围内部状态,其中代码的一部分中发生的操作可以通过调用std ::*类(例如std :: set)来影响代码的某些远程部分？为了更具体一点,我见过这样的崩溃(仅显示堆栈跟踪的顶部):
std::__1::__tree<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__insert_unique(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 156, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
解决方法是升级不直接参与崩溃的库,以纠正C++ ABI问题.我很惊讶ABI问题可能会对原因造成影响,并且想知道标准库本身是否有某些状态已损坏？
在Objective-C中将一个调用推迟[super dealloc]到某个多步清理完成之前是否非法,或者必须[super dealloc]始终在dealloc(或根本不调用)之前调用？
例如,
- (void)dealloc
{
// Pretend this returns immediately and results in a call
// to OnAsynchronousShutdownProcessDone some time later:
StartAsynchronousShutdownProcess();
}
- (void) OnAsynchronousShutdownProcessDone()
{
// Let's assume the worst and pretend we might even be on
// a different thread here.
[super dealloc];
}
这是允许的吗？如果没有,有哪些替代方法？
编辑:为了提供一些上下文,这涉及关闭与定位此对象的外部库的交互(作为void*,但所有相同,指的是这个).只有在我们收到"交互完成"消息后,我们才知道其他任何内容都不会针对此对象.换句话说,关闭中涉及请求/响应.可能有很多方法可以做到这一点,但是如果我们可以推迟[super dealloc]直到我们从外部库得到响应,那就很简单了.