Здравствуйте, samius, Вы писали:
...
спасибо за ответ, но есть большая вероятность того что в ближайшие пару дней мне не удастся ответить, так что звиняйте если что.

Здравствуйте, Sinclair, Вы писали:

S>Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт.

В фирмваре такое сплошь и рядом. Например, речь идёт о неком железе, запись на которое может происходить только кусками, кратными размеру страницы.

Здравствуйте, AlexNek, Вы писали:

AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.

По мне код надо писать как можно проще, без наворотов, — потому что когда приходится
вносить добавления (исправления) через 5-10 лет (как мне) – уже самому приходится вспоминать – и что же этот кусок делает?

Здравствуйте, xobotik, Вы писали:

X>Здравствуйте, AlexNek, Вы писали:
X>

X>if (buffer != null)
X>

X>Порадовало такое ощущение что код писал параноик)

От многих привычек не так-то и просто избавиться.
Например: на М220 сравнение I=3 никогда не сработает т.к. в целой переменной I не 3 а
2,(9) приходилось добавлять дельту, и при переходе на ЕСку первое время делал также.
А на ЕСке — при записи на винчестер не было никакой гарантии что, данные файла, записались нормально

Здравствуйте, AlexNek, Вы писали:

AN>Незнаю как вы, но большой одной строки для foreach я как то слабо представляю, поэтому также не смог сразу врубиться, не говоря уж об обилии лямбд

Код вполне очевидный и более менее просто читаемый. Твое плохое знакомство с рядом конструкций C# 3 не делает этот код объективно плохим.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, _FRED_, Вы писали:

FRE>> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.

FRE>> 25 см?
AN>Ну если это код, то я зелёный

Ты зеленый, а у меня 26.

Здравствуйте, Sealcon190, Вы писали:

S>В фирмваре такое сплошь и рядом. Например, речь идёт о неком железе, запись на которое может происходить только кусками, кратными размеру страницы.
Хороший поинт. Но по коду примера этого не видно: по факту функция в данном случае отправит 11 байт (префикс+10 байт), никак не ругаясь.
То, о чём вы говорите, должно работать совершенно наоборот: пользователь отправляет те данные, которые ему нужны, а уже функция взаимодействия с фирмварью обеспечивает выравнивание.

Здравствуйте, Sinix, Вы писали:

S>1. warning CS3001: Argument type 'uint' is not CLS-compliant
S>2. а собсно зачем заводить массив, который займёт >2гб памяти? (берём крайний случай — с byte[]/bool[].) В типовой системе из-за фрагментации легко получить OutOfMemory даже на 200мб.

Как это зачем? Мне, например, совсем не помешало бы, объемы данных у нас бывают очень большие. Или "64КБ достаточно для всех"?

Здравствуйте, Sinix, Вы писали:

K>>Дык уже У массивов есть LongLength
S>
S>Оно есть начиная с .NET 1.1. Позор на мою неседую голову, что ещё сказать.

Есть-то оно есть, но во всех интерфейсах коллекций используется int.

Здравствуйте, Andy77, Вы писали:

A>Как это зачем? Мне, например, совсем не помешало бы, объемы данных у нас бывают очень большие. Или "64КБ достаточно для всех"?

Нет конечно. просто шансов, что такой софт регулярно будет падать с out of memory >> 99%.

Ну, и если реально надо — или перелазить на unmanaged, или глядеть в сторону готовых решений — например,
http://blogs.msdn.com/b/joshwil/archive/2005/08/10/450202.aspx

Здравствуйте, xobotik, Вы писали:

X>Здравствуйте, AlexNek, Вы писали:
X>

X>if (buffer != null)
X>

X>Порадовало такое ощущение что код писал параноик)

Такой подход может стать результатом скрытых ошибок.
К примеру где-то из-за ошибки эта функция 1000 раз вызывается с нулевым буфером.
И эта ошибка может кочевать из версии в версию, пока странным образом не всплывет где-то в другом месте.

В с++ на такое обычно пишутся ассерты.

Здравствуйте, Ops, Вы писали:

Ops> AN>Здравствуйте, _FRED_, Вы писали:

Ops> FRE>> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.

Ops> FRE>> 25 см?

Ops> AN>Ну если это код, то я зелёный

Ops> Ты зеленый, а у меня 26.

А дело разве в длине? Да и жалко что вместо Петра 1, не была особа женского пола, хоть вагоны не нужно было переставлять

Здравствуйте, Ночной Смотрящий, Вы писали:

НС> AN>Незнаю как вы, но большой одной строки для foreach я как то слабо представляю, поэтому также не смог сразу врубиться, не говоря уж об обилии лямбд

НС> Код вполне очевидный и более менее просто читаемый. Твое плохое знакомство с рядом конструкций C# 3 не делает этот код объективно плохим.

а где там конструкции C# 3 или мы о разном коде говорим?

Здравствуйте, Bandy11, Вы писали:

B> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.

B> По мне код надо писать как можно проще, без наворотов, — потому что когда приходится
B> вносить добавления (исправления) через 5-10 лет (как мне) – уже самому приходится вспоминать – и что же этот кусок делает?
совершенно согласен

Здравствуйте, Sinclair, Вы писали:

S>Хороший поинт. Но по коду примера этого не видно: по факту функция в данном случае отправит 11 байт (префикс+10 байт), никак не ругаясь.

Согласен. Я всего лишь отметил излишне обобщённое высказывание.

Здравствуйте, Sinix, Вы писали:

S>Нет конечно. просто шансов, что такой софт регулярно будет падать с out of memory >> 99%.

Намного больше 99% — это сколько? И откуда такой вывод? Памяти нынче много, про характер софта тебе ничего не известно.

S>Ну, и если реально надо — или перелазить на unmanaged, или глядеть в сторону готовых решений — например,
S>http://blogs.msdn.com/b/joshwil/archive/2005/08/10/450202.aspx

Мы в некотором роде как раз и разрабатываем "готовые решения". Понятно, что существуют обходные пути, но всё это напоминает мучения с моделями памяти 8086

Здравствуйте, Andy77, Вы писали:

A>Намного больше 99% — это сколько? И откуда такой вывод? Памяти нынче много, про характер софта тебе ничего не известно.
Все 200 Максимальный размер объекта в .Net — 2гб. Кстати, мы ведь обсуждаем только решения под x64?

A>Мы в некотором роде как раз и разрабатываем "готовые решения". Понятно, что существуют обходные пути, но всё это напоминает мучения с моделями памяти 8086

Так способов куча — BigArray, MMF, аллокация в нативной куче... Всё не подходит?

Здравствуйте, Sinix, Вы писали:

S>Так способов куча — BigArray, MMF, аллокация в нативной куче... Всё не подходит?

Подходит, но без костылей было бы лучше.