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

как насчет быстрого преобразования Фурье на Клиппере?
когда люди сильно увлекаются чем-то новым они пытаются пихать это новое
везде где можно.

кстати M$ мог бы создать новый рынок железа продвигая .NET. например
стимулировать создание процессора напрямую исполняющего MSIL

VD>Тогда остается сделать один небольшой шаг... создать новый проект на C# и поэксперементировать. >Вот нужно будет утилитку какую написать... попробуй, не поленись... уверен, что отношение резко >зменится.

пробовал немного. преимушества пока вижу только в веб-разработке (ASP.NET вместо ASP).
для остальных наших задач спорно. пока C++ удовлетворяет

VD>>>Вот как раз подобные вещи очень любят клепать на Яве.

A>>угадайте на каком языке пишут 90% программистов в Microsoft?

VD>Сейчас уже неизвестно. Раньше 90% было на С. А что?
мои знакомые работают в DirectX, Visual Studio, Commerce Server и MS Office team.
везде C++. насколько я знаю под .NET пока только BizTalk пишут.

VD>А полностью не будет никогда. Драйверы и ядро все одно на С/С++ с асм-мом писать будут. Ну, а >многие прикладные части должны быть переписаны.

дык спорим то о чем? я ж не говорю о том что C# хуже/лучше а о том что для С++ всегда
будет место в больших проектах. GUI возможно перестанут на нем писать, но какие-то
низкоуровневые части есть и будут

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

VD>>Сейчас уже неизвестно. Раньше 90% было на С. А что?
A>мои знакомые работают в DirectX, Visual Studio, Commerce Server и MS Office team.

Под Commers Server можно уже на дотнете писать. С MS Office ситуация пока непонятная.

A>везде C++. насколько я знаю под .NET пока только BizTalk пишут.
В смысле пишут? Biztalk это инициатива. Ты имеешь ввиду Biztalk сервер? А что под него писать?

A>дык спорим то о чем? я ж не говорю о том что C# хуже/лучше а о том что для С++ всегда
A>будет место в больших проектах. GUI возможно перестанут на нем писать, но какие-то
A>низкоуровневые части есть и будут
Спор о том что С++ лучше приспособлен для любых больших проектов. С чем мы и не согласны.

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

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

ГВ>[properties]
VD>>Стоит, не стоит. Это удобно и нет ни одного противопоказания. Но в стандрат не вводят. Мелочь конечно, но пративно.

ГВ>Всё равно, не убедительно: зачем они нужны? Только как отображение способа открытия данных, принятого в компонентных моделях?

— Папа! А что такое жопа?
— Сынок. Нет такого слова!
— Странно. Жопа есть, а слова нет.

Вот и со свойсвтвами так же. Понимаешь, ну есть такая сущьность. Создавать современные RAD-среды без них тоже самое, что говорить что "у нас секса нет". В чем проблем признать что то что есть — есть? И просто добавить в язык? К тому же почти все компиляроты С++ свойства (не официально) уже поддерживают.

VD>>Уж извени не восвем я его забыл. Указатели на глобальные фуникции там конечно от С остались, но язык то стал ОО. Страуструп попытался сделать указатели в ОО-стиле но получился жудкий уродец котоый на практике никто не применяет.

ГВ>Я применяю ;)

Интересно для чего?

ГВ>Ну уж! Вознесём молитву делегатам ;) ИМХО, единственное, где они могут облегчить жизнь — это при скрытии деталей реализации вызова с конкретной сигнатурой.

Короче. Я конечно понимаю, что отвыкать от старого (как бы убого оно не было) сложно. Но посмотри правде в глаза. Что тебе не станет проще если колбэк-вызовы для ОО-объектов в С++ станет делать так же просто как это было когда-то на С? И что тебе будет плохо еслит ты сможешь прозрачно использовать такой механизм для вызова удаленных объектов? Или такой механизм повредит самому языку?

ГВ>Кстати — делегаты великолепно создаются и не одним способом при наличии полноценного C++ — компилятора. MSVC6 — отстой полнейший для решения подобных задач. а) Частичного инстанцирования нет, б) через ж... под язык работает со вложенными шаблонами.

И как тебе шаблоны и другая дребедень позволит сделать то о чем мы говорим? Короче, все это вглядет как обычный треп. Вон VC7 и вложенные шаблоны поддерживает. Покажи код упрощающий создание событий. Или вообще покажи как орнанизовать на С++ делегаты. Вот тогда можно удет говрить придметно.

VD>>>>Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

ГВ>>>Ну да, так примерно и есть.

VD>>Где? В Билдере — да. В стандарте — нет.

ГВ>См. выше. Нужен полноценный компилятор. Intel C++ 5.0 подойдёт. Он, кстати, и в среду встраивается.

Куда смотреть? Выше одни рассуждения. Ты бы продемострировал бы принцип хоть. А то на твоем "полноценном" тоже приходится через зад автогеном. :(

ГВ>Сегодня или завтра заброшу свой вариант делегатов на C++.

Интересно будет глянуть. Особо интересно, что станет со строгой типизацией.

ГВ>ИМХО, необходимость их совместной реализации прямо следует из того, что интерейс — группа всё-таки семантически связанных функций. Если не так — то можно попенять на кривое проектирование или неуместное применение интерфейса.

Все верно. Но проблема в том, что интерфейс это по совместительству аналог того самого указателя на метод объекта (экземпляра). Только указатель не на один любой метод, а на группу заранее определенных методов. Вот это и приводит к геморою.

ГВ>Если вставляются где надо и не надо. Думаешь, я сам не хлебал этой каши? :down:

Дык это же все по нужде. Вот я и говорю. Ввели бы указатель на метод обстрактоно объекта. Так чтобы было достаточно только совподения описания методов. Это конечно было бы по слабее чем делегат. Но хоть что-то. А так...

VD>>Главное что нет никакой поддержки компилятора. Нужны всякие кодогененраторв. Ну, и самое противное, что вся хваленая типобезопастность С++ идет под снос. :(

ГВ>Ну правильно, если её сознательно обходить, то...

А ты можешь придложить вариант без объхода?

VD>>Например, в С++ безпроблем можно привести указатель на один объект к указатлю на другой. Все грохнет в рантайме. И грохнет серьезно (обычно AV).

ГВ>Не верю.

Во что? В то что в С++ можно привести что угодно к чему угодно? Ды мы это мигом организуем. :)

ГВ>Потому, что явное приведение типов — всегда небезопасное занятие. То есть, скажем так — "нерекомендуемое". То есть, "делай, но думай, что делаешь".

Дык вот в Шарпе они это дело обазвали unsafe и чтобы такие выкрутасы делать нужно два раза компилятору сказать, о том что ты соображаешь что делаешь. А преобразования по дереву наследования проверяются в рантаймом и полностью безопасны. Введены даже жва удобных оператора "as" и "is". Первый нечто на подобии dinamic_cast<> только работает в 100% случаев, а второй позволяет узнать приводим ли объект к другому. И все это работает для динамически созданных объектов (из других модулей).

VD>> В .NET же в рантайме делаются проверки и неправильное приведение вызовет исключение. Но исключение неправильного приведения типов. Такое исключение легко обработать.

ГВ>С одной стороны, исключение — тот же свал программы, только в профиль, с другой — CLR спроектирован для поддержки "RTTI-oriented"-программирования. Что же тут удивительного?

А это не удивительно. Этог просто в С++ не поддерживается. И к тому же нет понятия RTTI в .NET. Там есть рефлекшон. Это значит, что информацию о типах можно читать не только в рантайме, но и о чужих компонентах и модулях.

VD>>И кое-что было даже включено в язык (динамик_каст), но работает это только внутри одного проекта (т.е. опять же нельзя применять в рантайме).

VD>>В смысле? Я имею в виду, то что С++ идеологически настроен на генерацию кода. И рантай его подсистема заканчивается на CRT.

ГВ>C++ идеологически настроен на разработку цельных

Вот здесь не поспоришь. Правда это не достоиство, а наследие 70-ых годов. :(

ГВ>, устойчивых программ и не его вина, что а) компиляторы через одного поддерживают стандарт на 60%

Его. Его. Язык слишком сложный для парсинга и разбора. Именно из-за этого нет ни одной удачной попытки сделать нормальную визуальную срду разработки. Сравни Билдер и Дельфи!

ГВ> и б) что программисты часто бросаются кодировать до проектирования или боятся перепроектировать "готовую" программу.

Проектировать готовую — это круто. Идея классная, но тут уж точно придется обойтись без С++. :)

VD>>Чтобы понять о чем я говорю, представь сколько кода нужно для вызова метода информация о котором не была доступна во время компиляции? Т.е. на входе есть имя модуля (длл-ки) и нужно дать мозможность вызвать один из методов класса который находится в этом модуле. На C# это пишится за пол часа. На С++ эта задача в общем не решаема. Решить ее можно применяя разные расширения типа COM.

ГВ>А идиома фабрики классов уже отменена? На самом деле, это всё следствия (ИМХО) очень разумной парадигмы C++.

Опять же. Че трепаться. Давай я продемонстрирую код динамически создающий объект и вызывающий у него метод по описанию полученному из фала или из текстового поля. А ты продемонстрируешь аналогичный код на С++. А так это просо пустые разговоры. Я уже 10 лет занимаюсь компонентами на С++ и немного заню на сколько это сложно.

VD>>Согласись, что С++ стал бы только лучше если бы в него добавили бы эти самые делегаты и рефлекшон? Кому от этог хуже.

ГВ>Делегаты отлично добавляются при наличии полноценного компилятора. MSVC6 — увы... :down:

Пока что это опять таки только декларации. Ни одной приемлемой реализации нет. Ты код покажи. Может тебе действительно удастся хоть что-то сделать. К тому же MSVC6 может и не полноценен, но это самы массовый компилятор. И говоря о С++ пока что приходится опираться именно на эту реализацию. Правда на сегодня уже мжно ориентироваться на VC7. В конце концов если твой код заработает хотя бы на семерке, будет уже здорово.

VD>>...Ну, а гибкость?... Дык она в основном нужна там где проблема не решается штатными методами.

ГВ>Штатными методами чего? C#? Java? У них по сравнению с C++ набор штатных методов кастрирован.

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

VD>>Например, на Шарпе можно создать здоровенное приложение ни разу не обратившись к указатлям.

ГВ>Vlad, ну это уже софистика. Знаешь, "на C++ можно создать приложение меньшего размера

Нельзя (меньшего размера).

ГВ> с той же функциональностью, что и написанное на C#". Расскажи: что за приложение, сколько окошек/табличек/кода в нём. Там уже и поспорим.

Я вот тут файловй реплейсер написал. В RSDN Magazin № 1 есть статья о том как это делалось. Такую же программу на С++ я писал бы месяца три. А на Шарпе отнело неделю чистого времени.

VD>>Но как только нужно взаимодействовать с теми же контролами виндовс, как без них не обойтись. Да и вообще становится удобнее писать на С++.

ГВ>???

В смысле прямого обращения к API-шным контролам типа хэадер или дерево. В .NET есть оболочки над ними. Но если вдруг захочется написать свой вариант, то проще взять MC++. Там можно просто пользоваться С-шными хеадерами и писать не CLR-код.

VD>>Ты что рекламу не смотришь? :)

ГВ>Я телевизор вообще стараюсь не смотреть.

:) Ну, это правильно.

VD>>Нет. Это явные недостатки. Причем явно слизанные с Явы и Дельфи. Мы это уже обсуждали. Вопрос в том, что приемуществ явно больше. Да и скорее всего недостатки эти скоро устранят. Уж если Ява дожила до шаблонов... :)

ГВ>ИМХО, всё гораздо гаже. Эти недостатки либо слизаны с компонентной модели, либо внесены из-за желания упростить реализацию рантайма.

Скорее второе. Но движение в правильном направлении есть.

VD>>Ну, дык когда выбор из одного блюда, то думать особо долго не приходится.

ГВ>Вот тут-то и пригодилось бы умени делать индукцию...

Не понял?

VD>>С тачки зрения абстракции COM-интерфейс вещь законченная.

ГВ>То есть, программы, реализующей его методы уже как бы и нет?

Т.е. прогамме использующей его методы уже как бы по фигу как реализован сервер. А серверу как бы по большому барабану как реализован клиент.

ГВ>А как ты думаешь, что мешает применять подобный подход, — с чётким разделением на модули и специфицированием интерфейсов, — при программировани на C++?

Думаю, что не проработанность этого дела в стандарте. Т.е. пока ты пишишь моналитную программу, то можно конечно. Но как ты выходишь за пределы модуля, то придется испльзовать COM или его аналоги (хе-хе).

К тому же в С++ ты можешь начихать на такое разделение, а COM тебя заставляет это делать. Это как бы введение еще одного модификатора — realpublic, т.е. видимый из других модулей.

ГВ>Я уже так сделал. Но элегантно это получается только при наличии полноценного C++ — компилятора. Кстати, вот здесь самый важный вопрос: ты пробовал другие компилеры? Например, Intel? Он только в 2001 вышел (5.0) и, ясно, что многие эксперименты не удались бы принципиально.

Интел я тогда поставил, но в нововедениях не разобрался еще как следует. У меня так же была семерка, но в ней я тоже не нашел нужных вещей. Видимо потому, что их нет в стандарте. Я вообще пока не пойму, что там у тебя за идея. Может покажешь?

ГВ>Признаюсь сразу — на MSVC6 помучился и забросил эту байду после десятого C1001 INTERNAL COMPILER ERROR, а на Intel — вроде получилось.

Дык хоть идею бы показал!

ГВ>Ну, ещё бы. Придётся прятать все указатели/ссылки и т.п. Тут уж, ИМХО, проще C# сделать ;) Просто без GC обойтись можно. Ну да ладно...

Да ничерта делать не пришлось бы. Вообще-то GC можно бы было реализовать и на С++ если бы у него был человеческий рефлекшон и атрибуты.

Ну, а сам GC можно было бы сделать как дополнительное ключевое слово. Вон как в MC++. Помечаешь класс как _gc и пусть за жизнью объекта следит компилятро. Не помечаешь, следи сам...

VD>>>> Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять.

ГВ>>>Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.

VD>>Ну, ну. Можно поглядиеть на клиличество кода, да и на саму идею. Как это сделать без информации о типах?

ГВ>В принципе, да, особено, если предположить, что объект должен извлечься неизвестно откуда. :) Но решить можно.

Такое решение называется COM. О том как в нем для этого извращаются думаю рассказывать не нужно.

В .NET же рефлекшон стандартизировали и обязали к реализации. При этом все CLR-совместимые языки автоматом получают функциональность о которой я говорил.

ГВ>ИМХО, язык должен держаться ещё и за концептуальную целостность. А подсознание у всех разное.

Как показывает практика 90% народа не читавшего (или читавшего не внимально) стандарт удивляются когда видят такое поведение. К тому же нет разумных объяснений почему нельзя создать пост-кострукторы и пре-деструкторы из которых можно было бы производить виртуальные вызовы.

VD>>Это без разницы. Были бы "талантливые" руки. Компонентный же подход как раз и становится выходом когда размеры проета становятся невыносимыми.

ГВ>Примеры! Хочу примеры! Я даже волшеьное слово знаю: пожалуйста.

Примеры? Пожайлуста. Броузер в котором ты сейчас сидишь. Он воспринимает html как дерево компонентов. Если начать парсить html то появится каша которую сможет разобрать далеко не каждый программист. Когда же все представлено в виде компоненов, то этот процесс даже можно визуализирвать.

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

Таким образом за один проект можно посадить море программистов/проэктировщиков и они смогут создать единый продукт.

VD>>>>А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище.

ГВ>>>Видел. То, как их реализуют мне тоже не понравилось.

VD>>Так может дело в людях?

ГВ>ИМХО — YES!!!

Ну, вот хоть на чем-то сошлись. :)

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

IT>Странный ты человек. Тебе говорят люди, которые писали, пишут и собираются продолжать писать на C++, говорят, что этот язык уже не самый крутой и он уже давно не воплащает самые современные идеи. Заметь, что никто не говорит, что C++ плох, говорят только, что есть языки не хуже, а местами даже лучше и более пригодные для решения большинства сегодняшних задач.

Более того. Я бы хотел видеть в одном языке все приемущества вышеупомянутых. Т.е. хочу C# с шаблонами и подключением реализаций (вместо множественного наследования).

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

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

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


A>как насчет быстрого преобразования Фурье на Клиппере?
A>когда люди сильно увлекаются чем-то новым они пытаются пихать это новое
A>везде где можно.

А вот чистые алгоритмы могут оказаться на Яве или Шарпе быстрее чем на самых крутых Интеловских компиляторах. Там ведь никаких обращений к внешниму миру. Один вичисления. Тут как раз джиты рулят.

A>кстати M$ мог бы создать новый рынок железа продвигая .NET. например
A>стимулировать создание процессора напрямую исполняющего MSIL

Ну, это довольно утопично. Железо делается для получения максимлаьной произодительности. Интерпретация спец. процессорами — это (по-моему) не верный шаг. Хотя для явы это кое где используется.

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

A>мои знакомые работают в DirectX

Дык сам бох велел.

A>, Visual Studio

Уже половина визардов на Шарпе. Дальше думаю будет больше.

A>, Commerce Server и MS Office team.

Офис тоже вроде на .NET хотят переводить.

A>везде C++. насколько я знаю под .NET пока только BizTalk пишут.

BizTalk межу прочим сервер. Это уже серьезная разработка. Лиха беда начало...

VD>>А полностью не будет никогда. Драйверы и ядро все одно на С/С++ с асм-мом писать будут. Ну, а >многие прикладные части должны быть переписаны.

A>дык спорим то о чем? я ж не говорю о том что C# хуже/лучше а о том что для С++ всегда
A>будет место в больших проектах. GUI возможно перестанут на нем писать, но какие-то
A>низкоуровневые части есть и будут

Ну, дык с этим я полностью согласен.

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

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

VD>>Более того. Я бы хотел видеть в одном языке все приемущества вышеупомянутых. Т.е. хочу C# с шаблонами и подключением реализаций (вместо множественного наследования).
AVK>Ну если немножко извратится то подключение множественных реализаций можно и на шарпе сделать. Правда только в рантайме, но автоматически.

Уж слишком приходится извращаться. А вещь нужная постоянно. Особенно при разработке базовх классов.

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

VD>Уж слишком приходится извращаться. А вещь нужная постоянно. Особенно при разработке базовх классов.
Ну пользователю этого дела сильно извращаться не нужно, достаточно разметить класс-хозяин атрибутами. Не сильно сложнее чем в Дельфи.

VD>А вот чистые алгоритмы могут оказаться на Яве или Шарпе быстрее чем на самых крутых Интеловских >компиляторах. Там ведь никаких обращений к внешниму миру. Один вичисления. Тут как раз джиты рулят.

спорный факт. производительность алгоритмов с мощной математикой зависит прежде всего от возможностей процессора с плавающей точкой и как компилятор генерит оптимизированный для него код. вряд ли JVM-инструкции создавались под цель оптимизации FP-операций. про MSIL не в курсе. возможно там с этим делом лучше.

VD>Ну, это довольно утопично. Железо делается для получения максимлаьной произодительности. >Интерпретация спец. процессорами — это (по-моему) не верный шаг. Хотя для явы это кое где >используется.

для Java точно делали. но применяется ли это промышленно? мне кажется имеет смысл в мобильных девайсах типа сотовых телефонов или палмов

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

[...]

ГВ>>Ну уж! Вознесём молитву делегатам ;) ИМХО, единственное, где они могут облегчить жизнь — это при скрытии деталей реализации вызова с конкретной сигнатурой.

VD>Короче. Я конечно понимаю, что отвыкать от старого (как бы убого оно не было) сложно. Но посмотри правде в глаза. Что тебе не станет проще если колбэк-вызовы для ОО-объектов в С++ станет делать так же просто как это было когда-то на С? И что тебе будет плохо еслит ты сможешь прозрачно использовать такой механизм для вызова удаленных объектов? Или такой механизм повредит самому языку?

ГВ>>Кстати — делегаты великолепно создаются и не одним способом при наличии полноценного C++ — компилятора. MSVC6 — отстой полнейший для решения подобных задач. а) Частичного инстанцирования нет, б) через ж... под язык работает со вложенными шаблонами.

VD>И как тебе шаблоны и другая дребедень позволит сделать то о чем мы говорим? Короче, все это вглядет как обычный треп. Вон VC7 и вложенные шаблоны поддерживает. Покажи код упрощающий создание событий. Или вообще покажи как орнанизовать на С++ делегаты. Вот тогда можно удет говрить придметно.

Посмтори в конференции "Программирование \ C/C++" ;)
URL: http://www.rsdn.ru/forum/message.asp?mid=91643&amp;only

Автор: Геннадий Васильев
Дата: 28.08.02

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

VD>>>Вот народ потрахался и стал изобретать разные Явы и .NET-ы...

A>>имхо. слишком много "левого" народу пришло в программирание.
A>>это я не об участниках этого форума, а вообще. изобретение удобных средств RAD,
A>>языков с упрошенными типами которые не надо описывать и которые сами освобождают
A>>память и т.д.... это все хорошо но уже после того как ты прошел "трудный путь"
A>>ассемблера и C. . получается так что программистами себя считают те кто
A>>прошел курс "освой программирование за 21 день" и что-то вроде этого.

IT>Я не считаю, что это лишние люди. Просто характер отрасли меняется.
IT>Когда-то "радиолюбители" — это были такие редкие люди, которые слушали радио с помощью допотопных самодельных приемников. Сегодня их ПРОСТО НЕТ. Потому что радио может слушать каждый, купив FM-приемник. Часть радиолюбителей теперь условно "делает эти приемники".

IT>То же самое — с автомобилистами. Да с любой наверное достаточно новой отраслю — начиная от использования узким кругом людей, которые понимают все в отрасли и заканчивая самым широким применением людьми, которые совершенно не знают "а что внутри".

IT>Это не плохо и не хорошо, а похоже на закон. Потенциально программирование вообще может умереть с созданием очень развитого искусственного интеллекта.

IT>Кто что думает по этому поводу?

Я думаю, плохая у тебя получилась аналогия.

"Радиолюбители" ЕСТЬ И СЕГОДНЯ. И все так же слушают радио с помощью самодельных приемников. Вот только самодельный приемник стало возможным собрать, прикрутив к какой-то микросхемке батарейку, динамик, и пару деталей для настройки на волну (а может и просто пару кнопочек). Но люди все равно собирают сложные системы. Которые могут делать то, то, и вот это. Им просто нравится. И такая возможность у них есть.

Автомобилисты. Ну, тут с радиолюбителями вообще никакой аналогии. Автомобилисты — это вообще чистой воды "пользователи". С программистами тоже параллель весьма смутная. Как-то я уже здесь возмущался тем, что Шумахер, мол, должен знать, как у Феррари двигатель устроен...

Программирование умрет только тогда, когда этот самый искусственный интеллект научится творить интеллект, более высокоуровневый, чем он сам. Да и вообще... А хоть кто-нибудь нужен будет этому ИИ? Рекомендую пересмотреть "Матрицу"...

Вот так вот примерно я думаю...

P.S. Ну и задолбался же я эту тему читать!!!

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

A>а 15 лет назад и "юзеров" не было. компьютеры были достоянием узкого круга инженеров,
A>которые сами являлись и программистами и пользователями
A>при этом понятие "пользовательский интерфейс" отсутствовало напрочь — программа просто скидывала результат в файл или на принтер.

Да ладно! 15 лет назад уже персоналки были...

A>>при этом понятие "пользовательский интерфейс" отсутствовало напрочь — программа просто скидывала >результат в файл или на принтер.

TL>:) Да ладно! 15 лет назад уже персоналки были... :))

быть то они были но не у массового пользователя
одну на лабораторию выпросить — и то проблема была деньги
выбить ибо стоили они в 2 раза больше чем автомобиль.

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


TL>P.S. Ну и задолбался же я эту тему читать!!!


Та же фигня

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

A>не пугайте человека. C++ жил жив и будет жить. мир программирования не ограничивается .NET. есть еще обработка звука, графика и видео, ОС реального времени, встраиваемый embedded-софт, программирование драйверов, межпроцессные и сетевые коммуникации и еще наверное куча областей где C++ незаменим.

"Незаменимых у нас нет!"@Сталин И.В.

WBR
Vladimir Bychkov

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

IT>VM Size показывает распределённую приложению память, включая своп и мап-файлы. Откуда следует, что 50 мег может легко набежать не за счёт свопа, а за счёт того, что Windows мапит файлы, которые могут понадибиться для работы сборок. Что такое маппинг и как он использует память я, недеюсь, тебе объяснять не надо.

Это не оно. Сейчас смотрел на премере Together у него 700Mb адресного пространства,
из них 102Mb лежит как Private Pages и именно они показываются в Task Manager как
VM Size. Так что это не Mapping — это честный swap.

A>>>>Стабильная утечка памяти 10K в минуту элементарно отлавливается(Bounds checker еще никто не отменял)
AVK>>>Увы, это не так.
A>>Хм. Видимо зависит от программиста, у нас не так.

IT>Вот как-то мне не понравился тон этого сообщения... как-то сквозь него пальцы проглядывают...

Это не пальцы, это просто наезд, притом в достаточно культурной форме.
Человек мне объясняет, что я не могу писать без утечек памяти, это помоему для
плюсового программера еще больший наезд.

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

IT>>VM Size показывает распределённую приложению память, включая своп и мап-файлы. Откуда следует, что 50 мег может легко набежать не за счёт свопа, а за счёт того, что Windows мапит файлы, которые могут понадибиться для работы сборок. Что такое маппинг и как он использует память я, недеюсь, тебе объяснять не надо.

A>Это не оно. Сейчас смотрел на премере Together у него 700Mb адресного пространства, из них 102Mb лежит как Private Pages и именно они показываются в Task Manager как VM Size. Так что это не Mapping — это честный swap.

Я как-то свой формат БД делал на мап-файлах, так VM Size для только что запущенной программы был больше 300 мег, при этом памяти на машине всего было 16М. Всё работало быстро, ничего не тормозило, из чего следует что VM Size это всего лишь помеченная системой память, которая возможно понадобится программе.

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

IT>Я как-то свой формат БД делал на мап-файлах, так VM Size для только что запущенной программы был больше 300 мег, при этом памяти на машине всего было 16М. Всё работало быстро, ничего не тормозило, из чего следует что VM Size это всего лишь помеченная системой память, которая возможно понадобится программе.

Не верю. У тебя же стоит Visual Studio на машине? Запусти Process Viewer и посмотри Memory Details. Увидишь что параметр который показывается как VM Size это на самом деле Private Pages в разделе Virtual Memory Count. При этом у меня например прога которая там показывает 700K, при этом Working Set у нее 2396K, а Virtual Size 26192K.

Надо смотреть исходники твоей проги для того чтобы точно понять как она память расходует, я может быть такую же напишу потом чтобы проверить.