Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>Здравствуйте, remark, Вы писали:
R>>Вариант-то один — И не использовать механизмы, которые нарушают контракт, *И* сводить все ошибки к тому, что дано в контракте.
ЮЖ>См. две первые реализации 'get' из предыдущего ответа. "Механизм" используется в двух реализациях, но тем не менее в одной есть нарушение контракта (именно по причине использования этого механизма), а в другой нет.
И как оттуда вернуть ошибку "нет прав для выделения памяти" именно через такой контакт "возвращается указатель на int или 0"?
Никак. Там просто тупо давятся все ошибки.
R>От того, что пользователи используют функциональность через контракт. Если в контракте этого нет, то это бессмысленно. Пользователь не знает ни о чём, кроме контракта.
Ну от чего же? Допустим, у нас выходит новая версия библиотеки, которая поддерживает расширенную информацию об ошибках. Контракт нарушать нельзя в целях обратной совместимости. Введя дополнительную функцию можно обеспечить расширение функциональности без нарушения контракта.
Здравствуйте, remark, Вы писали:
ЮЖ>>См. две первые реализации 'get' из предыдущего ответа. "Механизм" используется в двух реализациях, но тем не менее в одной есть нарушение контракта (именно по причине использования этого механизма), а в другой нет.
R>И как оттуда вернуть ошибку "нет прав для выделения памяти" именно через такой контакт "возвращается указатель на int или 0"? R>Никак. Там просто тупо давятся все ошибки.
Давятся, т.к. на уровне контракта в общем случае невозможно специфицировать все возможные ошибки, которые могут возникнуть в реализации.
Здравствуйте, Vamp, Вы писали:
R>>От того, что пользователи используют функциональность через контракт. Если в контракте этого нет, то это бессмысленно. Пользователь не знает ни о чём, кроме контракта.
V>Ну от чего же? Допустим, у нас выходит новая версия библиотеки, которая поддерживает расширенную информацию об ошибках. Контракт нарушать нельзя в целях обратной совместимости. Введя дополнительную функцию можно обеспечить расширение функциональности без нарушения контракта.
Ты говоришь о ситуации, когда можно менять контракт. Тут действительно нет проблеим.
Я говорю о ситуации, когда контракт менять нельзя. Нужно решить в рамках данного контракта. И тут решений нет. Поэтому я и довольствуюсь тем, что разработчика при отладке кинет на нужный ассёрт, и у него будет вся необходимая информация под рукой. Всё лучше, чем без этого.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>>См. две первые реализации 'get' из предыдущего ответа. "Механизм" используется в двух реализациях, но тем не менее в одной есть нарушение контракта (именно по причине использования этого механизма), а в другой нет.
R>>И как оттуда вернуть ошибку "нет прав для выделения памяти" именно через такой контакт "возвращается указатель на int или 0"? R>>Никак. Там просто тупо давятся все ошибки.
ЮЖ>Давятся, т.к. на уровне контракта в общем случае невозможно специфицировать все возможные ошибки, которые могут возникнуть в реализации.
R>Ты говоришь о ситуации, когда можно менять контракт. Тут действительно нет проблеим. R>Я говорю о ситуации, когда контракт менять нельзя.
Как правило, с практической точки зрения введение дополнительных функций не является нарушением контракта, так как не нарушает работу ранее существовавших приложений. Изменение же возвращаемого значения, безусловно, является.
Здравствуйте, Vamp, Вы писали:
R>>Ты говоришь о ситуации, когда можно менять контракт. Тут действительно нет проблеим. R>>Я говорю о ситуации, когда контракт менять нельзя.
V>Как правило, с практической точки зрения введение дополнительных функций не является нарушением контракта, так как не нарушает работу ранее существовавших приложений. Изменение же возвращаемого значения, безусловно, является.
Введение дополнительных функций конечно не является нарушением контракта, но и бессмысленно.
Интересно у кого раньше стек кончится...
R>Введение дополнительных функций конечно не является нарушением контракта, но и бессмысленно. R>Интересно у кого раньше стек кончится...
Такое ощущение, что ты меня не слышишь. Попробую объяснить на очень простом примере.
У тебя есть библиотека, вызывающая некоторое системное API. На момент разработки библиотеки API возврашало bool — success or failure. Соответствено, библиотечная функция тоже возвращала bool — предположим, собственных ошибок она породить не могла. В новой версии ОС API стало предоставлять дополнительные сведения об ошибках, и ты хочешь вернуть их пользователю.
Расширять возвращаемое значение нельзя — посыпятся старые приложения. Единственный выход — ввести дополнительную функцию возврата расширеной ошибки. Таким образом обеспечивается обратная совместимость и предоставляются механизмы для тех, кто может ими воспользоваться.
Здравствуйте, Vamp, Вы писали:
R>>Введение дополнительных функций конечно не является нарушением контракта, но и бессмысленно. R>>Интересно у кого раньше стек кончится...
V>Такое ощущение, что ты меня не слышишь. Попробую объяснить на очень простом примере. V>У тебя есть библиотека, вызывающая некоторое системное API. На момент разработки библиотеки API возврашало bool — success or failure. Соответствено, библиотечная функция тоже возвращала bool — предположим, собственных ошибок она породить не могла. В новой версии ОС API стало предоставлять дополнительные сведения об ошибках, и ты хочешь вернуть их пользователю. V>Расширять возвращаемое значение нельзя — посыпятся старые приложения. Единственный выход — ввести дополнительную функцию возврата расширеной ошибки. Таким образом обеспечивается обратная совместимость и предоставляются механизмы для тех, кто может ими воспользоваться.
Я тебя слышу, только ты говоришь о совершенно другой ситуации, когда мы можем менять контракт — твоя новая функция возврата расширенной ошибки — это новый контракт. В такой ситуации всё достаточно прозрачно и просто.
Я говорю о ситуации, когда контракт менять нельзя.
Допустим у меня есть моя реализация библиотеки pthreads, с расширенными функциями. Ты сейчас в своём приложении их используешь? Нет. Потому что тебе фиолетово на мой *новый* контракт, ты пишешь под POSIX. ДОпустим я тебе даю свою библиотеку. Тебе есть какая-то польза от этих расширенных функций? Нет. Потому что во-первы[, у тебя куча кода именно под POSIX, а во-вторых ты просто не хочешь затачивать свою программу под мой контракт, т.к. после этого под POSIX она даже компилироваться не будет.
Ну и что, имеет мне смысл менять контракт POSIX? Вот как хочешь, так под интерфейсом POSIX и пляши, даже если pthread_create() вызывает CreateThread(), которая может возвращать INVALID_SECURITY_DESCRIPTOR.
R>Допустим у меня есть моя реализация библиотеки pthreads, с расширенными функциями.
Ты пишешь не о контрактах, а о стандартах. Если твоя библиотека реализует некий СТАНДАРТ — то да, не убавить, ни прибавить. Но далеко не все контракты привязаны к стандартам. Кстати, даже в твоем примере, я не согласен.
ПОСИКС ориентирован на Nix. Если ты реализуешь кросслпатформенный посикс, умеющий работать в том числе под вин, то да, вполне можно ввести туда дополнительные функции типа get_win_error. В этом случае те, кому нужна чистая кроссплатформенность не будут ее использовать (а могут и использовать, если функция будет уметь закорачивать себя в иных средах), а те, кого интересует только виндовая имплементация — получат преимущества дополнительной диагностики.
Так что даже в твоем примере вполне полезно.
Здравствуйте, remark, Вы писали:
R>>>Там просто тупо давятся все ошибки.
ЮЖ>>Давятся, т.к. на уровне контракта в общем случае невозможно специфицировать все возможные ошибки, которые могут возникнуть в реализации.
R>Вот это я и пытаюсь решить.
Т.е. не только для отладочных целей? Можно аналог errno сделать, как в CRT(MSVC) добавили _doserrno.
errno value is not necessarily the same as the actual error code returned by a system call from the Windows operating systems. To access the actual operating system error code, use the _doserrno variable, which contains this value.
Здравствуйте, Vamp, Вы писали:
R>>Допустим у меня есть моя реализация библиотеки pthreads, с расширенными функциями.
V>Ты пишешь не о контрактах, а о стандартах.
А разница в данном контексте?
V>Если твоя библиотека реализует некий СТАНДАРТ — то да, не убавить, ни прибавить. Но далеко не все контракты привязаны к стандартам. Кстати, даже в твоем примере, я не согласен. V>ПОСИКС ориентирован на Nix. Если ты реализуешь кросслпатформенный посикс, умеющий работать в том числе под вин, то да, вполне можно ввести туда дополнительные функции типа get_win_error. В этом случае те, кому нужна чистая кроссплатформенность не будут ее использовать (а могут и использовать, если функция будет уметь закорачивать себя в иных средах), а те, кого интересует только виндовая имплементация — получат преимущества дополнительной диагностики. V>Так что даже в твоем примере вполне полезно.
Так а чего плохого предоставить какие-то преимущества и тем, кому нужна кросс-платформенность, если альтернатива только не предоставлять никаких преимущуств? Если речь о POSIX, то это — все пользователи. Писать под интерфейс POSIX, но при этом только под Windows, выглядит поменьшей мере странно.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
R>>>>Там просто тупо давятся все ошибки.
ЮЖ>>>Давятся, т.к. на уровне контракта в общем случае невозможно специфицировать все возможные ошибки, которые могут возникнуть в реализации.
R>>Вот это я и пытаюсь решить.
ЮЖ>Т.е. не только для отладочных целей?
Только для отладочных целей. Не для отладочных тут ничего не сделать, так пусть хоть будет для отладочных.
Можно аналог errno сделать, как в CRT(MSVC) добавили _doserrno.
R>Так а чего плохого предоставить какие-то преимущества и тем, кому нужна кросс-платформенность, если альтернатива только не предоставлять никаких преимущуств? Если речь о POSIX, то это — все пользователи. Писать под интерфейс POSIX, но при этом только под Windows, выглядит поменьшей мере странно.
Просто тем, кто пользуется позикс в юниксе, никаких преимуществ уже не нужно — подсистемане сможет верунть ничего такого, чтобы не было предусмотрено в позиксе.
Здравствуйте, Vamp, Вы писали:
R>>Так а чего плохого предоставить какие-то преимущества и тем, кому нужна кросс-платформенность, если альтернатива только не предоставлять никаких преимущуств? Если речь о POSIX, то это — все пользователи. Писать под интерфейс POSIX, но при этом только под Windows, выглядит поменьшей мере странно. V>Просто тем, кто пользуется позикс в юниксе, никаких преимуществ уже не нужно — подсистемане сможет верунть ничего такого, чтобы не было предусмотрено в позиксе.
R>Я рад за них. А остальным что делать?
Остальным — это кому? Тем, кто пользуется твоей библиотекой в средах, не реализующих позикс и предоставляющими дополнительние коды возврата — использовать get_ext_error.
Разве нет?
Здравствуйте, Vamp, Вы писали:
R>>Я рад за них. А остальным что делать?
V>Остальным — это кому? Тем, кто пользуется твоей библиотекой в средах, не реализующих позикс и предоставляющими дополнительние коды возврата — использовать get_ext_error. V>Разве нет?
Млять тем, кто просто пользуется интерфейсом POSIX. Не в средах, а просто. Что б работало и в Unix, и в Windows, и в MacOX.
Здравствуйте, Vamp, Вы писали:
R>>Млять тем, кто просто пользуется интерфейсом POSIX. Не в средах, а просто. Что б работало и в Unix, и в Windows, и в MacOX.
V>Разве мы не говорили о гипотетичском примере — кроссплатформенной реализации позикс? Я уже потерял нить.
Об этом и говорим. И у такой библиотеки могут быть не только пользователи, которые используют её под юникс, или которые используют её под виндовс. Могут быть и такие, которые используют её и под юникс и под виндовс, да ещё и не хотят отклоняться от интерфейса ПОСИКС.
Они не могут использовать get_ext_error(), но при этом им надо работать и под виндовс.
Вот представь себе. Реальная ситуация.
И это могут быть не только интерфейсы POSIX, но и ISO C/C++, или там какие-нибудь интерфейсы для XML.
R>Об этом и говорим. И у такой библиотеки могут быть не только пользователи, которые используют её под юникс, или которые используют её под виндовс. Могут быть и такие, которые используют её и под юникс и под виндовс, да ещё и не хотят отклоняться от интерфейса ПОСИКС.
Ради бога. Эти пользователи либо откажутся от использования get_ext_error, либо она всегда будет возвращать empty в не-вин средах.
R>Они не могут использовать get_ext_error(), но при этом им надо работать и под виндовс.
См. выше.
