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

RO>Итак, единственным обсуждаемым недостатком C++ оказалось отсутствие GC

Автор: jazzer
Дата: 02.06.08

из обсуждений касаемо GC мне понравилось вот это.

RO>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

Это ОЧЕНЬ богатая удобная вещь. Имхо, вещь много ценнее GC.
На РСДНе же был очень вдохновенный пост

Автор: IT
Дата: 13.01.04

на эту тему:

...
Начнём хотя бы с того, что ты слабо себе представляешь что такое рефлекшин. Рефлекшин — это такая штука, Рома, которая предоставляет исчерпывающую метадату о твоём приложении. С помощью рефлекшина ты можешь исследовать структуру любого типа, любой сборки вдоль и поперёк. IDispatch & ITypeInfo со своими возможностями рядом даже близко никогда не стояли. Добавим сюда возможность расширять метаданные с помощью атрибутов и, в результате, имеем ещё одно дополниетельное измерение. Как им распорядиться это уже дело твоей фантазии. Например, студия умеет распознавать и использовать твои собственные редакторы для твоих же объектов. Веб-сервисы используют атрибуты для отделения веб-методов от остальных процедур, для управления параметрими сессии и куками и т.п. Сериализаторы полностью настраиваются с помощью атрибутов. Защита, управление компиляцией и отладкой, всё это может свободно управляться с помощью атрибутов.

В числе прочего атрибуты(часть рефлекшена) кажутся очень неплохим нововведениям.
Вот маленький пример:

    public class FooModel
        : BaseModel
    {
        [XmlElementAttribute(ElementName = "h")]
        [DisplayName("Height")]
        [Description("Height of the Foo Model")]
        [Category("Model's Geometry")]
        public int Height
        { get/set... }

        [XmlElementAttribute(ElementName = "w")]
        [DisplayName("Width")]
        [Description("Width of the Foo Model")]
        [Category("Model's Geometry")]
        public int Width
        { get/set... }

        [XmlElementAttribute(ElementName = "name")]
        [DisplayName("Name")]
        [Description("Name of the Foo Model")]
        [Category("General")]
        public string Name
        { get/set... }
    }

Что это дают эти атрибуты? Если вкратце — настраиваемую сериализацию, возможность истинного отделения представления от модели (т.е. крайне легкое написание визуального компонента редактирования/отображения основываясь только на концепции атрибутов).

В качестве маленького примера — для того, чтобы показать наш объект на стандартном компоненте — страницах свойств (PropertyGrid) достаточно выполнить только одно присвоение объекта свойству SelectedObject:

mPropertyGridObject.SelectedObject = mFooModel;

Этим, конечно же, не исчерпывается возможности сериализации

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

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

SI>>Ко всему прочему стоит заметить, что, видимо, написание аналогичного кода на С++ потребует большей подготовки и большей квалификации девелопера.

GN>Потому, что С можно изучить за 2 дня, а С++ "несколько" дольше? Значит, для библиотечного кода — да, для пользовательсокго кода — наоборот. Как минимум, квалификация С кодера должна быть таковой, что он не имеет права забыть освободить любой ресурс. Тоже самое делает RAII...

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

SI>>Элементарно простой пример: std::map (а так же, например, стандартнуя реализация AVL tree) нельзя (ну или скажем, неблагоразумно) использовать в коде ядра. Насчет Windows не уверен, но в Linux'е точно.

GN>В чём проблема то, в памяти? Это обычный trade-off — стоит или нет, решает пользователь. Или у Линуса не получилось в 92м году? Тут есть один нюанс — подобный биржевым медведю и быку — мнение может быть не объективно.

В размере стека в ядре. В линуксе, как правило, он совсем небольшой — вроде всего одна страница — 4096 байт. В то же время указанные вещи (RB и AVL деревья) используют (во многих реализациях) рекурсивные алгоритмы вставки и удаления.

SI>>Вот, к примеру, память в ядре линукса экономится настолько сильно, что нужно помечать инициализирующую функцию и данные для инициализации в модуле ядра специальными ключами (__init/__initdata вроде), которые помещаются линкером в специальную секцию ELF файла, которая будет удалена после инициализации модуля ядром.

GN>В виндосе так же, плюс еще разделение на (non)pageable секции. Это, кстати единственное непреодолимое ограничение для С++ — нельзя сделать для функций с C++ linkage. Можно конечно делать обходные манёвры с обертками на С... Но, как правило, забивают, если пишут на "С с классами". Вообще, непоняно, почему еще не доработан транслятор



SI>>Нет, ну почему же нету, есть, только по стандарту ISO C89 (если не изменяет память). Нету <stdbool.h> и иже с ним, возможности объявлять переменные не только в начале функции и ряда других вещей.

GN>Угу, чего только нет: этого нет, того нет
... а то, что есть — бажное и недоделанное
Вот меня бесит, почему в стандарт не включили #pragma once? Это мелочь конечно, но нафига каждый раз изобретать новый макрос?

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

SI>В размере стека в ядре. В линуксе, как правило, он совсем небольшой — вроде всего одна страница — 4096 байт. В то же время указанные вещи (RB и AVL деревья) используют (во многих реализациях) рекурсивные алгоритмы вставки и удаления.
Сколько деревьев видел/писал — ни в одном при insert/erase не была использована рекурсия. Да и не нужна она там.
Единственное применение рекурсии там могу придумать только когда надо грохнуть все дерево/ветку. Но даже в этом случае можно обойтись без рекурсии.

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

TC>Тут кстати, есть один из подводных камней: если используются полиформные классы — не очень понятно, как управлять положением vtbl, а то может ( чисто принципиально ) получиться нехорошесть — экземпляр класса находиться в NonPaged памяти, а vtbl в Paged с возможными плачевными последствиями.

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

TC> Я лично когда юзал С++ ( сейчас отказался от этого )

Почему, если не секрет?

TC>в ядре писал __declspec(novtable) — чтобы даже руки не чесались .

Впринципе можно в (дебажном) operator new поверить, в какой секции VTbl. Где-то может и static_assert(std::is_polymorphic<T>) ( __is_polymorphic(T) ) пригодиться...

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

SI>введение дополнительных слоев абстракции с помощью таких конструкций С++, как классы и шаблоны необходимо очень четко знать, что внутренности этой абстракции будут безопасны во всех случая ее использования

Я именнно это и имел ввиду, упоминая "библиотечный код". Там — да. Но порог вхождения (и, как следствие, общая стоимость разработки) понижается, поскольку пользователи этой библиотеки в определённых случаях могут вообще ничего не понимать в ядре. Им достаточно знать С++ (а стало быть и стандартную библиотеку).

SI>В размере стека в ядре. В линуксе, как правило, он совсем небольшой — вроде всего одна страница — 4096 байт. В то же время указанные вещи (RB и AVL деревья) используют (во многих реализациях) рекурсивные алгоритмы вставки и удаления.

Даже в общем случае: стек для рекурсии — это не обязательно стек процессора. Например, рекурсия, реализованная через for() не его использует

SI>Вот меня бесит, почему в стандарт не включили #pragma once? Это мелочь конечно, но нафига каждый раз изобретать новый макрос?

Что бы можно было этот макрос проверить в других файлах

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

RO>>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

SI>Это ОЧЕНЬ богатая удобная вещь. Имхо, вещь много ценнее GC.
SI>В числе прочего атрибуты(часть рефлекшена) кажутся очень неплохим нововведениям.
SI> [XmlElementAttribute(ElementName = "h")]
SI> [DisplayName("Height")]
SI> [Description("Height of the Foo Model")]
SI> [Category("Model's Geometry")]
SI> public int Height
SI> { get/set... }

Я видел такое и раньше. Меня всё время смущало, что будет, если нужно отображать один и тот же класс в разных элементах управления, или если его нужно уметь класть в файлы разной структуры (разные XML, или что-нибудь вроде CSV, или S-выражения и т. п.)? Или просто перевести Description и Category на другой язык?

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

J>Но это не эффективность прототипа, конечно
Вот и я про то же

J>ну да, и везде чтоб только они и летали, и не дай бог ссылку передать, и чтоб атрибуты сами тоже указателями были и, соответственно, конструкторы из гроздьев new состояли + конструкторы копирования и операторы присваивания везде придется руками организовывать, чтоб было глубокое копирование, потому что те, что по умолчанию генерятся, никак с смарт-поинтерами не дружат, и так далее...
А ты напиши себе удобный смарт-поинтер. И будет тебе тут же счастье, IMHO...

Кстати говоря, вообще-то вопрос о том глубокое копирование надо в этом конкретном месте или нет, довольно небанален. И в скриптовых языках тоже нерешается, в отличии от C++, кстати...

J>Потому что в плюсах чтоб просто, например, распечатать нечто (в прототипах печатать много приходится, не все ж под дебаггером запускать), надо присесть двадцать раз, а в скрипты все это встроено сразу (помнишь такой чудо-синтаксис: "asd $qwe zxc $qweqweqwe"?)
Да в плюсах тоже вроде бы печатать всё удобно... Ещё и формат задавать просто.
Правда я в прототипах и эксперементах никогда не печатаю, так вот просто. Обычно пишется довольно сложно устроенный "деревянный" лог, к которому есть вьюшка, которая поддерживает небанальную по себе навигацию, и нетривиальные отображалки. IMHO очень удобно, кстати...
Если уж у тебя задача прототипирования стоит во весь рост, то возьми какой-нибудь тулкит для этого, или сам напиши. Вот это и будет С++-way...

J>Чего о С++ не скажешь, сила С++ совсем в другом: возможность сваять что угодно любой сложности, а вот цена ваяния — дело десятое.
Ну если тебе надо решать задачи, под которые заточен пёрл, то не вопрос, С++ тебе не нужен конечно. Но GC тут не при чём, при этом.
А вот если тебе нужно решать какие-то сложные задачи, да ещё и сложную архитектуру к этому привинтить, то пёрл тебе точно не подходит. Я бы ещё понял прототипирование на прологе или лиспе, скажем, но на пёле --

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

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

RO>>>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

SI>>Это ОЧЕНЬ богатая удобная вещь. Имхо, вещь много ценнее GC.
SI>>В числе прочего атрибуты(часть рефлекшена) кажутся очень неплохим нововведениям.
SI>> [XmlElementAttribute(ElementName = "h")]
SI>> [DisplayName("Height")]
SI>> [Description("Height of the Foo Model")]
SI>> [Category("Model's Geometry")]
SI>> public int Height
SI>> { get/set... }

RO>Я видел такое и раньше. Меня всё время смущало, что будет, если нужно отображать один и тот же класс в разных элементах управления, или если его нужно уметь класть в файлы разной структуры (разные XML, или что-нибудь вроде CSV, или S-выражения и т. п.)? Или просто перевести Description и Category на другой язык?

Справедливый вопрос.
Ну вот более подробный пример (здесь вместо сериализации я представил вывод полей некоего объекта на экран):

// FooModel.cs

using System;
using System.ComponentModel;

namespace CsReflectionTest
{
    class FooModel
    {
        int width;
        int height;
        string name;


        // assign specific display name attribute to the FooModel.Width prop.
        // instead of DisplayName other Attribute's descendant can be used.
        [DisplayName("SuperMegaWidthOfFoo")]
        public int Width
        {
            get { return width; }
            set { width = value; }
        }

        public int Height
        {
            get { return height; }
            set { height = value; }
        }

        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        public FooModel(int w, int h, string n)
        {
            width = w;
            height = h;
            name = n;
        }
    }
}

// Program.cs

using System;
using System.Reflection;
using System.ComponentModel;

namespace CsReflectionTest
{
    class Program
    {

        static void OutputSample(object model)
        {
            Type modelType = model.GetType();
            PropertyInfo[] modelProperties = modelType.GetProperties();

            foreach (PropertyInfo propInfo in modelProperties)
            {
                // all our data memebers shall have a display name attribute
                object[] attrs = propInfo.GetCustomAttributes(
                        typeof(DisplayNameAttribute), // type of attribute we want to see
                        false // inherit?
                        );

                string propertyDisplayName;

                if (attrs.GetLength(0) > 0)
                {
                    // for this property there is an assigned specific name
                    DisplayNameAttribute a = (DisplayNameAttribute)attrs[0];
                    propertyDisplayName = a.DisplayName;
                }
                else
                {
                    propertyDisplayName = propInfo.Name;
                }

                object propertyValue = modelType.InvokeMember(
                    propInfo.Name, BindingFlags.GetProperty, null, model, null);

                Console.WriteLine("{0} -> {1}", propertyDisplayName, propertyValue);
            }
        }

        static void Main(string[] args)
        {
            FooModel f1 = new FooModel(12, 34, "foo1");

            OutputSample(f1);

            Console.ReadLine();
        }
    }
}

Здесь основной интерес представляет функция OutputSample. Она довольна проста — пробеаем по всем свойствам объекта, извлекаем атрибут DisplayName(можно любой другой — некий user-defined например) и вызываем это свойство у объекта.

Вывод программы:

SuperMegaWidthOfFoo -> 12
Height -> 34
Name -> foo1

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

CC>Сколько деревьев видел/писал — ни в одном при insert/erase не была использована рекурсия. Да и не нужна она там.
CC>Единственное применение рекурсии там могу придумать только когда надо грохнуть все дерево/ветку. Но даже в этом случае можно обойтись без рекурсии.

Да я ж не спорю — есть нерекурсивные алгоритмы, слава Богу. Но во многих книжках — Н. Вирт "Алгоритмы и структуры данных", например, я не видел нерекурсивный алгоритм вставки-удаления для того же AVL дерева.

Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?

Если в стандарте написана явно рекомендация-требование к такой реализации деревьев для map/set, тогда прошу меня простить

Щаз придёт Котд и всё разрулит! И вас помирит!

"Roman Odaisky" <48787@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:2972943@news.rsdn.ru...
> На C++ пишут меньше прикладных программ, чем он того заслуживает, в первую очередь потому, что мало хороших прикладных библиотек. А вот хотелось бы выяснить: если бы на C++ были удобные библиотеки для всего-всего, то все перешли бы (обратно) на C++, или индусы в любом случае будут продолжать писать на Java, Python и т. п., потому что там сложнее обстрелять свои ноги? Для каких задач C++ останется неприменим даже с самыми лучшими библиотеками?

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

SI>Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?
Ну, я просто удивлялся. Потому как рекурсивно работать с деревьями ИМХО это как то очень дубово в большинстве случаев.

SI>Если в стандарте написана явно рекомендация-требование к такой реализации деревьев для map/set, тогда прошу меня простить
Не, не написана.

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

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

SI>>Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?
CC>Ну, я просто удивлялся. Потому как рекурсивно работать с деревьями ИМХО это как то очень дубово в большинстве случаев.

Между тем в ФП только рекурсивно и работают

You will always get what you always got
  If you always do  what you always did

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

SI>>>Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?
CC>>Ну, я просто удивлялся. Потому как рекурсивно работать с деревьями ИМХО это как то очень дубово в большинстве случаев.

J>Между тем в ФП только рекурсивно и работают ;)

Там преимущественно хвостовая рекурсия.

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

J>Между тем в ФП только рекурсивно и работают
так то ж в ФП.
Там почти все через ж.... пардон, рекурсию

GN>По умолчанию, весь код идет в невыгружаемые секции PE. То есть, нужно специально написать свободные функции, поместить их в выгружаемые секции и вызывать их из функций-членов, что бы споткнуться?

Естественно. Маленький драйвер наверное и не нуждается в подобной оптимизации ( разделение на выгружаемые и не выгружаемые функции ). А если проект большой, то довольно вероятен такой сценарий: сначала делали все в NonPaged. Сделали. Отладили. Занялись оптимизацией. Расставить прагмы вокруг функций, содержащих отладочный макрос PAGED_CODE, дело не хитрое. А вот после этого может начаться та самая ж..а.

TC>> Я лично когда юзал С++ ( сейчас отказался от этого )
GN>Почему, если не секрет?

1)
А потому что, когда писал на С++ занимался не кодированием, т.е решением конкретной задачи, а постоянными размышлениями — как бы это написать на С++? Почитайте форум, половина вопросов в стиле "как бы так выпендриться, чтобы заставить данный код работать"? Мне нравится С — там есть все, чтобы писать простой и понятный всем код и он не занимает мой мозг синтаксическими извращениями и размышлениями, как лучше сделать. Кроме того, драйвера — достаточно простые с точки зрения алгоритмов и типов данных программки. При этом повторяемость кода — нулевая практически. Пишу я драйвер всегда один. На что мне полиморфизм? На что мне наследование? На что мне инкапсуляция? На что мне паттерны проектирования, если я сам себе гуру в своей области?

2)
Нет СТАНДАРТНЫХ библиотек. Чужие велосипеды даже не рассматриваются ( я никогда даже не смотрю на библиотеки вроде "вот, создал свой фреймворк для ядра" ), не хватало потом чужие баги по крешдампам искать. Я ради интереса собирал драйвера с STL контейнерами, но как то это стремно. Кроме того, как сделать, чтобы STL нормально работал в условиях отказов в выделении памяти? При том, что обработка исключений — невозможна. Кроме того, большая часть стандартной библиотеки — это всякие классы для потокового ВВ, на что мне это добро в ядре?

Короче, нет весомых плюсов у плюсов в моем нелегком деле. Это как раз та нишка, где остался чистый С. Век плюсов тоже прошел, вытеснят их в нишку анализа текста. Чего бороться за мертвеца? Если у меня будет времячко, я буду C# изучать, ибо лет через 10 закончится наконец то век слоноподобных ОС со всеми этими процессами и виртуальными памятями. Вендекапец будет вместе с линухкапцом — эти два урода-близнеца тоже близятся к своему климаксу. . Будущее — это платформы виртуализации и управляемый код. Window, Linux, C++ — в кочегарку, там знают что с ними делать.

Здравствуйте, TarasCo, Вы писали:
GN>>Почему, если не секрет?

TC>1)
TC>А потому что, когда писал на С++ занимался не кодированием, т.е решением конкретной задачи, а постоянными размышлениями — как бы это написать на С++? Почитайте форум, половина вопросов в стиле "как бы так выпендриться, чтобы заставить данный код работать"? Мне нравится С — там есть все, чтобы писать простой и понятный всем код и он не занимает мой мозг синтаксическими извращениями и размышлениями, как лучше сделать. Кроме того, драйвера — достаточно простые с точки зрения алгоритмов и типов данных программки. При этом повторяемость кода — нулевая практически. Пишу я драйвер всегда один. На что мне полиморфизм? На что мне наследование? На что мне инкапсуляция? На что мне паттерны проектирования, если я сам себе гуру в своей области?
А почему нельзя писать на плюсах просто? Без заморок, STL, исключений и полиморфизма?
Уже проверка типов + ООП довольно много. + простые понятные шаблоны -- ещё больше...
Какой смысл исползовать С вместо С++, используемого, как "С с классами"?

Здравствуйте, TarasCo,

Спасибо, в первую очередь интересны "пессимистичные" точки зрения
Сначала написал развёрнутый ответ по-пунктам, но мне не интересен "спор", поэтому решил попробовать выделить главное:

Итак, фреймворки для ядра не нужны (это конечно не относится к тому что двигает MS ).

Могут быть полезны стандартные кирпичики — а именно STL часть, string library, что-то еще (атомарные типы из нового стандарта). Но, что бы этим можно было спокойно пользоваться, нужно имплементировать нормальный __CxxFrameHandler (который не будет завязан на TLS)

Правильно?

---

Что же до перспектив С++ в не столь отдалённом будущем — я совершенно спокоен, MS давно похоронили С, но заметно вкладываются в С++. Поживём, увидим... пока я угадал судьбу Itanic'а и про дотнет в ядре Vista

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

TC>Вендекапец будет вместе с линухкапцом — эти два урода-близнеца тоже близятся к своему климаксу. . Будущее — это платформы виртуализации и управляемый код. Window, Linux, C++ — в кочегарку, там знают что с ними делать.

Смешно. История деляет полный круг и возвращается к VM/CMS

Я думаю, будушее принесет нам осознание, что 1) пользователю все равно, какое там у ОС ядро, линух ли, BSD, или MS-DOS на стероидах. Пользователь пользуется приложениями, а не ядрами 2) приложения нуждаются в более высокоуровневой прослойке, чем API, предлагаемый современными OS. Грубо говоря, война OS кончится тем же, чем война бровсеров: как сейчас более-менее любой сайт можно открыть в любом бровсере, так через N лет любое приложение можно будет запустить на любом компутере с любой OS, лишь бы хватило памяти и мегагерцев.