> я Вам не чувак
а было очень похоже, когда речь пошла про дельфи.
>> класс string в dll С++
> Из этой строчки вы поняли, что и dll и основное приложение написано на C++?
из этой строчки я понял, что dll пишется автором на C++. Основное приложение должно бы быть написано на С++ чтобы с лёгкостью передавать std::string куда-нибудь, иначе мы бы сначала увидели какой-нибудь другой вопрос, например, "как из дельфи передать в dll на С++ std::string".
> в любом случае Вы даете плохой совет
во-первых в моих ответах нет советов.
Во-вторых, не в любом же. В типичном случае использования одного компилятора всё будет работать нормально.
> Используйте в dll только pod-типы. Внутри можно использовать все, что захотите, но снаружи должны быть видны только pod'ы
вы бы тогда уж добавили, что функции видные снаружи должны быть хотя бы extern "C", а то ведь и mangling может быть разный, и конвенция вызова.
@becks вон вы о чём. Ключевая фраза по вашей ссылке -- "I can't control what compiler these plugins are built with". Сравните с вопросом автора: "В рамках задачи написания dll-библиотеки, в которую собираюсь передавать строки...".
Если бы ваш класс был POD-типом, то можно было бы заменить указатель на член смещением от начала: offsetof(color, hsv[0]). Указатель на член мощнее этой конструкции в том смысле, что может быть использован не только с оригинальным типом T из &T::f, но и с его наследниками.
> что происходит после 1000 перезаписей?
ошибки записи, после которых контроллер карточки перестаёт использовать сбойные блоки.
> Как тогда помогает технология TRIM
помечая области как неиспользуемые вы даёте контроллеру флэша больше свободы манёвра в распределении записываемых данных по блокам. Чем равномернее используются блоки -- тем меньше записей приходится на каждый из них, тем больше времени пройдёт до исчерпания ресурса флэшки.
> в RFC немного сумбурно описаны некоторые моменты
Вот так раз. "А мужики-то и не знают" (С).
> А имел я в виду, что значение этого поля при подтверждении получения пакета ставлю равным длине полученных данных.
Этим вы говорите противоположной стороне "о, можешь послать ещё столько же, сколько в последнем пакете, пока я тут молчу". А зачем?
Window в ваших ответах, по-хорошему, должен быть связан только с доступным объёмом приёмного буфера для этого соединения.
В вашем любимом RFC793 есть целая глава "managing the window". Прочтите её.
> у меня все-таки нет CCNP сертификата
У меня тоже. Я даже не знаю, что это такое.
> нужно было еще window задать в длину данных в ACK-ответе
Что такое "задать window в длину данных"? о_О @Color скажите, вы просто перебираете всё подряд пока не заработает, или пытаетесь понять, что вы делаете и зачем? Как по-вашему window сервера может быть связан с ретрансмитами от клиента?
