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

E>>Ты считаешь, что по одной статье можно узнать инструмент. Я с этим не согласен.

VD>Я считаю что по одной статье можно узнать список задач которые решает инструмент и понять целесобразно ли его писать на С++.

Ну да, ты же у нас провидец. Извини, совсем забыл.

VladD2 wrote:
> И видимо именно по этому есть языки спокойно обходящиеся без mutable.
А еще есть языки, обходящиеся без типов вообще. И что?

IT wrote:
> C>Берем Comet (генерирует чистый С++, даже на GCC работает) — и видим,
> что свойства совсем и не нужны на самом деле.
> Т.е. ты решаешь за меня нужны мне свойсва или не нужны?
Ну должен же кто-то решать?

Свойства — это не более чем простенький синтаксический сахар. Причем
сахар с солью (как взять ссылку на свойство?).

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

E>>Mutable -- это фундаментальная особенность, она нужна для любой предметной области, чтобы не прибегать к хакам.
E>>Свойства -- напротив. Лямбды так же нужны не всем.

IT>Гениально! Если так рассуждает консенсус комитетчиков, то многое становится ясным.

Блин, так об этом я тебе и твердил все это время. Комитет не выбирал самые популярные решения или решения, восстребованые или модные в данный момент времени.

IT>Значешь какую ошибку я считаю самой серьёзной и непростительной при разработке чего-либо? Это попытка решать что юзеру нужно, а без чего он обойдётся, решать, не спросив об этом самого юзера.

Ты думаешь, что я буду тебе возражать? Не буду, потому что ты практически на 100% прав.
Есть только один ньюанс: юзеры у C++ были (да и есть сейчас, вероятно) слишком уж разнополярными. Как ни крути, а у разработчиков систем реального времени и сетевых маршрутизаторов требования к языку совсем другие, чем у разработчиков графических САПР и систем документооборота. В таких условях принцип "и вашым, и нашим" ведет к слишком громоздкому языку, принцип "тем, кого больше" ведет к оттоку части пользователей, а самым жизненым является "ни вашим, ни нашим". Что в итоге в C++ и получилось.

Нравится ли это мне и считаю ли я сам такое положение вещей правильным? Нет, мне это не нравится. И сомневаюсь, что это правильно. Тем не менее, так есть объективная реальность с которой приходится считаться.

IT>Свойства во многих языках используются уже много лет и очень хорошо себя зарекомендовали. Полноценные лямбды в C# я, например, жду с нетерпением, а пока во всю используют анонимные методы. А вот mutable в .NET совсем отсутствует, и никого это сильно не напрягает. В Java, кстати, тоже как-то без mutable нород живёт.

Так ведь в Java, помниться, ни лямбд, ни делегатов нет вовсе. И ничего, наличие огромного community Java программистов доказывает, что не так это уж необходимо.

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

E>>Если хеш хранится в объекте в виде атрибута, то как этот атрибут будет изменяться константным методом объекта для константного же объекта?

VD>А зачем его делать константным? Еще раз название константный — это бред созданный Страуструпом.

Умеете вы не обращать внимание на реальность. В C++ есть такое понятие, как модификатор const. Поэтому, если в коде присутствует:

void process( const Actor & a ) { ... }

то в process() компилятор позволяет вызывать только те методы, которые помечены как const. Бред это или нет -- уже не важно. Важно, что это есть. Следовательно, возникает вопрос, что делать, если метод Actor::hash() помечен как константный, но будет вычислять и сохранять значение хеша только при первом обращении. Как Actor::hash() изменит атрибут объекта, если this в hash() имеет тип const Actor *?

Можно либо прибегнуть к хаку, сняв константность через приведение типа, либо использовать модификатор mutable. Последнее решение дает корректный с точки зрения языка результат. Опять же, речь идет о C++, в котором const есть. Следовательно, mutable решает фундаментальную проблему языка, которая возникла после поддержки const-ов.

А если в языке const-ов нет, то нет и проблемы. И понять необходимость mutable не представляется возможным.

VD>Неизменяемый объект — это дизайн, а не атрибут. Я на C# без проблем делаю неизменямые объеты и уверен в их неизменности. А вот на С++ при наличии const я все равно ни в чем не уверен.

E>>Это та же самая задача, словесную формулировку которой вы с IT просили у меня.

VD>И в чем проблемы бло дать словесное описание?

Потому что описание было дано сразу же, когда IT спросил, где я использую mutable.

VD>А есть ли разница? В конце концов данным можно держать и вне объекта, а в объекте держать их индекс в неком массиве. Тогда останется только сделать в конструктре приращение счетчика.

Да уж, просто пример правильного объектно ориентированного дизайна. Специфические данные одного объекта рассовываются по вспомогательным таблицам. Таки отличное структурное и модульное программирование. С особым уважением к многопоточности.

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

IIT>Забавные тесты. Правда фортрана я там не нашёл. Зато обнаружил, что преславутые Руби и Tcl уверенно замыкают список практически во всех тестах, отставая от лидеров в десятки и сотни раз, а порой вообще имеют timeout.

Плохо искал? Мне сразу 2 фортрана попалось: Fortran G95 (хз че за зверь), Fortran Intel

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Спасибо. Уже сам посмотрел. Пользовать в случае крайней необходимости... (Вот интересно всякие отображалки (типа Console.WriteLine и Graphics.DrawString) нормально переваривают такие символы?)

Консоль использует кодоввые страницы. Например, по умолчанию используется 886 или что-то вроде этого. В бэтах студии были глюки, так как консоль переправляли в окно, а там была не та раскладка. Я на время отладки включал раскладку 1251.

Graphics должен поддерживать Юникод на 100%. Я проверял только "заурядные" вещи вроде арабской вязи.

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

C>Найти твою цитату про память, которая сейчас очень дешовая?

Она и есть дешевая. Вопрос только в том, что UTF-16 всем хватает и платить больше просто нет смысла.

C>Увеличение размера символа в два раза плохо скажется только на
C>редакторах текстов. В остальных программах строки обычно занимают
C>процентов 10 памяти.

Думаю, что по скорости вообще ничего не изменится. Но объем памяти... В общем, это к стратегам из IBM, Sun и MS. Думаю они сто раз измерели прежде чем отрезать до UTF-16.

Собственно лично я работаю с UTF-16 как с плоской раскладкой и уверен, что проблемы в этой жизни не будут.

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

E>Умеете вы не обращать внимание на реальность. В C++ есть такое понятие, как модификатор const.

Это проблемы С++. Собственно в нем и const_cast есть. Как раз чтобы оходить собственные просчеты в дизайне.


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

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

C>А еще есть языки, обходящиеся без типов вообще. И что?

Совсем? Назови хоть один.

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

FR>Я что-то похоже пропустил, покажи пожалуйста где это они слили?

У тебя поиск неработает?

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

АХ>>(на практике именно на вычислительных задачах можно посмотреть их сравнение здесь,

IT>Забавные тесты. Правда фортрана я там не нашёл. Зато обнаружил, что преславутые Руби и Tcl уверенно замыкают список практически во всех тестах, отставая от лидеров в десятки и сотни раз, а порой вообще имеют timeout.

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

Эту ссылку здесь уже сто раз обсасывали, но ее даюет и дают. Перемеренный первый попавшийся тест (Аккерман) показал, что тот же Немерел задвинул VC в лучем виде. А у них на Моно и в добавок с измерением джит комплияции и инициализации рантайма получается совсем по другому.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>А это спорно

Ну, поспорь для разнообразия.

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

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

FR>Классно, так извратить название темы. Влад тебе уже пора в политику идти.

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

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

C>Увеличение размера символа в два раза плохо скажется только на
C>редакторах текстов. В остальных программах строки обычно занимают
C>процентов 10 памяти.

Только не в .NET. Посмотри какой-нибудь memory profile. Строчки в .NET обычно занимают подавляющую часть памяти: 50% или больше. Вот тебе один profile: http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx. Он создан для тестового приложения ShowFormComplex.exe, которое ничего не делает, а просто создаёт одно WinForms окошко со 100 простейшими контролами. В этом приложении GC Heap составляет 843K. Из них 561K отнимают объекты класса System.String.

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

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

FR>>Я что-то похоже пропустил, покажи пожалуйста где это они слили?

VD>У тебя поиск неработает?
Кому лень искать (или если кто не владеет этим навыком) привожу ссылки: здесь

Автор: VladD2
Дата: 29.01.06

и здесь

Автор: Vermicious Knid
Дата: 22.05.06

.

А для тех кто никому не доверяет и считает, что все тесты злостно подделаны привожу исходники на C++,D,C# и Nemerle (последний в двух вариантах — обычный и с pattern-matching), чтобы могли проверить сами:

C++:

#include <iostream>

#include <windows.h> // for GetTickCount


int Akk(int a, int b)
{
    if (a == 0)
        return b + 1;
    else
    if (b == 0)
        return Akk(a - 1, 1);
    else
        return Akk(a - 1, Akk(a, b - 1));
}

int main()
{
    DWORD start = GetTickCount();
    std::cout << Akk(3, 11) << std::endl;
    DWORD stop = GetTickCount();
    std::cout << stop-start << " ms elapsed.\n";
    
    return 0;
}

D:

private import std.perf, std.stdio;

int Akk(int a, int b)
{
    if (a == 0)
        return b + 1;
    else
    if (b == 0)
        return Akk(a - 1, 1);
    else
        return Akk(a - 1, Akk(a, b - 1));
}

void main()
{
    HighPerformanceCounter t = new HighPerformanceCounter();
    t.start();
    Akk(3, 11);
    t.stop();
    writefln("%d ms elapsed.", t.milliseconds());
}

C#:

using System;
using System.Diagnostics;

class Ackermann
{
   public static int Ack(int m, int n) 
   {
      if (m == 0) 
        return n + 1;
      if (n == 0)
        return Ack(m-1, 1);
      else 
        return Ack(m-1, Ack(m, n-1));
   }

   static void Main(string[] args)
   {
      Stopwatch stopwatch = new Stopwatch();
      stopwatch.Start();
      Console.WriteLine(Ack(3, 11));
      stopwatch.Stop();
      Console.WriteLine(stopwatch.Elapsed);
   }
}

Nemerle:

using System;
using System.Diagnostics;

def Akk(a, b)
{
    if (a == 0)
        b + 1
    else
    if (b == 0)
        Akk(a - 1, 1)
    else
        Akk(a - 1, Akk(a, b - 1) )

}

def AkkDecl(a, b)
{
    | (0, _) => b + 1
    | (_, 0) => AkkDecl(a - 1, 1)
    | (_, _) => AkkDecl(a - 1, AkkDecl(a, b - 1))
}

def time(f)
{
    def stopwatch = Stopwatch();
    stopwatch.Start();
    f();
    stopwatch.Stop();
    stopwatch.Elapsed
}

Console.WriteLine(time(fun() { Console.WriteLine(Akk(3, 11)) }));
Console.WriteLine(time(fun() { Console.WriteLine(AkkDecl(3, 11)) }));

А кому лень тестировать, я проверил:
Для проверки на моем компьютере (Pentium M 1.7 Dothan/ Win XP SP2 /.NET 2.0) были использованы следующие компиляторы:

MS C++ compiler от VS2005
GCC 3.4.2 в составе MinGW (не самый новый, сразу скажу)

Digital Mars D compiler 0.157

MS C# compiler от VS2005

Nemerle 0.9.3

во всех компиляторах оптимизация была по возможности выставлена на максимум.
Вот bat-файл:

ncc -out:akk-n.exe akk.n
csc /o+ /out:akk-cs.exe akk.cs
dmd akk.d -O -release -inline -ofakk-d.exe
cl akk.cpp /Ox /Feakk-cpp.exe
g++ akk.cpp -O99 -oakk-gpp.exe

Вот результаты (усредненные по 10 запускам и отсортированные по времени):
1) MS C++ : 830.5 ms
2) Nemerle : 844.4 ms
3) GCC : 990.4 ms
4) MS C# : 1567.4 ms
5) DMD : 2247.3 ms
6) Nemerle-decl : 3134.6 ms

Итак какие можно сделать выводы:
Компиляторы умеющие раскручивать хвостовую рекурсию выигрывают в этом тесте.
Очевидно, это сделали MS C++, Nemerle и GCC.
Явно это не сделал DMD (за что ему наше ) и Nemerle с паттерн-матчингом (простим, т.к. есть более эффективная альтернатива).

И что-то среднее с C# .

Вообще в программах со множеством рекурсивных вызовов функциональные языки обычно выигрывают,
что и показывает, к примеру, тест Binary Trees
на том же сайте.

Думал еще проверить на Scala, скорее всего дала бы схожие с Nemerle результаты, но заломало функцию замера времени искать .

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

IT>>Гениально! Если так рассуждает консенсус комитетчиков, то многое становится ясным.
E>Блин, так об этом я тебе и твердил все это время. Комитет не выбирал самые популярные решения или решения, восстребованые или модные в данный момент времени.

И ты считаешь это правильным?

E>В таких условях принцип "и вашым, и нашим" ведет к слишком громоздкому языку, принцип "тем, кого больше" ведет к оттоку части пользователей, а самым жизненым является "ни вашим, ни нашим". Что в итоге в C++ и получилось.

В результате итак получился отток пользователей. Самый "жизненый" принцип "ни вашим, ни нашим" не сработал. Но не исключено, что если бы в языке была налажена унифицированная работа со строками, присутсвовали свойства и вместо ugly '->' использовалась бы '.', то я бы так и осталься с C++ и не переводил бы на .NET целый департмент.

IT>>Свойства во многих языках используются уже много лет и очень хорошо себя зарекомендовали. Полноценные лямбды в C# я, например, жду с нетерпением, а пока во всю используют анонимные методы. А вот mutable в .NET совсем отсутствует, и никого это сильно не напрягает. В Java, кстати, тоже как-то без mutable нород живёт.

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

Свойства в Java как раз есть. Точнее то, что народ использует специальные соглашения при определении методов для того, чтобы определить свойство, как раз очень хорошо доказывает необходимость свойств. Лямб нет, потому что в Java нет делегатов. В свою очередь их отсутствие приводит к тому, что их функциональность эмулируется интерефейсами с одним методом. Это приводит к совершенно непотребному количеству используемых интерфейсов.

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

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

>> Т.е. ты решаешь за меня нужны мне свойсва или не нужны?
C>Ну должен же кто-то решать?

Я за себя уж как-нибудь сам.

C>Свойства — это не более чем простенький синтаксический сахар. Причем сахар с солью (как взять ссылку на свойство?).

Зачем тебе ссылка на свойство?

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

IT>Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу

Простейший случай: объект синхронизации, затрагиваемый внутри const-метода.
Второй простейший случай: отложенное вычисление в каком-нибудь указателе.

IT>А вот свойствами (расширениями от производителей) пользовался во всю как только узнал, что они есть. Потому что удобно. И теперь ты мне можешь до посинения рассказывать, почему mutable нужен в языке, а property, которую реализовать фигня как два байта об асфальт, оказалась вещью, по мнению Страуструпа не нужной и бесполезной.

Потому что property и в самом деле эмулируются, как два байта. А вот ты мне скажи, виртуальные проперти бывают или нет? А абстрактные? А можно ли передать проперть как объект в какой-нить метод? А сделать его параметром шаблона? А сделать проперть отдельным классом и отнаследоваться?

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

A>>Можно поговорить о практической полезности этой фичи в C++. Вот ты как её использовал, например?
IT>Началось всё с #import. Там без свойств никак.

Ошибаешься. Есть ещё raw (кажется, не помню на вскидку модификатор). Прекрасно импортирует COM-интерфейсы без пропертей.