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

PD>Как он хранит — не мое дело. А вот возвращает он из без длины.

возвращает не он. Возвращает библиотека доступа к нему, причем — тот конкретный экземпляр, который ты используешь.

PD>Бог с тобой, зачем же ? Ты вообще с MMF знаком ? Там прямой доступ. Если уж мне надо расширить файл, то я просто создам мэппинг на размер, больший, чем текущий размер файла на требуемую величину.

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

PD>Да в общем-то ничего интересного. По крайней мере ничего нового для себя я не нашел. Довольно наивные рассуждения, особенно забавно вот это

>>Строка не может содержать нулевые байты. Так что хранить произвольные двоичные данные вроде картинки в формате JPEG в строке нельзя.

PD>Между прочим, JPEG очень неудобно хранить так же в виде стека, линейного списка, двоичного дерева и т.д. И не надо — не предназначены эти структуры для хранения JPEG . Как и строка. Кстати, ты готов хранить JPEG в виде string ?

Я буду хранить в том, что будет удобно для моей задачи. Хоть в массиве, хоть в строке, хоть в дереве.

Забавно, что ты обратил внимание только на это.
Я даже не могу сказать, что ты не видишь леса из-за деревьев. Потому что ты настолько погрузился в разглядывание травы под своими ногами, что даже про существование деревьев забыл.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Код, который читает данные из базы, длину не вычисляет.
Еще как вычисляет. Неудачный пример.
PD> Нет такого в SQL SELECT, к примеру. Внутри себя этот SELECT на сервере я не знаю что делает, но мне на клиент в итоге строка попадает как последовательность ASCIIZ.
Неправда. Строка попадает в довольно сложном виде. Никаким ASCIIZ там и не пахнет — приезжает и длина, и признак null, а то еще и кодировка.
PD>Последовательность ASCIIZ — "сырые" данные, откуда они взялись — не важно.
Нет уж позвольте. Мне вот очень интересно — откуда взялись эти сырые данные, и почему у них отобрали длину.
PD>А в объекте string на входе конструктора эти же сырые данные (а как ты еще string сконструируешь, если не по ASCIIZ или по другому string ?)
Как это? Миллион способов сконструировать строку есть.
PD>, а вот в полученном объекте — уже с длиной. Т.е. длину при создании экземпляра string вычислили.
Все верно.
PD>Да ведь во входном мире ничего другого нет. Есть некий входной массив байт (из файла, из сети, ...).
Неправда. Это какой-то не тот мир, который я знаю. Файлы уже лет тридцать как снабжаются длиной. Совершенно незачем выполнять последовательное сканирование для ее определения. Я понимаю, что трудно заставить в это поверить человека, привыкшего работать с магнитной лентой, но это так
PD>Этот набор нам дают и все. И чем-то заканчивают, чтобы знали, когда остановиться.
В 21 веке пора привыкать к тому, что строка в 99.9999% обладает длиной. И потерять эту длину можно только отрезав ее в одном месте. Чтобы тут же начать вычислять ее в другом.
PD>gets банальный, например. А дальше уж наше дело — то ли string из него соорудить, длину мимоходом посчитав и время потратив, то ли не считать длину, отложить до того момента, когда понадобится (может, и не понадобится) . Кстати, в моем примере с конкатенацией я эту длину мог мимоходом вычислить.

>>Читал историю про маляра Шлемиэля?
PD>Нет.
Очень, очень напрасно. Вот здесь.

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

Д>то есть, в данном случае размер хранится где-то отдельно. Иными словами, это не ASCIIZ строка

Да, конечно. Ты же заявил, что это файл придется просмотреть. чтобы в конец добавить, я и объяснил, как это делается. А так — конечно, не ASCIIZ. И длину считать придется, пройдя весь файл. И кстати, даже не знаю как — если запретить мне GetFileSize, то я и не представляю как ее определить самому.

А что, ты можешь предложить способ найти конец файла не зная его длину ?


Д>Забавно, что ты обратил внимание только на это.
Д>Я даже не могу сказать, что ты не видишь леса из-за деревьев. Потому что ты настолько погрузился в разглядывание травы под своими ногами, что даже про существование деревьев забыл.

Наверное, пора прекращать дискуссию. Оставляю за тобой последнее слово (если хочешь ответить), я больше отвечать не буду. Как сказал один дипломат по поводу результатов переговоров :"Переговоры прошли блестяще — мы разошлись во мнении по всем без исключения вопросам"

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

Хм. Мне казалось. что я ответил. Оказывается, нет.

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Код, который читает данные из базы, длину не вычисляет.
S>Еще как вычисляет. Неудачный пример.

Может быть.

PD>>Последовательность ASCIIZ — "сырые" данные, откуда они взялись — не важно.
S>Нет уж позвольте. Мне вот очень интересно — откуда взялись эти сырые данные, и почему у них отобрали длину.

Я откуда знаю, почему ? Не возвращает fgets длину — и все. Могла бы, в принципе, но не возвращает. А на ней весь консольный ввод построен.
Да и в WinAPI то же. К примеру, edit. Естественно, у него можно и длину спросить, и строку. Есть, в общем, длина. Только от этого не легче — чтобы из этой ASCIIZ строки получить string, придется его конструктор вызывать, string(char*), а он эту строку к себе скопирует (и правильно, конечно, сделает) и длину пристроит.

А на fgets и edit вообще-то говоря, весь пользовательский ввод построен (ну не только, конечно). Прежде чем строка в БД оказалась, ее , скорее всего, кто-то вводил...

PD>>А в объекте string на входе конструктора эти же сырые данные (а как ты еще string сконструируешь, если не по ASCIIZ или по другому string ?)
S>Как это? Миллион способов сконструировать строку есть.

Есть, не спорю. Только давай договоримся — из этого миллиона оставим только те, которые принимают на входе некий поток символов, а потом некий признак конца (не обязательно 0). Вот это и есть то, что я называю сырые данные.

PD>>Да ведь во входном мире ничего другого нет. Есть некий входной массив байт (из файла, из сети, ...).
S>Неправда. Это какой-то не тот мир, который я знаю. Файлы уже лет тридцать как снабжаются длиной. Совершенно незачем выполнять последовательное сканирование для ее определения. Я понимаю, что трудно заставить в это поверить человека, привыкшего работать с магнитной лентой, но это так

Во-первых, на МЛ были файлы — по крайней мере, в СМ-4. И длина у них была. а во-вторых подобный ернический тон, пожалуйста, оставь.

PD>>Этот набор нам дают и все. И чем-то заканчивают, чтобы знали, когда остановиться.
S>В 21 веке пора привыкать к тому, что строка в 99.9999% обладает длиной. И потерять эту длину можно только отрезав ее в одном месте. Чтобы тут же начать вычислять ее в другом.

Именно. Только от Win32 мы почему-то, как правило, получаем строки с отрезанной длиной. А потом ее пристраиваем — хоть в string, хоть в CString, хоть где-то еще.

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

C>Это, наверное, если все сервисы сразу запустить. Я долгое время без
C>проблем работал на P166+32Mb+NT SP6...

... в notpad-е...

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

C>Ошибаетесь, вот МС показала здравый смысл — в Windows Vista все как и
C>раньше будет основано на unmanaged-приложениях. В том числе и explorer с
C>оффисом. И пока программисты, ратующие за увеличение производительности
C>труда, будут писать чего-то там на WinForms или Avalon'е — МС будет
C>совершенствовать свой набор оффисных программ, интегрированных через
C>OLE2 (аналога которого в managed-мире нет и не предвидится).

Это банальная нехватка времени. Погоди несколько лет будет тебе и управляемый Офис, и все остальное.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>И да, и нет. Если переписать, то, может, оно и нормально будет — сейчас, без эксперимента, сложно наверняка говорить Но вот причина, почему они не выпускают Office, перекомпилировав его с помощью MC++ или C++/CLI, заключается как раз в заметно уменьшающейся производительности, которую показывают собранные таким образом приложения Office.

Это информация от группы Офиса, или умозаключения?

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

PD>Но вот одно либо я недостаточно четко изложил, либо меня не поняли, либо не хотели понять. Я не призыаваю к тотальной оптимизации, это просто глупо, в конце концов. И те, кто меня в этом упрекают, зря стучатся в открытую дверь. Я выступаю за то, чтобы код на своем уровне писался эффективно. Чтобы не использовались явно избыточные по памяти или времени конструкции, когда это совсем не обязательно и вполне ясно, как без них обойтись, отнюдь не поступаясь при этом ясностью и четкостью.

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

PD>И если интструмент спроектирован так, что он мне неизбыточное кодирование делать не дает, а заставляет или хотя бы толкает на это избыточное исходя из того, что нечего эти ресурсы экономить — вот с этим я и не согласен.

Вот-вот. Инструмент тебе предоставляет абстракцию — строка, а ты объявляешь ее избиточной.

E>Тут уже кто-то сказал, что это "потом" никогда не наступает.

Это "потом" наступить может лишь тогда, когда этого потребует заказчик, сиречь заплатит еще денег.(Естественно, если в первоначальных требованиях этого не было).
В свободных же проектах это "потом" может наступить в зависимости от энтузиазма разработчиков, и, имхо, главное, от наличия у них времени, так что не надо приводить в пример некоммерческие проекты в данном случае.

PD>+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.

Исходим от затрат, часто гораздо дешевле поставить еще один сервер.

PD>Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше.
Если Вы будете писать это дольше то "лучше" это не будет скорее всего. Опять слова "эффективность", "лучше".
В чем измеряеться Ваша "эффективность", в чем измеряется Ваше "лучше"?
В разных контекстах они могут означать противоположные или просто разные вещи.
>А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам.
Зато это достаточно трудно обнаружимые баги, ибо не всегда вы за несколько минут найдете, откуда память потекла, а битый указатель может проявится совсем не в том месте, где его "сломали". Это могут быть вполне разные программные модули. Если машина помогает избавиться от технических багов, почему б не использовать эту возможность?

PD>Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.

Кто определил сколько программе "в действительности нужно"? Бог Программистов? Опять какие то непонятные идеалы? Аппелирование к абсолютным истинам? Их несуществует, тем более в программировании, имхо.


PD>Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.
PD>Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.

Закон рынка — пока клиент готов платить, пусть платит.
Какое мне дело до того сколько они платят, если они готовы это делать? Главное, что мои доходы от этого повышаются.
Извините за некскромность, вы боретесь за какую то абсолютную правду?


PD> Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.
Вот когда будет известно что, то и можно говорить о "лучшем решении". Опять же, никто не запрещал юзать разные технологии в одном проетке, адекватные конкретной подзадаче проекта.
И, главный, имхо, вопрос: А зачем вам убеждать заказчика? Что лично ВЫ(ваша команда, компания) от этого получает? Прошу не воспринимать это как наезд, это вопросы, которые я бы сам себе задал, если б пришлось убеждать в чем то заказчика. Кстати говоря, заказчик не всегда знает, что ему конкретно надо, для этого есть этап сбора требований

PD>Ничего ты не соптимизиуешь. Не ты лично, а те, кто к эффективности не привык. Им и в голову не придет, что это все на 20 Мб может меньше требовать.
Уже было выше, им это прийдет в голову, когда начнут падать продажи продукта и клиенты побегут к конкурентам. Рынок — саморегулируемая система.

VladD2 wrote:

> Это банальная нехватка времени. Погоди несколько лет будет тебе и
> управляемый Офис, и все остальное.

Следующий Оффис управляемым не будет, а что будет через 5 лет для меня
пока не так важно — все успеет не раз поменяться.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:
> PD>KISS — Keep It Simple, Stupid!
>
> Помнится один авторитетный товаришь к этот прицип формулировал несколько
> иначе "Все должно быть простым, настолько простым насколько это возможно
> — но не проще.". И я с ним согласен.

Это был Эйнштейн.

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

C>Следующий Оффис управляемым не будет, а что будет через 5 лет для меня
C>пока не так важно — все успеет не раз поменяться.

Это и поменяется. Но думаю еще до этого сильно поменяется мнение о возможностях управляемого кода. Сейчас даже в Сан готовят революцию, а уж МС запрягла такое количество научных учереждений, что у меня сомнений не возникает.

VladD2 wrote:

> C>Следующий Оффис управляемым не будет, а что будет через 5 лет для меня
> C>пока не так важно — все успеет не раз поменяться.
> Это и поменяется.

С чего бы? В бэтах Висты .NET играет роль пятого колеса, в Mac OS X (до
которой Винде еще долго расти) управляемый код тоже далеко не главная часть.

Инфраструкту COM на .NET так нормально к Виста перенести и не смогли, а
до следующей итерации пройдет немало времени.

> Но думаю еще до этого сильно поменяется мнение о возможностях
> управляемого кода. Сейчас даже в Сан готовят революцию, а уж МС
> запрягла такое количество научных учереждений, что у меня сомнений не
> возникает.

Вы не ловите момент: сейчас .NET и Java — это уже вчерашний день.
Будущее за AJAX

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>VladD2 wrote:

>> C>Следующий Оффис управляемым не будет, а что будет через 5 лет для меня
>> C>пока не так важно — все успеет не раз поменяться.
>> Это и поменяется.

C>С чего бы?

Увидишь. Как я уже говорил в научные исследования посвященные этой поблеме вкладываются огромные деньги. Но эти деньги просто не могут првратиться в реальные результаты сразу. На это нужно время. Первые ласточки уже есть. Те же дженерики в дотнете, например.

C>В бэтах Висты .NET играет роль пятого колеса, в Mac OS X (до
C>которой Винде еще долго расти) управляемый код тоже далеко не главная часть.

C>Инфраструкту COM на .NET так нормально к Виста перенести и не смогли, а
C>до следующей итерации пройдет немало времени.

Это не важно.

C>Вы не ловите момент: сейчас .NET и Java — это уже вчерашний день.
C>Будущее за AJAX

Тебе виднее.

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

GN>А когда начнут интегрировать RAM в корпус CPU (что бы избавиться от проблем с печатными платами), то как будем добавлять память?

А надо? Для каждого периода времени есть некие негласные принятые объемы памяти. Ввести три градации:
1. Лоэнд — сейчас где-то 128 метров.
2. Лоэнд+ — 256 на сегодня.
3. Мидлэнд — 512.
4. Хайэнд — 1 Гиг.
5. Мечта идиота 4 Гб.

Если это будет статическая память (попросу кэш), то ее можно тактировать частотой ядра и получать офигительные решения. Каждый класс к тому же будет иметь разное число ядер, разную тактовую частоу и т.п.

На будющее просто выростут объемы памяти и частоты. Классы же останутся.

Это кстати позволит делать девайсы миниатюрнее.

Можно пойти и таким путем. делать матери сразу под много процессоров с доставляемыми процессорными блоками. Каждый блок доставляет не только процессор но и память.

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

GN>ИМХО проблема не в языках. Многие алгоритмы имеют зависимости по данным (нельзя продолжать выполнение, пока не известен результат предыдущей операции). Да возьмём для примера любимый компилятор — даже если распараллелим компиляцию отдельных файлов, то как быть с линкером?

Хм. Распалаллелить парсинг и даже мемантический анализ можно. А линкер не везде есть. В дотнете, напрмер, он не нужен. JIT позволяет компилировать функции оп отдельности. Так что распараллелить этот процесс как два байта об асфальт.

Так что твои сомнения — это твои догмы.

Если хочешь посмотреть на то как будут параллелиться вычисления завтра посмотри на ФЯ. В них нет побочных эффектов при вычислениях, а это позволяет распараллеливать большинство вычислений. Причем автоматически.

GN>Можно вспомнить много таких "революционных" технологий даже на x86 — MMX, SSE, ... реальных выигрышей они не дают, если бы обычных регистров добавили, да нормальный (не стековый) FPU сделали — результат бы мог и лучше получиться. Но это бы была только *эволюция*.

Это заблуждение. В некоторых областях SSE дает огромный выигрыш. Просто фичи больно специализрованные. Хотя как не странно даже дотнет умеет их применять.

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

PD>Да, бедные мы все. До появления Net писали себе char* и не знали. что не программы пишем, а только плодим "ни того, ни другого, да еще и дырка в безопасности впридачу"

Агащазблин, мы. Вы, а мы использовали и используем: std::string | CString

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

E>Возьмем Janus. Когда я пишу это сообщение он у меня занимает в пямяти 53Mb. Сам инсталлятор у него маленький, но к нему же еще и .Net нужен. А к следующим версиям еще и .Net 2.0 потребуется. А уж поиск по базе сообщений по скорости с Opera вообще не сравнится. Да и объем сохраняемых сообщений на диске не маленький. Так что для меня Janus удобная программа, но вот эффективной я ее назвать не могу. А если для повышения ее эффективности для хранения сообщений вообще что-то посерьезнее Jet-та потребуется (какой-нибудь FireBird или MSSQL), то вообще...

Улыбнуло капитально.

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

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

VD>Распалаллелить парсинг и даже мемантический анализ можно.

Если совсем примитивно картину нарисовать — это будет работать, если исходник состоит из нескольких файлов. То есть, всё равно нужен какой-то (последовательный) механизм который будет выделять эти "параллельные" части. А вот как быть с той же таблицей символов? не пойму . Тут нужно, что бы язык на уровне синтаксиса не давал создавать такие проблемы. То есть, для старых языков не годится.

VD>А линкер не везде есть. В дотнете, напрмер, он не нужен. JIT позволяет компилировать функции оп отдельности. Так что распараллелить этот процесс как два байта об асфальт.

VD>Так что твои сомнения — это твои догмы.

Мои сомнения — не только мои догмы, но и догмы большого количества людей... Линкер-то и в С++ не особо нужен (ICC например идёт в этом направлении... и даже MSVC).

VD>Если хочешь посмотреть на то как будут параллелиться вычисления завтра посмотри на ФЯ. В них нет побочных эффектов при вычислениях, а это позволяет распараллеливать большинство вычислений. Причем автоматически.

А теперь представим, как все дружно пересаживаются на эти языки .

GN>>Можно вспомнить много таких "революционных" технологий даже на x86 — MMX, SSE, ... реальных выигрышей они не дают, если бы обычных регистров добавили, да нормальный (не стековый) FPU сделали — результат бы мог и лучше получиться. Но это бы была только *эволюция*.

VD>Это заблуждение. В некоторых областях SSE дает огромный выигрыш. Просто фичи больно специализрованные.

Я таких областей не знаю, можно подробнее? Если, например, говорить о параллельной обработке 4х float — так это маркетинг чистой воды. CPU и без того параллелит вычисления обычного последовательного кода. То есть, можно было довести до ума существующий механизм. SSE — по сути просто другой интерфейс к тем же самым вычислительным ресурсам. Где-то он удобнее и лучше, но это — результат того, что улучшали именно его, а не старый .