Ибо вы хотите реально соместимый между компиляторами ABI
Я хочу понять как это обеспечивается и есть ли такое вообще.
А "не обеспечивается и, вообще, есть другие проблемы" - это вполне себе хороший ответ. Можете расписать?
johnymkp, есть такой юз-кейс рэббита, когда в одну очередь отправляешь сообщение (и сразу возвращаешься) и после отправки сразу подписываешься на очередь из которой будешь читать ответ.
Т.е. ты строишь синхронное взаимодействие поверх асинхронного.
Например, для балансировки нагрузки
partyzanx, на сколько мне известно, гит не смотрит на содержимое строк (сами символы) - он подсчитывает хэш строки, и так определяет какая строка добавилась, какая изменилась или удалилась.
Короче, он сохраняет целые строки, а не символы.
partyzanx, ну иначе можно сделать так:
1. Каждый раз вычислять дельту изменений с предыдущим комментарием (+CPU время)
2. Добавить столбец по типу "History", который будет хранить массив этих изменений (+Место)
3. Чтобы получить актуальное состояние:
- Либо берем исходное сообщение и применяем дельты
- Либо сразу храним обновленное состояние
Сергей,
1. В таком случае, можно смотреть на то есть ли расширение изображения или нет (.EndsWith(".png") например)
2. Я бы не рекомендовал так делать (/images/image.jpg - файл, а /images/image - обработчик). Для обработчиков лучше сделать отдельный путь. Очень просто в таком случае в ногу выстрелить
Я хочу понять как это обеспечивается и есть ли такое вообще.
А "не обеспечивается и, вообще, есть другие проблемы" - это вполне себе хороший ответ. Можете расписать?