Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 04:41
Оценка: 18 (1) :)
Здравствуйте, VladD2, Вы писали:


D>> Конечно! Но Qt дополняет язык, в него вводятся новые возможности, недоступные ранее, он становится именно ОО — объекты получают события, и для программиста это очевидно, а не так как в стандартном С++, где событие это вызов метода. Да, нужен дополнительный moc-компилятор, но что с того — обычное метапрограммирование. Еще раз оговорюсь — не знаю как это реализовано в немерле.

D>> И foreach там есть

VD>Вот только заслуги С++ тут нет. Тут есть борьба с его проблемами внешними средствами.


VD>К тому же это все детский лепет. Даже C# не нужны подпорки чтобы создать полноценную компонентную систему построения GUI. А уж Nemerle и подавно.


Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#, интересно из-за этого С# становится отстоем? (хотя нет тогда C# должен был быть отстоем еще до своего появления на свет).

03.06.06 17:25: Ветка выделена из темы Синтаксический сахар или C++ vs. Nemerle :)
Автор: Чистяков Влад aka VladD2
Дата: 24.05.06
— VladD2
Re: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 05:54
Оценка:
Здравствуйте, FR, Вы писали:

FR>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#,


Можешь продемонстрировать кусочек?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 08:20
Оценка:
Здравствуйте, IT, Вы писали:

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


FR>>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#,


IT>Можешь продемонстрировать кусочек?


Tcl мне не родной, меня лично его синтаксис (как и лисп) убивает, но на питоне на базе tcl'ной tk могу.
Только что именно нужно?
Re: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 12:09
Оценка:
Здравствуйте, FR, Вы писали:

FR>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#, интересно из-за этого С# становится отстоем? (хотя нет тогда C# должен был быть отстоем еще до своего появления на свет).


Нет, конечно, ведь проще только языком. И качество тоже значительно ниже.

Да и причем тут tcl? tcl это одельный язык специально заточеный для конкретных нужд. Он в другой весовой катерогрии (скрпт). И возможности его сильно ограничены. C++ и C# же — это универсальные языки первый из которых в чистом виде не пригоден для компонентной разработке и потому требует подпорок вроде COM, QT и т.п., а второй без проблем справляется с этой задаче срествами поддержки компонентной разработки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 13:16
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#, интересно из-за этого С# становится отстоем? (хотя нет тогда C# должен был быть отстоем еще до своего появления на свет).


VD>Нет, конечно, ведь проще только языком. И качество тоже значительно ниже.


VD>Да и причем тут tcl? tcl это одельный язык специально заточеный для конкретных нужд. Он в другой весовой катерогрии (скрпт). И возможности его сильно ограничены. C++ и C# же — это универсальные языки первый из которых в чистом виде не пригоден для компонентной разработке и потому требует подпорок вроде COM, QT и т.п., а второй без проблем справляется с этой задаче срествами поддержки компонентной разработки.


Ну так я тоже про ту же самую мысль, почему C# с этим прекрасно справляется?, потому что его тоже под это специально заточили. А C++ возник слишком рано, тогда такие задачи еще не были майнстримом.
И вообще если уж охота было сравнивать Nemerle с другими языками в области метапрограммирования, то идеальный кандидат никак ни C++, по моему это Forth.
Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Андрей Хропов Россия  
Дата: 27.05.06 15:00
Оценка: 22 (1)
Здравствуйте, FR, Вы писали:

FR>Ну так я тоже про ту же самую мысль, почему C# с этим прекрасно справляется?, потому что его тоже под это специально заточили. А C++ возник слишком рано, тогда такие задачи еще не были майнстримом.

Проблема мне кажется несколько в другом, а именно — то, что С++ развивался постепенными добавками к C, сохраняя при этом совместимость, поэтому в нем реализация ОО парадигмы тоже не классическая (все — объект)
, потом еще добавили шаблоны, потом началось метапрограммирование на них...
Полноценные модули не сделали, поскольку уже все привыкли к #include, а сделали namespace и т.д.

FR>И вообще если уж охота было сравнивать Nemerle с другими языками в области метапрограммирования, то идеальный кандидат никак ни C++, по моему это Forth.

Да можно и с Forth, конечно, как и с Lisp,

правда синтаксис у него конечно, это жесть

Вот сравните (Аккерман):
Это C/C++ (я написал):
int Akk( int a, int b )
{
    if( b == 0 )
        return Akk(a - 1, 1);
    else if( a == 0 )
        return b + 1;
    else
        return Akk(a - 1, Akk(a, b - 1));
}

Это Forth (взято здесь):
: -ack ( y x -- n )
   ?dup if
     swap ?dup
      if
         1- over recurse swap 1- recurse
      else
         1- 1 swap recurse
      then
   else
      1+
   then ;

Это Lisp (взято здесь):
(define (ack m n)
    (cond ((= m 0) (+ n 1))
          ((= n 0) (ack (- m 1) 1))
      (true    (ack (- m 1) (ack m (- n 1))))))

А это Немерле (взято здесь
Автор: WolfHound
Дата: 22.05.06
):
def Akk(a : int, b : int)
{
  |(_, 0) => Akk(a - 1, 1)
  |(0, _) => b + 1
  |(_, _) => Akk(a - 1, Akk(a, b - 1))
}

C++ я думаю, поймут все .
Хотя я не специалист в Немерле мне понятна последняя программа,
можно разобраться с некотороыми усилиями в Lisp,
а вот Forth...

Это правда не метапрограммирование, а так...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 15:54
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

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


FR>>Ну так я тоже про ту же самую мысль, почему C# с этим прекрасно справляется?, потому что его тоже под это специально заточили. А C++ возник слишком рано, тогда такие задачи еще не были майнстримом.

АХ>Проблема мне кажется несколько в другом, а именно — то, что С++ развивался постепенными добавками к C, сохраняя при этом совместимость, поэтому в нем реализация ОО парадигмы тоже не классическая (все — объект)
АХ>, потом еще добавили шаблоны, потом началось метапрограммирование на них...
АХ>Полноценные модули не сделали, поскольку уже все привыкли к #include, а сделали namespace и т.д.

Угу эвлоюция, без потери совместимости.

FR>>И вообще если уж охота было сравнивать Nemerle с другими языками в области метапрограммирования, то идеальный кандидат никак ни C++, по моему это Forth.

АХ>Да можно и с Forth, конечно, как и с Lisp,

АХ>правда синтаксис у него конечно, это жесть


АХ>C++ я думаю, поймут все .

АХ>Хотя я не специалист в Немерле мне понятна последняя программа,
АХ>можно разобраться с некотороыми усилиями в Lisp,
АХ>а вот Forth...

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

АХ>Это правда не метапрограммирование, а так...


Вот если брать именно мета, то forth вполне достойный конкурент Nemerle.
Re[5]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: WolfHound  
Дата: 27.05.06 16:06
Оценка:
Здравствуйте, FR, Вы писали:

FR>Вот если брать именно мета, то forth вполне достойный конкурент Nemerle.

Ну повтори на forth'е примеры из этой
Автор: WolfHound
Дата: 26.05.06
ветки. Посмотрим насколько они будут понятны.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 16:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>Вот если брать именно мета, то forth вполне достойный конкурент Nemerle.

WH>Ну повтори на forth'е примеры из этой
Автор: WolfHound
Дата: 26.05.06
ветки. Посмотрим насколько они будут понятны.


Давай я тебя через 12 лет попрошу что ни-будь написать на Nemerle
(вернее через 12 лет после того как ты перестал писать на Nemerle)
Хотя может и попробую, но ничего ни обещаю.
Re[3]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 16:18
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ну так я тоже про ту же самую мысль, почему C# с этим прекрасно справляется?, потому что его тоже под это специально заточили. А C++ возник слишком рано, тогда такие задачи еще не были майнстримом.

FR>И вообще если уж охота было сравнивать Nemerle с другими языками в области метапрограммирования, то идеальный кандидат никак ни C++, по моему это Forth.

Тебе это интересно? Сравнивай. Я на Форте писать принципильно не желаю. И думаю, что 99% программистов тоже.

И вообще, что вы мне пытаетесь указывать с чем и что мне сравнивать? Если у вас другое мнение, то милости просим изложить его в статье. А свои предпочтения оставьте для себя. Мне они не интересны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 16:22
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Давай я тебя через 12 лет попрошу что ни-будь написать на Nemerle


Договорились если обещашь не просить эти 12 лет писат на Форте других. ОК?

FR>(вернее через 12 лет после того как ты перестал писать на Nemerle)


А кто тебе, кстати, такое сказал? Может через 12 лет ты будешь все рассказывать, что сразу увидел в Немерле божью искру, а разные Вольфхаунты тебе мозги пудрили.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Demiurg  
Дата: 27.05.06 16:38
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>C++ я думаю, поймут все .

АХ>Хотя я не специалист в Немерле мне понятна последняя программа,
АХ>можно разобраться с некотороыми усилиями в Lisp,
АХ>а вот Forth...

Пролог забыл Попробуй.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 17:21
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Давай я тебя через 12 лет попрошу что ни-будь написать на Nemerle


VD>Договорились если обещашь не просить эти 12 лет писат на Форте других. ОК?


Так я не просил вроде никого это делать.

FR>>(вернее через 12 лет после того как ты перестал писать на Nemerle)


VD>А кто тебе, кстати, такое сказал? Может через 12 лет ты будешь все рассказывать, что сразу увидел в Немерле божью искру, а разные Вольфхаунты тебе мозги пудрили.




Ты бы спроcил меня двенадцать лет назад про форт, да я тогда был готов за него всех в землю закопать
Кстати я тогда и на лиспе немного писал и никакие скобки не смущали, а сейчас китайская грамота
Я думаю ты сам через несколько лет забудешь про N и будешь какой ни-будь X двигать
Re[5]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 17:21
Оценка:
Здравствуйте, Demiurg, Вы писали:

D>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>C++ я думаю, поймут все .

АХ>>Хотя я не специалист в Немерле мне понятна последняя программа,
АХ>>можно разобраться с некотороыми усилиями в Lisp,
АХ>>а вот Forth...

D> Пролог забыл Попробуй.


В прологе вообще не поймешь где мета, где не мета, по моему там все мета, но другое мета
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 17:21
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Ну так я тоже про ту же самую мысль, почему C# с этим прекрасно справляется?, потому что его тоже под это специально заточили. А C++ возник слишком рано, тогда такие задачи еще не были майнстримом.

FR>>И вообще если уж охота было сравнивать Nemerle с другими языками в области метапрограммирования, то идеальный кандидат никак ни C++, по моему это Forth.

VD>Тебе это интересно? Сравнивай. Я на Форте писать принципильно не желаю. И думаю, что 99% программистов тоже.


Было интересно, сейчас уже не очень.
Но сравнение было бы интересно.

VD>И вообще, что вы мне пытаетесь указывать с чем и что мне сравнивать? Если у вас другое мнение, то милости просим изложить его в статье. А свои предпочтения оставьте для себя. Мне они не интересны.


Хорошо. Может и попытаюсь вспомнить форт и сравнить.
Re[6]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Demiurg  
Дата: 27.05.06 17:30
Оценка:
Здравствуйте, FR, Вы писали:

D>> Пролог забыл Попробуй.


FR>В прологе вообще не поймешь где мета, где не мета, по моему там все мета, но другое мета


Я вообще не понимаю где там мета
Там прикольно, написал прогу на С, потом аналогичную на прологе. На С строк 700, на прологе 24. Нюанс! Писал на С и мало думал Писал на прологе и думал много
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 17:36
Оценка: -1 :)
Здравствуйте, FR, Вы писали:

FR>>>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#,


IT>>Можешь продемонстрировать кусочек?


FR>Tcl мне не родной, меня лично его синтаксис (как и лисп) убивает, но на питоне на базе tcl'ной tk могу.

FR>Только что именно нужно?

Демонстрация лёгкого построения ГУИ. Рабочий код приводить совсем не обязательно, генерируемый радакторами код тоже. Просто хотя бы идею обозначить.

Для примера, для такого простого диалога, поддерживающего валидацию и подсветку изменённых полей



код на C# может выглядеть следующим образом:

public partial class EditPersonForm : BizEntityForm
{
    public EditPersonForm(Person person)
    {
        InitializeComponent();
        binder.Object = person;
    }
}

Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Demiurg  
Дата: 27.05.06 17:45
Оценка: +2
Здравствуйте, IT, Вы писали:

IT>код на C# может выглядеть следующим образом:


IT>
IT>public partial class EditPersonForm : BizEntityForm
IT>{
IT>    public EditPersonForm(Person person)
IT>    {
IT>        InitializeComponent();
IT>        binder.Object = person;
IT>    }
IT>}
IT>


Это все? ИИ уже придумали...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 17:47
Оценка:
Здравствуйте, Demiurg, Вы писали:

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


D>>> Пролог забыл Попробуй.


FR>>В прологе вообще не поймешь где мета, где не мета, по моему там все мета, но другое мета


D> Я вообще не понимаю где там мета


Там же как и в любой динамике?

D> Там прикольно, написал прогу на С, потом аналогичную на прологе. На С строк 700, на прологе 24. Нюанс! Писал на С и мало думал Писал на прологе и думал много


Угу и в конечном счете может оказатся что на си и проще и быстрее
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 17:47
Оценка:
Здравствуйте, IT, Вы писали:


IT>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


Если обозначить только идею, то тоже будет пара строк подключающих или готовый из билиотеки или сгенерированый RAD'остью код. Только боюсь и в Delphi и в любой другой среде с радостями будет что-то похожее.

Инетреснее сравнить рукописный код какого ни-будь простого диалога.
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 17:53
Оценка:
Здравствуйте, Demiurg, Вы писали:

D> Это все? ИИ уже придумали...


А твой И тогда зачем будет нужен?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 17:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если обозначить только идею, то тоже будет пара строк подключающих или готовый из билиотеки или сгенерированый RAD'остью код. Только боюсь и в Delphi и в любой другой среде с радостями будет что-то похожее.


Подожди, ты утверждал следующее:

Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#,


Теперь ты говоришь "тоже будет". Т.е. это можно понимать как такой же, но не проще. Правильно?

FR>Инетреснее сравнить рукописный код какого ни-будь простого диалога.


Можно бы и это сравнить, но лень
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Demiurg  
Дата: 27.05.06 18:01
Оценка: :)
Здравствуйте, FR, Вы писали:

D>> Там прикольно, написал прогу на С, потом аналогичную на прологе. На С строк 700, на прологе 24. Нюанс! Писал на С и мало думал Писал на прологе и думал много


FR>Угу и в конечном счете может оказатся что на си и проще и быстрее


Почему может быть? Так и оказалось. Да и прога была простенькой. Сложную систему на прологе я мало себе представляю... Ээээ, к чему это мы...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Demiurg  
Дата: 27.05.06 18:01
Оценка:
Здравствуйте, IT, Вы писали:

D>> Это все? ИИ уже придумали...


IT>А твой И тогда зачем будет нужен?


А можно я тебя забаню за оффтоп?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 18:06
Оценка:
Здравствуйте, IT, Вы писали:

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


FR>>Если обозначить только идею, то тоже будет пара строк подключающих или готовый из билиотеки или сгенерированый RAD'остью код. Только боюсь и в Delphi и в любой другой среде с радостями будет что-то похожее.


IT>Подожди, ты утверждал следующее:


IT>

IT>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#,


IT>Теперь ты говоришь "тоже будет". Т.е. это можно понимать как такой же, но не проще. Правильно?


Ладно уговарил будет проще:

import module
module.run()


FR>>Инетреснее сравнить рукописный код какого ни-будь простого диалога.


IT>Можно бы и это сравнить, но лень


Ну колхоз дело добровольное
Re[8]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Demiurg  
Дата: 27.05.06 18:16
Оценка: :)))
Здравствуйте, FR, Вы писали:

FR>Угу и в конечном счете может оказатся что на си и проще и быстрее


Кстати, когда я еще на асме писал, однажды за день написал только одну строчку кода — символов 7. Я до сих пор называю тот день удачным
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Андрей Хропов Россия  
Дата: 27.05.06 18:18
Оценка:
Здравствуйте, Demiurg, Вы писали:

D>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>C++ я думаю, поймут все .

АХ>>Хотя я не специалист в Немерле мне понятна последняя программа,
АХ>>можно разобраться с некотороыми усилиями в Lisp,
АХ>>а вот Forth...

D> Пролог забыл Попробуй.

Дык можно и на Прологе
(опять отсюда*):
ack(0,N,Val) :- Val is N + 1.
ack(M,0,Val) :- M > 0, M1 is M - 1, ack(M1,1,Val).
ack(M,N,Val) :- M > 0, N > 0, M1 is M - 1, N1 is N -1,
        ack(M, N1, Val1), ack(M1, Val1, Val).

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

(*) Этот сайт — просто рай для тех кто любит сравнивать языки + можно присылать свои реализации, а те что есть можно скачать из cvs и устраивать свои тесты. Прощу прощения за рекламу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Андрей Хропов Россия  
Дата: 27.05.06 18:18
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тебе это интересно? Сравнивай. Я на Форте писать принципильно не желаю. И думаю, что 99% программистов тоже.

+1.
Я бы неформально сказал, что Немерле — это "функциональное и метапрограммирование с человеческим лицом" .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 18:37
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Ладно уговарил будет проще:


FR>
FR>import module
FR>module.run()
FR>


И не надо никакой привязки к редактируемому объекту. Круто!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 19:42
Оценка: +1
Здравствуйте, IT, Вы писали:

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


FR>>Ладно уговарил будет проще:


FR>>
FR>>import module
FR>>module.run()
FR>>


IT>И не надо никакой привязки к редактируемому объекту. Круто!


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

import person_module
Re[6]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 19:58
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:


АХ>(*) Этот сайт — просто рай для тех кто любит сравнивать языки + можно присылать свои реализации, а те что есть можно скачать из cvs и устраивать свои тесты. Прощу прощения за рекламу.


Только если не смотреть на результаты из тестов
Re[9]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 20:20
Оценка: -2 :)
Здравствуйте, FR, Вы писали:

IT>>И не надо никакой привязки к редактируемому объекту. Круто!


FR>Конечно со сфероконями, оно всегда так


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

FR>А привязкой можешь считать вызов функции или импорт модуля, вообще можно еще сократить(и притом с привязкой):


Я вообще-то не вызов у тебя просил, а реализацию. Но, в принципе, всё с вами понятно. Очередной голословный наезд на C#, а как доходит до дела, то сразу переключаемся на сферокоников.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 20:23
Оценка:
Здравствуйте, Demiurg, Вы писали:

IT>>А твой И тогда зачем будет нужен?


D> А можно я тебя забаню за оффтоп?


Какой офтоп, ты о чём
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Gadsky Россия  
Дата: 27.05.06 20:34
Оценка:
Здравствуйте, FR, Вы писали:

D>> Там прикольно, написал прогу на С, потом аналогичную на прологе. На С строк 700, на прологе 24. Нюанс! Писал на С и мало думал Писал на прологе и думал много


FR>Угу и в конечном счете может оказатся что на си и проще и быстрее


Не согласен, если бы для пролога сущестовал тот самый компилятор, который создает идеальный код для идеальных утверждений — так писать на нем было б идеально (для меня).
Хотя может задачи все такие попадаются.
Re[10]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 20:38
Оценка: +1
Здравствуйте, IT, Вы писали:

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


IT>>>И не надо никакой привязки к редактируемому объекту. Круто!


FR>>Конечно со сфероконями, оно всегда так


IT>Поэтому я тебя и попросил не сфероконика, а кусочек не обязательно рабочего, но реального кода. Я тебе, кстати, привёл именно рабочий код, даже скриншотик приложил.


Что изменится от того что я что-то нашлепаю в RAD'е и пришлю тебе скриншот?

FR>>А привязкой можешь считать вызов функции или импорт модуля, вообще можно еще сократить(и притом с привязкой):


IT>Я вообще-то не вызов у тебя просил, а реализацию. Но, в принципе, всё с вами понятно. Очередной голословный наезд на C#, а как доходит до дела, то сразу переключаемся на сферокоников.


Спасибо конечно за реализацию, из нее я с большим удивлением узнал что на C# оказывается можно вызывать функции и присваивать значения переменным.
До дела пока не дошло, чтобы дошло я предлагал сделать простейший рукописный диалог, можно было бы сравнить именно языки а не возможности RAD или библиотек.
Re[9]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 27.05.06 20:43
Оценка:
Здравствуйте, Gadsky, Вы писали:

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


D>>> Там прикольно, написал прогу на С, потом аналогичную на прологе. На С строк 700, на прологе 24. Нюанс! Писал на С и мало думал Писал на прологе и думал много


FR>>Угу и в конечном счете может оказатся что на си и проще и быстрее


G>Не согласен, если бы для пролога сущестовал тот самый компилятор, который создает идеальный код для идеальных утверждений — так писать на нем было б идеально (для меня).

G>Хотя может задачи все такие попадаются.

Ну значит у тебя произошла удачная стыковка с прологом
Вообще все люди разные поэтому и языков много и "то что рускому хорошо то немцу смерть" и наооборот
Правда тут некторые товарищи утверждают что все языки равны, но некторые языки более равны
Re[11]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 20:55
Оценка: +1 -2
Здравствуйте, FR, Вы писали:

IT>>Поэтому я тебя и попросил не сфероконика, а кусочек не обязательно рабочего, но реального кода. Я тебе, кстати, привёл именно рабочий код, даже скриншотик приложил.


FR>Что изменится от того что я что-то нашлепаю в RAD'е и пришлю тебе скриншот?


Можно без скриншота, я переживу.

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


Ты сделал громкое заявление, что ГУИ на Tcl делать, цитирую "проще чем в C#". Всё чего я хочу, так это увидеть хотя бы аналогичный моему пример, диалог, который умеет редактировать внешний объет. Если это так просто на Tcl, то тебе всего лишь надо привести пример из максимум 7-ми строчек кода. Код, генерируемый RAD и код библиотек я тебе приводить не предлагаю. Меня интересует заявленная тобой простота их использования, выраженная в количестве рукописного кода. В примере, который я привёл — это ровно 1 строка, вот эта:

binder.Object = person;

Всё что она делает, инициализирует форму переданным объектом. После твоих заявлений я ожидал чего-то подобного. Но видимо не судьба
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 27.05.06 21:22
Оценка: 1 (1) +5 -1
Здравствуйте, IT, Вы писали:


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


IT>Ты сделал громкое заявление, что ГУИ на Tcl делать, цитирую "проще чем в C#". Всё чего я хочу, так это увидеть хотя бы аналогичный моему пример, диалог, который умеет редактировать внешний объет. Если это так просто на Tcl, то тебе всего лишь надо привести пример из максимум 7-ми строчек кода. Код, генерируемый RAD и код библиотек я тебе приводить не предлагаю. Меня интересует заявленная тобой простота их использования, выраженная в количестве рукописного кода. В примере, который я привёл — это ровно 1 строка, вот эта:


IT>
IT>binder.Object = person;
IT>

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

Так я и прислал, совершено идентичный код. Он может делать тоже самое и несет ровно столько же информации о возможностях языка как и твой пример.
Если тебе лень делать нормальный пример я ничем помощь не могу, извини.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Demiurg  
Дата: 27.05.06 21:33
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>А твой И тогда зачем будет нужен?


D>> А можно я тебя забаню за оффтоп?


IT>Какой офтоп, ты о чём


Я просто не осилил с первого раза. Уже осилил
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 27.05.06 21:52
Оценка: +1 -1
Здравствуйте, FR, Вы писали:

FR>Так я и прислал, совершено идентичный код. Он может делать тоже самое и несет ровно столько же информации о возможностях языка как и твой пример.


Я даже больше скажу, твой код гораздо круче, что я пытался выразить говоря

И не надо никакой привязки к редактируемому объекту. Круто!


На что ты ответил, что это сфероконь. Так? После этого я засомневался как в крутости твоего кода, так и в "проще чем в C#".

К тому же ты во второй раз утверждаешь, что этот код делает "тоже самое". Т.е. твоё утверждение, к которому я собственно говоря и прицепился про "tcl деает это проще чем C#", мягко говоря не соответствует действительности.

FR>Если тебе лень делать нормальный пример я ничем помощь не могу, извини.


Чем не нормален мой пример? Он даже более чем нормальный, он вполне рабочий. Типичный код C# формы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка: -2
Здравствуйте, FR, Вы писали:

FR>Так я не просил вроде никого это делать.


А как понять твои слова:

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


Мне их сравнивать не написав на Форте ни строчки?

Я несколько раз смотрел на код Форта и какждый раз ни каких положительных эмоций не возникало. Изучать такй язык и темболее использовать я не хочу.

VD>>А кто тебе, кстати, такое сказал? Может через 12 лет ты будешь все рассказывать, что сразу увидел в Немерле божью искру, а разные Вольфхаунты тебе мозги пудрили.


FR>


Это было бы смешно если бы я не видел как те кто в 94-ом вопил, что Майкрософту Новел не уделать, а нетварь рулит, рулила и будет рулить, а потом в 98-ом даже не могли вспомнить, что такое говорили. Так что ты свою улыбочку вспомни лет через 10.

FR>Ты бы спроcил меня двенадцать лет назад про форт, да я тогда был готов за него всех в землю закопать


Что же. Ты явно ителлектуально вырос за эти 12 лет. Это не может не радовать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка:
Здравствуйте, FR, Вы писали:

FR>Было интересно, сейчас уже не очень.

FR>Но сравнение было бы интересно.

ОК. Посмотрим на исходные данные.
1. Мнтересно тебе.
2. Форт знаешь (знал) ты.
3. Я Форт не знаю, изучать его не хочу, и сравнивать с ним высокоуровневый язык не хочу.

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

Если ктому-то это не нравится, то он идет лесом. Если у него есть другие идеи, то он может оформить их в виде статьи и мы опубликуем их.

VD>>И вообще, что вы мне пытаетесь указывать с чем и что мне сравнивать? Если у вас другое мнение, то милости просим изложить его в статье. А свои предпочтения оставьте для себя. Мне они не интересны.


FR>Хорошо. Может и попытаюсь вспомнить форт и сравнить.


Ждем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

VD>>Тебе это интересно? Сравнивай. Я на Форте писать принципильно не желаю. И думаю, что 99% программистов тоже.

АХ>+1.
АХ>Я бы неформально сказал, что Немерле — это "функциональное и метапрограммирование с человеческим лицом" .

Именно. Весь кайф в том, что Немерле очень красиво сращивает множество парадигм, и в том, что он дает возможность мягкого старта для тех кто раньше не знат ни функционального стиля, ни метапрограммирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка: -3 :)
Здравствуйте, FR, Вы писали:

FR>Инетреснее сравнить рукописный код какого ни-будь простого диалога.


Откровенно говоря мне это не интересно. Если есть дизайнер форм, то писать код сложной формы вручную просто глупо. Это для мастадонтов, чтобы время было чем убить. Я же накидаю контролы, настрою выравнивание, добавлю менюшки с тулбарами и займусь реализацией логики. Файл с формой же я никогда без дизайнера не открою. Если только для рефакторинга.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка:
Здравствуйте, FR, Вы писали:

Цитируй, только то что нужно для понимания твоих слов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка:
Здравствуйте, Gadsky, Вы писали:

G>Не согласен, если бы для пролога сущестовал тот самый компилятор, который создает идеальный код для идеальных утверждений — так писать на нем было б идеально (для меня).

G>Хотя может задачи все такие попадаются.

Проблема в том, что порождение идеального решения для предикатной логики это насколько я знаю NP-задача, то есть не факт, что закончится при этой жизни. Возможно когда-то и будет прорыв в этой области, но пока что Прологи являются некими СУБД для построения простеньких экспертных систем. Когда-то это было популярно, но потом народ осознал, что в основном нужно писать софт далекий от экспертных истем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:19
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

D>> Пролог забыл Попробуй.

АХ>Дык можно и на Прологе
АХ>(опять отсюда*):
АХ>
АХ>ack(0,N,Val) :- Val is N + 1.
АХ>ack(M,0,Val) :- M > 0, M1 is M - 1, ack(M1,1,Val).
АХ>ack(M,N,Val) :- M > 0, N > 0, M1 is M - 1, N1 is N -1,
АХ>        ack(M, N1, Val1), ack(M1, Val1, Val).
АХ>


Кстати, выглядит сложнее чем на С++, не то что на Немерле с паттерн-матчингом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.05.06 22:57
Оценка: -1 :)
Здравствуйте, FR, Вы писали:

Ничего личного, но если я еще раз увижу, что объем цитирования более чем в трое превышает высказывание, то пойдешь в бан на неделю, тренероваться убирать оверквотинг.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Tcl как обоснование ненужности поддержки компонентности в С++
От: GlebZ Россия  
Дата: 27.05.06 23:35
Оценка: +2 :)
Здравствуйте, FR, Вы писали:

FR>И вообще если уж охота было сравнивать Nemerle с другими языками в области метапрограммирования, то идеальный кандидат никак ни C++, по моему это Forth.

Ну в статье я бы не стал так делать. Мало кто помнит что такое Форт, кроме его фанатов. И его метокомпиляция, кроме того, несколько другая специализированная вещь в той же степени как и Forth мало похож на другие языки.
Но мне подумалась другая вещь. Forth был чрезвычайно небольшой базовый язык. Но он был в обратной польской нотации и был завязан на стек. Хотя все можно было дописать в разных позах, базовые вещи пугали. В Nemerle базовая вещь = функциональный язык столь нелюбимый коммерческими программистами....

PS Для тех кто знает Forth набрел на статью о метакомпиляции

PPS. Для тех кто не знает Forth. Я сам не собираюсь писать на Forth. Мало-того. Я никогда ничего серьезного не писал на форте(кроме форт-ассемблера аккурат 12 лет назад ). Но Форт был действительно был и остается явлением в программировании. И знания о том, как он функциклирует нужны примерно как знания о работе Lisp, хотя на нем ничего и никогда писать не собираешься. Просто для увеличения кругозора. Тем более что он настолько прост, что более часа на это не понадобится.

PPPS. Все-таки у меня есть религиозные чувства. Это было оно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.05.06 02:17
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>PPS. Для тех кто не знает Forth. Я сам не собираюсь писать на Forth. Мало-того. Я никогда ничего серьезного не писал на форте(кроме форт-ассемблера аккурат 12 лет назад ). Но Форт был действительно был и остается явлением в программировании. И знания о том, как он функциклирует нужны примерно как знания о работе Lisp, хотя на нем ничего и никогда писать не собираешься. Просто для увеличения кругозора. Тем более что он настолько прост, что более часа на это не понадобится.


Ну, вот и написали бы статейку чтобы народ кругозор расширил. Может оно для кругозора и полезно. А то выглядит код на Форте просто ужасно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 28.05.06 07:22
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Инетреснее сравнить рукописный код какого ни-будь простого диалога.


VD>Откровенно говоря мне это не интересно. Если есть дизайнер форм, то писать код сложной формы вручную просто глупо. Это для мастадонтов, чтобы время было чем убить. Я же накидаю контролы, настрою выравнивание, добавлю менюшки с тулбарами и займусь реализацией логики. Файл с формой же я никогда без дизайнера не открою. Если только для рефакторинга.


Ты про генерацию GUI никогда ни слышал?
И про декларативное описание GUI тоже?
Re[2]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 28.05.06 07:22
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Вот tcl'у тоже не нужны никакие подпорки чтобы строить очень даже компонентный GUI, и при том делать это проще чем в C#, интересно из-за этого С# становится отстоем? (хотя нет тогда C# должен был быть отстоем еще до своего появления на свет).


VD>Нет, конечно, ведь проще только языком. И качество тоже значительно ниже.


Я никогда ни сомневался в твоих телепатических возможностях.

VD>Да и причем тут tcl? tcl это одельный язык специально заточеный для конкретных нужд. Он в другой весовой катерогрии (скрпт). И возможности его сильно ограничены. C++ и C# же — это универсальные языки первый из которых в чистом виде не пригоден для компонентной разработке и потому требует подпорок вроде COM, QT и т.п., а второй без проблем справляется с этой задаче срествами поддержки компонентной разработки.


Я не только и не столько про tcl, сколько про принципы и архитектуру построения GUI на tk, а tk используется не только в tcl, но и многих других языках, например а питоне, есть даже биндинг на C++.
Re[10]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 28.05.06 07:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:


VD>А как понять твои слова:

VD>

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


VD>Мне их сравнивать не написав на Форте ни строчки?


Это было пожелание, и думаю это было бы интереcно не только мне.

VD>Я несколько раз смотрел на код Форта и какждый раз ни каких положительных эмоций не возникало. Изучать такй язык и темболее использовать я не хочу.


Твои проблемы

VD>Это было бы смешно если бы я не видел как те кто в 94-ом вопил, что Майкрософту Новел не уделать, а нетварь рулит, рулила и будет рулить, а потом в 98-ом даже не могли вспомнить, что такое говорили. Так что ты свою улыбочку вспомни лет через 10.


Я не вопил, и вообще всегда хорошо, но без восхищения относился к MS.
И не надо делать выводы обо мне на основании того что кто-то вопил.

FR>>Ты бы спроcил меня двенадцать лет назад про форт, да я тогда был готов за него всех в землю закопать


VD>Что же. Ты явно ителлектуально вырос за эти 12 лет. Это не может не радовать.


Спасибо за комплимент, но интеллект тут ни причем, просто стал более терпимым, кое кому тут этого до сих пор не хватает
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 28.05.06 07:22
Оценка: +2 -1
Здравствуйте, IT, Вы писали:


IT>На что ты ответил, что это сфероконь. Так? После этого я засомневался как в крутости твоего кода, так и в "проще чем в C#".


Конечно сфероконь ибо ни демонстрирует абсолютно никаких языковых возможностей.
Хорошо давай будет так:
module.run(person)

чем этот сфероконь лучше?

IT>К тому же ты во второй раз утверждаешь, что этот код делает "тоже самое". Т.е. твоё утверждение, к которому я собственно говоря и прицепился про "tcl деает это проще чем C#", мягко говоря не соответствует действительности.


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

FR>>Если тебе лень делать нормальный пример я ничем помощь не могу, извини.


IT>Чем не нормален мой пример? Он даже более чем нормальный, он вполне рабочий. Типичный код C# формы.


Вот это тоже:
file_name = asksaveasfilename(filetypes = [("levels", "*.lev")], initialfile = def_name)

типичный пример кода на tkinter (из реального проекта) и несет он столько же смысла сколько и твой пример.
Re[10]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Gadsky Россия  
Дата: 28.05.06 07:41
Оценка:
Здравствуйте, VladD2, Вы писали:

G>>Не согласен, если бы для пролога сущестовал тот самый компилятор, который создает идеальный код для идеальных утверждений — так писать на нем было б идеально (для меня).


VD>Проблема в том, что порождение идеального решения для предикатной логики это насколько я знаю NP-задача, то есть не факт, что закончится при этой жизни


Ну так я и говорю, кабы существовал...
Re[6]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 28.05.06 08:47
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>ОК. Посмотрим на исходные данные.

VD>1. Мнтересно тебе.
VD>2. Форт знаешь (знал) ты.
VD>3. Я Форт не знаю, изучать его не хочу, и сравнивать с ним высокоуровневый язык не хочу.

Форт вполне высокоуровневый язык.

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


Ладно любишь ты критиковать C++, твое право, критикуй.
Но все таки на твоем месте фортом я бы поинтересовался, немерле в принципе многие вещи из него повторил, например все управляющие конструкции на форте написаны на самом форте (то есть в терминах немерле на макросах), по моему мало какие языки еще этим могут похвастатся, форт тоже реализует философию минимализма, ядро очень маленькое все остальное написано на самом форте. И опять же "макросы" на форте тоже пишутся на самом форте. Кроме того создание DSL и есть суть философии форта. Например:

Языки программирования, созданные специально для
опеределенных применений, таких как робототехника,
производственный контроль, статистика и т.д., известны как
"проблемно-ориентированные". Форт — это программные средства
для `создания` проблемно-ориентированных языков. (Последняя
фраза — быть может, самое краткое из возможных описаний Форта.)
На самом деле Вам не стоит писать каких-либо серьезных
задач на Форте; как язык, он просто недостаточно мощен. Вам
`следует` писать на Форте свои собственные языки (лексиконы)
для моделирования Вашего понимания проблемы, на которых Вы
можете элегантно описать ее решение.

Thinking FORTH
A Language and Philosophy for Solving Problems

Englewood Cliffs, N.J., Prentice-Hall, Inc., 1984


В общем если смотреть с позиции метапрограмминга немерле гораздо ближе к форту (и наверно к лиспу) чем к C++.
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.05.06 15:38
Оценка:
Здравствуйте, FR, Вы писали:

FR>Форт вполне высокоуровневый язык.


По примерам на нем этого не заметно.

FR>Ладно любишь ты критиковать C++, твое право, критикуй.


Договорились.

FR>Но все таки на твоем месте фортом я бы поинтересовался, немерле в принципе многие вещи из него повторил, например все управляющие конструкции на форте написаны на самом форте (то есть в терминах немерле на макросах), по моему мало какие языки еще этим могут похвастатся, форт тоже реализует философию минимализма, ядро очень маленькое все остальное написано на самом форте. И опять же "макросы" на форте тоже пишутся на самом форте. Кроме того создание DSL и есть суть философии форта.


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

FR>

FR> На самом деле Вам не стоит писать каких-либо серьезных
FR>задач на Форте; как язык, он просто недостаточно мощен. Вам
FR>`следует` писать на Форте свои собственные языки (лексиконы)
FR>для моделирования Вашего понимания проблемы, на которых Вы
FR>можете элегантно описать ее решение.


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

FR>В общем если смотреть с позиции метапрограмминга немерле гораздо ближе к форту (и наверно к лиспу) чем к C++.


Возомжно. Но тогда и сравнивать их нужно по разному. Что сравнивать одинаковые черты? Вевь смысл сравнивать разное, но нацеленное на решение одних задач. Или как в случае моей статьи сравнения реализации лознгов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.05.06 15:38
Оценка:
Здравствуйте, FR, Вы писали:

VD>>Мне их сравнивать не написав на Форте ни строчки?


FR>Это было пожелание,


Как-то оно слишком ултипативно выглядело.

FR>и думаю это было бы интереcно не только мне.


Ага. Еще 3-5 человекам из 10 000.

Для начала нужно статью про сам Форт сделать.

VD>>Я несколько раз смотрел на код Форта и какждый раз ни каких положительных эмоций не возникало. Изучать такй язык и темболее использовать я не хочу.


FR>Твои проблемы


Мое счастье.

VD>>Это было бы смешно если бы я не видел как те кто в 94-ом вопил, что Майкрософту Новел не уделать, а нетварь рулит, рулила и будет рулить, а потом в 98-ом даже не могли вспомнить, что такое говорили. Так что ты свою улыбочку вспомни лет через 10.


FR>Я не вопил, и вообще всегда хорошо, но без восхищения относился к MS.

FR>И не надо делать выводы обо мне на основании того что кто-то вопил.

Я не о МС говорил. А о том, что про NT тогда делали очено похожие заявления. Никто не верил, что она снесет Новел. Я же посмотрел NT и сказал — "Хана новелю. Несколько лет и его не станет. NT на порядок грамотнее спроектирована и удобнее.". На что сразу же получил очень похожую на текущую реакцию. Прошли годы и те кто вопили во все горло, что я ламер и нихрена не понимаю, как-то даже не смогли вспомнить своих воплей и даже (некторые) уверяли меня, что они сразу оценили NT и ее перспективность. Хотел бы я поглядеть на их реакцию если бы я ошибся.

Вот я так же хочу поглядеть на вашу реакцию если таки Неперле проскочит в мэйнстрим. Послушать как вы дружно будете говрить, что вы это наперед знали.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.06 19:07
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А если не проскочит?
<< Под музыку: Inti-Illimani — Palimpsesto >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 28.05.06 20:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как-то оно слишком ултипативно выглядело.


Так на фоне агрессии Nemerle вполне нормально

FR>>и думаю это было бы интереcно не только мне.


VD>Ага. Еще 3-5 человекам из 10 000.




VD>Для начала нужно статью про сам Форт сделать.


Найти в инете и статьи и книги по форту несложно. Тем более в России есть група фанатичных поклоников, и один из лучших на сегодня трансляторов делают именно они — http://www.forth.org.ru/


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


Мечтай
К тому же Nemerle мне тоже интересен, и как будет немного свободного времени буду его плотно изучать.
Но в мэйнстрим он не пройдет. Даже если пройдет, то очень большая вероятность что я на нем писать не буду.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 28.05.06 20:22
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Форт вполне высокоуровневый язык.


VD>По примерам на нем этого не заметно.


Если привык к стеку то все просто.

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


http://www.forth.org.ru/

VD>Здорово, но писать свои языки вместо работы как-то не хочется. Меня олее устраивает качественный, высокоуровневый, гибкий язык программирования общего назначения который можно подстраивать под свои нужды.


А как же теперешняя мода на DSL? вот пожалуйста есть первопроходец.

FR>>В общем если смотреть с позиции метапрограмминга немерле гораздо ближе к форту (и наверно к лиспу) чем к C++.


VD>Возомжно. Но тогда и сравнивать их нужно по разному. Что сравнивать одинаковые черты? Вевь смысл сравнивать разное, но нацеленное на решение одних задач. Или как в случае моей статьи сравнения реализации лознгов.


Там только идея одинаковая а реализации совершено разные, и смысл их сравнить есть.
Re[13]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: IT Россия linq2db.com
Дата: 28.05.06 20:38
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Но в мэйнстрим он не пройдет.


Почему?

FR>Даже если пройдет, то очень большая вероятность что я на нем писать не буду.


Нам будет тебя не хватать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 28.05.06 20:50
Оценка: -1 :)
Здравствуйте, IT, Вы писали:

FR>>Но в мэйнстрим он не пройдет.


IT>Почему?


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

FR>>Даже если пройдет, то очень большая вероятность что я на нем писать не буду.


IT>Нам будет тебя не хватать


Но вы не сдавайтись боритесь за светлое будущее и мир во всем мире
Re[15]: Зачем нужен Немерле
От: Андрей Хропов Россия  
Дата: 28.05.06 21:14
Оценка:
Здравствуйте, FR, Вы писали:

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


FR>>>Но в мэйнстрим он не пройдет.


IT>>Почему?


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

Ответил здесь
Автор: Андрей Хропов
Дата: 21.05.06
.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 05:14
Оценка: +1
FR,

FR>Ты про генерацию GUI никогда ни слышал?

FR>И про декларативное описание GUI тоже?

Таак, с этого места можно поподробнее. Меня интересуют следующие вопросы:

1. Как сделать сложный GUI без миллиона обработчиков onNthF_ckingComponentEvent? Пока я видел только три альтернативных подхода: www.drools.org, подход в ФЯ типа Эрланга, и конечно web с явным графом переходов, но имхо web приложения делать тяжелее (особенно без фреймворков), чем обычные окна.

2. Что в декларативном описании GUI предлагается декларативно описывать? (Начальное состояние и так без проблем декларативно описывается в ресурсах: button1.color = clRed, а вот декларативно описать поведение — ).

3. Что генерируется в случае "генерации GUI"? Код соответствующего модуля, который рисует форму? На основании чего генерируется? Какое поведение будет у сгенерированного GUI? Как будет отладка и тестирование выглядеть?

+: я тоже считаю, что умный layout лучше, чем умное ёрзание мышкой, но с автоматическими генераторами GUI по спецификациям всё довольно мрачно как раз из-за последнего пункта (мы использовали Java+XSLT).

Ну в-общем, если тебе есть чем поделиться, милости прошу.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[16]: Зачем нужен Немерле
От: FR  
Дата: 29.05.06 06:05
Оценка: +1
Здравствуйте, Андрей Хропов, Вы писали:

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

АХ>Ответил здесь
Автор: Андрей Хропов
Дата: 21.05.06
.


И что?
Ну введут в C# 3 некторые минимальные функциональные возможности, для использования которых не надо перестраивать мышление и плюс встроят пару специализированных DSL, это же как небо и земля по сравнение с Nemerle.
Взять тот же C++, большинство не пользуются метопрограммированием, в лучшем случае используют готовые библиотеки написанные с его использованием. И вообще здесь по моему переоценивают важность метопрограммирования.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 29.05.06 06:05
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>FR,


FR>>Ты про генерацию GUI никогда ни слышал?

FR>>И про декларативное описание GUI тоже?

LCR>Таак, с этого места можно поподробнее. Меня интересуют следующие вопросы:


LCR>1. Как сделать сложный GUI без миллиона обработчиков onNthF_ckingComponentEvent? Пока я видел только три альтернативных подхода: www.drools.org, подход в ФЯ типа Эрланга, и конечно web с явным графом переходов, но имхо web приложения делать тяжелее (особенно без фреймворков), чем обычные окна.


Сложный GUI не генерировал, так что не совсем понимаю вопрос, генерировал только простой но объемный.

LCR>2. Что в декларативном описании GUI предлагается декларативно описывать? (Начальное состояние и так без проблем декларативно описывается в ресурсах: button1.color = clRed, а вот декларативно описать поведение — ).


В тех же tcl/tk или python/Tkinter сам код построения GUI вполне декларативен, и по объему часто меньше чем он же в XML. Обработчики конечно декларативно не делаются.

LCR>3. Что генерируется в случае "генерации GUI"? Код соответствующего модуля, который рисует форму? На основании чего генерируется? Какое поведение будет у сгенерированного GUI? Как будет отладка и тестирование выглядеть?


Генерируется код, например на питоне, некторые обработчики также генерирются, генерируется или на основании декларативного описания(которое тоже программа на том же целевом языке) или просто класса с данными. Отладка и тестирование ничем ни отличается от рукописного кода. Ну и конечно отдельно тестируется генератор.

LCR>+: я тоже считаю, что умный layout лучше, чем умное ёрзание мышкой, но с автоматическими генераторами GUI по спецификациям всё довольно мрачно как раз из-за последнего пункта (мы использовали Java+XSLT).


Ну динамическим языкам часто просто не нужен дополнительный язык описания все можно выразить на одном языке.

LCR>Ну в-общем, если тебе есть чем поделиться, милости прошу.


Вряд ли то что нормально в tcl или python подойдет для java.
Re[9]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 06:21
Оценка:
FR,

LCR>>1. Как сделать сложный GUI без миллиона обработчиков onNthF_ckingComponentEvent? Пока я видел только три альтернативных подхода: www.drools.org, подход в ФЯ типа Эрланга, и конечно web с явным графом переходов, но имхо web приложения делать тяжелее (особенно без фреймворков), чем обычные окна.


FR>Сложный GUI не генерировал, так что не совсем понимаю вопрос, генерировал только простой но объемный.


Я о том, что при классических подходах (типа onNthF_ckingComponentEvent) сложность реализации возрастает очень быстро. Максим об этом хорошо написал :
True Unix GUI
Автор: McSeem2
Дата: 04.04.06


LCR>>+: я тоже считаю, что умный layout лучше, чем умное ёрзание мышкой, но с автоматическими генераторами GUI по спецификациям всё довольно мрачно как раз из-за последнего пункта (мы использовали Java+XSLT).


FR>Ну динамическим языкам часто просто не нужен дополнительный язык описания все можно выразить на одном языке.

Согласен, это плюс.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 29.05.06 06:49
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Я о том, что при классических подходах (типа onNthF_ckingComponentEvent) сложность реализации возрастает очень быстро. Максим об этом хорошо написал :

LCR>True Unix GUI
Автор: McSeem2
Дата: 04.04.06


Так он же вроде про тоже самое что и я, что динамические языки при построении GUI одновременно могут использоватся и как декларативные языки для описания так и как код выполняющий обработку.
Re[11]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 07:49
Оценка:
Здравствуйте, FR, Вы писали:

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


LCR>>Я о том, что при классических подходах (типа onNthF_ckingComponentEvent) сложность реализации возрастает очень быстро. Максим об этом хорошо написал :

LCR>>True Unix GUI
Автор: McSeem2
Дата: 04.04.06


FR>Так он же вроде про тоже самое что и я, что динамические языки при построении GUI одновременно могут использоватся и как декларативные языки для описания так и как код выполняющий обработку.


Подожди, ты хочешь сказать, что я пишу некий конфиг (скажем к sendmail), и потом запускаю этот конфиг под питоном, и оно чудом выдаёт формочку соответствующие этому конфигу? Причём уже с валидацией, layout-ом и т.п. И всё что мне остаётся — это написать мясцо для обработки этих данных?

Чую, что до "code is data is code" картинка всё же не дотягивает... Или я не прав?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 29.05.06 08:26
Оценка: 9 (1)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:


FR>>Так он же вроде про тоже самое что и я, что динамические языки при построении GUI одновременно могут использоватся и как декларативные языки для описания так и как код выполняющий обработку.


LCR>Подожди, ты хочешь сказать, что я пишу некий конфиг (скажем к sendmail), и потом запускаю этот конфиг под питоном, и оно чудом выдаёт формочку соответствующие этому конфигу? Причём уже с валидацией, layout-ом и т.п. И всё что мне остаётся — это написать мясцо для обработки этих данных?


Да только конфиг уже не будет произвольным, у него будет особый формат, чтобы он одновременно был и программой на питоне (или tcl) и вполне декларативным описанием.

LCR>Чую, что до "code is data is code" картинка всё же не дотягивает... Или я не прав?


Ну немного не дотягивает, хотя принцип вроде тот же, данные это одновременно и код.
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 29.05.06 09:09
Оценка: 14 (1)
Здравствуйте, IT, Вы писали:

IT>Демонстрация лёгкого построения ГУИ. Рабочий код приводить совсем не обязательно, генерируемый радакторами код тоже. Просто хотя бы идею обозначить.


Тк тем и хорош, что позволяет описывать логику ГУИ

IT>Для примера, для такого простого диалога, поддерживающего валидацию и подсветку изменённых полей


подсветка добавляется парой команд. (только нафига она нужна?)

# функция валидации
proc test {val} {
    tk_messageBox -message $val
    return 1
}

# toplevel окно. не обязательно.
set w {}

# фрейм с информацией о человеке
set info $w.info
# пакуем сверху, растягиваем по горизонтали
pack [frame $info -padx 2 -pady 2] -side top -fill x 

#растягиваем 2-й столбец на всю длину
grid columnconfigure $info 1 -weight 1
#вставляем нужные поля
foreach row {{n1 "First Name"} {n2 "Middle Name"} {n3 "Last Name"}} {
#для каждого entry можно прибиндить переменную, которая будет изменяться в соответствии с вводом
    grid [label $info.l[lindex $row 0] -text [lindex $row 1] -anchor w] [entry $info.[lindex $row 0] -text [lindex $row 1]] -sticky we
}

# определяем функцию валидации для 2-го поля
$info.n2 config -validate key -vcmd {test %P}

# добавляем радиобуттон
set radio $w.radio
pack [labelframe $radio -text "Gender" -pady 2 -padx 2] -side top
foreach item {Female Male Unknown Other} {
    radiobutton $radio.the$item -text $item -variable gender -relief flat -anchor w -value $item
    pack $radio.the$item -side top -fill x
}

# снизу добавляем фрейм с кнопками
pack [frame $w.action -padx 10 -pady 10] -side bottom -fill x
pack [button $w.action.save -text Save -width 10] -side left
pack [button $w.action.cancel -text Cancel -width 10 -command exit] -side right


IT>


картинки вставлять не умею, уж извини. (если интересно, могу прислать по маилу)

IT>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


Для тк этот код может генерировать кто угодно. никакие редакторы форм не обязательны.
Ты можешь вставить в форму едитбокс и в реальном времени изменять эту форму.
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 09:10
Оценка: +1
FR,

FR>Да только конфиг уже не будет произвольным, у него будет особый формат, чтобы он одновременно был и программой на питоне (или tcl) и вполне декларативным описанием.


Да, понял.

LCR>>Чую, что до "code is data is code" картинка всё же не дотягивает... Или я не прав?


FR>Ну немного не дотягивает, хотя принцип вроде тот же, данные это одновременно и код.


Ладно, мне всё понятно (Мне эта идея, кстати, очень нравится (я имею ввиду "code is data is code")).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 29.05.06 14:22
Оценка: +1 -1 :)
Здравствуйте, night beast, Вы писали:

NB>Тк тем и хорош, что позволяет описывать логику ГУИ


ГУИ надо рисовать, а не описывать.

NB>подсветка добавляется парой команд. (только нафига она нужна?)


Это ты у пользователей спроси

NB>
NB>pack [frame $info -padx 2 -pady 2] -side top -fill x 
NB>pack [frame $w.action -padx 10 -pady 10] -side bottom -fill x
NB>

А почему в одном случае 2, а в другом 10?

IT>>[img]http://www.rsdn.ru/File/1/CsUIDemo.gif[/img]


NB>картинки вставлять не умею, уж извини. (если интересно, могу прислать по маилу)


Ну вот, в таком птичьем языке разобрался, а с простейшими тегами форматирования нет

IT>>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


NB>Для тк этот код может генерировать кто угодно. никакие редакторы форм не обязательны.


Редактроы форм нужны не для того, чтобы что-то там генерировать. Как раз генерация — это побочный эффект реализации. Редакторы форм, как это ни странно, нужны, чтобы не заниматься рутинной стрельбой по пикселям, пристреливая контролы к форме. В том же веб, например, многие имеют все эти дизайнеры ввиду, т.к. проще и быстрее набить html ручками. Но это лишь потому, что лэйаут html контролов подчиняется своим, не связанным с абсолютным позиционированием правилам. Эта причина не единственная, конечно, но одна из основных.

NB>Ты можешь вставить в форму едитбокс и в реальном времени изменять эту форму.


Да это без проблем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 30.05.06 04:26
Оценка:
Здравствуйте, IT, Вы писали:

NB>>Тк тем и хорош, что позволяет описывать логику ГУИ


IT>ГУИ надо рисовать, а не описывать.


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

NB>>
NB>>pack [frame $info -padx 2 -pady 2] -side top -fill x 
NB>>pack [frame $w.action -padx 10 -pady 10] -side bottom -fill x
NB>>

IT>А почему в одном случае 2, а в другом 10?

да просто так

NB>>картинки вставлять не умею, уж извини. (если интересно, могу прислать по маилу)


IT>Ну вот, в таком птичьем языке разобрался, а с простейшими тегами форматирования нет


с самими тегами проблем нет. картинку куда-то на рсдн заливать надо...
то-ли дело в гугл-группах.

IT>>>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


NB>>Для тк этот код может генерировать кто угодно. никакие редакторы форм не обязательны.


IT>Редактроы форм нужны не для того, чтобы что-то там генерировать. Как раз генерация — это побочный эффект реализации. Редакторы форм, как это ни странно, нужны, чтобы не заниматься рутинной стрельбой по пикселям, пристреливая контролы к форме.


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

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


в этом смысле хтмл ничем не отличается от любого другого нормального гуи (тк например )

NB>>Ты можешь вставить в форму едитбокс и в реальном времени изменять эту форму.


IT>Да это без проблем.


допустим, нахаляву получаешь возможность в писать

walk $player dx dy
hit $player $enemy
...

и видеть все изменения в реальном времени.
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.05.06 11:34
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ты сделал громкое заявление, что ГУИ на Tcl делать, цитирую "проще чем в C#".


Если гуй ограничить только тем, что можно накидать в визуальном редакторе на формы, то, конечно, проще врядли где получится. Правда, сложнее тоже сделать тяжело. Но, только шаг в лево, шаг в право... А вот виджеты в Tcl/Tk это нечто вроде xhtml+css+dom+JavaScript.

IT> Всё чего я хочу, так это увидеть хотя бы аналогичный моему пример, диалог, который умеет редактировать внешний объет. Если это так просто на Tcl, то тебе всего лишь надо привести пример из максимум 7-ми строчек кода. Код, генерируемый RAD и код библиотек я тебе приводить не предлагаю. Меня интересует заявленная тобой простота их использования, выраженная в количестве рукописного кода. В примере, который я привёл — это ровно 1 строка, вот эта:


IT>
IT>binder.Object = person;
IT>

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

Давно не юзал tcl, но "чего-то подного" есть:

set form [editPerson $object]


И что с того? Пример то куцый. Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 30.05.06 12:38
Оценка: :)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>Ты сделал громкое заявление, что ГУИ на Tcl делать, цитирую "проще чем в C#".


ANS>Если гуй ограничить только тем, что можно накидать в визуальном редакторе на формы, то, конечно, проще врядли где получится. Правда, сложнее тоже сделать тяжело. Но, только шаг в лево, шаг в право... А вот виджеты в Tcl/Tk это нечто вроде xhtml+css+dom+JavaScript.


Тут было безапелляционно заявлено, что C# отдыхает, рулит в гуях сегодня tcl. Вот это не соответствующее истине заявление я и попытался развеять.

ANS>Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.


Так это всё тоже в дизайнере задаётся или как в данном примере автоматически библиотечным/один-раз-написанным кодом.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 30.05.06 12:46
Оценка:
Здравствуйте, night beast, Вы писали:

IT>>А почему в одном случае 2, а в другом 10?


NB>да просто так


Т.е. пристреливаем контролы к форме

IT>>Ну вот, в таком птичьем языке разобрался, а с простейшими тегами форматирования нет


NB>с самими тегами проблем нет. картинку куда-то на рсдн заливать надо...


В профиле есть ссылка на файлы.

NB>то-ли дело в гугл-группах.


А как там сделано, может и мы идейку потырим.

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


Где бы посмотреть скриншотик образцово показательной картинки таких гуёв. А то что-то меня мучают смутные подозрения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 30.05.06 13:13
Оценка: +2
Здравствуйте, IT, Вы писали:


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


IT>Где бы посмотреть скриншотик образцово показательной картинки таких гуёв. А то что-то меня мучают смутные подозрения.


Так он не обязывает делать вручную, есть и RAD'ости, например:
http://vtcl.sourceforge.net/
http://vtcl.sourceforge.net/?x=screen
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.05.06 13:27
Оценка: +4
Здравствуйте, IT, Вы писали:

ANS>>Если гуй ограничить только тем, что можно накидать в визуальном редакторе на формы, то, конечно, проще врядли где получится. Правда, сложнее тоже сделать тяжело. Но, только шаг в лево, шаг в право... А вот виджеты в Tcl/Tk это нечто вроде xhtml+css+dom+JavaScript.


IT>Тут было безапелляционно заявлено, что C# отдыхает, рулит в гуях сегодня tcl. Вот это не соответствующее истине заявление я и попытался развеять.


У тебя не получилось.

ANS>>Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.


IT>Так это всё тоже в дизайнере задаётся или как в данном примере автоматически библиотечным/один-раз-написанным кодом.


Вот хочу я прикрутить спел-чекер. Движок есть. Что я должен задать в дизайнере, чтобы RichTextBox начал с ним работать? А в Tk уже всё (я вверху выделил) написано. Вот и вся разница.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 30.05.06 14:02
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>>>А почему в одном случае 2, а в другом 10?


NB>>да просто так


IT>Т.е. пристреливаем контролы к форме


отступы можно

NB>>то-ли дело в гугл-группах.


IT>А как там сделано, может и мы идейку потырим.


да просто есть возможность приложить к сообщению файл.
некоторые вставляют картинки в тело письма. как -- х.з

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


IT>Где бы посмотреть скриншотик образцово показательной картинки таких гуёв. А то что-то меня мучают смутные подозрения.


все зависит от того, что ты понимаешь под словом образцово.
вот простенький просмотрщик текстовых словарей



обычное натив гуи.
при изменении размеров нужные нужные части подстраиваются (как в хтмл только удобнее)
результат тот-же что и при работе с билдером, только полученый другим путем.
ну и халявная поддержка скриптов.
Re[17]: Зачем нужен Немерле
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 00:10
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>И что?

FR>Ну введут в C# 3 некторые минимальные функциональные возможности, для использования которых не надо перестраивать мышление и плюс встроят пару специализированных DSL, это же как небо и земля по сравнение с Nemerle.

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

FR>Взять тот же C++, большинство не пользуются метопрограммированием, в лучшем случае используют готовые библиотеки написанные с его использованием. И вообще здесь по моему переоценивают важность метопрограммирования.


Дык и чем хуже Немерле? Будет точно так же. Кто-то будет использовать его как улучшеный C# (как когда-то С++ использовали как улучшенный С), а кто-то будет писать мета-код для общего использования.

Вот, шутки, шутками, а Остиновская работа рожденная в процессе доказательства, что Немерле не ишак (т.е. в процессе пенисометрии) в предь будет включаться в план ежедневного тестирования Немерла и будет доступна всем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 00:10
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если привык к стеку то все просто.


Да, да... Если привык к стеку... Если привык к программированию в АСТ... Если привык... Большинство людей не будет привыкать к убогости. Ведь есть неплохая альтернатива.


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


FR>http://www.forth.org.ru/


Спасибо, мне эта ссылка на фиг не ппала. Ты дай ссылку на статью на русском. А то я там что-то ничего хорошего не нашел.

VD>>Здорово, но писать свои языки вместо работы как-то не хочется. Меня олее устраивает качественный, высокоуровневый, гибкий язык программирования общего назначения который можно подстраивать под свои нужды.


FR>Там только идея одинаковая а реализации совершено разные, и смысл их сравнить есть.


Сравни, а мы опубликуем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 01:59
Оценка: :))
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Вот хочу я прикрутить спел-чекер. Движок есть. Что я должен задать в дизайнере, чтобы RichTextBox начал с ним работать? А в Tk уже всё (я вверху выделил) написано. Вот и вся разница.


Выбрать страницу событий и обработать одно из них. А если спилчекер умеет сам подключаться к событиям, то вообще только настроить. В общем, все зависит от проектирования спилчекера.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 01:59
Оценка: -4
Здравствуйте, FR, Вы писали:

FR>Так он не обязывает делать вручную, есть и RAD'ости, например:

FR>http://vtcl.sourceforge.net/
FR>http://vtcl.sourceforge.net/?x=screen

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

Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 01.06.06 08:40
Оценка: 32 (6) +4 :)
Здравствуйте, VladD2, Вы писали:

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


Он *расширяется* средсвами языка на котором ведётся разработка, к нему есть (ну ладно, в 2000 году, когда я последний раз использовал Tcl/Tk было, а сейчас не знаю) несколько наборов виджетов на все случаи жизни. В *море* готовых контролов нет острой необходимости, потому что все наличные виджеты легко расширяются и модифицируются.

Что-бы не быть голословным приведу пример, который я использовал.
Использовался код

# <s>------------------------------------------------------------------</s>
# EXAMPLE: appointment schedule widget
# <s>------------------------------------------------------------------</s>
# Effective Tcl/Tk Programming
# Mark Harrison, DSC Communications Corp.
# Michael McLennan, Bell Labs Innovations for Lucent Technologies
# Addison-Wesley Professional Computing Series
# ======================================================================
# Copyright © 1996–1997 Lucent Technologies Inc. and Mark Harrison
# ======================================================================


Вот код создания виджета (коментарии жирным — мои):
#  USAGE:  appointment_create <win>
#
#  Creates one page in an appointment book.  This includes a text
#  widget with some special tags and bindings, and a scrollbar.
#  Information is loaded into the page via appointment_load.
# ----------------------------------------------------------------------
proc appointment_create {win} {
   frame $win -class Appointment

   scrollbar $win.sbar -command "$win.text yview"
   pack $win.sbar -side right -fill y

    #Тут создаётся текстовый виджет (аналог RichTextEdit)
    # с вертикальным скролбаром с двумя колонками: 
    # одна 2 сантиметра от левого края и с 
    # правым выравниванием, другая - 2,4 см с левым.
    #
   text $win.text -background white -wrap word \
       -cursor left_ptr -tabs {2c right 2.4c left} \
       -yscrollcommand "$win.sbar set"
   pack $win.text -side left -expand yes -fill both

   #
   # Set up tags for the various text styles...
   #
     # Тэги - это нечто вроде стилей
     # Они имеют ряд свойст, которые исменяют
     # как внешний вид так и поведение элементов,
     # к которым эти теги привязаны. То есть,
     # изменени некого визуального атрибута в тэге
     # изменяет внешний вид всех элементов к которым
     # этот тег привязан. К одному элементу можно
     # привязывать много тегов.
     #
     # Тут конфигурируются теги title, date, hour, 
     # comment, stripe, space.
     # 
     # Строчка 'option get $win titleFont Font' это
     # получение значений из внешних конфигов.
     # На 'X' это родной механизм, по виндами - эмуляция
     
   $win.text tag configure title \
       -font [option get $win titleFont Font]

   $win.text tag configure date \
       -font [option get $win dateFont Font]

   $win.text tag configure hour \
       -font [option get $win hourFont Font]

   $win.text tag configure comment \
       -lmargin1 2.4c -lmargin2 2.4c \
       -font [option get $win commentFont Font]

   $win.text tag configure stripe \
       -background [option get $win stripeBackground Background] \
       -foreground [option get $win stripeForeground Foreground]

   $win.text tag configure space -spacing1 5

   #
   # Set up bindings to handle appointment editing...
   #
   set btags [bindtags $win.text]
   set i [lsearch $btags Text]
   if {$i >= 0} {
       set btags [lreplace $btags $i $i]
   }
   bindtags $win.text $btags

    #Тут ничего необычного - обработка событий клавиатуры...
   bind $win.text <KeyPress> "appointment_insert $win %W %A"
   bind $win.text <Control-KeyPress-h> "appointment_backspace $win %W"
   bind $win.text <KeyPress-BackSpace> "appointment_backspace $win %W"
   bind $win.text <KeyPress-Delete> "appointment_delete $win %W"
   bind $win.text <KeyPress-Tab> "appointment_next $win %W; break"
   bind $win.text <KeyPress-Down> "appointment_next $win %W; break"
   bind $win.text <KeyPress-Up> "appointment_prev $win %W; break"
   bind $win.text <KeyPress-Left> "appointment_left $win %W; break"
   bind $win.text <KeyPress-Right> "appointment_right $win %W; break"

   #
   # Bind to the "comment" fields to let the user position
   # the cursor...
   #
    #... и нажатий мыши
   $win.text tag bind comment <ButtonPress-1> "
       focus %W
       %W mark set insert @%x,%y
   "

   return $win
}


Теперь пример добавления строчек в виджет:
# ----------------------------------------------------------------------
#  USAGE:  appointment_load_slot <win> <slot> <appmt> <allSlots>
#
#  Adds a single line to the appointment book <win>.  Each line
#  represents one time slot.  <slot> contains the hour like "8:00am".
#  <appmt> is a list containing the alarm setting and the comment
#  message.  <allSlots> is a list of all of the slots, in the order
#  that they are displayed on the page.
# ----------------------------------------------------------------------
proc appointment_load_slot {win slot appmt allSlots} {
   if {[string match "*:00" $slot]} {
       set htags "hour space"
   } else {
       set htags "hour"
   }
     # htags - это набор тэтов, согласно которым
     # меняется внешний вид текста
     # Текст добавляется уже с тэгами (последняя переменная).
   $win.text insert end "\t$slot\t" $htags

   appointment_load_bell $win $slot $appmt

   set pos [lsearch $allSlots $slot]
   if {$pos % 2 != 0} {
       set ctags "comment stripe"
   } else {
       set ctags "comment"
   }
   set mesg [lindex $appmt 1]
   $win.text insert end "$mesg\n" $ctags
}


Переход между строчками:
# ----------------------------------------------------------------------
#  USAGE:  appointment_next <twin>
#
#  Moves to the next appointment slot on the text widget <twin>.
# ----------------------------------------------------------------------
proc appointment_next {win twin} {
   set range [$twin tag nextrange hour insert]
   if {$range != ""} {
       set index [lindex $range 0]
       set range [$twin tag nextrange comment $index]
       set index [lindex $range 0]
       $twin mark set insert $index
   }
   $twin see insert
}


Весь код приводить естественно не стану.
Вот внизу картинка того как оно выглядит. Поставить курсор куда-то кроме поля для ввода текста нельзя. Автоматически развдигаются строчки для ввода кода. По умолчанию поле со временем белое, я его сделал желтым что-бы выделить. Добавлю еще, что не смотря на то, что исходно Tcl на поддерживает никакого ООП, сами виджеты традиционно работают по вполне ООП схеме.
Например, .but configure ....
Тут .but — это кнопка, объект-получатель сообщения 'configure' с параметрами ..... Достигается это путём создания процедуры которая и занимается "диспетчеризацией" сообщений. В далёком 2000 "pure tcl" виджеты в разных виджетсетах работали с нормальной скоростью.
То есть то что получился полноценный виджет, отличающийся довольно радикально от исходного текстового. Работает на куче платформ.

А теперь внимание вопрос, как расширить RichTextEdit до чего-то подобного? Вопрос дялеко не праздный, так как попытавшись изменить поведение какого-то контрола, я вдруг с удивлением узнал, что у него половина методов не виртуальные, и наследников создавать бесполезно, а переписывать с нуля — не спортивно.



VD>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.


А я уж думаю думаю, неужели у Влада 5 копеек нету? Тогда просвети, Влад, ты зачем сцинтилу прикручивал я Янусу? Почему не расширил функциональность стандартных котролов? Так вот, Влад, "убожество" это когда, чтобы что-то сделать приходся брать сторонний контрол, или переписывать всё с нуля. "Коде реюзе", блин.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 15:00
Оценка: +1 -4 :)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


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


ANS>В *море* готовых контролов нет острой необходимости, потому что все наличные виджеты легко расширяются и модифицируются.


Да? Ну, тода тебе не составит труда быстренько продемонстрировать мне расширение уж низнаю чего, но так чтобы оно по функциональности было как Инфрагистевский или ДевЭеспресовский грид. ОК? А до тех пор не надо смешить окружающих.

ANS>А теперь внимание вопрос, как расширить RichTextEdit до чего-то подобного? Вопрос дялеко не праздный, так как попытавшись изменить поведение какого-то контрола, я вдруг с удивлением узнал, что у него половина методов не виртуальные, и наследников создавать бесполезно, а переписывать с нуля — не спортивно.


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

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

VD>>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.


ANS>А я уж думаю думаю, неужели у Влада 5 копеек нету? Тогда просвети, Влад, ты зачем сцинтилу прикручивал я Янусу? Почему не расширил функциональность стандартных котролов?


А Сцинтила и есть контрол расширяющий функциональность. Сделать качественный редактор кода из RTF-редактора нельзя в принципе. У них разные принцыпы работы и задачи.

ANS> Так вот, Влад, "убожество" это когда, чтобы что-то сделать приходся брать сторонний контрол, или переписывать всё с нуля. "Коде реюзе", блин.


Не. Возможность взять сторонний контрол или разработать его самому — это как раз универсальное решение позволяющее не мериться с убогостью окружающей среды. А вот ссылаться на разные tcl при обсуждении убогости дизайна С++ — это как раз красноречивешее свидетельство того, что язык не полноценен и требует моря подпорок для реальной жизни.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 01.06.06 16:56
Оценка: 1 (1) +4
Здравствуйте, VladD2, Вы писали:

VD>RichTextEdit это обертка для виндового контрола. Если что-то не расширяется средствами самого контрола, то всегда можно ловить виндовые сообщения.

VD>Короче это переход с обсуждения средсва разработки н набор контролов. ГУИ на базе tcl которые я видел были на редкость убогими. Так что его рутость мне даже обсждать не хочется.

VD>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок. А для С++ мне нужные разные подпорки вроде внешних кодогенераторов или отдельного скриптового языка tcl?


ваша эрудиция прямо таки потрясает воображение.
а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?
наверно это очень увлекательно, бороться с ветряными мельницами...
Re[10]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 01.06.06 18:22
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


У тебя все что не NET убого, так что это не аргумент. Ну и посмотрим на сколько неубогим станет NET если будет подерживать столько же платформ сколько и tcl/tk.
Он может расширятся как и средствами языка на котором ведется разработка так и с помощью си — с++
На него достаточно много готовых контролов от других производителей.

VD>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.


Нет просто ты достаточно часто ничего ни зная о предмете любишь делаеть безапиляционные заявления.
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 04:40
Оценка: +1 -1 :)))
Здравствуйте, night beast, Вы писали:

NB>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?


А что поделаешь, если это не далеко от истины
C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 02.06.06 04:49
Оценка:
Здравствуйте, IT, Вы писали:

NB>>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?


IT>А что поделаешь, если это не далеко от истины


только вот к теории упругости не имеет никакого отношения

IT>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.


ну а по поводу устаревший -- фортран тоже устаревший.
тем не менее на нем работает куча народа.
и будет работать дальше.
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 05:06
Оценка: +1 -1 :)
Здравствуйте, IT, Вы писали:

IT>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.


Выделенное не правда. Комитет всего лишь систематизировал часть предложений пользователей C++. Лишь небольшую часть предложений.

Если почитать Страуструпа, то становится понятно, что у C++ были настолько разнородные пользователи, в настолько разных предметных областях C++ применялся, насколько разные требования к нему предъявлялись, настолько разные по своему характеру и целям люди входили в комитет, что хорошо еще, что язык C++ вообще получился таким, какой он есть. Могло быть гораздо хуже.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 05:06
Оценка:
Здравствуйте, night beast, Вы писали:

NB>>>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?

IT>>А что поделаешь, если это не далеко от истины
NB>только вот к теории упругости не имеет никакого отношения

Зато к теме топика имеет самое непосредственное

IT>>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.


NB>ну а по поводу устаревший -- фортран тоже устаревший.

NB>тем не менее на нем работает куча народа.

А какая куча народа на нём не работает!

NB>и будет работать дальше.


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

Что же касается плюсов, то от острия они тоже уже отдалились на весьма приличное расстояние.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 05:17
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

IT>>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.

E>Выделенное не правда. Комитет всего лишь систематизировал часть предложений пользователей C++. Лишь небольшую часть предложений.

Почему неправда? Я про небольшую часть и говорю. Небольшую часть, отвечающую интересам комитета.

E>Если почитать Страуструпа, то становится понятно, что у C++ были настолько разнородные пользователи, в настолько разных предметных областях C++ применялся, насколько разные требования к нему предъявлялись, настолько разные по своему характеру и целям люди входили в комитет, что хорошо еще, что язык C++ вообще получился таким, какой он есть. Могло быть гораздо хуже.


Кто знает, может быть хуже, а может и гораздо лучше

Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу А вот свойствами (расширениями от производителей) пользовался во всю как только узнал, что они есть. Потому что удобно. И теперь ты мне можешь до посинения рассказывать, почему mutable нужен в языке, а property, которую реализовать фигня как два байта об асфальт, оказалась вещью, по мнению Страуструпа не нужной и бесполезной.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 02.06.06 05:26
Оценка:
Здравствуйте, IT, Вы писали:

NB>>только вот к теории упругости не имеет никакого отношения


IT>Зато к теме топика имеет самое непосредственное


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

NB>>ну а по поводу устаревший -- фортран тоже устаревший.

NB>>тем не менее на нем работает куча народа.

IT>А какая куча народа на нём не работает!


как и на .Нет

NB>>и будет работать дальше.


IT>Флаг в руки и барабан на шею. Впрочем, не думаю, что эти несчастные работают на фортране по собственной воле. А если им или они сами себе всё же внушили такую глупость, то не думаю, что они сами же полагают, что находятся на острие передовых технологий


у фортрана огромное количество библиотек численных расчетов.
хороший оптимизатор. некоторым большего и не надо.

IT>Что же касается плюсов, то от острия они тоже уже отдалились на весьма приличное расстояние.


а где нынче острие, интересно?
Re[16]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 02.06.06 05:39
Оценка: :)
Здравствуйте, IT, Вы писали:

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


иногда нужно. делал linked умный указатель.

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


без них вполне можно жить. если тяжело, то можно эмулировать.
а const_cast эмулировать нельзя.
Re[16]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 06:07
Оценка:
Здравствуйте, IT, Вы писали:

IT>Почему неправда? Я про небольшую часть и говорю. Небольшую часть, отвечающую интересам комитета.


Потому что не было такого понятия, как "интересы комитета". Были интересы отдельных групп в коммитете.

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


Пользовался. И пользуюсь время от времени (где-то раз в полгода). В последний раз использовал для проведения отложенных вычислений в константном объекте. Т.е., есть объект, доступный через константный указатель или ссылку. Обычно у него вызваются всего несколько самых частоиспользуемых методов. Эти методы тривиальны и эффективны. Но иногда требуется вызвать некий "тяжелый" метод, который должен провести ряд дорогих преобразований (сериализация нескольких объектов для получения уникальной бинарной строки). Вот в этом методе mutable оказывается восстребован.

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


А вот у меня никогда ни возникало желания использовать property.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 02.06.06 07:27
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Да? Ну, тода тебе не составит труда быстренько продемонстрировать мне расширение уж низнаю чего, но так чтобы оно по функциональности было как Инфрагистевский или ДевЭеспресовский грид. ОК? А до тех пор не надо смешить окружающих.


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

VD>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок.


Пока это не было продемонстрировано.

VD> А для С++ мне нужные разные подпорки вроде внешних кодогенераторов или отдельного скриптового языка tcl?


Проблемы С++ меня не интересуют, но, неужели в программе на С++ нельзя использовать сцинтилу или вышеупомянутый грид?

VD>Сделать качественный редактор кода из RTF-редактора нельзя в принципе.


Вот это убожество и есть.

ANS>> Так вот, Влад, "убожество" это когда, чтобы что-то сделать приходся брать сторонний контрол, или переписывать всё с нуля. "Коде реюзе", блин.


VD>Не. Возможность взять сторонний контрол


Это уневерсальное решение?

VD>или разработать его самому —


это, да универсальное. Но есть одна загвоздка, и С++ и С# и Tcl одинаково универсальны. Так о чем разговор?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Kluev  
Дата: 02.06.06 08:18
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


VD>>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок.


Да просто из-за политики микрософта. По дефолту с VC идет недоношеный обрубок MFC, хотя даже его можно довести до ума. Взять например комерческие MFC-расширения типа BCG. Вполне можно программировать, достаточно грамотно сделано.
Re[17]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 11:52
Оценка:
Здравствуйте, night beast, Вы писали:

NB>а const_cast эмулировать нельзя.


(const XXX*)? Или ты dynamic имел ввиду?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 11:58
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>Почему неправда? Я про небольшую часть и говорю. Небольшую часть, отвечающую интересам комитета.

E>Потому что не было такого понятия, как "интересы комитета". Были интересы отдельных групп в коммитете.

Давай рассуждать логически, давай? Интересы в группах, группы в комитете, значит интересы в результате где? Правильно, в комитете.

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


E>Пользовался. И пользуюсь время от времени (где-то раз в полгода).


А class, if, while ты тоже раз в пол года используешь?

E>А вот у меня никогда ни возникало желания использовать property.


Не знал, что такое возможно, вот никогда и не возникало желание.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 12:04
Оценка:
Здравствуйте, IT, Вы писали:

NB>>а const_cast эмулировать нельзя.


IT>(const XXX*)? Или ты dynamic имел ввиду?


const_cast -- это вот для этого:
void f( const int * i )
  {
    *(const_cast< int * >( i )) = 0;
  }


Он снимает константность (заодно и volatile).
Без него можно обойтить приведением в стиле C:
*((int *)i) = 0;

Но приведения в стиле C в C++ не приветствуются. Как и вообще приведения типов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 12:16
Оценка: +2 -1
Здравствуйте, IT, Вы писали:

IT>Давай рассуждать логически, давай? Интересы в группах, группы в комитете, значит интересы в результате где? Правильно, в комитете.


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

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

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


E>>Пользовался. И пользуюсь время от времени (где-то раз в полгода).


IT> А class, if, while ты тоже раз в пол года используешь?


А при чем здесь это. Ты про mutable спрашивал -- я тебе ответил. mutable -- это способ указать компилятору, что объект при видимой логической константности не имеет физической константности (как в приведенном мной примере). Поэтому такой объект нельзя размещать в ROM. Поскольку такие случаи по определению не могут быть слишком частыми, то mutable и используется на несколько порядков раз реже чем остальные конструкции языка. Но зато это единственный способ сказать компилятору о своих намерениях. В отличии от использования const_cast где-то под ковром.

E>>А вот у меня никогда ни возникало желания использовать property.


IT>Не знал, что такое возможно, вот никогда и не возникало желание.


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

Ты мне лучше скажи, кроме Borland C++ и Visual C++ в каких еще компиляторах поддерживались property?
И были ли property в Borland C++ синтаксически и семантически эквивалентны таковым в Visual C++.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 12:17
Оценка:
Здравствуйте, eao197, Вы писали:

NB>>>а const_cast эмулировать нельзя.

IT>>(const XXX*)? Или ты dynamic имел ввиду?

E>const_cast -- это вот для этого:


Я в курсе, что это нужно для хаков.

E>Но приведения в стиле C в C++ не приветствуются. Как и вообще приведения типов.


Т.е. НЕЛЬЗЯ!!! Но если очень хочется, то можно
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 02.06.06 12:18
Оценка:
Здравствуйте, IT, Вы писали:

NB>>а const_cast эмулировать нельзя.


IT>(const XXX*)? Или ты dynamic имел ввиду?


из той же оперы что и mutable, только более опасный. снимает с объекта константность.

const int * y = &x;
int * z = const_cast<int *> (y);
Re[20]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 12:28
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Я в курсе, что это нужно для хаков.


E>>Но приведения в стиле C в C++ не приветствуются. Как и вообще приведения типов.


IT>Т.е. НЕЛЬЗЯ!!! Но если очень хочется, то можно


А это вообще философия C++: дать инструмент, который позволяет обходиться без хаков. НО! Если сильно-сильно захочется, то дать возможность обойти ограничения компилятора. Ответственность при этом полностью перекладывается на программиста в расчете на то, что программист сам знает, что делает.

Кроме того, const_cast иногда оказывается нужным при работе с каким-нибудь унаследованным кодом, в котором разработчики не озаботились правильно использовать константность. Например, если где-то есть:
extern int crypt_file( char * file_name, char * crypt_device_name );

то у меня нет другого выхода, кроме как написать:
void some_my_code( const std::string & file_name, const crypting_params_t & params )
  {
    crypt_file( const_cast< char * >( file_name.c_str() ),
      const_cast< char * >( params.device_name().c_str() ) );
    ...
  }


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 12:32
Оценка:
Здравствуйте, eao197, Вы писали:

E> Странная какая-то логика, ведь у групп разные интересы, а комитет один. Поэтому нельзя считать, что интерес комитета -- это сумма интересов групп. Как раз интерес комитета состоял в том, чтобы сделать сделать жизнеспособное и востребованное пересечение из всех интересов групп.


Т.е. ты это называешь нахождением компромисса?

E>А при чем здесь это. Ты про mutable спрашивал -- я тебе ответил. mutable -- это способ указать компилятору, что объект при видимой логической константности не имеет физической константности (как в приведенном мной примере).


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

E>Ты мне лучше скажи, кроме Borland C++ и Visual C++ в каких еще компиляторах поддерживались property?


Без понятия

E>И были ли property в Borland C++ синтаксически и семантически эквивалентны таковым в Visual C++.


Разные. Но я тебе вот что скажу. После того как я пересел на VC++, меня другие компиляторы волновали раз или два, когда надо было написать кросскомпиляторный код. Но этот код был каплей в море в сравнении с тем, что мне приходилось делать на VC++ и только на нём. Разница в синтаксисе меня не волновала совсем. Гораздо важнее было удобство разработки, а совместимый синтаксис было nice to have, что я и имел с успехом ввиду, особенно учитывая, что приходлось много писать на MFC и ATL.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 12:33
Оценка: 3 (1) +1 -2 :)
Здравствуйте, eao197, Вы писали:

E>А это вообще философия C++:


Это философия граблей.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 12:44
Оценка:
Здравствуйте, IT, Вы писали:

E>> Странная какая-то логика, ведь у групп разные интересы, а комитет один. Поэтому нельзя считать, что интерес комитета -- это сумма интересов групп. Как раз интерес комитета состоял в том, чтобы сделать сделать жизнеспособное и востребованное пересечение из всех интересов групп.


IT>Т.е. ты это называешь нахождением компромисса?


Страуструп называл это нахождением консенсуса.

E>>А при чем здесь это. Ты про mutable спрашивал -- я тебе ответил. mutable -- это способ указать компилятору, что объект при видимой логической константности не имеет физической константности (как в приведенном мной примере).


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


Нет не нахожу. Я, например, никогда не сталкивался с компилятором и платформой, где объекты могут размещаться в ROM. Но, говорят, такие платформы есть. И кто-то для них пишет код каждый день. Я думаю, что для них mutable был очень важен и нужен. А его появление позволило сделать код переносимый на такие платформы. Без него приходилось бы разбираться, почему код с const_cast прекрасно работает на одном компиляторе, но ломает программу на другом.

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

E>>И были ли property в Borland C++ синтаксически и семантически эквивалентны таковым в Visual C++.


IT>Разные. Но я тебе вот что скажу. После того как я пересел на VC++, меня другие компиляторы волновали раз или два, когда надо было написать кросскомпиляторный код. Но этот код был каплей в море в сравнении с тем, что мне приходилось делать на VC++ и только на нём. Разница в синтаксисе меня не волновала совсем. Гораздо важнее было удобство разработки, а совместимый синтаксис было nice to have, что я и имел с успехом ввиду, особенно учитывая, что приходлось много писать на MFC и ATL.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 13:00
Оценка: 2 (2) +3 :)
Здравствуйте, IT, Вы писали:

E>>А это вообще философия C++:


IT>Это философия граблей.


На этот счет могут быть разные мнения , но словесное жонглирование не имеет смысла, т.к. философия C++ такая какая есть. Другой она уже не будет.

Язык C++ создавался как "улучшенный C" для системного программирования. Одной из целей при проектировании C++ было добиться того, чтобы C++ программисту для низкоуровневых вещей не требовались другие языки, кроме ассемблереа (т.е., чтобы сложные системы, требовавшие высокой эффективности и прямого доступа к аппаратным ресурсам, можно было писать только на C++, без привлечения C). А при системной программировании и работе с железом без хаков для обхода граблей (пораскиданными кем только не лень) не обойтись.

Вообще, после вот этой книги
Автор(ы): Бьерн Страуструп

В книге, написанной создателем языка C++ Бьерном Страуструпом, представлено описание
процесса проектирования и разработки языка программирования C++. Здесь изложены цели,
принципы и практические ограничения, наложившие отпечаток на структуру и облик C++,
обсужден дизайн недавно добавленных в язык средств: шаблонов, исключений, идентификации
типа во время исполнения и пространств имен. Автор анализирует решения, принятые в ходе
работы над языком, и демонстрирует, как правильно применять реальный
объектно-ориентированный язык программирования.
я пришел к выводу о том, что проблема C++ не в самом C++ (все его особенности, грабли, просчеты и пр. -- это объективная реальность, она никуда не денется). Проблема в том, что C++ популяризировал (продвинул в массы) ООП больше, чем Smalltalk, CLOS, Eiffel и иже с ними. И C++ начали применять там, где его использовать вообще не следовало. За что и поплатились.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[21]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 13:40
Оценка: -1
Здравствуйте, eao197, Вы писали:

IT>>Т.е. ты это называешь нахождением компромисса?

E>Страуструп называл это нахождением консенсуса.

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

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


E>Нет не нахожу. Я, например, никогда не сталкивался с компилятором и платформой, где объекты могут размещаться в ROM. Но, говорят, такие платформы есть. И кто-то для них пишет код каждый день. Я думаю, что для них mutable был очень важен и нужен. А его появление позволило сделать код переносимый на такие платформы. Без него приходилось бы разбираться, почему код с const_cast прекрасно работает на одном компиляторе, но ломает программу на другом.


Думаю, что они и так в этих проблемах по уши. И никакой mutable тут не поможет. Это как раз хороший пример того, что надо правильно проектировать, а не полагаться на допущение хаков компилятором.

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


И главное заметь, отсутствие дженериков не сделало java лучше.

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


Каждый поплевал на каждого, потом все вместе поплевали на пользователей. В результате получился современный C++.
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 13:45
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>На этот счет могут быть разные мнения , но словесное жонглирование не имеет смысла, т.к. философия C++ такая какая есть. Другой она уже не будет.


Философия и не должна быть другой. Нужно всего лишь сделать нормальный дизайн, соостветствующий современным требованиям.

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


Это всё отговорки. Ничто не мешает ввести в язык современные конструкции вроде свойств и делегатов. Но проще, конечно же, рассуждать об отсутствии воды.
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 13:51
Оценка: +1
Здравствуйте, IT, Вы писали:

E>>Страуструп называл это нахождением консенсуса.


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


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

E>>Нет не нахожу. Я, например, никогда не сталкивался с компилятором и платформой, где объекты могут размещаться в ROM. Но, говорят, такие платформы есть. И кто-то для них пишет код каждый день. Я думаю, что для них mutable был очень важен и нужен. А его появление позволило сделать код переносимый на такие платформы. Без него приходилось бы разбираться, почему код с const_cast прекрасно работает на одном компиляторе, но ломает программу на другом.


IT>Думаю, что они и так в этих проблемах по уши. И никакой mutable тут не поможет. Это как раз хороший пример того, что надо правильно проектировать, а не полагаться на допущение хаков компилятором.


А можешь рассказать, как приведенный мной пример сделать без mutable?

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


IT>Каждый поплевал на каждого, потом все вместе поплевали на пользователей. В результате получился современный C++.


Ну получился же. Теперь его можно в грязь втоптать. А можно вспомнить сотни языков, которые были до C++, были с C++ и будут после C++, но которые вообще никому не известны. Есть такой замечательный пример -- Eiffel. По совокупности всех имеющихся в нем возможностей, да еще с учетом времени его появления (1985) это вообще отличный язык. Глядя на него невольно задаешься вопросом -- как же вообще место для Java и C# под солнцем нашлось? А на практике -- где тот Eiffel, кому он на фиг нужен кроме тех, кого Бертран Мейер на бабки развел. Вот и получилось, что отличный в теории язык на практике не восстребован. И наоборот, корявый и убогий C++, в который здесь только ленивый не плюет, жив себе, курилка. Чего и всем остальным желает

Может быть это из-за того, что C++ создавался не для красоты, а чтобы практичекие задачи решать? Какие были задачи, такой и язык.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 14:04
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Философия и не должна быть другой. Нужно всего лишь сделать нормальный дизайн, соостветствующий современным требованиям.


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

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


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


Не мешает говоришь? Так введи. Какие проблемы? Берешь GCC или OpenWatcom и подкручиваешь C++ под себя.
А потом объясняешь, почему еще в двадцати (или сколько их там сейчас) компиляторах C++ нет никаких свойств или делегатов. И пытаешься заставить разработчиков этих компиляторов добавить их в свои творения.

К тому же рассуждать о том, что C++ динозавр и не соответствует современным требованиям действительно проще, чем признать, что нафиг не нужно было на C++ COM-ы писать.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 02.06.06 14:08
Оценка:
IT wrote:
> Думаю, что они и так в этих проблемах по уши. И никакой mutable тут не
> поможет. Это как раз хороший пример того, что надо правильно
> проектировать, а не полагаться на допущение хаков компилятором.
Стандартный пример для mutable — кэши и счетчики ссылок. Там mutable как
раз очень нужен и вполне логичен — так как изменение членов объекта не
приводит к изменению его инварианта.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 14:46
Оценка: +3 :)
Здравствуйте, eao197, Вы писали:

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


А как ты определяешь где и кому следует, где и кому не следует? И вообще, а судьи кто?

E>А можешь рассказать, как приведенный мной пример сделать без mutable?


Какой именно?

IT>>Каждый поплевал на каждого, потом все вместе поплевали на пользователей. В результате получился современный C++.


E>Ну получился же. Теперь его можно в грязь втоптать. А можно вспомнить сотни языков, которые были до C++, были с C++ и будут после C++, но которые вообще никому не известны.


Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.

E>Может быть это из-за того, что C++ создавался не для красоты, а чтобы практичекие задачи решать? Какие были задачи, такой и язык.

Вот как он эти задачи решает

CString fun(std::string s)
{
    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
}
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 15:00
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>А как ты определяешь где и кому следует, где и кому не следует? И вообще, а судьи кто?


Мне не нужно ничего определять и судить. Я на C++ помои не выливаю. Хотя мне не нравится, что с языком происходит. ИМХО, гораздо проще и конструктивнее сменить язык.

А кому и где не следует -- ты сам привел пример.

E>>А можешь рассказать, как приведенный мной пример сделать без mutable?


IT>Какой именно?


Описанный здесь
Автор: eao197
Дата: 02.06.06
, про ресурсоемкий метод, который вызывается у объекта через контантную ссылку/указатель.

IT>Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.


А мне как-то фиолетово, номер один язык, которым я пользуюсь или номер двадцать. Считается ли он мейнстримом или нет. Если меня язык устраивает, есть к нему библиотеки, есть информационные ресурсы, есть community -- этого достаточно.

IT>Вот как он эти задачи решает


IT>
IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>


А что бы ты хотел вместо этого? Чтобы C++ не позволял писать такой жуткий код? Так ведь целью C++ было не это. Он никогда не задумывался как простой и безопасный язык. НИКОГДА. Пора бы это понять.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 15:09
Оценка: 1 (1) +1 :)
Здравствуйте, IT, Вы писали:

E>>Может быть это из-за того, что C++ создавался не для красоты, а чтобы практичекие задачи решать? Какие были задачи, такой и язык.

IT>Вот как он эти задачи решает

IT>
IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>


Вот тебе еще один пример:
void f(CORBA::Octet o);
void f(CORBA::Boolean b); // Ambiguous
cout << ref—>getString(); // Leak
r1—>putString(r2—>getString()); // Leak
char *p = getString();
delete p; // Heap corruption
std::string s(ref—>getString()); // Leak
if(ref1 == ref2) ... // Undefined

(взят из документа A New Approach to Middleware Track Object-Oriented Middleware найденого когда-то на сайте http://www.zeroc.com).

Вот здесь C++ виноват в провоцировании всех показанных проблем или те, кто спроектировал такой маппинг CORBA на C++? Причем они ведь знали что такое C++ и чем черевато его неправильное использование.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kan_izh Великобритания  
Дата: 02.06.06 15:30
Оценка: :)
IT wrote:

> Вот как он эти задачи решает

Не решает, а решают те, кто не умеет читать документацию, у _bstr_t есть оператор приведения как к wchar_t*, так и к char*.

> CString fun(std::string s)
> {
>     return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
> }
> 
Достаточно
CString fun(std::string s)
{
    return _bstr_t(s.c_str());
}

и это необходимо только для unicode версии, т.к. тут перекодируется. Так что лучше не std::string использовать, а
std::basic_string<TCHAR> и тогда вообще не понадобится перекодирование.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 15:35
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

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


IT>>А как ты определяешь где и кому следует, где и кому не следует? И вообще, а судьи кто?


E>Мне не нужно ничего определять и судить.


Вот и не надо этого делать. Те кто используют C++ как-нибудь сами без тебя разберуться где его следует использовать.

E>Я на C++ помои не выливаю. Хотя мне не нравится, что с языком происходит.


Больше всего помоев в языке от комитета, поэтому он не нравится не только тебе.

E>ИМХО, гораздо проще и конструктивнее сменить язык.


Я именно это и сделал.

E>>>А можешь рассказать, как приведенный мной пример сделать без mutable?

IT>>Какой именно?
E>Описанный здесь
Автор: eao197
Дата: 02.06.06
, про ресурсоемкий метод, который вызывается у объекта через контантную ссылку/указатель.


Этот пример не описывает начальную постановку задачи. А решать проблему, в которую ты попал только известным тебе самому способом мне не интересно.

IT>>Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.


E>А мне как-то фиолетово, номер один язык, которым я пользуюсь или номер двадцать. Считается ли он мейнстримом или нет. Если меня язык устраивает, есть к нему библиотеки, есть информационные ресурсы, есть community -- этого достаточно.


Это мне понятно. Когда больше сказать нечего, то остаётся только надуть щёки и заявить "Уходи из нашей песочницы и больше не писай в мой горшок".

E>А что бы ты хотел вместо этого? Чтобы C++ не позволял писать такой жуткий код?


Я бы хотел в C++ иметь стандартный тип строки.

E>Так ведь целью C++ было не это. Он никогда не задумывался как простой и безопасный язык. НИКОГДА. Пора бы это понять.


О безопасности вроде как речь не шла. А то, что C++ как-то не так задумывался и вообще не для этого, то пора бы тебе понять самому — это всё ОТГОВОРКИ.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 15:44
Оценка:
Здравствуйте, IT, Вы писали:

IT>Вот и не надо этого делать. Те кто используют C++ как-нибудь сами без тебя разберуться где его следует использовать.


Уже разобрались. Да так, что программируя на C# только и знаю, что C++ ругать.

E>>>>А можешь рассказать, как приведенный мной пример сделать без mutable?

IT>>>Какой именно?
E>>Описанный здесь
Автор: eao197
Дата: 02.06.06
, про ресурсоемкий метод, который вызывается у объекта через контантную ссылку/указатель.


IT>Этот пример не описывает начальную постановку задачи. А решать проблему, в которую ты попал только известным тебе самому способом мне не интересно.


Так и запишем -- решение не предложено.

IT>>>Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.


E>>А мне как-то фиолетово, номер один язык, которым я пользуюсь или номер двадцать. Считается ли он мейнстримом или нет. Если меня язык устраивает, есть к нему библиотеки, есть информационные ресурсы, есть community -- этого достаточно.


IT>Это мне понятно. Когда больше сказать нечего, то остаётся только надуть щёки и заявить "Уходи из нашей песочницы и больше не писай в мой горшок".


А это каким боком здесь?

IT>Я бы хотел в C++ иметь стандартный тип строки.


Он есть -- std::basic_string.

E>>Так ведь целью C++ было не это. Он никогда не задумывался как простой и безопасный язык. НИКОГДА. Пора бы это понять.


IT>О безопасности вроде как речь не шла. А то, что C++ как-то не так задумывался и вообще не для этого, то пора бы тебе понять самому — это всё ОТГОВОРКИ.


Это не отговорки. Отговорки -- это очередные попыки обвинить C++ в том, что кому-то его трудно использовать. Если трудно -- значит либо знаний не хватает (а скорее здравого смысла), либо не подходит C++ для конкретной задачи. В конце-концов, на Запорожце в Формуле-1 не гоняются, а Камазы в качестве пасажирского такси не используют.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 15:46
Оценка:
Здравствуйте, kan_izh, Вы писали:

>> Вот как он эти задачи решает

_>Не решает, а решают те, кто не умеет читать документацию, у _bstr_t есть оператор приведения как к wchar_t*, так и к char*.

Молодец! Возьми на полке пирожок

А теперь включаем фантазию и попробуем представить проект, в котором одновременно используются MFC, ATL, #import и STL. В качестве примера можно взять какое-нибудь приложение на MFC, работающее как сервер автоматизации, поддерживающее дуальный IDispatch.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 02.06.06 15:53
Оценка: :)
IT wrote:
> А теперь включаем фантазию и попробуем представить проект, в котором
> одновременно используются MFC, ATL, #import и STL. В качестве примера
> можно взять какое-нибудь приложение на MFC, работающее как сервер
> автоматизации, поддерживающее дуальный IDispatch.
У меня примерно такое: приложение на MFC с поддержкой автоматизации и
серверных документов, в котором объектная модель реализована на Comet,
включены #import'ами несколько бибилиотек и есть несколько
ActiveX-контролов на ATL+WTL.

После разборок с #include'ами — все нормально.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 15:56
Оценка: +1 -1 :))
Здравствуйте, eao197, Вы писали:

IT>>Вот и не надо этого делать. Те кто используют C++ как-нибудь сами без тебя разберуться где его следует использовать.


E>Уже разобрались. Да так, что программируя на C# только и знаю, что C++ ругать.


Ругают не язык, ругают комитет. А язык не ругать, а жалеть надо. И всех его пользователей-бедолаг.

IT>>Этот пример не описывает начальную постановку задачи. А решать проблему, в которую ты попал только известным тебе самому способом мне не интересно.


E>Так и запишем -- решение не предложено.


Лучше запиши -- задача не поставлена.

IT>>Я бы хотел в C++ иметь стандартный тип строки.

E>Он есть -- std::basic_string.

Ой, не смешите мои тапочки. тоже мне стандартный тип. И вообще, STL — стандарт — это уже не смешно. Сам Страуструп его назвал компромисом (консенсусом?) между универсальностью и производительностью. В результате получилось ни два ни полтора, ни универсальности, ни производительности.

E>Это не отговорки. Отговорки -- это очередные попыки обвинить C++ в том, что кому-то его трудно использовать.


Ещё раз. Обвиняется здесь только комитет за нежелание развивать язык в сторону, востребованную пользователями. А сам язык жалко

E>Если трудно -- значит либо знаний не хватает (а скорее здравого смысла), либо не подходит C++ для конкретной задачи. В конце-концов, на Запорожце в Формуле-1 не гоняются, а Камазы в качестве пасажирского такси не используют.


Ты имеешь ввиду C# — это болид Формулы 1, а C++ — запорожец? Пожалуй с этой аналогией я соглашусь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kedik  
Дата: 02.06.06 15:58
Оценка:
Здравствуйте, IT, Вы писали:

IT>Вот как он эти задачи решает


IT>
IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>


А причем тут С++?
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 16:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>После разборок с #include'ами — все нормально.


Т.е. без приседаний и танцев с бубнами не обошлось?
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 16:02
Оценка:
Здравствуйте, kedik, Вы писали:

K>А причем тут С++?


А при том, что весь этот строковый зверинец живёт именно в нём.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 02.06.06 16:03
Оценка:
IT wrote:
> C>После разборок с #include'ами — все нормально.
> Т.е. без приседаний и танцев с бубнами не обошлось?
Нет, просто пришлось сделать RTFM по тому какие #define'ы надо
проставлять — все оказалось вполне логично.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Left2 Украина  
Дата: 02.06.06 16:06
Оценка: +1
+100. Мэппинг корбы на С++ — это ИМХО типичный пример того как на С++ писать нельзя. Хуже только Symbian Там они вообще из языка такооое сделали....
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kedik  
Дата: 02.06.06 16:09
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>А причем тут С++?


IT>А при том, что весь этот строковый зверинец живёт именно в нём.


Я конечно может сильно отстал... но насколько я знаю ничего кроме std::string к языку непосредственно не относиться... да и это вроде как всего лишь часть "стандартной" библиотеки...

Собственно я так и не понял причем тут С++... можно какнить более развернуто... для тупых
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kan_izh Великобритания  
Дата: 02.06.06 16:15
Оценка: +1
IT wrote:

> А теперь включаем фантазию и попробуем представить проект, в котором

> одновременно используются MFC, ATL, #import и STL. В качестве примера
MFC, ATL могут использовать один и тот же CString (а писался он до того, как С++ стандартизовался). STL также прекрасно
может с CString работать, хотя если очень хочется, можно basic_string<TCHAR> заюзать.
Это не проблемы языка, а проблемы используемых библиотек.
Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для обычного инта куча типов: int, Integer,
AtomicInteger?

> можно взять какое-нибудь приложение на MFC, работающее как сервер

> автоматизации, поддерживающее дуальный IDispatch.
Напиши сервер автоматизации на какой-нибудь яве, чтобы оно легко с VB, JavaScript, и пр. взаимодействовало...
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 16:18
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ругают не язык, ругают комитет. А язык не ругать, а жалеть надо. И всех его пользователей-бедолаг.


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

E>>Так и запишем -- решение не предложено.


IT>Лучше запиши -- задача не поставлена.


Да уж... Имхо, описание было довольно конкретным.
Реальный код я тебе представить не могу, но в общем виде можно выразить так:
class Actor
  {
  public :
    const std::string & name() const;
    const std::string & address() const;
    const std::string & role() const;
    const std::string & unique_bit_string() const;
  private :
    std::string m_name;
    std::string m_address;
    std::string m_role;
    mutable std::string m_unique_bit_string;
    .../* еще закрытые поля */...
  };
...
void process_actor( const Actor & a )
  {
    // Здесь у Actor вызываются, в основном, методы name(), address(), role().
    // Но иногда, меньше чем в половине случаев, вызывается unique_bit_string().
  }

Вычисление m_unique_bit_string операция ресурсоемкая, использующая все поля объекта Actor, включая и те, которые через методы getter-ы не доступны. Функций process_actor() несколько, объект может попасть последовательно в несколько из них. В каком порядке -- не известно. Причем, если метод unique_bit_string() для объекта вызывается хотя бы один раз, то практически в 100% случаях он будет вызываться еще раз (он нужен для регистрации объекта в нескольких каталогах, если объект оказался неизвестен).

IT>Ой, не смешите мои тапочки. тоже мне стандартный тип. И вообще, STL — стандарт — это уже не смешно. Сам Страуструп его назвал компромисом (консенсусом?) между универсальностью и производительностью. В результате получилось ни два ни полтора, ни универсальности, ни производительности.


Тем не менее STL (и basic_string как его часть) описаны в стандарте C++. И я тебя хочу заверить, что это очень спасает при переходе с одного компилятора на другой.

IT>Ещё раз. Обвиняется здесь только комитет за нежелание развивать язык в сторону, востребованную пользователями. А сам язык жалко


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

IT>Ты имеешь ввиду C# — это болид Формулы 1, а C++ — запорожец? Пожалуй с этой аналогией я соглашусь.


Да без проблем. Главное, что на одних и тех же трасах они не втречаются.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kan_izh Великобритания  
Дата: 02.06.06 16:32
Оценка:
kedik wrote:

> Собственно я так и не понял причем тут С++... можно какнить более

> развернуто... для тупых
Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все
обязаны использовать.
Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kedik  
Дата: 02.06.06 17:30
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>kedik wrote:


>> Собственно я так и не понял причем тут С++... можно какнить более

>> развернуто... для тупых
_>Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все
_>обязаны использовать.
_>Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.

А-аааа... ну тада понятно

Знаем, знаем, проходили... сначала хочу что бы было "стандарные строки", потом "стандартные файлы"...
... потом стандартные интрерфейсы... стандартный Гуй... и все чтоб работало на стандартном железе... и пользователей тоже надо стандартных ... а ещё лучше один... но очччень богатый

Это проходит... надо просто поучавствовать в проекте который разрабатываеться под... ну хотя бы под 3 платформы

... и вот тогда это желание "стандартности" быстро проходит... и приходит понимание что — никаких стандартов нет... и не может быть в принципе — это противоречит некоторым законам... эээ... скажим так, общим законам... типа "закона сохранения энергии"

А что есть?
А есть только некоторые соглашения между группой разработчиков... ну хотя бы теми кто работает над одним проектом... в идеале
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 19:06
Оценка:
Здравствуйте, kedik, Вы писали:

K>Я конечно может сильно отстал... но насколько я знаю ничего кроме std::string к языку непосредственно не относиться...


Боюсь, что std::string непосредственно к языку тоже не относится.

K>да и это вроде как всего лишь часть "стандартной" библиотеки...


Появившейся в каком году?

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


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

А теперь вопрос. Почему нельзя добавить в сам язык давно напрашивающийся тип string и покончить раз и навсегда эту строковую вакханалию.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 19:16
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>MFC, ATL могут использовать один и тот же CString (а писался он до того, как С++ стандартизовался).


Начиная с 2002 года. Это конечно большой прогресс.

_>Это не проблемы языка, а проблемы используемых библиотек.


Это очень серьёзный аргумент. Я даже больше скажу. Это не проблемы комитета, а тех, кто использует язык и библиотеки. Комитету же ведь дела нет ни до библиотек, ни до тех кто их использует. Они сконцентрированы только на языке, млин В результате, как я уже говорил, получается "компромис", ни два ни полтора.

_>Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для обычного инта куча типов: int, Integer,

_>AtomicInteger?

Ключевое слово "в int Jave есть". А в C++ string нет.

_>Напиши сервер автоматизации на какой-нибудь яве, чтобы оно легко с VB, JavaScript, и пр. взаимодействовало...


Если ты думаешь нормальный сервер просто пишется на MFC, то ты ошибаешься. К тому же, из-за подобных строковых преобразований в коде и логики-то не видно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 02.06.06 19:23
Оценка: +1 -1
Здравствуйте, IT, Вы писали:


IT>Флаг в руки и барабан на шею. Впрочем, не думаю, что эти несчастные работают на фортране по собственной воле. А если им или они сами себе всё же внушили такую глупость, то не думаю, что они сами же полагают, что находятся на острие передовых технологий


Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 19:25
Оценка: +2
Здравствуйте, kan_izh, Вы писали:

_>Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все

_>обязаны использовать.
_>Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.

Это не только согласуется, но великолепно работает на практике.
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 19:35
Оценка: 23 (2)
Здравствуйте, IT, Вы писали:

IT>Давай рассуждать логически, давай? Интересы в группах, группы в комитете, значит интересы в результате где? Правильно, в комитете.


Обещенные цитаты из Страуструпа. Прошу прощения за большой объем, но это самые характерные высказывания по поводу комитета и процесса стандартизации.

Раздел 5.4:

...Перед комитетом по C++ стояли довольно трудные задачи:
* определение языка должно быть точным и полным;
* необходимо принять во внимание совместимость с C;
* нужно рассмотреть расширения, выходящие за пределы текущей практики применения C++;
* должны быть рассмотрены библиотеки.
Ко всему прочему сообщество пользователей C++ было очень неоднородным и совершенно неорганизованным, поэтому комитету по стандартизации пришлось стать его центром. В краткосрочной перспективе именно это и было самой важной его целью:
Комитет по C++ -- это место, где разработчики компиляторов и инструментальных средств, их коллеги и представители могут обсудить проблемы определения языка и -- насколько позволяет коммерческая конкуренция -- его реализации. Таким образом, комитет уже сослужил добрую службу обществу: помог сблизить различные реализации, предоставив площадку для дискуссий. В противном случае разработчики компиляторов вместе с немногими коллегами или в одиночестве строили бы догадки относительно тех вопросов, на которые нет ответа в ARM. Возможно, они связались бы со мной, но я не в состоянии один справиться со всеми возникающими проблемами. Отсутствие общения неизбежно ведет к появлению диалектов. Комитет противостоит таким тенденциям.
Стандартизация -- непростой процесс. В комитет входили люди, стремившиеся сохранить status quo; мечтавшими вернуться на несколько лет назад; были такие, кто хотел "порвать с проклятым прошлым" и спроектировать совершенно новый язык; те, кого волновал лишь один конкретный класс систем; люди, чьи голоса были куплены их работодателями, и представлявшие лишь себя; специалисты, озабоченные в основном теоретическими взглядами на программирование вообще и языки в частности; нетерпеливые и требовавшие принять стандарт немедленно, даже если некоторые детали останутся неразрешенными, и наоборот, те, которых не устраивало ничего, кроме идеального определения языка. Были такие, кто полагал, что C++ -- совсем новый язык, у которого и пользователей-то почти нет, и представители организаций, написавших за минувшее десятилетие миллионы строк кода и т.д. Но в соответствии с правилами стандартизации нам всем предстояло прийти к более или менее одинаковому мнению. Мы должны были достичь консенсуса (обычно под этим словом понимают подавляющее большинство). Это разумные правила, они имеют национальный и интернациональный характер. Все интересы законны, и если позволить большинству ущемлять интересы меньшинства, то получится стандарт, полезный лишь ограниченному кругу пользователей. Поэтому каждому члену комитета предстоит научиться уважать другие, чуждые ему точки зрения и идти на компромиссы. И это вполне соответствует стилю C++.

Раздел 6.2.1:

В комитет по C++ входят люди с разными интересами, ожиданиями и подготовкой. Одни работают на персональных компьютерах, другие на UNIX-машинах, третьи -- на мейнфреймах и т.д. Одни используют C++, другие -- нет. Кто-то хочет, чтобы C++ стал более объектно-ориентированным языком (причем "объектной ориентированности" даются очень разные определения), других бы больше устроило, если бы эволюция C остановилась на ANSI C. Многие, но не все работали с C. Некоторые имеют опыт работы над стандартами, но их меньшинство. Есть профессиональные программисты. Одни обслуживают интересы конечных пользователей, другие поставляют на рынок инструментальные средства. Некоторым интересны крупные проекты. Кому-то необходима совместимость с языком C, кому-то -- нет.
Если не считать того, что все входящие в комитет -- добровольцы, не получающие за свою работу в нем ни копейки (хотя некоторые представляют компании), то трудно выделить какие-то черты, присущие всем без исключения. И это хорошо: только очень разношерстная группа людей может выразить интересы весьма неоднородного сообщества пользователей C++. Правда, из-за этого дискуссии бывают не очень конструктивными и занимают много времени. Меня беспокоит также, что голос пользователей C++ (программистов и проектировщиков) может быть не услышан в хоре языковых пуристов, так называемых проектировщиков языков, бюрократов от стандартизации, разработчиков компиляторов и т.д.

Раздел 6.4:

Я уверен, что стремление добавить языку то или иное расширение неизбежно, и лучше, чтобы это происходило открыто, на публичном форуме, где есть хоть какие-то формальные правила. Альтернатива -- схватка за признание собственных идей через привлечение на свою сторону пользователей на рынке. Такой механизм не способствует спокойным размышлениям, открытым дискуссиям и попыткам удовлетворить потребностям всех пользователей. В результате мы получаем язык, распавшийся на диалекты.
Очевидные опасности, присущие рассмотрению указанного вопроса, лучще, чем хаос, который воцарится в противном случае. Большинство членов комитета согласилось со мной, но мы шли к той точке, когда работа над расширениями в том виде, в котором она ведется сейчас, должна была прекратиться, поскольку приближался момент принятия стандарта и все направили усилия на его критическое изучение.
Со временем кто-то переключился на другие языки, кто-то занялся экспериментальной работой, кто-то посвятил себя созданию библиотек. Интересно отметить, что группы по стандартизации, как и любые другие организации, расформировываются с большой неохотой. Часто такая группа возрождается, пусть даже в виде бюрократического механизма для создания стандарта следующего уровня, то есть комитета по проектированию нового языка или диалекта. Примерами подобного явления служат комитеты по языкам Algol, Fortran, Pascal и даже ANSI C. Тем временем я стараюсь обезопасить себя от попыток проектирования чего-либо самим комитетом, посвящая много времени каждому поступившему предложению. Стратегия эта хоть как-то защищает от принятия взаимоисключающих средств, и язык, возможно, не утратит внутреннюю целостность.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 19:38
Оценка: +2
Здравствуйте, kedik, Вы писали:

K>Знаем, знаем, проходили... сначала хочу что бы было "стандарные строки",


Что значит хочу? У меня уже есть стандартные строки. Причём не просто для одного языка, а для целой платформы, для которой сегодня сущесвует с пол сотни языков. System.String называется. Запоминай, будешь знать

K>потом "стандартные файлы"...


Тоже в наличии. Чем тебе XML формат не стандарт?

K>... потом стандартные интрерфейсы...


В смысле стандартные интерфейсы? Интерфейс как стандартная конструкция языка? Без проблем, записывай по буквам — i-n-t-e-r-f-a-c-e

K>стандартный Гуй...


WinForms например. Пока ещё далёк от совершенства, но уж лучше такой, чем разброд, который творится в мире C++.

K>и все чтоб работало на стандартном железе...


А оно у тебя какое?

K>и пользователей тоже надо стандартных


С этим проблемы, да.

K>... а ещё лучше один... но очччень богатый


Один — это не интересно. Пофлеймить в форуме не с кем будет

K>Это проходит... надо просто поучавствовать в проекте который разрабатываеться под... ну хотя бы под 3 платформы


K>... и вот тогда это желание "стандартности" быстро проходит... и приходит понимание что — никаких стандартов нет... и не может быть в принципе — это противоречит некоторым законам... эээ... скажим так, общим законам... типа "закона сохранения энергии"


Для некоторых это противоречит фобиям, застарелым привычкам и незнанию того, что происходит в мире.

K>А есть только некоторые соглашения между группой разработчиков... ну хотя бы теми кто работает над одним проектом... в идеале


Глупости. Стандарт на внешние интерфейсы модулей давно существует и с успехом применяется. Соглашения между разработчиками учитываются только на уровне соглашений о наименованиях. Да и на это уже выработался более менее вменяемый стандарт.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 19:38
Оценка:
Здравствуйте, IT, Вы писали:

_>>Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для обычного инта куча типов: int, Integer,

_>>AtomicInteger?

IT>Ключевое слово "в int Jave есть". А в C++ string нет.


Кстати, String в Java -- это не ключевое слово. Просто класс в стандартной библиотеке.
А int в Java -- это даже не объект


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 20:05
Оценка: -1 :)
Здравствуйте, eao197, Вы писали:

E>Кстати, String в Java -- это не ключевое слово. Просто класс в стандартной библиотеке.

E>А int в Java -- это даже не объект

Совершенно верно. В C# тоже. Но Java без стандартной библиотеки, так же как и C# не представляют никакой ценности. В C++ такой библиотеки нет, вот все и лепят на коленках что у кого получится.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 20:07
Оценка: :))) :)
Здравствуйте, eao197, Вы писали:

E>Обещенные цитаты из Страуструпа. Прошу прощения за большой объем, но это самые характерные высказывания по поводу комитета и процесса стандартизации.


Особенно вот это порадовало:

E> В комитет по C++ входят люди с разными интересами, ожиданиями и подготовкой. ... Одни используют C++, другие -- нет.


Что можно сказать? Очень важно иметь в комитете людей, которые даже не используют язык, который взялись стандартизировать.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kedik  
Дата: 02.06.06 20:13
Оценка: 30 (2) +1
Здравствуйте, IT, Вы писали:

IT>А теперь вопрос. Почему нельзя добавить в сам язык давно напрашивающийся тип string и покончить раз и навсегда эту строковую вакханалию.


Ну почему ж нельзя... можно конечно...

Пока "строка" в библиотеке... пускай даже в стандартной... я могу её выкинуть, если по каким-то причинам она меня не устраивает... а если её добавить в язык — тогда сам язык станет заточен под какие-то определённые требования и задачи потеряв универсальность — вот тогда действительно начнуться проблемы.

1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?
2) Что эта строка будет уметь?

1)
Но что делать с проектами в которых нафик не нужна кодировка которую мы выберем?
Можно конечно реализацию (т.е. кодировку) спрятать внутри класса, но что делать если под Виндами стандарт UTF-16, а на Униксах UTF-32... или UTF-8? ... на лету кoнвертить будем? Хм... в некоторых местах — это непозволительная роскошь...
2)
И даже если эту проблему решить... то на самом деле существует, проблема гораздо серьезнее: какой набор методов такая "строка" будет предоставлять? На все случаи жизни?... Хм... нереально... а что бы этот набор расширить для требований проекта нужна будет возможность эти методы добавлять... а для этого нам надо будет иметь доступ к непосредственно к данным строки и знать, как она устроена... и тогда мы возвращаемся к п.1 ...


Если всерьез задаться целью создать совершенно универсальный класс универсальной строки, то резутьтат будет, только один — как минимум лекгая шизофрения у его разработчиков

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


PS. Как начсет добавить в язык тип "время"?
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 20:16
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>Ругают не язык, ругают комитет. А язык не ругать, а жалеть надо. И всех его пользователей-бедолаг.


E>Ругать тех, кто что-нибудь делает всегда можно. Это не сложно.


Как раз тех, кто что-то сделал ругать сложно. Легко ругать тех, кто ничего не делает.

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


В том, что происходит с C++ происходит что-то не так. Сложный это процесс или лёгкий — это уже не важно.

E>Да уж... Имхо, описание было довольно конкретным.


Это не постановка. Это приглашение отрефакторить твой код. Этого я делать не собираюсь. Если ты объяснишь мне задачу (на словах, а не в коде), я попробую её решить без mutable. Но пытаться выкрутится в ситуации, когда без них уже никуда мне не интересно.

E>Тем не менее STL (и basic_string как его часть) описаны в стандарте C++. И я тебя хочу заверить, что это очень спасает при переходе с одного компилятора на другой.


Да ради бога. Вот только когда мне нужна была производительность, а не переходы с одного компилятора на другой, то stl со своими контейнерами сходил разок в лес.

IT>>Ещё раз. Обвиняется здесь только комитет за нежелание развивать язык в сторону, востребованную пользователями. А сам язык жалко


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


Следит, чтобы крена не было ни в плохую сторону, ни в хорошую.

IT>>Ты имеешь ввиду C# — это болид Формулы 1, а C++ — запорожец? Пожалуй с этой аналогией я соглашусь.


E>Да без проблем. Главное, что на одних и тех же трасах они не втречаются.


К счастью это не возможно. Болиды не ездят по разбитым просёлочным дорогам.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 20:16
Оценка:
Здравствуйте, FR, Вы писали:

FR>Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET


В IT? Сомневаюсь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 02.06.06 20:25
Оценка: 17 (2) +2
IT wrote:
> K>Я конечно может сильно отстал... но насколько я знаю ничего кроме
> std::string к языку непосредственно не относиться...
> Боюсь, что std::string непосредственно к языку тоже не относится.
Достало уже.

std::string описывается в ISO-IEC-14882 в секции 21. На титульной
странице этого документа записано:

INTERNATIONAL
STANDARD

ISO/IEC
14882
Second edition
2003-10-15
Programming languages — C++


Так что std::string — это такая же часть языка, как и string в C#.

> K>да и это вроде как всего лишь часть "стандартной" библиотеки...

> Появившейся в каком году?
В 94 году был первый вариант (у SGI?), кажется. В середине 90-х были уже
вполне нормальные многочисленные реализации.

> В самом языке типа string нет, в результате он есть в каждой более менее

> уважающей себя библиотеке. Что из этого получается я привёл в качестве
> примера выше.
В C# реализация строки тоже находится в библиотеке.

> А теперь вопрос. Почему нельзя добавить в сам язык давно напрашивающийся

> тип string и покончить раз и навсегда эту строковую вакханалию.
А с какой семантикой — нужна ли SSO (если да, то какой размер буффера?),
а может еще и refcount'инг нужен? Или лучше просто копировать
содержимое? А может использовать GC и дать ему собирать мусор? Нужна ли
мутируемость строк? Нужно ли поддерживать использование хранения внешней
строки по ссылке? А как насчет передачи содержимого строки в вектор без
копирования? А нужно ли вставлять концевой 0 сразу или делать это по
требованию в c_str? А как насчет поддержки move construction? А если
потребуется положить строку в shared memory? А нужна ли поддержка
хэширования строки? А нужно ли кэшировать результат хэша, если да, то
как синхронизировать в многопоточном режиме? А если нужна своя
хэширующая функция? А если захочется utf-32? А если нужен utf-8?

В Стандарт добавили что-то среднее между всем этим, с достаточно
посредственными характеристиками для многих задач.

Но C++ хорош тем, что позволяет делать выбор когда это нужно (алгоритмы
шаблонные, а почти все нормальные либы позволяют использовать
custom-строки) и я могу в своей задаче использовать свою велосипедную
строку максимально приспособленную для данной задачи.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 20:33
Оценка:
Здравствуйте, kedik, Вы писали:

K>Пока "строка" в библиотеке... пускай даже в стандартной... я могу её выкинуть, если по каким-то причинам она меня не устраивает... а если её добавить в язык — тогда сам язык станет заточен под какие-то определённые требования и задачи потеряв универсальность — вот тогда действительно начнуться проблемы.


Почему-то в других языках такой проблемы нет

K>1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?


Юникод вполне подойдёт.

K>2) Что эта строка будет уметь?


Посмотри в MSDN Members System.String.

K>на лету кoнвертить будем? Хм... в некоторых местах — это непозволительная роскошь...


Здесь надо жирным выделить в некоторых. Т.е. если мне один раз в некотором месте не подошло, то такой тип надо считать вредным для всей индустрии. Логично.

K>И даже если эту проблему решить... то на самом деле существует, проблема гораздо серьезнее: какой набор методов такая "строка" будет предоставлять? На все случаи жизни?... Хм... нереально... а что бы этот набор расширить для требований проекта нужна будет возможность эти методы добавлять... а для этого нам надо будет иметь доступ к непосредственно к данным строки и знать, как она устроена... и тогда мы возвращаемся к п.1 ...


Ознакомься с System.String. В .NET такой "серьёзной" проблемы не существует.

K>Если всерьез задаться целью создать совершенно универсальный класс универсальной строки, то резутьтат будет, только один — как минимум лекгая шизофрения у его разработчиков


На C++ — вполне возможно.

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


Мы же не о массиве байт говорим, который как ты сам правильно заметил, неизвестно как конвертрировать, а типе string.

K>PS. Как начсет добавить в язык тип "время"?


Я понимаю. Если строка, то это обязательно должен быть массив байт, если дата, то длинное целое. От этих привычек очень трудно избавиться. Но всё же, будет время, взгляни на тип System.DateTime.
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 20:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Так что std::string — это такая же часть языка, как и string в C#.


Это абсолютно неверное утверждение. Начнём хотя бы с того, что std::string появилась в C++ десять лет спустя. Результат нам всем хорошо известен. Даже по прошествии 10 лет, std::string так и не стала фактическим стандартом.

C>А как насчет передачи содержимого строки в вектор...


А как насчёт посмотреть реализации в других языках или хотя бы взять за основу реализацию одной из C++ библиотек?

C>В Стандарт добавили что-то среднее между всем этим, с достаточно посредственными характеристиками для многих задач.


Это называется отмазаться. Хотели строку? Нате подавитесь

C>Но C++ хорош тем, что позволяет делать выбор когда это нужно


Достоинства C++ мне прекрасно известны. Мы сейчас не о них
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kedik  
Дата: 02.06.06 20:54
Оценка:
Здравствуйте, IT, Вы писали:

IT>Для некоторых это противоречит фобиям, застарелым привычкам и незнанию того, что происходит в мире.


Знаешь, IT, вы, с VladD2, например, тут конечно люди умные... без фобий и застарелых привычек...

Стандарты то они конечно стандарты... но то что ты перечистил... ты почему-то видимо свято уверен, что жизни за пределами Windows не существует

Я тебе такую реальную историю расскажу...

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

Все довольны и разработчики и потенциальные клиенты после демонстрации в восторге... но...

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

Вот ты скажешь, мол клиенты такие попались... или не понимают нифига в технологиях... и вообщем-то будешь в чем-то прав... дело только за малым... останеться только убедить в этом практически всех ведущих разработчиков чипов, которые и были клиентами в данном случае
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kan_izh Великобритания  
Дата: 02.06.06 20:58
Оценка:
IT wrote:

> _>Это не проблемы языка, а проблемы используемых библиотек.

> Это очень серьёзный аргумент. Я даже больше скажу. Это не проблемы
> комитета, а тех, кто использует язык и библиотеки. Комитету же ведь дела
> нет ни до библиотек, ни до тех кто их использует. Они сконцентрированы
> только на языке, млин В результате, как я уже говорил, получается
> "компромис", ни два ни полтора.
Главное — работает.

> _>Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для

> обычного инта куча типов: int, Integer,
> _>AtomicInteger?
> Ключевое слово "в int Jave есть". А в C++ string нет.
Есть basic_string, чем не устраивает???
Ну есть в яве/.нете String, а он всего 2-байтный. Как оно с UTF-32 дружить будет?.. Ладно нам 2-х байт хватает, а что
китайцам с японцами делать?

> _>Напиши сервер автоматизации на какой-нибудь яве, чтобы оно легко с VB,

> JavaScript, и пр. взаимодействовало...
> Если ты думаешь нормальный сервер просто пишется на MFC, то ты
> ошибаешься. К тому же, из-за подобных строковых преобразований в коде и
> логики-то не видно.
Не просто, но на яве явно не проще, и строковые преобразования тут роль не играют.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 02.06.06 21:07
Оценка: -1
IT wrote:
> C>Так что std::string — это такая же часть языка, как и string в C#.
> Это абсолютно неверное утверждение.
Покажит международный стандарт на C# и место где в нем описывается строка.

> Начнём хотя бы с того, что

> std::string появилась в C++ десять лет спустя. Результат нам всем хорошо
> известен. Даже по прошествии 10 лет, std::string так и не стала
> фактическим стандартом.
std::string — это Стандарт (с большой буквы). Практически это
тоже сейчас распространенный стандарт, но не абсолютный. Что вполне всех
устраивает.

> C>А как насчет передачи содержимого строки в вектор...

> А как насчёт посмотреть реализации в других языках или хотя бы взять за
> основу реализацию одной из C++ библиотек?
А как ты думаешь комитет поступил? Они как раз взяли за пример строки из
других языков, в результате в интерфейсе std::string сейчас 84 публичных
метода. При правильном проектировании их число уменьшается до пары
десятков, а остальное становится алгоритмами (см. flex_string у
Александреску).

А самого идеального решения не существует. Например, refcount-строки
часто неэффективны в многопоточных приложениях, а SSO может приводить к
сильному замедлению в дегенеративных случаях.

> C>В Стандарт добавили что-то среднее между всем этим, с достаточно

> посредственными характеристиками для многих задач.
> Это называется отмазаться. Хотели строку? Нате подавитесь
Да, примерно так и есть. Комитет попытался найти золотую середину —
получилось... средне.

Но это не так важно — в С++ есть все средства, чтобы это компенсировать.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[30]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kedik  
Дата: 02.06.06 21:14
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?

IT>Юникод вполне подойдёт.
Какой Юникод? 2.x? 3.x? — UTF-8? UTF-16? UTF-32?

IT>Я понимаю. Если строка, то это обязательно должен быть массив байт, если дата, то длинное целое. От этих привычек очень трудно избавиться. Но всё же, будет время, взгляни на тип System.DateTime.


В том что все и дело, что это не привычки это требования!
С++ — это язык системного уровня — и в нем все быты и байты. Если при разработке это напрягает, значит С++ явно не нужен...

Взглянуть то на System.String и System.DateTime я могу, только как они решат мои задачи на Sun и HP например при хиром алгоритме обработки фалов на диске, к примеру?


PS. Решение абстрактых проблем это конечно интересно и увлекательно... только за решения таких проблем платят исключительно абстрактные деньги... котороый можно потратить на все что угодно... чисто абстрактно конечно
Re[30]: Tcl как обоснование ненужности поддержки компонентности в С++
От: kan_izh Великобритания  
Дата: 02.06.06 21:24
Оценка:
IT wrote:

> UTF-8? UTF-16? UTF-32? а как на счет остальных?

> Юникод вполне подойдёт.
Юникод это не кодировка, а набор символов. А UTF — Unicode Transfer Format, кодировки юникода.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 23:22
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

IT>>Философия и не должна быть другой. Нужно всего лишь сделать нормальный дизайн, соостветствующий современным требованиям.


E>Видишь ли, понятие нормальности меняется не только в зависимости от области использования языка, но и от времени. То, что было нормально в 1986, тебе сейчас кажется не нормальным.


Я же ясно написал, что понимаю под нормальным дизайном.

E>А если гоняться за современной модой, то никакой компилятор не будет за этим успевать.


Гонятся не надо. Но и по 10 лет обсуждать каждую фичу тоже не имеет смысла. К этому времени фича уже успеет устареть.

E>И уж тем более сохранять совместимость с ранее написанным кодом.


А это тут при чём? Все компиляторы развиваются, включая C++ и тем не менее остаются совместимы с легаси кодом.

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


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


E>Не мешает говоришь? Так введи. Какие проблемы? Берешь GCC или OpenWatcom и подкручиваешь C++ под себя.

E>А потом объясняешь, почему еще в двадцати (или сколько их там сейчас) компиляторах C++ нет никаких свойств или делегатов. И пытаешься заставить разработчиков этих компиляторов добавить их в свои творения.

Давай мы будем говорить о реальных вещах.

E>К тому же рассуждать о том, что C++ динозавр и не соответствует современным требованиям действительно проще, чем признать, что нафиг не нужно было на C++ COM-ы писать.


А были альтернативы? Как только мне предоставилась другая возможность, я поднапрягся, сжал силу воли в кулак и расстался с пережитками прошлого И, поверь мне на слово, ни капельки не жалею. Даже наоборот, чувствую, что прошёл один level и перешёл на следующий.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 23:27
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

>> Т.е. без приседаний и танцев с бубнами не обошлось?

C>Нет, просто пришлось сделать RTFM по тому какие #define'ы надо проставлять — все оказалось вполне логично.

Т.е. RTFM по тому как приседать и стучать в бубен.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 02.06.06 23:32
Оценка:
Здравствуйте, kan_izh, Вы писали:

>> В результате, как я уже говорил, получается "компромис", ни два ни полтора.

_>Главное — работает.

Ну что это такое? А где стремление к совершенству, где забота о потомках, где желание писать код, по которому сегодняшние школьники будут учиться программировать серьёзные системы?

>> Ключевое слово "в int Jave есть". А в C++ string нет.

_>Есть basic_string, чем не устраивает???

Очередной коспромис?

_>Ну есть в яве/.нете String, а он всего 2-байтный. Как оно с UTF-32 дружить будет?.. Ладно нам 2-х байт хватает, а что китайцам с японцами делать?


Ничего не делать. И главное не задумываться о глупостях вроде сколько там байт в символе. Тогда и китайцам и японцам будет хорошо.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: :)
Здравствуйте, night beast, Вы писали:

NB>ваша эрудиция прямо таки потрясает воображение.

NB>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?
NB>наверно это очень увлекательно, бороться с ветряными мельницами...

С теореией упругости это не сюда.

Что касается темы... Я конечно пнимаю, что разговор уже ушел очень далего от нее и надо было останавливать все разглагльствования о tcl еще на зачаточной стадии, но все же не думаю, что тяжело поднять голову в верх и прочесть тему, а потом вернуться на десяток сообщений вверх по ветке...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: -2 :)
Здравствуйте, night beast, Вы писали:

NB>поправь если ошибаюсь. мне казалось что в этой ветке мы тикл обсуждали


Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.

ЗЫ

Ты хоть смотри к чему присоеденяешся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: :)
Здравствуйте, night beast, Вы писали:

NB>а const_cast эмулировать нельзя.


Да, да. Надо срочно подменять тему разговора...

Особенно хорошо для этого подходят такие "полезные" вещи как const_cast. Если бы не они и указатели, то язык мог бы получиться безопасным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>Это философия граблей.


E>На этот счет могут быть разные мнения , но словесное жонглирование не имеет смысла, т.к. философия C++ такая какая есть. Другой она уже не будет.


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

E>Язык C++ создавался как "улучшенный C" для системного программирования.


Можно название хотя бы одной ОС целиком написанной на С++? А то складывается впечатление, что те кто занимается этим системным программированием как-то не заметили что С++ был создан для системного программирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: :)
Здравствуйте, eao197, Вы писали:

IT>>Т.е. ты это называешь нахождением компромисса?


E>Страуструп называл это нахождением консенсуса.


Если бы он обратился к словарю, то понял бы, что это называется убогостью.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, eao197, Вы писали:

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


Ой ли. Я один пример знаю... СОбжектайзер... Замечательно демонсрирует использование С++ не по делу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Мне не нужно ничего определять и судить.


...но сужу так как хочется...

E> Я на C++ помои не выливаю.


... я его защищаю...

E> Хотя мне не нравится, что с языком происходит. ИМХО, гораздо проще и конструктивнее сменить язык.


О. Вот об этом и тема. Давно пора сменить язык. С++ морально устарел. Не имеет ни одного приемущества. И, что главное, не развивается в нужном людям направлении. В прочем, ту скорость его развития вообще развитием назвать нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ругать тех, кто что-нибудь делает всегда можно.


Погоди. Ты кого имешь в виду? Уж не Страуструпа с комитетом не выпустившего ни одного стандарта за последние 13 лет?

E> Это не сложно.


Ах вот почему ты чужие статьи ругашь. Ясно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Вот тебе еще один пример:

E>
E>void f(CORBA::Octet o);
E>void f(CORBA::Boolean b); // Ambiguous
E>cout << ref—>getString(); // Leak
E>r1—>putString(r2—>getString()); // Leak
E>char *p = getString();
E>delete p; // Heap corruption
E>std::string s(ref—>getString()); // Leak
E>if(ref1 == ref2) ... // Undefined
E>

E>(взят из документа A New Approach to Middleware Track Object-Oriented Middleware найденого когда-то на сайте http://www.zeroc.com).

E>Вот здесь C++ виноват в провоцировании всех показанных проблем или те, кто спроектировал такой маппинг CORBA на C++? Причем они ведь знали что такое C++ и чем черевато его неправильное использование.


Конечно виноваты тупые пользователи. Ведь те дядьки что седят в OMG они же тупые ламеры. А те что в комитете по С++ крутые гуру консенсуса.

И почему эти олухи из OMG биндинг для Явы сделели безопасным? Ах, да... ламеры!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, Left2, Вы писали:

L>+100. Мэппинг корбы на С++ — это ИМХО типичный пример того как на С++ писать нельзя. Хуже только Symbian Там они вообще из языка такооое сделали....


Сори, приведи подобные кривые мапинги для Явы, плиз.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>MFC, ATL могут использовать один и тот же CString


Это теперь. А в 98-ом не могли. Да и вопрос не в этом, а в том зачем вообще было делать 10 варинтов строк? Почему было не ввести строки в язык? Ведь они нужны в любом приложении?

Это такие же вопросы как "Почему не добавить свойства? Они же никому не помешали бы." или "кому помешали бы функциональные типы?". На эти вопросы есть только отбрехи фанатов С++ и комитета. Отбрехи эти пахнут маргинальностью и старперством.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, kedik, Вы писали:

K>Я конечно может сильно отстал... но насколько я знаю ничего кроме std::string к языку непосредственно не относиться... да и это вроде как всего лишь часть "стандартной" библиотеки...


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


А ты задумайся почему в куче языков хватает одной строки, а в С++ понадобилось создавать такое количество? Ответ тут очень простой. Та строка которая была в СТЛ настолько не устраивала пользователей и разработчиков библиотек, что им пришлось вводить заменители. А кто не обеспечил наличие полноценной строки в языке или его библиотеке?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все

_>обязаны использовать.
_>Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.

Примеры не согласования с требованиями к строкам в Ява, C# и т.п., плиз, приведи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: :)
Здравствуйте, kedik, Вы писали:

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


IT>>Для некоторых это противоречит фобиям, застарелым привычкам и незнанию того, что происходит в мире.


K>Знаешь, IT, вы, с VladD2, например, тут конечно люди умные... без фобий и застарелых привычек...


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

K>Стандарты то они конечно стандарты... но то что ты перечистил... ты почему-то видимо свято уверен, что жизни за пределами Windows не существует


Батенька, ды вы совсем дальше своего носа не видите. (с) Дотнет давно в виде Моно живет под Линуксом. Ява на таком количестве платформ, что С++ позавидует. Тут дело в том, что лично нам эти платформы просто не нужны. Ну, не занимаемся мы дешевым хостингом, где Линукс король песочнецы.

K>Я тебе такую реальную историю расскажу...


K>Собрались, значит несколько человек, тоже умных и без фобий и застарелых привычек... и пришла им в голову потрясающая идея... ну они значит как люди умные и прогрессивные её конечно быстренько реализовали... сделали замечательно, с использованием последних технологий, на самой распространённой платформе...


K>Все довольны и разработчики и потенциальные клиенты после демонстрации в восторге... но...


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


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


Ты эту сказку сейчас рассказал человеку который этих клиентов пачками окучивает. Дай угадаю, ты лично этих клиентов видишь в щель дверного проема из своей комнаты где работашь программистом на дядю? Не обижайся, но потны лучше оставлять за пределами РСДН.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: :)))
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


Ясно. Значит хотел было пиписькой помериться, но понял, что она не очень длинная.

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

VD>>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок.


ANS>Пока это не было продемонстрировано.


Ага. Так зачем дело встало? Как подпоркой вроде tcl можно обосновать разумность отсуствия в С++ компонетных технологий?

VD>> А для С++ мне нужные разные подпорки вроде внешних кодогенераторов или отдельного скриптового языка tcl?


ANS>Проблемы С++ меня не интересуют,


Тогда зачем влезать в эту тему? Ты название то прочел? А суть спора?

ANS> но, неужели в программе на С++ нельзя использовать сцинтилу или вышеупомянутый грид?


Ага! Нельзя! Ведь они компоненты. А компонентам нужна среда исполнения. Сцинтила в С++ выглядит как тип окна с сообщениями. О визуальных дизайнерах не может быть и речи. Если сравнить сложность и обхем работ требуемый для подключения Сцинтилы к проекту на С++ не сравним с тем же самым на C#. В C# я просто бросаю компонет на форму и настраиваю его свойства. А в С++ нет ни, формы, ни компонента, ни даже понятия свойства. Это закат солнца врнучную вместо работы. С гридом же еще смешнее. Его просто не написали для С++. Он есть для КОМ и дотнета. КОМ-варинт в сто раз проще использовать в ВБ6. А дотнет... да в нем есть МС++, но к С++ он никакого отношения не имеет.

VD>>Сделать качественный редактор кода из RTF-редактора нельзя в принципе.


ANS>Вот это убожество и есть.


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

VD>>Не. Возможность взять сторонний контрол


ANS>Это уневерсальное решение?


Ага. Причем идиальное. Тысячи людей могут параллельно создавать нужные друг-другу и дургим вещи.

VD>>или разработать его самому —


ANS>это, да универсальное. Но есть одна загвоздка, и С++ и С# и Tcl одинаково универсальны. Так о чем разговор?


Незнаю как tcl (он тут просто не причем), но С++ не позволяет использовать компоненты без внешних подпорок. Да и с одными делает это из рук вон плохо. А причина в самом С++. Он приципиально (то есть по горячему желанию его авторов) не поддерживает компонентного подхода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Да просто из-за политики микрософта. По дефолту с VC идет недоношеный обрубок MFC, хотя даже его можно довести до ума. Взять например комерческие MFC-расширения типа BCG. Вполне можно программировать, достаточно грамотно сделано.


Что есть такой же как в Студии дизайнер?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Tcl как обоснование ненужности поддержки компонентности в С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка: -1
Здравствуйте, FR, Вы писали:

FR>У тебя все что не NET убого, так что это не аргумент.


Это ты откровенно переверашь мои слова. Я гляжу и сужу. Вижу убогость, называю ее таковой. Вот полгядел на ссылку и увидил малый набор компонентов, кривейший внешний вид (даже иконки и те убогие). На вопрос о гриде получил ответ, что пиписка коротка. Какие мне еще делать выводы?

FR>Ну и посмотрим на сколько неубогим станет NET если будет подерживать столько же платформ сколько и tcl/tk.


А зачем мне столько платформ если для этого нужно обязательно мириться с убогостью? Ну, их в лес. Мне Виндовс за глаза хватит. Хотя конечно есть Ява с ее компонентным подходом. Там не все так здорово, видать многоплатформность дает знать, но все же куда лучше чем tcl. И компоненты сторонние есть, и ГУЙ приличный делается (смотрим на IDEA).

А вот где приличный ГУЙ на С++ и без подпорок? А? Я и на tcl то его не вижу.

FR>Он может расширятся как и средствами языка на котором ведется разработка так и с помощью си — с++

FR>На него достаточно много готовых контролов от других производителей.

Ну, где среди них приличный грид? И почему его нет если все так шоколадное? Может быть кто-то выдает желаемое за дейсвительное?

VD>>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.


FR>Нет просто ты достаточно часто ничего ни зная о предмете любишь делаеть безапиляционные заявления.


А... Ну, извини. Я когда вижу убогие скриншоты, то не задумываюсь над великим ДАО в них скрытым.

ЗЫ

И все же если вспомнить, что tcl это очередная подпорка, то можно откинув ее объяснить что мешало встроить в С++ поддержку компонентного подхода? Почему в этом языке до сих пор единственным средством импорта чужих модулей являются допотопные #include-ы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 04:26
Оценка: +3
Здравствуйте, VladD2, Вы писали:

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


VD>Ой ли. Я один пример знаю... СОбжектайзер... Замечательно демонсрирует использование С++ не по делу.


Бым-га-га. Наглядная демонстрация того, что в большинстве случаев ты говоришь о том, чего не знаешь.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 04:28
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Язык C++ создавался как "улучшенный C" для системного программирования.


VD>Можно название хотя бы одной ОС целиком написанной на С++? А то складывается впечатление, что те кто занимается этим системным программированием как-то не заметили что С++ был создан для системного программирования.


Целиком? А есть ОС целиком написанные на C? Т.е. чтобы совсем без ассемблера?
Насколько мне известно, в твоей любимой ОС очень много на С++ написано.
Кроме того, системное программирование -- это не только ОС. Разработка KDE, к примеру, так же относится к системному программированию.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 04:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Погоди. Ты кого имешь в виду? Уж не Страуструпа с комитетом не выпустившего ни одного стандарта за последние 13 лет?


Стандарт C++ был принят в 1998 году. С тех пор прошло всего восемь лет.

E>> Это не сложно.


VD>Ах вот почему ты чужие статьи ругашь. Ясно.


Я твою статью еще не ругал. Просто спросил, на каком основании ты сравниваешь C++ с Nemerle.
Если хочешь, чтобы поругал, то вышли, пожалуйста вариант статьи мне на e-mail, а то бумажный журнал до меня доберется месяца через два.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 04:59
Оценка: 1 (1)
Здравствуйте, kedik, Вы писали:

IT>>Для некоторых это противоречит фобиям, застарелым привычкам и незнанию того, что происходит в мире.

K>Знаешь, IT, вы, с VladD2, например, тут конечно люди умные... без фобий и застарелых привычек...

Мы стараемся

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


Раз уж зашёл разговор о лирике и про клиентов, я тебе вот что скажу. Я — контрактник. Мне дают в руки лопату и говорят от куда и до куда копать. Свой бигбакс я получаю потому, что в качестве лопаты мне могут выдать практически любой инструмент, от совочка для песочницы до современного карьерного экскаватора и я должен буду в состоянии этим управлять. Но это ещё не всё. Свой бигбигбакс я получаю за то, что могу засунуть подальше свои предпочтения и сказать сомневающемуся или нанявшему меня специально для этого клиенту какая именно лопата сегодня лучше всего подходит для наших задач. И, поверь мне, если среди этих лопат лучшая будет с маркировкой C++, я не задумываясь покажу на неё пальцем. Обманывать клиента в моём положении просто глупо, я же сам приду просить у него референс для следующего проекта. Так что плюсы как лучший выбор для конкретной задачи я притеснять ни в коем случае не собираюсь и не буду.

Но вот что-то всё никак не получается показать на них пальцем Иногда так... взглядом бывает покосишься...

ЗЫ. Может я слегка погорячился в предыдущем посте и вёл себя недостойно "люди умные...". Извини.
ЗЫ2. Но вас тут много, а я один
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 05:02
Оценка: :))
Здравствуйте, VladD2, Вы писали:

О! Влад подтянулся, ну всё... капец вам, пацаны
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 05:12
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>Можно название хотя бы одной ОС целиком написанной на С++? А то складывается впечатление, что те кто занимается этим системным программированием как-то не заметили что С++ был создан для системного программирования.


E>Целиком? А есть ОС целиком написанные на C? Т.е. чтобы совсем без ассемблера?


Отвечать вопросом на вопрос не красиво.

E>Насколько мне известно, в твоей любимой ОС очень много на С++ написано.


В CLI ~20 мег исходников из 80-ти написаны на C++. Главным образом рантайм. Но этого никто и не скрывает.

E>Кроме того, системное программирование -- это не только ОС. Разработка KDE, к примеру, так же относится к системному программированию.


WinForms базируются на GDI+. На чём написан GDI+ тоже мало кого интересует.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 05:12
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Стандарт C++ был принят в 1998 году. С тех пор прошло всего восемь лет.


1998 — 13 = 1985.

Впрочем для нового стандарта ещё не всё потеряно, осталось всего 5 лет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 05:43
Оценка:
Здравствуйте, kedik, Вы писали:

K>>>1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?

IT>>Юникод вполне подойдёт.
K>Какой Юникод? 2.x? 3.x? — UTF-8? UTF-16? UTF-32?

Юникодный юникод. Пойми простую вещь. Я без понятия кокой юникод у китайцев и японцев. Я даже разбираться не хочу. Но вот на этом сайте one hundred percent работает мой код, в котором такой проблемой, я тебя уверяю, я не озабачивался.

K>С++ — это язык системного уровня — и в нем все быты и байты. Если при разработке это напрягает, значит С++ явно не нужен...


Это не так. По крайней мере это было не так 5-10 лет назад. Сегодня eao197 нас убеждает в том, что якобы C++ все последние 20 лет использовался не по назначению. Я в это не верю. Более того, я протестую! В своё время я принял плюсы как ману и делал на них примерно те же задачи, которые я делаю и сейчас. И делал я это не день и не два, а более 10 лет (в сумме вместе с C примерно лет 14), методично, практически каждый день.

K>Взглянуть то на System.String и System.DateTime я могу, только как они решат мои задачи на Sun и HP например при хиром алгоритме обработки фалов на диске, к примеру?


Тогда взгляни на Java.

K>PS. Решение абстрактых проблем это конечно интересно и увлекательно... только за решения таких проблем платят исключительно абстрактные деньги... котороый можно потратить на все что угодно... чисто абстрактно конечно


Практика, друг мой, только практика, циничная практика.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 05:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Покажит международный стандарт на C# и место где в нем описывается строка.


http://www.ecma-international.org/publications/standards/Ecma-334.htm пункт 9.4.4.5.

C>std::string — это Стандарт (с большой буквы). Практически это тоже сейчас распространенный стандарт, но не абсолютный. Что вполне всех устраивает.


Это примерно как слово художник от слова "худо", так и std::string — это стандарт от слова "консенсус". Ну вот надо было всех удовлетворить. Удовлетворили, получили std::string.

C>А как ты думаешь комитет поступил? Они как раз взяли за пример строки из других языков, в результате в интерфейсе std::string сейчас 84 публичных метода. При правильном проектировании их число уменьшается до пары десятков, а остальное становится алгоритмами (см. flex_string у Александреску).


Здесь мне даже комментировать не хочется

C>А самого идеального решения не существует. Например, refcount-строки часто неэффективны в многопоточных приложениях, а SSO может приводить к сильному замедлению в дегенеративных случаях.


Самая эффективная реализация строки, которая мне попадалась как раз была сделана на рефкаунтерах — CString из MFC. Может меня, конечно, не сильно проблемы многозадачности волновали, а может в многозадачной версии библиотеки CString была специально под это заточена... но меня это никогда не волновало.

C>Да, примерно так и есть. Комитет попытался найти золотую середину — получилось... средне.


Получился у комитета, как всегда, консенсус.

C>Но это не так важно — в С++ есть все средства, чтобы это компенсировать.


Я понимаю. Закат солнца вручную, впрочем как и возможность валить лобзиком Беловежскую пущу ещё никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 03.06.06 05:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Стандартный пример для mutable — кэши и счетчики ссылок. Там mutable как раз очень нужен и вполне логичен — так как изменение членов объекта не приводит к изменению его инварианта.


А зачем данные, не влияющие на изменение инварианта, вообще хранить в объекте. Никогда не задумывался, что в этом есть некоторое противоречие?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 06:27
Оценка: -1
Здравствуйте, IT, Вы писали:

E>>Стандарт C++ был принят в 1998 году. С тех пор прошло всего восемь лет.


IT>1998 — 13 = 1985.


Ну давай тогда для справедливости скажем, что работа по стандартизации C++ началась в 1989 году. Т.е. спустя четыре года после выхода первой коммерческой версии компилятора C++. Для C# ANSI/ISO стандарта нет. Для Java так же.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 06:30
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это не так. По крайней мере это было не так 5-10 лет назад. Сегодня eao197 нас убеждает в том, что якобы C++ все последние 20 лет использовался не по назначению.


Точную цитату пожалуйста.

IT> Я в это не верю. Более того, я протестую!


Я тоже, ибо такой муры не говорил.
Я говорил, что C++ умудрились применить там, где не следовало, за что и получили. Но это совсем не означало что "все последние 20 лет" язык использовался не по назначению.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 06:33
Оценка:
Здравствуйте, IT, Вы писали:

IT>Особенно вот это порадовало:


IT>

E>> В комитет по C++ входят люди с разными интересами, ожиданиями и подготовкой. ... Одни используют C++, другие -- нет.


IT>Что можно сказать? Очень важно иметь в комитете людей, которые даже не используют язык, который взялись стандартизировать.


Очень может быть, что избавиться от них не было никакой возможности. Кроме того, в комитете могли быть, например, маркетологи компаний, занимающиеся разработкой компиляторов C++. Или технические писатели, отвечающие за создание документации к компилятору/библиотеке/инструментальному средству.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 06:42
Оценка:
Здравствуйте, IT, Вы писали:

E>>Видишь ли, понятие нормальности меняется не только в зависимости от области использования языка, но и от времени. То, что было нормально в 1986, тебе сейчас кажется не нормальным.


IT>Я же ясно написал, что понимаю под нормальным дизайном.


Свойства и делегаты?
Боюсь, что очень многие (в том числе и я) не разделяю твою точку зрения по этому вопросу.

E>>И уж тем более сохранять совместимость с ранее написанным кодом.


IT>А это тут при чём? Все компиляторы развиваются, включая C++ и тем не менее остаются совместимы с легаси кодом.


Тем не менее кроме C я не могу припомнить другого языка с таким же возрастом, как C++, для которого было столько же компиляторов на стольком количестве платформ, как для C++. Так что очень вероятно, что ты просто не подозреваешь масштаба задачи.

E>>А потом объясняешь, почему еще в двадцати (или сколько их там сейчас) компиляторах C++ нет никаких свойств или делегатов. И пытаешься заставить разработчиков этих компиляторов добавить их в свои творения.


IT>Давай мы будем говорить о реальных вещах.


Я тебе о реальных вещах и говорю. К моменту принятия C++ стандарта не было ни одного компилятора, который бы поддерживал стандарт. Поэтому стандарт писался с опережением. С расчетом на то, что со временем разработчики компиляторов подтянуться. Практически так и вышло, но 100% поддержки стандарта нет все равно. А ты говоришь о том, чтобы в то время в стандарт засунули еще несколько фич, про которые в то время никто не задумывался.

E>>К тому же рассуждать о том, что C++ динозавр и не соответствует современным требованиям действительно проще, чем признать, что нафиг не нужно было на C++ COM-ы писать.


IT>А были альтернативы? Как только мне предоставилась другая возможность, я поднапрягся, сжал силу воли в кулак и расстался с пережитками прошлого И, поверь мне на слово, ни капельки не жалею. Даже наоборот, чувствую, что прошёл один level и перешёл на следующий.


А я не тебя имел в виду, а тех, кто изобрел COM и сделал программирование на C++ для COM там веселым занятем. У них-то точно выбор был.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
От: alexeiz  
Дата: 03.06.06 06:44
Оценка:
Здравствуйте, Left2, Вы писали:

L>Хуже только Symbian Там они вообще из языка такооое сделали....


Я с Symbian'ом не знаком. Интересно узнать, что именно.
Re[30]: Tcl как обоснование ненужности поддержки компонентности в С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 06:46
Оценка:
Здравствуйте, IT, Вы писали:

E>>Да уж... Имхо, описание было довольно конкретным.


IT>Это не постановка. Это приглашение отрефакторить твой код. Этого я делать не собираюсь. Если ты объяснишь мне задачу (на словах, а не в коде), я попробую её решить без mutable. Но пытаться выкрутится в ситуации, когда без них уже никуда мне не интересно.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 03.06.06 06:53
Оценка:
Здравствуйте, VladD2, Вы писали:

NB>>наверно это очень увлекательно, бороться с ветряными мельницами...


VD>Что касается темы... Я конечно пнимаю, что разговор уже ушел очень далего от нее и надо было останавливать все разглагльствования о tcl еще на зачаточной стадии, но все же не думаю, что тяжело поднять голову в верх и прочесть тему,


во-первых, не я поднял тему tcl.
во-вторых, вас, кажется, исходная тема никогда не останавливала от перевода разговора с сторону немерле.

VD>а потом вернуться на десяток сообщений вверх по ветке...


уж не поленитесь, пожалуйста.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 03.06.06 06:57
Оценка:
Здравствуйте, VladD2, Вы писали:

NB>>поправь если ошибаюсь. мне казалось что в этой ветке мы тикл обсуждали


VD>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.


цитату не затруднит? могу даже помочь
Автор: FR
Дата: 27.05.06


VD>ЗЫ


VD>Ты хоть смотри к чему присоеденяешся.


и вам того-же

PS: может вам все-таки стоит ознакомится с языком tcl. хотя-бы поверхностно.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 03.06.06 07:01
Оценка:
IT wrote:
> K>Какой Юникод? 2.x? 3.x? — UTF-8? UTF-16? UTF-32?
> Юникодный юникод. Пойми простую вещь. Я без понятия кокой юникод у
> китайцев и японцев. Я даже разбираться не хочу. Но вот на этом сайте
> <http://www.tiffany.jp> one hundred percent работает мой код, в котором
> такой проблемой, я тебя уверяю, я не озабачивался.
Так вот, это типичный подход MS. Любой чайник может попрыгать на
клавиатуре — и это будет даже как-то работать.

Вот только как что-то потребуется серьезное сделать — начинаются проблемы.

Текущий Unicode определяет примерно 130 тысяч символов. В два байта они
не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только
никто их обычно не поддерживает в C#.

В число суррогатных символов входят, например, нотные символы. И иногда
они действительно бывают важны.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 03.06.06 07:09
Оценка:
Здравствуйте, VladD2, Вы писали:

NB>>а const_cast эмулировать нельзя.


VD>Да, да. Надо срочно подменять тему разговора...


бревнышко в глазу не мешает? нет?
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 03.06.06 07:16
Оценка:
IT wrote:
> C>Стандартный пример для mutable — кэши и счетчики ссылок. Там mutable
> как раз очень нужен и вполне логичен — так как изменение членов объекта
> не приводит к изменению его инварианта.
> А зачем данные, не влияющие на изменение инварианта, вообще хранить в
> объекте. Никогда не задумывался, что в этом есть некоторое противоречие?
А где их еще хранить без потерь скорости?

Стандартный пример для mutable — это строка, в которой хранится ее хэш.
Хэш вычисляется при необходимости.

Покажи как это сделать без mutable, const_cast и сохраняя при этом
const-correctness.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[33]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 03.06.06 07:16
Оценка:
Здравствуйте, IT, Вы писали:

IT>О! Влад подтянулся, ну всё... капец вам, пацаны


затопит

сорри за оффтоп. в веб интерфейсе съезжает дерево сообщений, если поставить textsize=smaller.
вот.
Re[33]: Tcl как обоснование ненужности поддержки компонентности в С++
От: alexeiz  
Дата: 03.06.06 08:52
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


E>>>Стандарт C++ был принят в 1998 году. С тех пор прошло всего восемь лет.


IT>>1998 — 13 = 1985.


E>Ну давай тогда для справедливости скажем, что работа по стандартизации C++ началась в 1989 году. Т.е. спустя четыре года после выхода первой коммерческой версии компилятора C++. Для C# ANSI/ISO стандарта нет. Для Java так же.


Не совсем нету. Для C# 1.0 есть:
ISO/IEC 23270 C# Language Specification

Стандартизация C# проводится через ECMA, а потом ECMA стандарт продвигается в ISO в соответствии с Fast Track процессом.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 03.06.06 09:01
Оценка:
IT wrote:
> C>Покажит международный стандарт на C# и место где в нем описывается строка.
> http://www.ecma-international.org/publications/standards/Ecma-334.htm
> пункт 9.4.4.5.

11.2.3 The string type
The string type is a sealed class type that inherits directly from
object. Instances of the string class
represent Unicode character strings.
Values of the string type can be written as string literals (§9.4.4).
The keyword string is simply an alias for the predefined class
System.String.

И это почти все, что есть про string в стандарте языка.

Из С++:

21 Strings library [lib.strings]
1 This clause describes components for manipulating sequences of
“characters,” where characters may be of
any POD (3.9) type. In this clause such types are called char-like
types, and objects of char-like types are
called char-like objects or simply “characters.”
2 The following subclauses describe a character traits class, a string
class, and null-terminated sequence utilities,
as summarized in Table 36
...

А это С++ — по сути тоже самое написано.

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

> Это примерно как слово художник от слова "худо", так и std::string — это

> стандарт от слова "консенсус". Ну вот надо было всех удовлетворить.
> Удовлетворили, получили std::string.
Ну да, а как ты еще хотел? В C# точно так же получили System.String. И я
не вижу чем оно лучше.

> Самая эффективная реализация строки, которая мне попадалась как раз была

> сделана на рефкаунтерах — CString из MFC.
Фига. В ней нет SSO (Small String Optimization), так что в куче задач
она проиграет std::string'ам (так как благодаря SSO отпадает
необходимость в динамическом распределении памяти для маленьких строк).

> Может меня, конечно, не сильно

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

> C>Да, примерно так и есть. Комитет попытался найти золотую середину —

> получилось... средне.
> Получился у комитета, как всегда, консенсус.
На то он и комитет. Я не вижу в этом ничего плохого.

> C>Но это не так важно — в С++ есть все средства, чтобы это компенсировать.

> Я понимаю. Закат солнца вручную, впрочем как и возможность валить
> лобзиком Беловежскую пущу ещё никто не отменял.
Ага. У меня есть свои велосипедные строки (а еще вектора и списки),
которые на большинстве задач эффективнее стандартных.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: kaer  
Дата: 03.06.06 09:43
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Проблема в том, что порождение идеального решения для предикатной логики это насколько я знаю NP-задача, то есть не факт, что закончится при этой жизни.


Насколько мне известно, Пролог работает с более узким языком, чем предикатная логика плюс есть правила разрешения неопределенностей (что-то вроде не сумели доказать — значит выдаем отрицательный ответ). Так что где NP-полнота я не понял Либо я не понял, в чем заключается идеальность
Re[20]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Cyberax Марс  
Дата: 03.06.06 09:48
Оценка:
IT wrote:
> E> В комитет по C++ входят люди с разными интересами, ожиданиями и
> подготовкой. ... Одни используют C++, другие -- нет.
> Что можно сказать? Очень важно иметь в комитете людей, которые даже не
> используют язык, который взялись стандартизировать.
Можно вопрос? Все ли менеджеры в MS, участвующие в разработке языка,
владеют C#ом?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
От: alexeiz  
Дата: 03.06.06 11:14
Оценка: 14 (1)
Здравствуйте, IT, Вы писали:

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


Почитай введение в этом документе. Может он тебя на счёт возможности/реальности/полезности свойств в C++ просветит.

Советую обратить внимание на следующий фрагмент, из которого понятно, что введение свойств в язык C++ приносит в лучшем случае очень ограниченную выгоду, так как C++ не может гарантировать сопутствующей инфраструктуры, наподобие той, что есть в .NET:

My impression is that the main benefit of properties is not their syntactic sleight-of-hand but (1)
their ability to be discovered through introspection/reflection and manipulated nonprogrammatically
by some sort of RAD tool, and (2) their ability to be stored (I think "pickled" is
the term used with Java Beans) in this configured state, so that they can be loaded at runtime,
already configured.

Re[36]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка:
Здравствуйте, eao197, Вы писали:

E>Бым-га-га. Наглядная демонстрация того, что в большинстве случаев ты говоришь о том, чего не знаешь.


Что я в данном случае не знаю? Статью я твою о нем прочел. И вывода было два. 1. Очередной велосипед. 2. Средство разработки явно выбрано не верно.

Скорее это ты наглядно демонстрируешь, что единственным "аргументом" в споре у тебя является необоснованное сомнение в словах оппонента. Ну, дык такие аргументы идут лесом в месте с теми кто ими пытается оперировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А где их еще хранить без потерь скорости?


C>Стандартный пример для mutable — это строка, в которой хранится ее хэш.

C>Хэш вычисляется при необходимости.

C>Покажи как это сделать без mutable, const_cast и сохраняя при этом

C>const-correctness.

Нда, и эти люди тут еще спорить пытаются о чем-то .

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

Вот только есть одна проблема. Данный подход отлично работает в безопасных языка. Но в языках где есть приведения типов и указатели на любую защиту можно наплевать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка:
Здравствуйте, night beast, Вы писали:

NB>во-первых, не я поднял тему tcl.


Ты в нее влез в середине. Думаешь, это что-то меняет?

NB>во-вторых, вас, кажется, исходная тема никогда не останавливала от перевода разговора с сторону немерле.


Ты голову то подними, и прочти название темы. Может тогда прийдет просветление.

VD>>а потом вернуться на десяток сообщений вверх по ветке...


NB>уж не поленитесь, пожалуйста.


Нда, полная дезориентация в пространстве. Это я тебе сказал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка: -1
Здравствуйте, kaer, Вы писали:

K>Насколько мне известно, Пролог работает с более узким языком, чем предикатная логика плюс есть правила разрешения неопределенностей (что-то вроде не сумели доказать — значит выдаем отрицательный ответ). Так что где NP-полнота я не понял Либо я не понял, в чем заключается идеальность


Почитай любую научную работу о Прологе. Пересказывать подобные вещи тут нет ни желания, ни возможности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Так вот, это типичный подход MS. Любой чайник может попрыгать на

C>клавиатуре — и это будет даже как-то работать.

Как ты думшь, кто из вас двоих для окружающих чайник? Ты или IT?

C>Вот только как что-то потребуется серьезное сделать — начинаются проблемы.


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

C>Текущий Unicode определяет примерно 130 тысяч символов. В два байта они

C>не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только
C>никто их обычно не поддерживает в C#.

Эти слова я уже слышал. На них я тебе уже отвечал. Приведи, плиз, ссыкли доказывающие ущербность поддержки юникода в дотнете. А если не можешь, то не повторяй глупость снова и снова. От этого она рузумными словами не становится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка: -1
Здравствуйте, night beast, Вы писали:

VD>>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.


NB>цитату не затруднит? могу даже помочь
Автор: FR
Дата: 27.05.06


Меня как-то пугает полная неадекватность оппонентов. Ты же сам привел ссылку в которой видно, что tcl появился совершенно от балды, в подветке где обсуждалась проблема построения гуи на С++? Одну подпорку (генераторы кода в QT) подменили второй подпоркой tcl. Причем вторая имеет еще меньшее отношение к С++.

VD>>ЗЫ


VD>>Ты хоть смотри к чему присоеденяешся.


NB>и вам того-же


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

NB>PS: может вам все-таки стоит ознакомится с языком tcl. хотя-бы поверхностно.


Это как-то поможет встраиванию в С++ средств построения ГУИ? Если нет, то спасибо. Я знаю куда более удобные для меня пути построения качественного ГУИ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 03.06.06 13:49
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Почитай введение в этом документе. Может он тебя на счёт возможности/реальности/полезности свойств в C++ просветит.


В их полезности меня не надо убеждать/отговаривать. Я ими реально пользовался в C++ несколько лет и находил их удобными.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Tcl как обоснование ненужности поддержки компонентности
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:49
Оценка:
Здравствуйте, FR, Вы писали:

Все, спорьте ребята без меня. Тема отличная, но мне не интересная.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:49
Оценка: +1 :))
Здравствуйте, eao197, Вы писали:

E>Свойства и делегаты?

E>Боюсь, что очень многие (в том числе и я) не разделяю твою точку зрения по этому вопросу.

Сри, а тебя сильно покоробило бы если бы эти вещи были бы в языке? Причем вместо делегатов лучше говорить о функциональном типе.

E>Я тебе о реальных вещах и говорю. К моменту принятия C++ стандарта не было ни одного компилятора, который бы поддерживал стандарт.


... к сегодняшнему момент есть один такой компилятор...

Прогресс однако.

E> Поэтому стандарт писался с опережением.


Да, да. Всем очень интересны аспекты написания кривых решений. Рассказывайте моэстро...

E>А я не тебя имел в виду, а тех, кто изобрел COM и сделал программирование на C++ для COM там веселым занятем. У них-то точно выбор был.


Серьезно? И какой? Ты бы чем говорить о том в чем не понимаешь (ты кажется любишь мне подобные вещи говорить) почитал бы труды Дона Бокса посвященные КОМ-у. Он там очень хорошо рассказывает как создавался КОМ, что за идеи легли в основу, на чем создавался КОМ, и почему КОМ получился таким как получился.

За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с). И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:49
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>

A>My impression is that the main benefit of properties is not their syntactic sleight-of-hand but (1)
A>their ability to be discovered through introspection/reflection and manipulated nonprogrammatically
A>by some sort of RAD tool, and (2) their ability to be stored (I think "pickled" is
A>the term used with Java Beans) in this configured state, so that they can be loaded at runtime,
A>already configured.


То есть обоснованием для отсуствия одной фичи является отсуствие другой фичи в сочетании с которой полезность первой повышается? А что мешало ввести вторую фичу? По этому поводу тоже есть огромные притензии. Отсуствие механизма на подобии рефлексии являетвя главным припятствием не позволяющим упростить решение огромного класса задач.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:49
Оценка: +1 -1
Здравствуйте, eao197, Вы писали:

IT>>Это не постановка. Это приглашение отрефакторить твой код. Этого я делать не собираюсь. Если ты объяснишь мне задачу (на словах, а не в коде), я попробую её решить без mutable. Но пытаться выкрутится в ситуации, когда без них уже никуда мне не интересно.


E>Все, вопрос закрыт.

E>Без обид, но мы с тобой на одном проекте не работали, квалификации друг друга не знаем. Поэтому не будем сейчас учить друг друга правильному проектированию или доказывать что кто-то чего-то не понимает или делает не так.

Да, действительно. На лицо полный слив, так как на просьбу дать описание задачи на раговорном языке пошли рассуждения о квалификации оппонента.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Можно вопрос? Все ли менеджеры в MS, участвующие в разработке языка,

C>владеют C#ом?

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

Вот только пиарщики в стандартизации явно не принимают участия. Как и в процессе введения фич в язык.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 03.06.06 14:25
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>И это почти все, что есть про string в стандарте языка.


Я в курсе что такое string. Могу ещё раз повторить специально для тебя. C# без фреймворка не является полноценным языком и System.String был в нём с самого начала и пусть через алиан, но выглядит как часть языка. В C++ std::string появился 10 лет спустя и за последующие 10 лет так и не стал стандартной строкой.

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


А с практической, в C#... даже не так, в .NET одна строка на всех, а C++ целый зверинец, в котором std::string как стандарт выглядит мягко говоря не очень убедительно.

>> Самая эффективная реализация строки, которая мне попадалась как раз была сделана на рефкаунтерах — CString из MFC.

C>Фига. В ней нет SSO (Small String Optimization), так что в куче задач она проиграет std::string'ам (так как благодаря SSO отпадает необходимость в динамическом распределении памяти для маленьких строк).

Тем хуже для плюсов

>> Получился у комитета, как всегда, консенсус.

C>На то он и комитет. Я не вижу в этом ничего плохого.

Здесь консенсус надо взять в кавычки.

>> C>Но это не так важно — в С++ есть все средства, чтобы это компенсировать.

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

У меня тоже были. Строки, коллекции, работа с датами. Было жалко всё это вот так выкидывать. Сейчас я о них даже не вспоминаю.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 03.06.06 14:25
Оценка:
Здравствуйте, eao197, Вы писали:

E>Очень может быть, что избавиться от них не было никакой возможности. Кроме того, в комитете могли быть, например, маркетологи компаний, занимающиеся разработкой компиляторов C++. Или технические писатели, отвечающие за создание документации к компилятору/библиотеке/инструментальному средству.


Вот и я говорю. Не комитет, а балаган. Технические писатели определяют стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Синтаксический сахар или C++ vs. Nemerle :)
От: Cyberax Марс  
Дата: 03.06.06 14:28
Оценка: 1 (1)
VladD2 wrote:
> Строка должна быть неизменяемым классом.
Не согласен, но пока пусть будет так.

> Хэш рассчитываться при создании или первом обращении.

А как он может рассчитываться, если объект неизменяем?

Следовательно, неизменяемым должно быть его поведение в ответ на события
(aka "инвариант"), но внутреннее состояние должно при этом изменится.

> Защита при этом обеспечивается средстами ООП, а константровсть

> вообще как бы не причем.
Константность в С++ — это простейшее средство проверки правильности
использования модели.

> Вот только есть одна проблема. Данный подход отлично работает в

> безопасных языка.
Не работает. Создатели Java и C# посчитали, что нагружать мозги бедных
индусов понятиями о константности не стоит. Вот и сделели ее бедную
эмуляцию в виде иммутабельных sealed классов.

> Но в языках где есть приведения типов и указатели на

> любую защиту можно наплевать.
Что все так на защите помешаны?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[45]: Синтаксический сахар или C++ vs. Nemerle :)
От: Cyberax Марс  
Дата: 03.06.06 14:31
Оценка:
VladD2 wrote:
> C>Так вот, это типичный подход MS. Любой чайник может попрыгать на
> C>клавиатуре — и это будет даже как-то работать.
> Как ты думшь, кто из вас двоих для окружающих чайник? Ты или IT?
А я что-то про IT говорил???

> C>Текущий Unicode определяет примерно 130 тысяч символов. В два байта они

> C>не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только
> C>никто их обычно не поддерживает в C#.
> Эти слова я уже слышал. На них я тебе уже отвечал. Приведи, плиз, ссыкли
> доказывающие ущербность поддержки юникода в дотнете.
1. Размер символа в CLR — два байта. Ты согласен или ссылки на спеку дать?
2. Всего символов 130 тысяч.
3. Все символы в два байта не вместятся.
4. Нельзя использовать прямую индексную адресацию для работы символами в
строке.
5. И нафига была затевать всю возню с двухбайтовыми символами???
6. И как теперь нормально использовать quadchar'ы в CLR?

Что здесь не так?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[22]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 03.06.06 14:36
Оценка: -1 :)
IT wrote:
> Вот и я говорю. Не комитет, а балаган. Технические писатели определяют
> стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
Так в C# тоже нет строк в языке!
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 03.06.06 15:35
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Так в C# тоже нет строк в языке!

В C# ВСЕ встроеные типы находятся в библиотеке. И это неизбежно из-за компонентной модели .НЕТ.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 15:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Так вот, это типичный подход MS. Любой чайник может попрыгать на

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

Значит все же про себя? К чему тут фраза про любого чайника?

>> C>Текущий Unicode определяет примерно 130 тысяч символов. В два байта они

>> C>не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только
>> C>никто их обычно не поддерживает в C#.
>> Эти слова я уже слышал. На них я тебе уже отвечал. Приведи, плиз, ссыкли
>> доказывающие ущербность поддержки юникода в дотнете.
C>1. Размер символа в CLR — два байта.

Неверная фрмулировка. Верная звучит так — для хранения строк .Net предпологает использование UTF-16.

C> Ты согласен или ссылки на спеку дать?


Я не согласен с формулировкой.

C>2. Всего символов 130 тысяч.


Вот эти подробности меня никогда не волновали.

C>3. Все символы в два байта не вместятся.


Да. Есть набор символов которые представляются в UTF-16 двубайтовыми сочетаниями. Огромная редкость и обычно их просто нет в шрифтах, но формально есть.

C>4. Нельзя использовать прямую индексную адресацию для работы символами в

C>строке.

Смотря для каких целей.

C>5. И нафига была затевать всю возню с двухбайтовыми символами???


Что использовать UTF-32?
UTF-16 является разумным компромисом. Программы для 99.9% применений можно писать так как будто символ всегда 16 бит. А если что есть возможность и повыпердиваться.

C>6. И как теперь нормально использовать quadchar'ы в CLR?


Так в чем проблема то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 15:37
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

>> Строка должна быть неизменяемым классом.

C>Не согласен, но пока пусть будет так.

Твои проблемы, жрать кактусы тоже кому-то надо.

>> Хэш рассчитываться при создании или первом обращении.

C>А как он может рассчитываться, если объект неизменяем?

Неизменяемость объекта != константности. Неизменяемость означает невозможность изменения его инварианта. То есть сколько бы ты не вызвал его методы с одними и теми же параметрами ты всегда должен получать один и тот же результат. Рассчет хэш-значения не меняет инваринта объекта. Так что его можно как вычислять каждый раз, так и закэшировать при первом обращении.

C>Следовательно, неизменяемым должно быть его поведение в ответ на события

C>(aka "инвариант"), но внутреннее состояние должно при этом изменится.

Неверные следствия. Поведение не меняется, состояние стало быть тоже. А то что делает объект в своих потрахах — это его личные трудности. Нас от них защищает инкапсуляция. Нам важно, что не возникает никаких побочных эффектов, а на остальное чехать.

>> Защита при этом обеспечивается средстами ООП, а константровсть

>> вообще как бы не причем.
C>Константность в С++ — это простейшее средство проверки правильности
C>использования модели.

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

В немерле есть понятие неизменяемой переменной, но нет понятия константности для классов или методов.

>> Вот только есть одна проблема. Данный подход отлично работает в

>> безопасных языка.
C>Не работает. Создатели Java и C# посчитали, что нагружать мозги бедных
C>индусов понятиями о константности не стоит. Вот и сделели ее бедную
C>эмуляцию в виде иммутабельных sealed классов.

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

Кстати та безграмотность с которой в С++ оперируют термином константность в очередной раз наводит на мысль о слабой теоритической подготовке его авторов. Изменяемая константа — это натуральный оксюморон.

>> Но в языках где есть приведения типов и указатели на

>> любую защиту можно наплевать.
C>Что все так на защите помешаны?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 15:37
Оценка:
Здравствуйте, IT, Вы писали:

IT>Вот и я говорю. Не комитет, а балаган. Технические писатели определяют стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.


Я думаю, что главное не то, что строки не в языке, а то, что они не удовлетворяют многих пользователей. Другими словами имеют плохой дизайн. Но тут мы быстро прийдем, что для хорошего дизайна хорошо бы иметь GC и безопасный язык.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 03.06.06 15:58
Оценка: -1
WolfHound wrote:
> C>Так в C# тоже нет строк в языке!
> В C# ВСЕ встроеные типы находятся в библиотеке. И это неизбежно из-за
> компонентной модели .НЕТ.
Вот! Значит в C# нет строки в языке. ЧТД.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 03.06.06 16:13
Оценка: 30 (1) +1
Здравствуйте, Cyberax, Вы писали:

C>IT wrote:

>> Вот и я говорю. Не комитет, а балаган. Технические писатели определяют
>> стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
C>Так в C# тоже нет строк в языке!

Не только в C# есть строки, но и в CIL, да и вообще они являются неотъемлемой частью CLR.

Вообще с такими заявлениями можно договориться до того, что в C++ нет например dynamic_cast и typeid,в Nemerle нет функциональных типов, кортежей и списков, а в D нет динамических и ассоциативных массивов, GC и тех же динамических кастов, да еще и кучи других вещей.

Дело в том, что язык это одно дело, а его рантайм это совсем другое дело. В C#, Nemerle и даже в D рантайм просто реализован более умно и дальновидно, и является более самостоятельной частью(практически частью стандартной библиотеки), чем в компиляторах C++.

Нужно больше обращать внимание на то чем являются эти конструкции/типы во время компиляции. Для компилятора C++ например строковые литералы являются константными массивами char или wchar_t, а для любого языка .NET они являются строкой, так как и для CLR они являются строкой. Более того JIT в CLR очень хорошо осведомлен о таких типах как System.String и System.Text.StringBuilder и умеет специально оптимизировать работу с ними.
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 03.06.06 16:48
Оценка: +1
Здравствуйте, VladD2, Вы писали:

IT>>Вот и я говорю. Не комитет, а балаган. Технические писатели определяют стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.


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


std::string, как и весь std:: — это "компромис", консенсус, блин.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Tcl как обоснование ненужности поддержки компонентнос
От: Зверёк Харьковский  
Дата: 03.06.06 16:52
Оценка: +2
Здравствуйте, IT, Вы писали:

NB>>Тк тем и хорош, что позволяет описывать логику ГУИ


IT>ГУИ надо рисовать, а не описывать.


А это спорно
FAQ — це мiй ай-кью!
Re: Tcl как обоснование ненужности поддержки компонентности
От: FR  
Дата: 03.06.06 17:17
Оценка: +2 :))
Классно, так извратить название темы. Влад тебе уже пора в политику идти.
Re[18]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 03.06.06 17:28
Оценка:
Здравствуйте, IT, Вы писали:

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


FR>>Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET


IT>В IT? Сомневаюсь.


В науке. Да и в IT острие отнюдь не в майнстриме.
Re[12]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 03.06.06 17:28
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это ты откровенно переверашь мои слова. Я гляжу и сужу. Вижу убогость, называю ее таковой. Вот полгядел на ссылку и увидил малый набор компонентов, кривейший внешний вид (даже иконки и те убогие). На вопрос о гриде получил ответ, что пиписка коротка. Какие мне еще делать выводы?


нормальные иконки, а то что коряво выглядит это вина linux'а под XP все нормально.

FR>>Ну и посмотрим на сколько неубогим станет NET если будет подерживать столько же платформ сколько и tcl/tk.


VD>А зачем мне столько платформ если для этого нужно обязательно мириться с убогостью? Ну, их в лес. Мне Виндовс за глаза хватит. Хотя конечно есть Ява с ее компонентным подходом. Там не все так здорово, видать многоплатформность дает знать, но все же куда лучше чем tcl. И компоненты сторонние есть, и ГУЙ приличный делается (смотрим на IDEA).


У tcl gui не хуже чем в java, и при этом работает шустрее.

VD>А вот где приличный ГУЙ на С++ и без подпорок? А? Я и на tcl то его не вижу.


А при чем тут C++?

FR>>Он может расширятся как и средствами языка на котором ведется разработка так и с помощью си — с++

FR>>На него достаточно много готовых контролов от других производителей.

VD>Ну, где среди них приличный грид? И почему его нет если все так шоколадное? Может быть кто-то выдает желаемое за дейсвительное?


Мне грид не нужен, так что все хорошо

VD>И все же если вспомнить, что tcl это очередная подпорка, то можно откинув ее объяснить что мешало встроить в С++ поддержку компонентного подхода? Почему в этом языке до сих пор единственным средством импорта чужих модулей являются допотопные #include-ы?


Какая подпорка, какой C++? Tcl совершенно самостоятельный язык, к C++ вообще никакого отношения ни имеет. Более того tk — gui часть tcl, легко используется из множества совершенно разных и не похожих на tcl языков.
Re[2]: Tcl как обоснование ненужности поддержки компонентнос
От: FR  
Дата: 03.06.06 17:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Все, спорьте ребята без меня. Тема отличная, но мне не интересная.


tcl как раз очень компонентно ореинтированная вещь, вообще что не сабж то перл в этой теме
Re[18]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 03.06.06 17:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.


TCL я приплел совершенно без всякого отношения к С++, только как пример языка заточенного на легкое построение GUI.
Re[18]: Tcl как обоснование ненужности поддержки компонентно
От: FDSC Россия consp11.github.io блог
Дата: 03.06.06 17:50
Оценка:
Здравствуйте, IT, Вы писали:

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


FR>>Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET


IT>В IT? Сомневаюсь.


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

P.S. Просьба не убеждать, что фортран — плохой, он просто г-но
Re[19]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 03.06.06 18:07
Оценка:
Здравствуйте, FR, Вы писали:

FR>В науке.


Если хочется обсудить науку, то можно завести отдельную ветку.

FR>Да и в IT острие отнюдь не в майнстриме.


А где?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Tcl как обоснование ненужности поддержки компонентно
От: IID Россия  
Дата: 03.06.06 18:10
Оценка: -1 :)))
Здравствуйте, VladD2, Вы писали:


VD>Ага! Нельзя! Ведь они компоненты. А компонентам нужна среда исполнения. Сцинтила в С++ выглядит как тип окна с сообщениями. О визуальных дизайнерах не может быть и речи. Если сравнить сложность и обхем работ требуемый для подключения Сцинтилы к проекту на С++ не сравним с тем же самым на C#. В C# я просто бросаю компонет на форму и настраиваю его свойства. А в С++ нет ни, формы, ни компонента, ни даже понятия свойства. Это закат солнца врнучную вместо работы. С гридом же еще смешнее. Его просто не написали для С++. Он есть для КОМ и дотнета. КОМ-варинт в сто раз проще использовать в ВБ6. А дотнет... да в нем есть МС++, но к С++ он никакого отношения не имеет.



Напомнило Дельфёвый TProgrammer... мдя...
kalsarikännit
Re[2]: Tcl как обоснование ненужности поддержки компонентнос
От: FDSC Россия consp11.github.io блог
Дата: 03.06.06 18:50
Оценка: +1 :)
Здравствуйте, FR, Вы писали:

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


Это называется доспорились до чёртиков. Я 2,5 часа тему читал, и самое интересное — по теме 1-2 поста, не больше
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 19:07
Оценка: +2 :)
Здравствуйте, VladD2, Вы писали:

VD>Сри, а тебя сильно покоробило бы если бы эти вещи были бы в языке? Причем вместо делегатов лучше говорить о функциональном типе.


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

E>> Поэтому стандарт писался с опережением.


VD>Да, да. Всем очень интересны аспекты написания кривых решений. Рассказывайте моэстро...


Кому расказывать, тебе что-ли? Рассмешил. Ты уже приговорил C++, так что толку тебе что-нибудь рассказывать?

E>>А я не тебя имел в виду, а тех, кто изобрел COM и сделал программирование на C++ для COM там веселым занятем. У них-то точно выбор был.


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


Нет уж, увольте. С меня хватило нескольких попыток поизучать OLE, OLE2 и того, что шло за ними.

VD>За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с).


Потому, что биндинг CORBA -- результат работы комитета. Ребята из www.zeroc.com для своего Ice более удобное решение нашли. Потому что были кровно заинтересованы в результате.

VD> И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.


Очень сильно сомневаюсь, что тебе довелось познакомиться хотя бы с 0.1% C++ библиотек.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Синтаксический сахар или C++ vs. Nemerle :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 19:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Неизменяемость объекта != константности. Неизменяемость означает невозможность изменения его инварианта. То есть сколько бы ты не вызвал его методы с одними и теми же параметрами ты всегда должен получать один и тот же результат. Рассчет хэш-значения не меняет инваринта объекта. Так что его можно как вычислять каждый раз, так и закэшировать при первом обращении.


Где хранить кэш. Внутри объекта или снаружи?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 19:11
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


Еще раз -- C++ не задумывался как безопасный язык. Вокруг него всегда было достаточно как безопасных языков, так и языков со сборкой мусора.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: Синтаксический сахар или C++ vs. Nemerle :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 19:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что я в данном случае не знаю? Статью я твою о нем прочел. И вывода было два. 1. Очередной велосипед.


Это никогда не скрывалось. Так что америку ты не открыл.

VD> 2. Средство разработки явно выбрано не верно.


До тех пор пока на C++ пишут код и создают реальные системы инструменты для C++ будет иметь смысл создавать.

Так что твой вывод, скорее, можно выразить так: "Для меня приговором явился выбор C++ вместо C#".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 03.06.06 19:31
Оценка:
Здравствуйте, IT, Вы писали:

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


A>>Почитай введение в этом документе. Может он тебя на счёт возможности/реальности/полезности свойств в C++ просветит.


IT>В их полезности меня не надо убеждать/отговаривать. Я ими реально пользовался в C++ несколько лет и находил их удобными.


Можно поговорить о практической полезности этой фичи в C++. Вот ты как её использовал, например?
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 03.06.06 19:48
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


Началось всё с #import. Там без свойств никак. Поначалу было странно, потом привык, понравилось. Подсмотрел реализацию и начал в своём коде использовать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 03.06.06 19:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


A>>

A>>My impression is that the main benefit of properties is not their syntactic sleight-of-hand but (1)
A>>their ability to be discovered through introspection/reflection and manipulated nonprogrammatically
A>>by some sort of RAD tool, and (2) their ability to be stored (I think "pickled" is
A>>the term used with Java Beans) in this configured state, so that they can be loaded at runtime,
A>>already configured.


VD>То есть обоснованием для отсуствия одной фичи является отсуствие другой фичи в сочетании с которой полезность первой повышается?


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

>А что мешало ввести вторую фичу? По этому поводу тоже есть огромные притензии. Отсуствие механизма на подобии рефлексии являетвя главным припятствием не позволяющим упростить решение огромного класса задач.


Может быть да, а может быть и нет. Было бы это так нужно большому количеству людей, которые без рефлексии страдают, нашёлся бы среди них один, который написал бы достаточно детальное предложение о включении рефлексии в стандарт. Пока этого не произошло.
Re[19]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка: -2
Здравствуйте, FR, Вы писали:

VD>>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.


FR>TCL я приплел совершенно без всякого отношения к С++, только как пример языка заточенного на легкое построение GUI.


То есть ты занялся злосным офтопиком, а я тебя просто не правильно понял? Если, так, то скажи... Тебя забаним на дене, а ветку в помойку отправим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка: 21 (1) :)
Здравствуйте, eao197, Вы писали:

VD>>Сори, а тебя сильно покоробило бы если бы эти вещи были бы в языке? Причем вместо делегатов лучше говорить о функциональном типе.


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


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

Вот об этом и идет речь.

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

И что же мы слышим в ответ? "Язык надо развивать библиотеками..." Но позвольте, реализация функционального типа и лямбды средствами С++ жутко сложное занятие и не приводящее к удовлетворительному для всех результату. За 20 лет существования языка было сделано множество попыток, но все они имели те или иные недостатки. А уж их сложность, объемность и тормоза при компиляции стали христоматийными.

Так с чем собственно борьба?

E>Нет уж, увольте. С меня хватило нескольких попыток поизучать OLE, OLE2 и того, что шло за ними.


Раз ты изучал данные технологии, то должен знать главное отличие ОЛЕ от ОЛЕ2. В чем оно заключается?

Ну, ладно, раз читать ты про КОМ не хочешь, то в предь не говори про него не чего. А то групость получается. Поверь просто на слово, что КОМ делали именно на С++. С++ и С — это два языка на которых можно разрабатывать КОМ-объекты без поддержки со стороны компилятора. Причем на С это выглядит просто ужасно, так как при этом эмулируются такие вещи как VTBL C++.

VD>>За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с).


E>Потому, что биндинг CORBA -- результат работы комитета. Ребята из www.zeroc.com для своего Ice более удобное решение нашли. Потому что были кровно заинтересованы в результате.


Согласен. Но комитета по плюсам, так как на Яве и дотнете биндинг выглядит отлично.

VD>> И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.


E>Очень сильно сомневаюсь, что тебе довелось познакомиться хотя бы с 0.1% C++ библиотек.


Это твои личные проблемы. Мало ли в чем сомневаюсь я...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


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

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


МС сделала даже реализацию С++-компилятора поддерживающего рефлексию. Борланд для своей VCL тоже кое что сделал. Обратились бы к ним если у самих мозгов не хватает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>Что я в данном случае не знаю? Статью я твою о нем прочел. И вывода было два. 1. Очередной велосипед.


E>Это никогда не скрывалось. Так что америку ты не открыл.


Причем тут америка? Я спросил — что я не знал?

VD>> 2. Средство разработки явно выбрано не верно.


E>До тех пор пока на C++ пишут код и создают реальные системы инструменты для C++ будет иметь смысл создавать.


E>Так что твой вывод, скорее, можно выразить так: "Для меня приговором явился выбор C++ вместо C#".


Не для меня, а с моей точки зрения. И не вместо C#, а вобще в корне не верно. Собственно результаты ты и пожинашь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>Неизменяемость объекта != константности. Неизменяемость означает невозможность изменения его инварианта. То есть сколько бы ты не вызвал его методы с одними и теми же параметрами ты всегда должен получать один и тот же результат. Рассчет хэш-значения не меняет инваринта объекта. Так что его можно как вычислять каждый раз, так и закэшировать при первом обращении.


E>Где хранить кэш. Внутри объекта или снаружи?


Без разницы. Это проблемы реализации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


E>Еще раз -- C++ не задумывался как безопасный язык.


Страуступ постоянно говорит обратное.

E> Вокруг него всегда было достаточно как безопасных языков, так и языков со сборкой мусора.


А сборка мусора в данном случае нужна не для безопасности. Просто он сильно пуростил бы реализацию и избавил бы от таких дурацких решений как метод возвращающий указатель на char.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 03.06.06 22:05
Оценка: +1 :))
Здравствуйте, VladD2, Вы писали:


FR>>TCL я приплел совершенно без всякого отношения к С++, только как пример языка заточенного на легкое построение GUI.


VD>То есть ты занялся злосным офтопиком, а я тебя просто не правильно понял? Если, так, то скажи... Тебя забаним на дене, а ветку в помойку отправим.


Да можешь забанить.
Наверно это будет первый случай когда тут банят за офтопик
Re[21]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 22:39
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Да можешь забанить.

FR>Наверно это будет первый случай когда тут банят за офтопик

Тут банят за офтопик не редко. Нужно просто часто им заниматься. Ну, и я за это действительно не баню. И вообще я тебя подкалываю. Но как известно в каждой шутке...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: Андрей Хропов Россия  
Дата: 04.06.06 00:00
Оценка: 1 (1) +2
Здравствуйте, VladD2, Вы писали:

VD>О. Вот об этом и тема. Давно пора сменить язык.

Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.
А в number crunching что-то не видно.

VD> С++ морально устарел.

Ну немолод

VD> Не имеет ни одного приемущества.

Основное преимущество — быстрый код, сравнимый с C.
И существенная экономия памяти по сравнению с Java/.NET
(не говоря уже про то, что хорошая реализация .NET пока есть только в Windows).

Впрочем все это уже 100 раз обсуждалось.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: Андрей Хропов Россия  
Дата: 04.06.06 00:14
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>> Не имеет ни одного приемущества.

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

Конечно, Nemerle способен предложить кое-что покруче, посмотрим что из этого выйдет...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 04.06.06 03:32
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.

АХ>А в number crunching что-то не видно.

Там рулят фортраны. Впрочем, если не сложно, дай ссылку на такой алгоритм перемалывания.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[47]: Синтаксический сахар или C++ vs. Nemerle :)
От: Дьяченко Александр Россия  
Дата: 04.06.06 03:38
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>2. Всего символов 130 тысяч.

VD>Вот эти подробности меня никогда не волновали.

C>>3. Все символы в два байта не вместятся.

VD>Да. Есть набор символов которые представляются в UTF-16 двубайтовыми сочетаниями.

Может всетаки 4 байтами? В UTF-16 вроде символы восновном 2 байтовые.

VD>Огромная редкость и обычно их просто нет в шрифтах, но формально есть.


Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй символ

C>>6. И как теперь нормально использовать quadchar'ы в CLR?

VD>Так в чем проблема то?

Действительно как? Мне просто интересно (врятли хоть раз использую...)
... << RSDN@Home 1.2.0 alpha rev. 648>>
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 04.06.06 03:42
Оценка:
Здравствуйте, eao197, Вы писали:

E>Еще раз -- C++ не задумывался как безопасный язык.


Откуда такие подробности? Ты свечку держал когда он задумывался? У меня вот, например, как у жителя эрии где непосредственно разрабатывался C++ есть про его создателя некоторые интимные подробности. Но про безопасный язык я что-то не слышал
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 04.06.06 05:50
Оценка: :)
IT wrote:
> A>Можно поговорить о практической полезности этой фичи в C++. Вот ты как
> её использовал, например?
> Началось всё с #import. Там без свойств никак. Поначалу было странно,
> потом привык, понравилось. Подсмотрел реализацию и начал в своём коде
> использовать.
Берем Comet (генерирует чистый С++, даже на GCC работает) — и видим, что
свойства совсем и не нужны на самом деле.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[47]: Синтаксический сахар или C++ vs. Nemerle :)
От: Cyberax Марс  
Дата: 04.06.06 05:56
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>А я что-то про IT говорил???

VD>Значит все же про себя? К чему тут фраза про любого чайника?
Это общая фраза, про некого абстрактного чайника.

C>>1. Размер символа в CLR — два байта.

VD>Неверная фрмулировка. Верная звучит так — для хранения строк .Net предпологает использование UTF-16.
Вот только 99.99% программистов на .NET используют строки как UCS-2.

C>>2. Всего символов 130 тысяч.

VD>Вот эти подробности меня никогда не волновали.
Ага. Ведь это разрушает картину идеальности CLR и непогрешимости их создателей.

C>>3. Все символы в два байта не вместятся.

VD>Да. Есть набор символов которые представляются в UTF-16 двубайтовыми сочетаниями. Огромная редкость и обычно их просто нет в шрифтах, но формально есть.
Из-за этой огромной редкости нельзя адресоваться к символам в строке напрямую по индексу.

C>>4. Нельзя использовать прямую индексную адресацию для работы символами в

C>>строке.
VD>Смотря для каких целей.
Практически для любых.

C>>5. И нафига была затевать всю возню с двухбайтовыми символами???

VD>Что использовать UTF-32?
Да. Или не парить мозги и взять UTF-8.

VD>UTF-16 является разумным компромисом. Программы для 99.9% применений можно писать так как будто символ всегда 16 бит. А если что есть возможность и повыпердиваться.

Кто-то в соседней ветке падал в обморок от sprintf'а. Ведь если int будет размером более 256бит, то будет ПЕРЕПОЛНЕНИЕ БУФФЕРА!

А реально существующие проблемы считаются несущественными.

Интересная логика.

C>>6. И как теперь нормально использовать quadchar'ы в CLR?

VD>Так в чем проблема то?
Как мне с ним регекспы, например, использовать?
Sapienti sat!
Re[48]: Синтаксический сахар или C++ vs. Nemerle :)
От: Cyberax Марс  
Дата: 04.06.06 05:58
Оценка: 8 (1)
Дьяченко Александр wrote:
> VD>Огромная редкость и обычно их просто нет в шрифтах, но формально есть.
> Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй
> символ
Там большая часть — символы мертвых или искусственных языков (типа
Линейного-B и Клингонского).

Но есть и реально нужные символы нотной грамоты и нескольких
экзотических (но существующих) языков.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[41]: Синтаксический сахар или C++ vs. Nemerle :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 06:17
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Где хранить кэш. Внутри объекта или снаружи?


VD>Без разницы. Это проблемы реализации.


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

Это та же самая задача, словесную формулировку которой вы с IT просили у меня. Только в моем случае был не хеш (с которым возможны коллизии), а уникальная двоичная последовательность.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Синтаксический сахар или C++ vs. Nemerle :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 06:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Причем тут америка? Я спросил — что я не знал?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 06:30
Оценка: +1
Здравствуйте, IT, Вы писали:

E>>Еще раз -- C++ не задумывался как безопасный язык.


IT>Откуда такие подробности? Ты свечку держал когда он задумывался? У меня вот, например, как у жителя эрии где непосредственно разрабатывался C++ есть про его создателя некоторые интимные подробности. Но про безопасный язык я что-то не слышал


Что-то мы друг друга не понимаем. Не делал Страуструп безопасный язык. Безопаснее C -- делал. Но не настолько безопасный, как какой-нибудь Smalltalk, Ada или Modula.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 06:33
Оценка:
Здравствуйте, IT, Вы писали:

АХ>>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.

АХ>>А в number crunching что-то не видно.

IT>Там рулят фортраны. Впрочем, если не сложно, дай ссылку на такой алгоритм перемалывания.


Есть у меня инсайдерская информация об использовании C++ и Intel-овских технологий (компиляторов и специальных библиотек) в расчете погоды на каких-то опупенно мощных кластерах.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 06:45
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Лямбда — это возможность создать анонимный метод. А чтобы на нее можно былопередать ссылку нужен функциональный стиль. Вот делегат это их разновидность. Не лучшее решение, на самом деле, но уж точно лучше его отсуствия или указателей на члены в С++.


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


Насколько я понимаю, при проектировании C++ как раз внимание уделяется именно тем вещам, которые нужны разным слоям пользователей C++. Mutable -- это фундаментальная особенность, она нужна для любой предметной области, чтобы не прибегать к хакам. Свойства -- напротив. Лямбды так же нужны не всем. Более того, интерес к лямбдам повышается с популяризацией к функциональному стилю. И еще не факт, что лямбды на самом деле так удобны, как об этом говорят. Лично я по опыту использования блоков кода в Ruby не сильно в этом уверен.

VD>И что же мы слышим в ответ? "Язык надо развивать библиотеками..." Но позвольте, реализация функционального типа и лямбды средствами С++ жутко сложное занятие и не приводящее к удовлетворительному для всех результату. За 20 лет существования языка было сделано множество попыток, но все они имели те или иные недостатки. А уж их сложность, объемность и тормоза при компиляции стали христоматийными.


VD>Так с чем собственно борьба?


Так вот с этим и борьба -- не нужно делать какое-то одно универсальное средство, которое не будет удобно всем и эфективно во всех применениях.

E>>Нет уж, увольте. С меня хватило нескольких попыток поизучать OLE, OLE2 и того, что шло за ними.


VD>Раз ты изучал данные технологии, то должен знать главное отличие ОЛЕ от ОЛЕ2. В чем оно заключается?


Вот уж чего никогда не мог понять, так это жем же отличаются OLE, ActiveX, COM, COM+ и пр.

VD>Ну, ладно, раз читать ты про КОМ не хочешь, то в предь не говори про него не чего. А то групость получается. Поверь просто на слово, что КОМ делали именно на С++. С++ и С — это два языка на которых можно разрабатывать КОМ-объекты без поддержки со стороны компилятора. Причем на С это выглядит просто ужасно, так как при этом эмулируются такие вещи как VTBL C++.


И сделали так удачно, что сложность работы с COM на C++ стала притчей во языцах.

VD>>>За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с).


E>>Потому, что биндинг CORBA -- результат работы комитета. Ребята из www.zeroc.com для своего Ice более удобное решение нашли. Потому что были кровно заинтересованы в результате.


VD>Согласен. Но комитета по плюсам, так как на Яве и дотнете биндинг выглядит отлично.


В Java и .NET есть сборка мусора.
Про ее отсутствие при проектировании биндинга на C++ почему-то забыли. Из-за чего это было сделано -- из-за элементарного ламерства или создания "унифицированного" биндинга для всех языков я не знаю.

VD>>> И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.


E>>Очень сильно сомневаюсь, что тебе довелось познакомиться хотя бы с 0.1% C++ библиотек.


VD>Это твои личные проблемы. Мало ли в чем сомневаюсь я...


Ты действительно работал с 99% процентами библиотек для C++? Или же это был литературный авторский прием, гипербола?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: Синтаксический сахар или C++ vs. Nemerle :)
От: night beast СССР  
Дата: 04.06.06 07:00
Оценка: 4 (1) +2
Здравствуйте, VladD2, Вы писали:

VD>>>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.


NB>>цитату не затруднит? могу даже помочь
Автор: FR
Дата: 27.05.06


VD>Меня как-то пугает полная неадекватность оппонентов. Ты же сам привел ссылку в которой видно, что tcl появился совершенно от балды, в подветке где обсуждалась проблема построения гуи на С++? Одну подпорку (генераторы кода в QT) подменили второй подпоркой tcl.


ага. закончились аргументы, переходим не личность. знакомо.
для самых одареных объясняю.
tcl был приведен как пример того, как надо делать гуи.
потом IT попросил показать код.
назавать tcl подпоркой С++ такой же смысл, что и питон.
так понятно?

VD>Причем вторая имеет еще меньшее отношение к С++.


ага. вобще не имеет отношения. это самостоятельный язык.
вот QT -- вполне себе библиотека. для плюсов их больше десятка.

NB>>PS: может вам все-таки стоит ознакомится с языком tcl. хотя-бы поверхностно.


VD>Это как-то поможет встраиванию в С++ средств построения ГУИ? Если нет, то спасибо. Я знаю куда более удобные для меня пути построения качественного ГУИ.


как минимум, это поможет не выглядеть глупо.
О языках для численных расчетах.
От: Андрей Хропов Россия  
Дата: 04.06.06 11:46
Оценка: 37 (3) +1
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.

АХ>>А в number crunching что-то не видно.

IT>Там рулят фортраны.


Ну, общеизвестно что самая популярная библиотека численных расчетов в мире LAPACK написана на Fortran.
Есть также популярный ее порт на C — CLAPACK.
Но это скорее по историческим причинам (люди которые ее писали проходили Fortran в университетах).
В Фортране единственно чуть удобнее работать с индексами и компилятор теоретически может порождать чуть более быстрый код взасчет того, что
матрицы встроены в язык, а не как указатели в C++
(на практике именно на вычислительных задачах можно посмотреть их сравнение здесь,
в большинстве случаев C++ впереди),
а в остальном он — ****.
(это я на своем опыте говорю, немного пописал на нем, так как в школе проходили, больше не захотелось ).

Вот здесь люди собирают подписи за то, чтобы формально отказались от Фортрана.

Ну а вообще в этой области (number crunching) начинают рулить шейдеры : ( здесь )
и соответственно такие языки как Cg, DirectX HLSL и GLSL.


IT> Впрочем, если не сложно, дай ссылку на такой алгоритм перемалывания.

Вот есть такой каталог ссылок по поводу Scientific Computing Software.
Там
Fortran,
C, C++,
Python (ядро вычислений в библиотеках использует те же C/C++, Fortran ) и
MATLAB (MATLAB использует LAPACK для расчетов, а оболочка теперь переписана на Java, поэтому весьма тормозит и пямять отжирает сотнями мегабайт )
в основном.

Есть библиотека Intel IPP (она правда на чистом C).

Ну вот я использую довольно большую библиотеку для компьютерного зрения vxl, где полно математики
(там внутри сидит netlib, но не для всего).
Есть еще вот библиотеки для довольно сложных задач минимизации на графах.

Подавляющее большинство игр, где как раз много математических расчетов, написано на C++.
Популярные физические движки ( Havok, ODE)
также написаны на C/С++.

Вот еще есть такой сайт.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[32]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка: :))
Здравствуйте, night beast, Вы писали:

NB>ага. закончились аргументы, переходим не личность.


Какие могут быть аргументы с высказываниями вообще никак не относящимися к делу и протеверечащими зравому смыслу?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


Да, да. По этому есть тонны программистов которые работали не в одной области и ни разу не использовали этой возможности. И видимо именно по этому есть языки спокойно обходящиеся без mutable. Более того именно по этому идут разговоры о замене значения некоторых таких же "нужных" вещей (например auto).

E> Свойства -- напротив.


Серьезно? А вот мне ИТ они нужны. Неувязочка у вас. Хочешь проведем глосование? Сам увидишь, что минимум треть народа проголосует за то что свойства нужны.

E> Лямбды так же нужны не всем.


Еще одна не увязочка. Mutable почти никому не нужен и он есть. А лямбда нужна не всем, но очень многим и ее нет.

E> Более того, интерес к лямбдам повышается с популяризацией к функциональному стилю.


Напомню, функциональный стиль в С++ используется с 98-го года когда в С++ был добавлен STL. При этом используется через зад автогеном именно потому, что С++ не имеет нужных возможностей.

E> И еще не факт, что лямбды на самом деле так удобны, как об этом говорят.


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

E> Лично я по опыту использования блоков кода в Ruby не сильно в этом уверен.


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

ОК, раз ты считашь нормальным пдобные рассуждения, то экстрополируем это на меня. Лично я ни разу не использовал Руби ни для чего кроме тестов. Без Руби можно спокойно обходится. Значит Руби не нужен и не имеет права на существование? Обсурд? Несоменно! Вот так же обсурдны твои слова и слова твоих сторонников.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка: -1 :))
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.


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

АХ>А в number crunching что-то не видно.


Оптимизаторы пока не на высоте. Многие цепляются за 10-20 процентов производительности. Но масса рассчетов уже ведется и на Яве и на дотнете. Я знаю о том, что для химических рассчетов уже используются менеджед-языки и с успехом.

VD>> С++ морально устарел.

АХ>Ну немолод

Знаешь, Лисп, например, куда более стар по сравнению с С++. И я бы сказал, что Лисп язык слишком своеобразный и вообще много чего нехорошего могу про него сказать. Но вот сказать о Лиспе, что он устарел я не могу. А языку уже около 60-ти.

VD>> Не имеет ни одного приемущества.

АХ>Основное преимущество — быстрый код, сравнимый с C.

Это фобия, а не приемущество. Тут вот все компиляторы С++ слили Немерлу в Аккермане. В других тестах они выглядят на равных. По крайней мере скорость С++-компиляторов никак не соотносится с заслугами проетировщиков языка. Это заслуга тех кто делал оптимизации и кодогенерацию в конкретных компилторах. Нет проблем найти С++ компилятор который сольет дотнету или Яве в 99% тестов. А компиляторы которым старше 10 лет делают это практически в 100% случаев.

АХ>И существенная экономия памяти по сравнению с Java/.NET


Это правда, но не совсем. Когда программы начинают обрабатывать действительно огромные объемы данных, то разница нивилируется. На нашем сервере есть дотнет-процессы жрущие по 30-40 метров и нэйтив отедающие по 1.5 гига.

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

АХ>(не говоря уже про то, что хорошая реализация .NET пока есть только в Windows).


Моно неплохая реализация. Оптимизатор у нее явно слабый. Но сама реализация вполне ничего себе.

АХ>Впрочем все это уже 100 раз обсуждалось.


Ага. Но фобии остаются. И ты их еще раз выразил. Понимашь в чем дело? Вот eao197 пишет сервер приложений на С++ и прикладные серверные решения на нем же. Казалось бы уж в его то области дотнет или Ява — это явное конкурентное приемущество, а н нет. Прикрываясь перчечислеными фобиями и подогревая это все своими фобиями по переносимости, он уговаривает себя, что С++ лучший выбор. А на деле просто не пробовал альтернатив. От того и ищет что-то вроде Руби чтобы хотя бы на внутреннем коде не иметь тот геморой что он имеет в коммерческом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

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


VD>>> Не имеет ни одного приемущества.

АХ>Да, и еще добавлю что у него есть нормальная поддержка обобщенного программирования на шаблонах,
АХ>чего не видно в других распространенных языках (урезанные genericи совершенно не рулят).

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

АХ>Конечно, Nemerle способен предложить кое-что покруче, посмотрим что из этого выйдет...


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

Что же касается дженериков, то их ограничения в основном связаны с требованиями модульности и компонентности. Нельзя получать в одном и терять в другом. Дотент, Яву и Дельфи многие предпочитали в замен С++-у даже тоггда когда в этих языках вообще небыло обобщенного программирования. И вызванно это именно отличной поддержкой компонентного программирования. Кстати, Руби, Смолток и Питон тоже по сути не поддерживают обобщенное программирование в том смыле в котором его поддерживают C++, C# и Nemerle. В скриптовых языках типа Смолтока для обобщения используется динамический полиморфизм, а в С++ и Немерел параметрический. Так вот дженерики — это компромис позволяющий включить в язык параметрический полиморфизм при этом не нанеся ущерба компонентным возможностям языка, рантайма и кода.

Конечно было бы здорово если в качестве ограничений дженериков можно было бы использовать отдельные методы и операторы, но и без этого жить можно препиваючи. Как минимум поддрежка компонентности и невероятная простота работы окупают эти недостатки. Специализацию возможностей дженериков можно с успехом делать делегатами и функциональными типами. В Немерле это вообще выглядит замечательно. Так что С++ и здесь аутсайдер. Просто мноие не могут переключить мышление на другой лад.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, eao197, Вы писали:

E>Есть у меня инсайдерская информация об использовании C++ и Intel-овских технологий (компиляторов и специальных библиотек) в расчете погоды на каких-то опупенно мощных кластерах.


То есть еденичный случай?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка: 8 (1)
Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Может всетаки 4 байтами?


Сори, я имел в виду двумя char-ами.

ДА> В UTF-16 вроде символы восновном 2 байтовые.


VD>>Огромная редкость и обычно их просто нет в шрифтах, но формально есть.


ДА>Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй символ


Это простраство 130 тысяч, а реально используется только назначительная часть. Так что программы для 99% нужд можно писать думая что один char == один символ. Код вроде вычисления размера строк в пикселях учитывает эти особенности и выведет любой шрифт. А в обработке тебе все это не важно. А если важно, ну, что же... или переведешь в UTF-32, или помучашся с вычленением составных символов.

Возможно когде нибудь, когда память начнет измеряться терабайтами мы перейдем к UTF-32 и забудем вообще о всех проблемах. Но и переход к UTF-16 — это большой прогресс! Ведь для тех самых 99% случаев можно забить на все.

C>>>6. И как теперь нормально использовать quadchar'ы в CLR?

VD>>Так в чем проблема то?

ДА>Действительно как? Мне просто интересно (врятли хоть раз использую...)


Мне тоже на эти подробности наплевать. Если интересно копать надо в сторону System.Globalization.UnicodeCategory, метода GetUnicodeCategory() и класса UTF32Encoding.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это общая фраза, про некого абстрактного чайника.


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

C>Вот только 99.99% программистов на .NET используют строки как UCS-2.


И что есть проблемы? Плевать всем на экзотику. А кому не плевать, тот разберется. Воспользуются UTF32Encoding в крейнем случае.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, eao197, Вы писали:

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


Я считаю что по одной статье можно узнать список задач которые решает инструмент и понять целесобразно ли его писать на С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, eao197, Вы писали:

E>Это уход от ответа.


Это ответ который тебя не удовлетворяет. Ищи проблемы в себе.

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


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

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

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


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

E>Только в моем случае был не хеш (с которым возможны коллизии), а уникальная двоичная последовательность.


А есть ли разница? В конце концов данным можно держать и вне объекта, а в объекте держать их индекс в неком массиве. Тогда останется только сделать в конструктре приращение счетчика. Для C# или Немерла такой дизайн прост и прозрачен. А в С++ мы имеем проблемы.

Интересно, что авторы Немерла задумывались над проблемой неизменяемости кода и вообще над проблемой проверки инваринтов методов, объектов и даже циклов. И вывод был однозначным — определять неизменяемость обязан компилятор или отдельная утилита! Короче кто угодно на не человек.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Синтаксический сахар или C++ vs. Nemerle :)
От: Cyberax Марс  
Дата: 04.06.06 14:24
Оценка:
VladD2 wrote:
> Возможно когде нибудь, когда память начнет измеряться терабайтами мы
> перейдем к UTF-32 и забудем вообще о всех проблемах.
Найти твою цитату про память, которая сейчас очень дешовая?

Увеличение размера символа в два раза плохо скажется только на
редакторах текстов. В остальных программах строки обычно занимают
процентов 10 памяти.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 04.06.06 15:04
Оценка:
Здравствуйте, VladD2, Вы писали:


АХ>>Основное преимущество — быстрый код, сравнимый с C.


VD>Это фобия, а не приемущество. Тут вот все компиляторы С++ слили Немерлу в Аккермане.


Я что-то похоже пропустил, покажи пожалуйста где это они слили?
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 04.06.06 16:04
Оценка: +1
Здравствуйте, eao197, Вы писали:

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

E>Свойства -- напротив. Лямбды так же нужны не всем.

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

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

Свойства во многих языках используются уже много лет и очень хорошо себя зарекомендовали. Полноценные лямбды в C# я, например, жду с нетерпением, а пока во всю используют анонимные методы. А вот mutable в .NET совсем отсутствует, и никого это сильно не напрягает. В Java, кстати, тоже как-то без mutable нород живёт. А вместе с C# комьюнити это сегодня будет побольше, чем комьюнити C++. Тем не менее, ты можешь себе позволить вот так решить за всех что им нужно
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 04.06.06 16:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Берем Comet (генерирует чистый С++, даже на GCC работает) — и видим, что свойства совсем и не нужны на самом деле.


Т.е. ты решаешь за меня нужны мне свойсва или не нужны?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Синтаксический сахар или C++ vs. Nemerle :)
От: Дьяченко Александр Россия  
Дата: 04.06.06 16:24
Оценка:
Здравствуйте, VladD2, Вы писали:

ДА>>Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй символ

VD>Это простраство 130 тысяч, а реально используется только назначительная часть. Так что программы для 99% нужд можно писать думая что один char == один символ. Код вроде вычисления размера строк в пикселях учитывает эти особенности и выведет любой шрифт. А в обработке тебе все это не важно. А если важно, ну, что же... или переведешь в UTF-32, или помучашся с вычленением составных символов.

Спасибо. Вобщем я и так догадывался что большая часть (если не все) этих 4-ех байтовых (2-х char-овых) символов не самая обще употребительная.

VD>Возможно когде нибудь, когда память начнет измеряться терабайтами мы перейдем к UTF-32 и забудем вообще о всех проблемах. Но и переход к UTF-16 — это большой прогресс! Ведь для тех самых 99% случаев можно забить на все.


Ну можно и пораньше переходить. Где-нить к через одной винде после Vista, ну или через 2 (Когда память перевалит рубеж в 32-64 гига и все давно уже будет 64 битным)

C>>>>6. И как теперь нормально использовать quadchar'ы в CLR?

VD>>>Так в чем проблема то?
ДА>>Действительно как? Мне просто интересно (врятли хоть раз использую...)
VD>Мне тоже на эти подробности наплевать. Если интересно копать надо в сторону System.Globalization.UnicodeCategory, метода GetUnicodeCategory() и класса UTF32Encoding.

Спасибо. Уже сам посмотрел. Пользовать в случае крайней необходимости... (Вот интересно всякие отображалки (типа Console.WriteLine и Graphics.DrawString) нормально переваривают такие символы?)
... << RSDN@Home 1.2.0 alpha rev. 648>>
Re: О языках для численных расчетах.
От: IT Россия linq2db.com
Дата: 04.06.06 16:25
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

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


Забавные тесты. Правда фортрана я там не нашёл. Зато обнаружил, что преславутые Руби и Tcl уверенно замыкают список практически во всех тестах, отставая от лидеров в десятки и сотни раз, а порой вообще имеют timeout.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Синтаксический сахар или C++ vs. Nemerle :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 16:33
Оценка: -2 :))
Здравствуйте, VladD2, Вы писали:

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


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 04.06.06 17:21
Оценка:
VladD2 wrote:
> И видимо именно по этому есть языки спокойно обходящиеся без mutable.
А еще есть языки, обходящиеся без типов вообще. И что?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 04.06.06 17:23
Оценка: +2 -1
IT wrote:
> C>Берем Comet (генерирует чистый С++, даже на GCC работает) — и видим,
> что свойства совсем и не нужны на самом деле.
> Т.е. ты решаешь за меня нужны мне свойсва или не нужны?
Ну должен же кто-то решать?

Свойства — это не более чем простенький синтаксический сахар. Причем
сахар с солью (как взять ссылку на свойство?).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 17:51
Оценка: 9 (1)
Здравствуйте, IT, Вы писали:

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

E>>Свойства -- напротив. Лямбды так же нужны не всем.

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


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

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


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

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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: Синтаксический сахар или C++ vs. Nemerle :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 17:54
Оценка: +3
Здравствуйте, 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>А есть ли разница? В конце концов данным можно держать и вне объекта, а в объекте держать их индекс в неком массиве. Тогда останется только сделать в конструктре приращение счетчика.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: О языках для численных расчетах.
От: Дьяченко Александр Россия  
Дата: 04.06.06 20:03
Оценка:
Здравствуйте, IT, Вы писали:

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


Плохо искал? Мне сразу 2 фортрана попалось: Fortran G95 (хз че за зверь), Fortran Intel
... << RSDN@Home 1.2.0 alpha rev. 648>>
Re[50]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка: 8 (1)
Здравствуйте, Дьяченко Александр, Вы писали:

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


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

Graphics должен поддерживать Юникод на 100%. Я проверял только "заурядные" вещи вроде арабской вязи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

C>Увеличение размера символа в два раза плохо скажется только на

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

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

Собственно лично я работаю с UTF-16 как с плоской раскладкой и уверен, что проблемы в этой жизни не будут.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Синтаксический сахар или C++ vs. Nemerle :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


А вообще, да стал я отвыкать от приколов плюсов. Начинает казаться что жизнь прекрасно и удивительна. Надо конечно не отрываться от жестокой реалиности и по чаще вспоминать о С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Совсем? Назови хоть один.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, FR, Вы писали:

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


У тебя поиск неработает?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: О языках для численных расчетах.
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, IT, Вы писали:

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


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


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

Эту ссылку здесь уже сто раз обсасывали, но ее даюет и дают. Перемеренный первый попавшийся тест (Аккерман) показал, что тот же Немерел задвинул VC в лучем виде. А у них на Моно и в добавок с измерением джит комплияции и инициализации рантайма получается совсем по другому.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Tcl как обоснование ненужности поддержки компонентнос
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

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


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

Думаю ничего хорошего не выйдет, так как визуальное представление самое выразительное. Так что сочетание чего-то вроде монтажного стола и дизайнера будет рулить долгие годы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Tcl как обоснование ненужности поддержки компонентнос
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка: :))
Здравствуйте, FR, Вы писали:

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


Скажи спосибо себе. Ты попер обсуждать tcl там где он был вообще не приший рукав.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: Синтаксический сахар или C++ vs. Nemerle :)
От: alexeiz  
Дата: 04.06.06 21:47
Оценка: +1 -1
Здравствуйте, 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.
[Benchmark] Еще раз про Аккерман на разных языках
От: Андрей Хропов Россия  
Дата: 04.06.06 23:18
Оценка: 30 (1)
Здравствуйте, 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 результаты, но заломало функцию замера времени искать .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 00:04
Оценка: +2
Здравствуйте, eao197, Вы писали:

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

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

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

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


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

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


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


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

Всё вместе это говорит о необходимости подобных фич. Но, в принципе, как говорит Влад, можно продолжать жрать кактус и доказывать, что это единственно правильный путь.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 00:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Ну должен же кто-то решать?

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

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


Зачем тебе ссылка на свойство?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 01:15
Оценка: +1 -1 :)
Здравствуйте, IT, Вы писали:

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


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

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


Потому что property и в самом деле эмулируются, как два байта. А вот ты мне скажи, виртуальные проперти бывают или нет? А абстрактные? А можно ли передать проперть как объект в какой-нить метод? А сделать его параметром шаблона? А сделать проперть отдельным классом и отнаследоваться?
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 01:36
Оценка:
Здравствуйте, IT, Вы писали:

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

IT>Началось всё с #import. Там без свойств никак.

Ошибаешься. Есть ещё raw (кажется, не помню на вскидку модификатор). Прекрасно импортирует COM-интерфейсы без пропертей.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 01:55
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Началось всё с #import. Там без свойств никак.


ГВ>Ошибаешься.


В чём именно?

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


#import мне понравился больше. Поддержка свойсв + обработка ошибок с человеческим лицом.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: [Benchmark] Еще раз про Аккерман на разных языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 01:58
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

В менеджед-языках перед замером времени нужно обязательно сделать одни холостой прогон, чтобы метод хотя бы разок выполнился иначе ты начинашь измерять скорость джит-компиляции. Плюс нужно сделать Sleep() на 100-200 мс. чтобы рантайм успел доинициализироваться. Ну, и не стоит не стоит повторять ошибки орлов с того сатйа и измерять скорость вывода в консоль.

В общем, лучше как-то так:
using System.Console;
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 timer = Stopwatch();
  timer.Start();
  def result = f();
  timer.Stop();
  WriteLine(timer.Elapsed);
  WriteLine("result = {0}", result : int);
}

_ = Akk(3, 2);
_ = AkkDecl(3, 2);

System.Threading.Thread.Sleep(200);

time(() => Akk(3, 11));
time(() => AkkDecl(3, 11));
WriteLine("===============");
time(() => Akk(3, 11));
time(() => AkkDecl(3, 11));
WriteLine("===============");
time(() => Akk(3, 11));
time(() => AkkDecl(3, 11));
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 02:05
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


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

ГВ>Второй простейший случай: отложенное вычисление в каком-нибудь указателе.

Боюсь даже просить тебя привести пример. Последний раз в этом топике это закончилось ничем.

ГВ>Потому что property и в самом деле эмулируются, как два байта.


Ну так в чём проблема?

ГВ>А вот ты мне скажи, виртуальные проперти бывают или нет?


Бывают.

ГВ>А абстрактные?


И абстрактные бывают.

ГВ>А можно ли передать проперть как объект в какой-нить метод?


Что имеется ввиду? Значение свойства, метадату или метод реализующий свойство?

ГВ>А сделать его параметром шаблона?


Возвращаемое значение? Можно конечно.

ГВ>А сделать проперть отдельным классом и отнаследоваться?


Этого вопроса я не понял. Можешь пояснить свою мысль?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 02:16
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Началось всё с #import. Там без свойств никак.

ГВ>>Ошибаешься.
IT>В чём именно?

В том, что при импорте COM-интерфейсов директивой #import (я полагаю, ты именно о ней?) нельзя обойтись без свойств в коде C++-программы.

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

IT>#import мне понравился больше. Поддержка свойсв + обработка ошибок с человеческим лицом.

Я имел ввиду модификатор для #import.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: [Benchmark] Еще раз про Аккерман на разных языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 02:18
Оценка:
Кстати, по ходу дела выяснил одну забавную вещь. Почему-то локальные функции Немерле объявляет с лшиним неиспльзуемым параметром. По этому если код оформить как методы, то скорость возрастает (не сильно правда, но все же). Так же становится возможным выполнить первый вариант теста со значениями (3, 12), что как я понимаю вообще не возможно у многих конкурентов.
using System.Console;
using System.Diagnostics;

public module Test
{
  public Akk(a : int, b : int) : int
  {
      if (a == 0)
          b + 1
      else if (b == 0)
          Akk(a - 1, 1)
      else
          Akk(a - 1, Akk(a, b - 1))
  }

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

def time(f)
{
  def timer = Stopwatch();
  timer.Start();
  def result = f();
  timer.Stop();
  WriteLine(timer.Elapsed);
  WriteLine("result = {0}", result : int);
}

_ = Test.Akk(3, 2);
_ = Test.AkkDecl(3, 2);

System.Threading.Thread.Sleep(200);

time(() => Test.Akk(3, 11));
time(() => Test.AkkDecl(3, 11));
WriteLine("===============");
time(() => Test.Akk(3, 11));
time(() => Test.AkkDecl(3, 11));
WriteLine("===============");
time(() => Test.Akk(3, 11));
time(() => Test.AkkDecl(3, 11));
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 02:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ошибаешься.

IT>>В чём именно?
ГВ>В том, что при импорте COM-интерфейсов директивой #import (я полагаю, ты именно о ней?) нельзя обойтись без свойств в коде C++-программы.

Разве я утверждал обратное?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 02:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Свойства — это не более чем простенький синтаксический сахар.


Да, тысячу раз да! Почти все конструкции современных ЯП — это синтаксический сахар. Иначе нельзя было бы писать на Лисп-е или ассемблере. Всем кто хочет и дальше жрать кактус даже не закусывая сахаром мой большой привет. Только не нащдо пропагандировать нищету и убожество. ОК?

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


Ты еще ссылку на конструктор возьми или на пространство имен. Тоже ведь как аргумент использовать можно. "А вот ххх дерьмо, так как в нем нельзя получить ссылку на пространство имен..."
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 02:56
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>>>Ошибаешься.

IT>>>В чём именно?
ГВ>>В том, что при импорте COM-интерфейсов директивой #import (я полагаю, ты именно о ней?) нельзя обойтись без свойств в коде C++-программы.
IT>Разве я утверждал обратное?

Началось всё с #import. Там без свойств никак.


<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 03:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>В том, что при импорте COM-интерфейсов директивой #import (я полагаю, ты именно о ней?) нельзя обойтись без свойств в коде C++-программы.

IT>>Разве я утверждал обратное?

ГВ>

ГВ>Началось всё с #import. Там без свойств никак.


ГВ>


Молодец, ты победил. Возьми на полке пирожок! Ты очень смело и решительно вмешался и присёк несправедливость на корню. Продолжай в том же духе, у тебя это хорошо получается.

А #import я действительно без свойств никогда не использовал. Собственно говоря, как раз только ради нормального читабельного синтаксиса и использовал. А raw я видел в документации один раз и честно говоря усомнился в полезности такой фичи. Кстати, не помнишь такая возможность была в #import с самого начала или добавилась только в последней версии?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 03:33
Оценка:
Здравствуйте, IT, Вы писали:

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


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


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

ГВ>>Второй простейший случай: отложенное вычисление в каком-нибудь указателе.

IT>Боюсь даже просить тебя привести пример. Последний раз в этом топике это закончилось ничем.


Лехко.

class Mutex
{
  public:
    void lock(); // Очевидно - non-const, поскольку состояние объекта меняется
    void unlock()
    private:
      // куча-куча счётчиков и прочего
};

class SomeClassForMultiThreadUsage
{
  public:
    size_t get_values(std::vector<int> *result) const
    {
          Guard g(&mutex_); // scope guard
            *result = values_;
    }
    protected:
      mutable Mutex mutex_;
        std::vector<int> values_;
};




ГВ>>Потому что property и в самом деле эмулируются, как два байта.

IT>Ну так в чём проблема?

Дык нет же её, в том-то и дело. Просто не нужны особо.

ГВ>>А вот ты мне скажи, виртуальные проперти бывают или нет?

IT>Бывают.
OK

ГВ>>А абстрактные?

IT>И абстрактные бывают.
OK

ГВ>>А можно ли передать проперть как объект в какой-нить метод?

IT>Что имеется ввиду? Значение свойства, метадату или метод реализующий свойство?

Само свойство, в том-то и дело.

ГВ>>А сделать его параметром шаблона?

IT>Возвращаемое значение? Можно конечно.

Само свойство.

ГВ>>А сделать проперть отдельным классом и отнаследоваться?

IT>Этого вопроса я не понял. Можешь пояснить свою мысль?

class Property
{
  // Механика реализации свойства
};

class AdvancedProperty : public Property
{
  // Что-то придумали пооригинальнее.
};
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 03:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Лехко.


Демонстрация хака, больше ничего

ГВ>>>Потому что property и в самом деле эмулируются, как два байта.

IT>>Ну так в чём проблема?

ГВ>Дык нет же её, в том-то и дело. Просто не нужны особо.


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

ГВ>>>А можно ли передать проперть как объект в какой-нить метод?

IT>>Что имеется ввиду? Значение свойства, метадату или метод реализующий свойство?

ГВ>Само свойство, в том-то и дело.


В чём дело? Что ты понимаешь под "само свойство"?

ГВ>>>А сделать его параметром шаблона?

IT>>Возвращаемое значение? Можно конечно.

ГВ>Само свойство.


Вот опять. Ты хотя бы сам понимаешь что такое свойство?

ГВ>>>А сделать проперть отдельным классом и отнаследоваться?

IT>>Этого вопроса я не понял. Можешь пояснить свою мысль?

ГВ>
ГВ>class Property
ГВ>{
ГВ>  // Механика реализации свойства
ГВ>};

ГВ>class AdvancedProperty : public Property
ГВ>{
ГВ>  // Что-то придумали пооригинальнее.
ГВ>};
ГВ>


И дальше что? Как ты собираешься это использовать?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 03:53
Оценка:
Здравствуйте, IT, Вы писали:

IT>А raw я видел в документации один раз и честно говоря усомнился в полезности такой фичи. Кстати, не помнишь такая возможность была в #import с самого начала или добавилась только в последней версии?


VC6 точно поддерживает, а что было раньше, я не в курсе.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 03:53
Оценка: +2
Здравствуйте, VladD2, Вы писали:

E>>Вот здесь C++ виноват в провоцировании всех показанных проблем или те, кто спроектировал такой маппинг CORBA на C++? Причем они ведь знали что такое C++ и чем черевато его неправильное использование.


VD>Конечно виноваты тупые пользователи. Ведь те дядьки что седят в OMG они же тупые ламеры. А те что в комитете по С++ крутые гуру консенсуса.


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

Впрочем, это моя неверифицируемая имха.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 04:14
Оценка:
Здравствуйте, IT, Вы писали:

IT>А теперь включаем фантазию и попробуем представить проект, в котором одновременно используются MFC, ATL, #import и STL. В качестве примера можно взять какое-нибудь приложение на MFC, работающее как сервер автоматизации, поддерживающее дуальный IDispatch.


Самая большщая проблема в этом — разобраться с импортом.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 04:14
Оценка:
Здравствуйте, IT, Вы писали:

IT>К тому же, из-за подобных строковых преобразований в коде и логики-то не видно.


Да ну? Набор простейших конвертеров и про строковые преобразования забываешь вообще.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 04:14
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>Лехко.

IT>Демонстрация хака, больше ничего

Фи, как неинтеллигентно.

ГВ>>>>Потому что property и в самом деле эмулируются, как два байта.

IT>>>Ну так в чём проблема?
ГВ>>Дык нет же её, в том-то и дело. Просто не нужны особо.
IT>Понятно. А ты никогда не задумывался почему тебе свойства не нужны, а другие их находят весьма полезной штукой? Я бы конечно мог попытаться это объяснить и привести примеры, но боюсь, это бесполезно. Раз ты решил, что свойства тебе не нужны, потому что я их нахожу полезными, то объяснять что-либо безсмысленно.

Связи не вижу, ну да ладно.

ГВ>>>>А можно ли передать проперть как объект в какой-нить метод?

IT>>>Что имеется ввиду? Значение свойства, метадату или метод реализующий свойство?
ГВ>>Само свойство, в том-то и дело.
IT>В чём дело? Что ты понимаешь под "само свойство"?

Вот мне и интересно, что под этим можно понимать? Под термином "данные объекта", или "функция объекта", или "класс" ясно, что скрывается. А вот что такое "свойство"? Класс? Или не класс?

ГВ>>>>А сделать его параметром шаблона?

IT>>>Возвращаемое значение? Можно конечно.
ГВ>>Само свойство.
IT>Вот опять. Ты хотя бы сам понимаешь что такое свойство?

См. выше.

ГВ>>>>А сделать проперть отдельным классом и отнаследоваться?

IT>>>Этого вопроса я не понял. Можешь пояснить свою мысль?

ГВ>>
ГВ>>class Property [...]
ГВ>>class AdvancedProperty : public Property [...]
ГВ>>


IT>И дальше что? Как ты собираешься это использовать?


Да как-как. Вот так, к примеру:

template<template <class> class PropImpl>
class MyClass
{
  public:
      PropImpl<int> prop1;
        PropImpl<double> prop2;
};


Пример упрощённый, ещё, скорее всего, понадобится связь с MyClass. А может, и не понадобится.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 04:39
Оценка: +2
Здравствуйте, VladD2, Вы писали:

_>>MFC, ATL могут использовать один и тот же CString

VD>Это теперь. А в 98-ом не могли. Да и вопрос не в этом, а в том зачем вообще было делать 10 варинтов строк? Почему было не ввести строки в язык? Ведь они нужны в любом приложении?

Вопрос: какие именно строки? В турбо-паскале, вон, были строки: до 255 символов. Это такие, как надо, или не такие? А сейчас какие они должны быть? CORBA-like, Java-like, C#-like? 16- или 32-битовые символы? Что делать с тем софтом, который уже написан на C и использует const char* ?

VD>Это такие же вопросы как "Почему не добавить свойства? Они же никому не помешали бы." или "кому помешали бы функциональные типы?". На эти вопросы есть только отбрехи фанатов С++ и комитета. Отбрехи эти пахнут маргинальностью и старперством.


А требования дать свойства любой ценой пахнут непониманием неоднозначности ответа на это вопрос.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 05:00
Оценка: +1 -1 :)
Здравствуйте, VladD2, Вы писали:

VD>А ты задумайся почему в куче языков хватает одной строки, а в С++ понадобилось создавать такое количество? Ответ тут очень простой.


Ну, как водится... Любая сложная проблема имеет простое неправильное решение. (с)

VD>Та строка которая была в СТЛ настолько не устраивала пользователей и разработчиков библиотек, что им пришлось вводить заменители. А кто не обеспечил наличие полноценной строки в языке или его библиотеке?


Сферической такой строки, вакуумдышащей.
<< Под музыку: Shocking Blue — Venus >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 05:06
Оценка:
Здравствуйте, VladD2, Вы писали:

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

E>>Еще раз -- C++ не задумывался как безопасный язык.
VD>Страуступ постоянно говорит обратное.

Да? А где он такое говорит?
<< Под музыку: Shocking Blue — Venus >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: Tcl как обоснование ненужности поддержки компонентно
От: Alex Soff Россия  
Дата: 05.06.06 05:17
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>И что с того? Пример то куцый. Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.

У меня есть тут как раз такой кусочек тиклевого кода :


 bind $path <Enter> "+ Messager::itemSelect %W $text %X %Y"
 bind $path <Leave> "+ Messager::itemUnselect %W"
Re[50]: Синтаксический сахар или C++ vs. Nemerle :)
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 05.06.06 07:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>Увеличение размера символа в два раза плохо скажется только на


Хе-хе. Это только в таких кривых недопроектированных сисьемах как Java или .Net увеличение символа в два раза на всём скажется плохо В нормальной системе (ST) строка может быть такой, какая нужна для хранения букв — одно, 2-х, 4-х байтовой.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 07:48
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот
N уступает C++, так что слово слили здесь неуместно.
Re[3]: Tcl как обоснование ненужности поддержки компонентнос
От: FR  
Дата: 05.06.06 07:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


Надо же немного разнобразить пейзаж
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 07:48
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


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


Forth
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 07:52
Оценка: 17 (2) :)))
Здравствуйте, IT, Вы писали:

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


Кактусы приносят человеку весьма разнообразную пользу. Многие виды доставляют съедобные и некоторые — даже довольно вкусные плоды. Под тропиками ягоды Cereus triangularis, имеющие величину кулака, предпочитаются даже всяким другим фруктам, поэтому это растение часто возделывается. Также славятся своими весьма сладкими ягодами Cereus giganteus и Cereus Thurberi, растущие в Мексике, Техасе и Аризоне. В некоторых местностях Мексики обильно разводят Cereus pruinosus. Почти каждая хижина в этих местах окружена зарослями этого кактуса, называемого также Cereus edulis. В южной Европе (в Италии, Испании, Португалии) и в особенности в Сицилии плоды Opuntia Ficus Indica — индийской смоковницы — составляют главную пищу бедных классов народа. Сок этих плодов (индийской фиги) имеет свойство окрашивать мочу в красный цвет, не причиняя, однако, никакого вреда для здоровья; только неумеренное употребление этих плодов вызывает холеровидные заболевания. В Мексике сладко-кислые и ароматичные стебли некоторых видов Echinocactus употребляются как компот. Мясистые, богатые водою ветви Opuntia даются в Техасе и Мексике скоту для утоления жажды, для этой же цели служат стебли Echinocactus, в особенности в сухое время года.


Мне особенно понравилось про неумеренное потребеление
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 05.06.06 07:57
Оценка:
Здравствуйте, IT, Вы писали:

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


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


IT>Началось всё с #import. Там без свойств никак. Поначалу было странно, потом привык, понравилось. Подсмотрел реализацию и начал в своём коде использовать.


Конечно, #import можно делать и без генерации свойств и получать на выходе get/put функции. Но если хочешь свойства, то, наверное, раширение языка (__declspec(property)) было необходимо, потому что все идеи реализовать свойства для C++ средствами стандартного C++ имеют space overhead. А это для описания COM интерфейсов не приемлимо.

Один из распостранённых методов эмулировать свойства такой:
#define DECLARE_PROP_CLASS( aclass ) typedef aclass __this_class__

#define ALL_P( type ,name )\
    class prop_func_##name; \
    friend class prop_func_##name; \
    class prop_func_##name{public: \
        __this_class__& MyClass() \
        {   char* p = (char*)this - offsetof(__this_class__,name) ; \
            return *((__this_class__*)p) ; \
        } \
        operator type(){return MyClass().Get##name();} \
        type operator =(type val){MyClass().Put##name(val);return val;} \
    } name

#define GET_P( type ,name )\
    class prop_func_##name; \
    friend class prop_func_##name; \
    class prop_func_##name{public: \
        __this_class__& MyClass() \
        {   char* p = (char*)this - offsetof(__this_class__,name) ; \
            return *((__this_class__*)p) ; \
        } \
        operator type(){return MyClass().Get##name();} \
    } name

#define PUT_P( type ,name )\
    class prop_func_##name; \
    friend class prop_func_##name; \
    class prop_func_##name{public: \
        __this_class__& MyClass() \
        {   char* p = (char*)this - offsetof(__this_class__,name) ; \
            return *((__this_class__*)p) ; \
        } \
        type operator =(type val){MyClass().Put##name(val);return val;} \
    } name

// example
class Person {
    DECLARE_PROP_CLASS(Person);

public:
    ALL_P(int, Age);  // get/set property
                      // empty object takes 1 byte

private:
    int GetAge() const {
        return age_;
    }

    void PutAge(int v) {
        age_ = v;
    }

private:
    int age_;
};

int main() {
    Person p;
    p.Age = 44;  // works
    int a = p.Age;

    cout << p.Age;  // doesn't work
    cout << (int) p.Age;  // works
    cout << sizeof(Person);  // == 8 (1 byte + alignment + sizeof(int))
}


Но несмотря на (некоторую) трудность в описании свойств средствами языка в C++ свойства навряд ли будут включены. Основная причина, как мне кажется, что они там просто не прижились, и использование свойств не является распостранённой практикой в C++, в отличие от компонентно-ориентированных языков (VB, C#, Delphi, и в Java бы ввели, если бы Sun не упёрся рогом), где свойства очень даже прижились, и широко используются.
Re[3]: О языках для численных расчетах.
От: FR  
Дата: 05.06.06 08:09
Оценка:
Здравствуйте, VladD2, Вы писали:


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


Угу, еще и запускать не умеют некторые вещи

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


Нет не задвинул. У меня VC (с правильными ключиками) быстрее.
Re: [Benchmark] Еще раз про Аккерман на разных языках
От: FR  
Дата: 05.06.06 08:09
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:


АХ>Итак какие можно сделать выводы:

АХ> Компиляторы умеющие раскручивать хвостовую рекурсию выигрывают в этом тесте.
АХ> Очевидно, это сделали MS C++, Nemerle и GCC.

C++ еще умеет агрессивный инлайнинг, если например в VC добавить
#pragma inline_recursion(on) то будет примерно в два раза быстрее.
Re[51]: Синтаксический сахар или C++ vs. Nemerle :)
От: Cyberax Марс  
Дата: 05.06.06 08:09
Оценка: 3 (1)
Andrei N.Sobchuck wrote:
> Хе-хе. Это только в таких кривых недопроектированных сисьемах как Java
> или .Net увеличение символа в два раза на всём скажется плохо В
> нормальной системе (ST) строка может быть такой, какая нужна для
> хранения букв — одно, 2-х, 4-х байтовой.
В С++ тоже
typedef std::basic_string<char> ansi_string;
typedef std::basic_string<unsigned short> ucs2_string;
typedef std::basic_string<unsigned int> utf32_string;
typedef std::basic_string<bool> strange_string; //И такое возможно :)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 05.06.06 08:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Лямбда — это возможность создать анонимный метод. А чтобы на нее можно былопередать ссылку нужен функциональный стиль. Вот делегат это их разновидность. Не лучшее решение, на самом деле, но уж точно лучше его отсуствия или указателей на члены в С++.


boost::function отлично выполняет эту функцию.
void foo(int);
void bar(char);
struct functor : std::unary_function<int, void> {...};
struct someclass { void foo(int); };

function<void (int)> f;

// straight forward call
f = &foo;
f(1); // -> foo(1)

// parameter types don't have to match
f = &bar;
f(2); // -> bar(2)

// lambda tricks
f = (cout << _1);
f(10); // -> cout << 10

// functors
f = functor();
f(10); // -> functor().operator(10);

// member functions
someclass var;
f = (&var ->* &someclass::foo);
f(10); // -> var.foo(10)
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: Left2 Украина  
Дата: 05.06.06 08:12
Оценка:
VD>Сори, приведи подобные кривые мапинги для Явы, плиз.

Отвечу в твоём же духе — а как я тебе буду приводить эти мэппинги для языка которого я не знаю и вжисть на нём двух строчек не написал?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: Left2 Украина  
Дата: 05.06.06 08:12
Оценка: 19 (2)
A>Я с Symbian'ом не знаком. Интересно узнать, что именно.

Вот очень хорошая статья на эту тему
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: kedik  
Дата: 05.06.06 08:30
Оценка:
Здравствуйте, VladD2, Вы писали:

K>>Стандарты то они конечно стандарты... но то что ты перечистил... ты почему-то видимо свято уверен, что жизни за пределами Windows не существует


VD>Батенька, ды вы совсем дальше своего носа не видите. (с) Дотнет давно в виде Моно живет под Линуксом. Ява на таком количестве платформ, что С++ позавидует. Тут дело в том, что лично нам эти платформы просто не нужны. Ну, не занимаемся мы дешевым хостингом, где Линукс король песочнецы.


Сынок, хостингом я тоже не занимаюсь... ни дорогим, ни дешёвым

А под Solaris или HP-UX Mono есть?

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

Проект в котором в настояшее время я участвую, живет на Win, Linux, Sun, HP, AIX. При разработке используеться С++, TCL, Java...

Вот обьясни мне как тот же .NET, например, ярым сторонником которого ты являешься, поможет мне в решении/выполнении требований клиентов на данных платформах и заменит все вышеуказанные языки/средства. Я вообще не являюсь "поклонником" какого либо языка или платформы, но допустим мне очень захотелось расстаться с "застарелыми привычками и фобиями" и я решил перейти на .NET

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

На каких платформах доступна полная функциональнось .NET? ... Сегодня?

PS.
VD>Ява на таком количестве платформ, что С++ позавидует.
Ну и конечно VM для этих платформ, написаны на самой же Java... или на нативном ассемблере?... или неужели на NET?

VD>Тут дело в том, что лично нам эти платформы просто не нужны.

Ключевое слово выделено. В том то все и дело.
Но это совершенно не значит что всем не нужны.
Будем дальше разговаривать о "носах" и "зрении" ...
... или может какнить консруктивно пообсуждаем? Если конечно ты это умеешь делать
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 08:58
Оценка:
VladD2 wrote:
> C>Свойства — это не более чем простенький синтаксический сахар.
> Да, тысячу раз да! Почти все конструкции современных ЯП — это
> синтаксический сахар.
Далеко не все.

> Иначе нельзя было бы писать на Лисп-е или

> ассемблере. Всем кто хочет и дальше жрать кактус даже не закусывая
> сахаром мой большой привет. Только не нащдо пропагандировать нищету и
> убожество. ОК?
На Лиспе как раз сахаром при желании можно обожраться по полной.

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

> Ты еще ссылку на конструктор возьми или на пространство имен.
Понимаешь, свойство выглядит и ведет себя как член класса. На член
класса я могу взять ссылку (в С++).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 09:34
Оценка: +1
IT wrote:
> ГВ>Есть ещё raw (кажется, не помню на вскидку модификатор). Прекрасно
> импортирует COM-интерфейсы без пропертей.
> #import мне понравился больше. Поддержка свойсв + обработка ошибок с
> человеческим лицом.
#import — это решение аля-MS. Правильное С++ное решение — это Comet, он
тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 09:37
Оценка:
IT wrote:
>> > Т.е. ты решаешь за меня нужны мне свойсва или не нужны?
> C>Ну должен же кто-то решать?
> Я за себя уж как-нибудь сам.
В С++ с этим просто — плюешь на стандартную строку и используешь вместо
нее свою любимую. Какие проблемы?

> C>Свойства — это не более чем простенький синтаксический сахар. Причем

> сахар с солью (как взять ссылку на свойство?).
> Зачем тебе ссылка на свойство?
Для передачи в качестве out-параметра, например.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: kedik  
Дата: 05.06.06 10:05
Оценка: +1
Здравствуйте, IT, Вы писали:

K>>PS. Решение абстрактых проблем это конечно интересно и увлекательно... только за решения таких проблем платят исключительно абстрактные деньги... котороый можно потратить на все что угодно... чисто абстрактно конечно


IT>Практика, друг мой, только практика, циничная практика.


Дык, я к практике и пытаюсь разговор повернуть... Ибо практика ни в какую теорию типа "это хорошо, а это отстой" не укладываеться совершено.

Вот давай практический пример: ты упомянул, что при выполнении своих конрактов, ты говоришь "эта лопата подходит, а эта нет".
Но ты никак не упомянул ДЛЯ ЧЕГО подходит.
Я совершенно с тобой согласен, что для каждого инструмента, есть свой тип работ, что удобно делать лопатой, то не удобно экскаватором и наоборот соответственно.

Раз уж мы в "философии" до давай филосовствовать... чуть шире чем просто "о языках" ибо они не ввакуме живут

Разве твой выбор вегда зависит только от того, что "тебе удобнее"?
Вот тебе допустим удобнее под Win и на .NET... а у клиента все под Solaris и на С++... история началась не с появления .NET... и сушествует масса систем, которые появились задолго до рождения .NET и продолжают успешно развиваться и поддерживаться...

И ты хочешь сказать что ты прийдешь и так авторитетно заявишь "мол, выбрасывайте все, будем ставить Win c .NETом" ?
Я конечно могу ошибаться, но что-то мне подсказывает, что ты не будешь этого делать... ты либо откажешься совсем, либо будешь таки делать на С++... тут конечно все от возможного дохода зависит

Есть ещё другой момент...
Ну нет возможности использовать .NET. Хорошо... можно взять Java... но вот проблема... есть подобная программа у конкурента и она работает на порядок быстрее, чем твоя написанная на Java... Это может конечно не сильный аргумент, например. можно сказать, что для пользователя без разницы выполняеться операция за 2 секуды или за 1... а если это минуты... или часы?
... более того, решение о покупке, если это не "CD Ejector", принимает не пользователь, а его начальство, а вот тут уже для убеждения идут в ход все аргументы, какие только возможно...
Ты конечно можешь сказать клиенту "обновите железо", но клиенту совершенно непонятно, зачем если он может этого не делать и купить у конкурента... особенно если речь идет, не о одном компе... ты либо уйдешь и оставишь клиента конкуренту... либо возьмешь в руки С++...

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

А просто брать и сравнивать "на каком языке удобней форму накатать"... ну я даж незнаю, че сказать... хотя, надо отдать должное, очень увлекательно читать такую "философскую дискусию"
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 05.06.06 10:11
Оценка: 51 (2)
Здравствуйте, Cyberax, Вы писали:

C>В С++ с этим просто — плюешь на стандартную строку и используешь вместо

C>нее свою любимую. Какие проблемы?
В .NET с этим тоже просто. Но либо для такого шага были серьезные причины, либо ты идиот.

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

C>Для передачи в качестве out-параметра, например.
В Nemerle с этим кстати проблем нет. Только вместо out параметра нужно передавать функцию-setter.

using Nemerle.Utility;

[Record]
class PropTest
{
    [Accessor(flags = WantSetter)]
    private mutable n : int;
}

def changeProp(setter : int->void)
{
    setter(10)
}

def p = PropTest(4);
changeProp(x.set_N);


В C# с этим чуть сложнее, но можно создать делегат по имени. Или использовать reflection.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 11:19
Оценка:
Vermicious Knid wrote:
> C>В С++ с этим просто — плюешь на стандартную строку и используешь вместо
> C>нее свою любимую. Какие проблемы?
> В .NET с этим тоже просто.
Агащаз. Как, например, со своими строками использовать регэкспы?

> Но либо для такого шага были серьезные причины, либо ты идиот.

Я уже привел пример с UTF-32.

> C>Для передачи в качестве out-параметра, например.

> В Nemerle с этим кстати проблем нет. Только вместо out параметра нужно
> передавать функцию-setter.
И как его передавать функциям, которые требуют out-параметр (и находятся
в скомпиленом коде)?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 13:01
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>В С++ с этим просто — плюешь на стандартную строку и используешь вместо нее свою любимую. Какие проблемы?


Почему тебе не приходит в голову переопределять в C++, например, тип double?

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

C>Для передачи в качестве out-параметра, например.

out-параметр — это серьёзный звоночек, говоряший о кривизне архитектуры.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 13:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>#import — это решение аля-MS. Правильное С++ное решение — это Comet, он тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.


Без исключений он тоже обходится?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 13:17
Оценка:
Здравствуйте, kedik, Вы писали:

K>Вот давай практический пример: ты упомянул, что при выполнении своих конрактов, ты говоришь "эта лопата подходит, а эта нет".

K>Но ты никак не упомянул ДЛЯ ЧЕГО подходит.

Для решаемых задач конечно.

K>Вот тебе допустим удобнее под Win и на .NET... а у клиента все под Solaris и на С++...


С легаси кодом как раз всё понятно. Если не стоит задача его переписать, то если он работает, то какой смысл его трогать.

K>И ты хочешь сказать что ты прийдешь и так авторитетно заявишь "мол, выбрасывайте все, будем ставить Win c .NETом" ?


Я как раз и пытался тебе объяснить, что я, во-первых, не скажу выбрасывайте всё, а, во-вторых, будем ставить то, что лучше подходит для текущей задачи. А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 13:22
Оценка:
Здравствуйте, IT, Вы писали:

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


C>>В С++ с этим просто — плюешь на стандартную строку и используешь вместо нее свою любимую. Какие проблемы?


IT>Почему тебе не приходит в голову переопределять в C++, например, тип double?


Мне приходилось подменять double своим специализированным классом.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 13:33
Оценка:
IT wrote:
> C>#import — это решение аля-MS. Правильное С++ное решение — это Comet,
> он тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.
> Без исключений он тоже обходится?
Наоборот, превращает HRы в исключения и автоматически добавляет
поддержку ISupportsErrorInfo к серверным классам.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 13:34
Оценка:
Здравствуйте, FR, Вы писали:

IT>>Почему тебе не приходит в голову переопределять в C++, например, тип double?


FR>Мне приходилось подменять double своим специализированным классом.


В каждом новом приложении? И long наверное приходилось подменять, и short, и int? И так в каждом новом проекте?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 13:35
Оценка:
IT wrote:

> C>В С++ с этим просто — плюешь на стандартную строку и используешь

> вместо нее свою любимую. Какие проблемы?
>
> Почему тебе не приходит в голову переопределять в C++, например, тип double?
А какие проблемы?
При желании и это можно сделать — переопределяешь ариф. операторы, при необходимости — оператор приведения к double,
делаешь имплицитный конструктор из double. И получаешь тип, который по поведению полностью соответствует double, но,
например, с очень высокой точностью.
Полиморфность, правда, не получится... но generic programming может помочь обойти и эту проблему.

Однако, у double (как и у int, void* и иже с ними) есть вполне веское оправдание — обычно он непосредственно
поддерживается процессором, оптимизируется компилятором, а значит работает относительно быстро. Что не скажешь о
строках. То бишь в С/С++ все примитивные типы (POD) — типы, с которыми способна работать "имплементация машины Тьюринга"
непосредственно. Вот когда изобретут другие железки, вот тогда тогда и задумаются о других примитивных типах. Какого
чёрта пытаются строку приплести к примитивным типам — мне совершенно не понятно.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 13:36
Оценка:
IT wrote:
> C>В С++ с этим просто — плюешь на стандартную строку и используешь
> вместо нее свою любимую. Какие проблемы?
> Почему тебе не приходит в голову переопределять в C++, например, тип double?
Я это делал — добавлял класс для long double (который MSом не
поддерживается).

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

> C>Для передачи в качестве out-параметра, например.
> out-параметр — это серьёзный звоночек, говоряший о кривизне архитектуры.
Ага, кончено.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: kedik  
Дата: 05.06.06 13:58
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>Вот давай практический пример: ты упомянул, что при выполнении своих конрактов, ты говоришь "эта лопата подходит, а эта нет".

K>>Но ты никак не упомянул ДЛЯ ЧЕГО подходит.

IT>Для решаемых задач конечно.


Дык в том и вопрос, что это за задачи... ибо именно от задачи, а не от языка приходиться плясать в большинстве именно реальных случаев... а если задача большая, то и несколько языков/средств применять не грех

K>>И ты хочешь сказать что ты прийдешь и так авторитетно заявишь "мол, выбрасывайте все, будем ставить Win c .NETом" ?


IT>Я как раз и пытался тебе объяснить, что я, во-первых, не скажу выбрасывайте всё, а, во-вторых, будем ставить то, что лучше подходит для текущей задачи. А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.


Ну значит, пардон, видимо я недопонял
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 14:03
Оценка:
Здравствуйте, IT, Вы писали:

IT>out-параметр — это серьёзный звоночек, говоряший о кривизне архитектуры.


С чего это вдруг?

bool
    get_current(Face *&f);

bool
    get_current(Edge *&e);

bool
    get_current(Shell *&e);

void test()
{
    Face *f;
    if ( get_current(f) )
    {
        // понеслась
    }
}


или я должен сделать функцию которая возвращает Object* а дальше dynamic_cast-om развлекатся? Или целое семейство наплодить get_curr_face, get_curr_edge, ...
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 14:19
Оценка: 21 (1)
Kluev wrote:

> или я должен сделать функцию которая возвращает Object* а дальше

> dynamic_cast-om развлекатся? Или целое семейство наплодить
> get_curr_face, get_curr_edge, ...
Я бы так и написал:
Face *f = get_current_face()
if(f)
{
  // понеслась
}

чем плохо?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 14:26
Оценка:
kan_izh wrote:

> чем плохо?

Плюс позволяет писать:
mud_on_your(get_current_face());
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 14:27
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Я бы так и написал:

_>
_>Face *f = get_current_face()
_>if(f)
_>{
_>  // понеслась
_>}
_>

_>чем плохо?

Такой код сложнее с шаблонами подружить. Если название get_current перегружено для разных типов, то шаблоны можно использовать для уменьшения copy-paste:
template< class T >
void do_something_usefull() {
  T * value;
  if( get_current( value ) ) {
    ... /* Обобщенный код обработки Face, Edge и пр. */...
  }
}
...
do_something_usefull< Face >();
...
do_something_usefull< Edge >();


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Свойства — это не более чем простенький синтаксический сахар.

>> Да, тысячу раз да! Почти все конструкции современных ЯП — это
>> синтаксический сахар.
C>Далеко не все.

Почти все! Для реализации любой логики достаточно одного оператора сравнения и goto.

C>На Лиспе как раз сахаром при желании можно обожраться по полной.


В Лиспе его вообще практически нет. Другое дело, что там есть макросы с помощью которых он делается. Вот это путь и видится мне перспективным.

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

>> Ты еще ссылку на конструктор возьми или на пространство имен.
C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
C>класса я могу взять ссылку (в С++).

Понимшь, С++ с его догами идет в лес. Нет теорем доказывающих, что кровь износу нужно делать сылки на все типы членов классов. Более того хороший код ни на что кроме функций и нитерфейсов ссылаться не должен. Иначе начинаются зависимости которые трудно отследить.

Собственно как-то раз я делал класс эмулирующий ссылку на свойство. Знаешь чем это закончилось? Он на фиг никому не упал. Ты можешь воспользоваться поиском и найти его код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: О языках для численных расчетах.
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Нет не задвинул. У меня VC (с правильными ключиками) быстрее.


Ключи в студию.

ЗЫ

Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка: -1
Здравствуйте, FR, Вы писали:

FR>Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот

FR>N уступает C++, так что слово слили здесь неуместно.

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

Re: [Benchmark] Еще раз про Аккерман на разных языках
Автор: VladD2
Дата: 05.06.06
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка: -1
Здравствуйте, FR, Вы писали:

FR>Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот

FR>N уступает C++, так что слово слили здесь неуместно.

Это банальная подтасовка результатов. При этом VC вычислит промежуточные результаты во время компиляции. Эдак Немерел всегда будет победителем, так как любое статическое вычисление на нем можно частично или полностью предвычислить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка:
Здравствуйте, Left2, Вы писали:



L>Отвечу в твоём же духе — а как я тебе буду приводить эти мэппинги для языка которого я не знаю и вжисть на нём двух строчек не написал?


Тогда советую изучить хоть один язык на котором можно сделать не кривые маниги.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Складывается впечатление, что кому-то крепко стукнуло в башку сделать Java из C++. А из этого мало что хорошего выходит, как правило...


ГВ>Впрочем, это моя неверифицируемая имха.


Так к сведению... КОРБА разрабатывалась приемущественно на С++ (как и КОМ в прочем), а биндинг для Явы был сделан значительно позже.

Ну, и сделать бейсбольную биту из гнилово дерева не получится не смотря на прямолинейность перво.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 14:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вопрос: какие именно строки? В турбо-паскале, вон, были строки: до 255 символов. Это такие, как надо, или не такие? А сейчас какие они должны быть? CORBA-like, Java-like, C#-like? 16- или 32-битовые символы? Что делать с тем софтом, который уже написан на C и использует const char* ?


Мне тебе рассказать о принципах проектирования?


VD>>Это такие же вопросы как "Почему не добавить свойства? Они же никому не помешали бы." или "кому помешали бы функциональные типы?". На эти вопросы есть только отбрехи фанатов С++ и комитета. Отбрехи эти пахнут маргинальностью и старперством.


ГВ>А требования дать свойства любой ценой пахнут непониманием неоднозначности ответа на это вопрос.


Про цену, плиз, по подробнее. А то ваши слова сами пахнут не очень приятно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 14:36
Оценка: +1
Здравствуйте, kan_izh, Вы писали:

_>Kluev wrote:


>> или я должен сделать функцию которая возвращает Object* а дальше

>> dynamic_cast-om развлекатся? Или целое семейство наплодить
>> get_curr_face, get_curr_edge, ...
_>Я бы так и написал:
_>
_>Face *f = get_current_face()
_>if(f)
_>{
_>  // понеслась
_>}
_>

_>чем плохо?

Тем что в программе используются несколько классов Face (с разной функциональностью): CFace, QS_Face, QF_Face, это как тогда функции называть? А так get_current и никаких лишних сущностей и мозговых напрягов. Перегрузка лучше чем новый символ.

Вообще С++ хороший язык, но логика разработчкиов stl слегка напрягает. Добавляют разные ненужные фичи, а до сих пор не могли сделать перегруженные функции для функций strlen, wcslen. т.е.
str_len(const char*) и str_len(const wchar_t*);

Имхо, уже давно созрела необходимость в низкоуровневевом языке типа С++ разрабатываемом сообществом, а не комитетами. Вот в линукс кернеле юзают нестандартные расширения gcc и никто не напрягается. Давно бы уже сделали бы форк g++ и послали бы комитет лесом. Все равно компилеры м-ду собой несовместимы. нафига тогда приддерживатся иллюзорных бесполезных стандартов
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 15:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>IT wrote:

>> C>#import — это решение аля-MS. Правильное С++ное решение — это Comet,
>> он тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.
>> Без исключений он тоже обходится?
C>Наоборот, превращает HRы в исключения и автоматически добавляет поддержку ISupportsErrorInfo к серверным классам.

А почему же тогда отказались от свойств? Не потому ли, что их не поддерживает стандарт?
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 15:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да? А где он такое говорит?


Везде. У него основные слова о типобезопасности и быстродействии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 15:17
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>А какие проблемы?


Так переопределяешь или нет? Со строками в C++ всё просто. Из-за отсутствия стандартной строки каждая уважающая себя библиотека имеет свою реализацию строки. Но я не замечал, что каждая уважающая себя библиотека имеет свою реализацию double, int, long. Не потому ли, что возможность раализовать и необходимость в этом — это очень разные вещи. Но вот что касается строк в плюсах, то возможность раелизации своих строк становится необходимостью из-за отсутствия нормальной стандартной строки.
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 15:18
Оценка: -1
VladD2 wrote:
> C>Далеко не все.
> Почти все! Для реализации любой логики достаточно одного оператора
> сравнения и goto.
Есть свойства языка, которые можно выразить через другие свойства — это
сахар. Операции циклов — сахар над if/goto, а вот switch — уже нет, так
как это абстракция таблицы переходов.

Точно так же — в C++ не являются сахаром шаблоны, исключения,
автоматические классы, и т.п.

Сахар — это перегрузка операторов, implicit-преобразования и т.п.

> C>На Лиспе как раз сахаром при желании можно обожраться по полной.

> В Лиспе его вообще практически нет. Другое дело, что там есть макросы с
> помощью которых он делается. Вот это путь и видится мне перспективным.
В связи с (повторным) увлечением Emacs'ом, мне стало интересно как же
используются макросы в Emacs'е. Оказалось, что почти никак.

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

> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член

> C>класса я могу взять ссылку (в С++).
> Понимшь, С++ с его догами идет в лес.
Изначально IT привел отсутствие свойств как пример отстоев С++.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 15:20
Оценка:
Здравствуйте, Kluev, Вы писали:

K>или я должен сделать функцию которая возвращает Object* а дальше dynamic_cast-om развлекатся? Или целое семейство наплодить get_curr_face, get_curr_edge, ...


Вот видишь, ты же сам всё знаешь. Это как раз будет более правильным решением Можно ещё шаблоны/дженерики зарядить, если получится.
Если нам не помогут, то мы тоже никого не пощадим.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 15:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Изначально IT привел отсутствие свойств как пример отстоев С++.


Не надо путать. Я это привёл как пример отстоя работы комитетчиков. Чтобы больше у нас в этом не было никаких домыслов, предлагаю в дальнйшем все мои притензии к языку относить исключительно на счёт комитета, т.к. сегодняшнее плачевное состояния языка — это их прямая заслуга.
Если нам не помогут, то мы тоже никого не пощадим.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 15:41
Оценка:
IT wrote:

> Так переопределяешь или нет? Со строками в C++ всё просто. Из-за

> отсутствия стандартной строки каждая уважающая себя библиотека имеет
> свою реализацию строки. Но я не замечал, что каждая уважающая себя
> библиотека имеет свою реализацию double, int, long. Не потому ли, что
> возможность раализовать и необходимость в этом — это очень разные вещи.
> Но вот что касается строк в плюсах, то возможность раелизации своих
> строк становится необходимостью из-за отсутствия нормальной стандартной
> строки.
Посмотри что такое DWORD, BYTE, UINT, или ещё всякие Int32, UInt32. А так же интересно поглядеть на это (gcj):
class ::com::lowagie::text::DocWriter : public ::java::lang::Object
{
...
   virtual jboolean setMargins (jfloat, jfloat, jfloat, jfloat);
...
   static const jint NEWLINE = 10;
   static const jint TAB = 9;
}

Оно, конечно, обычно не реализуется через class, обычно через #define либо typedef, но всё-таки многие библиотеки имеют
фактически все типы собственной реализации.


Ты вообще понимаешь принципиальную (теоретическую) разницу между типом int (и ему подобными) и string?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 15:59
Оценка:
VladD2 wrote:

> C>Свойства — это не более чем простенький синтаксический сахар.

> Да, тысячу раз да! Почти все конструкции современных ЯП — это
> синтаксический сахар. Иначе нельзя было бы писать на Лисп-е или
> ассемблере. Всем кто хочет и дальше жрать кактус даже не закусывая
> сахаром мой большой привет. Только не нащдо пропагандировать нищету и
> убожество. ОК?
Лично я не вижу большой семантической (только синтаксис разный) разницы между:
class Obj
{
   property value = {getValue, setValue}; //или как-то так, не важно как.
   int getValue(){return callCOMMethod();}
   void setValue(int v){callCOMMethod(v);}
};
obj.value = obj2.value;
// и
class Obj
{
   int getValue(){return callCOMMethod();}
   void setValue(int v){callCOMMethod(v);}
};
obj.setValue(obj2.getValue());
// или иногда пишут даже
class Obj
{
   int value(){return callCOMMethod();}
   void value(int v){callCOMMethod(v);}
};
obj.value(obj2.value());

просветите, в чём принципиальная разница??

Зато здесь, например:
std::auto_ptr<Obj> obj(new Obj);
obj->method();
return obj->method2();
// и
Obj *obj = new Obj;
obj->method();
Result r = obj->method2();
delete obj;
return r;


есть разница семантическая, разница не только в синтаксисе, но и в смысле кода, так что сахар далеко не всё.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 05.06.06 16:14
Оценка:
IT wrote:
>> > Без исключений он тоже обходится?
> C>Наоборот, превращает HRы в исключения и автоматически добавляет
> поддержку ISupportsErrorInfo к серверным классам.
> А почему же тогда отказались от свойств? Не потому ли, что их не
> поддерживает стандарт?
Они там есть:
#ifdef COMET_ALLOW_DECLSPEC_PROPERTY
     __declspec(property(get=GetChildren))
     com_ptr<WidgetOGLLib::I3DObjectCollection> Children;
#endif


Хотя зачем они нужны, если есть Get/Put-методы — мне непонятно.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 16:15
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>или я должен сделать функцию которая возвращает Object* а дальше dynamic_cast-om развлекатся? Или целое семейство наплодить get_curr_face, get_curr_edge, ...


IT>Вот видишь, ты же сам всё знаешь. Это как раз будет более правильным решением Можно ещё шаблоны/дженерики зарядить, если получится.


Не не будет. eao197 насчет шаблонов верно написал. Такой код с шаблонами не подружишь. Перегруженные функции лучше полюбому.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 16:32
Оценка:
Здравствуйте, IT, Вы писали:


FR>>Мне приходилось подменять double своим специализированным классом.


IT>В каждом новом приложении? И long наверное приходилось подменять, и short, и int? И так в каждом новом проекте?


Нет только в одном, страшное устройство на котором это приложение запускалось не умело аппаратно плавающие вычисления делать, пришлось написать свою реализацию, более быструю. А программу менять не хотелось и пришлось дефинить.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 16:58
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Посмотри что такое DWORD, BYTE, UINT, или ещё всякие Int32, UInt32.


Да, да, да. Как же, как же, про макросы я совсем забыл

_>Оно, конечно, обычно не реализуется через class, обычно через #define либо typedef, но всё-таки многие библиотеки имеют фактически все типы собственной реализации.


А теперь представим, что ты пишешь метод в своём коде, который принимает int, и должен его передать методу A из библиотеки аа, в кторой используется INT32, и также методу B из библиотеки bb, в которой int объявлен как Int32. Какой тип ты будешь использовать в своём методе?

_>Ты вообще понимаешь принципиальную (теоретическую) разницу между типом int (и ему подобными) и string?


А ты вообще понимаешь принципиальную (практическиу) разницу между наличием одного стандартного типа string и зверинца из std::string, LPCTSTR, CString, BSTR, _bstr_t и пр.?
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: О языках для численных расчетах.
От: FR  
Дата: 05.06.06 17:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Нет не задвинул. У меня VC (с правильными ключиками) быстрее.


VD>Ключи в студию.


Не помню, помню только прагму: #pragma inline_recursion(on)

VD>ЗЫ


VD>Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?


Ну у gcc тоже много ключиков, надо поискать которые за инлайнинг отвечают.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 17:02
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот

FR>>N уступает C++, так что слово слили здесь неуместно.

VD>Это банальная подтасовка результатов. При этом VC вычислит промежуточные результаты во время компиляции. Эдак Немерел всегда будет победителем, так как любое статическое вычисление на нем можно частично или полностью предвычислить.


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

#include <iostream>
#include <sstream>

#pragma inline_recursion(on)

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

int main(int argc, char *argv[])
    {
         int n = 0, m = 0;
         if(argc > 0)
          {
          std::istringstream in(argv[1]);
          in >> n;
          m = n + 9;
          std::cout << n << " " << m << std::endl;
          std::cout << akk( n, m) << std::endl;
          }

    }
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 17:06
Оценка:
Здравствуйте, Kluev, Вы писали:

IT>>Вот видишь, ты же сам всё знаешь. Это как раз будет более правильным решением Можно ещё шаблоны/дженерики зарядить, если получится.


K>Не не будет. eao197 насчет шаблонов верно написал. Такой код с шаблонами не подружишь. Перегруженные функции лучше полюбому.


Это заблуждение. eao197 вообще приверженец птичьей нотации. Для него идеальным вариантом было бы даже не get_curr_face, get_curr_edge, а g_c_f, g_c_e

Но это всё весело до тех пор пока мы пишем код, не думаю о последствиях. А последствия таковы, что код во много раз чаще читается чем пишется. И подобные неоднозначности при чтении приводят к плохой читаемости кода.

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

MyMethod(GetCurrentEdge());

придётся тебе вместо одной строчки писать минимум три.
Если нам не помогут, то мы тоже никого не пощадим.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 17:20
Оценка:
Здравствуйте, IT, Вы писали:

K>>Не не будет. eao197 насчет шаблонов верно написал. Такой код с шаблонами не подружишь. Перегруженные функции лучше полюбому.


IT>Это заблуждение. eao197 вообще приверженец птичьей нотации. Для него идеальным вариантом было бы даже не get_curr_face, get_curr_edge, а g_c_f, g_c_e


Пора в суд подавать, за клевету. Попробуй найти такие названия в моем коде. Например, здесь или здесь, или даже в Ruby коде

IT>Но это всё весело до тех пор пока мы пишем код, не думаю о последствиях. А последствия таковы, что код во много раз чаще читается чем пишется. И подобные неоднозначности при чтении приводят к плохой читаемости кода.


Т.е.
Face * f;
if( get_current( f ) ) { ... }

менее читабельно, чем это?
Face * f = get_current_face();
if( f ) { ... }

Если да, то почему?

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


IT>
IT>MyMethod(GetCurrentEdge());
IT>

IT>придётся тебе вместо одной строчки писать минимум три.

Зато в таком подходе MyMethod должен ожидать получение нулевого указателя. Если же он на это не расчитан, то по количеству строчек оба подхода не будут сильно различаться.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 17:46
Оценка:
Здравствуйте, eao197, Вы писали:

E>Пора в суд подавать, за клевету. Попробуй найти такие названия в моем коде. Например, здесь


Жмотный народ.ру очень медленно в буржуинии открывается. Экономят ребята на международном трафике.

E>или здесь,


В первой же строчке: so_4::rt::__init_t. Из всего этого чириканья я понял только что такое init. Да и его мне предлагается запомнить с двумя подчёркиваниями, что может оказаться уже выше моих сил.

IT>>Но это всё весело до тех пор пока мы пишем код, не думаю о последствиях. А последствия таковы, что код во много раз чаще читается чем пишется. И подобные неоднозначности при чтении приводят к плохой читаемости кода.


E>Т.е.

E>
E>Face * f;
E>if( get_current( f ) ) { ... }
E>

E>менее читабельно, чем это?
E>
E>Face * f = get_current_face();
E>if( f ) { ... }
E>

E>Если да, то почему?

Как минимум есть четыре причины.
1. Вполне возможно, что мне не надо будет создавать промежуточную переменную.
2. Проверка была сделана выше и повторно её делать не имеем смысла.
3. Уровень доверия в моём коде может быть выше необходимости проверять возвращаемое значение.
4. Вместо возврата null вызываемая функция может генерировать исключение.

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


E>Зато в таком подходе MyMethod должен ожидать получение нулевого указателя. Если же он на это не расчитан, то по количеству строчек оба подхода не будут сильно различаться.


Это не так. В методе ты это напишешь один раз. А в вызывающем коде каждый раз, когда тебе нужно будет вызвать этот метод. Т.е. количество кода в твоём случае увеличивается пропорционально количеству вызовов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 17:49
Оценка:
IT wrote:

> _>Оно, конечно, обычно не реализуется через class, обычно через #define

> либо typedef, но всё-таки многие библиотеки имеют фактически все типы
> собственной реализации.
> А теперь представим, что ты пишешь метод в своём коде, который принимает
> int, и должен его передать методу A из библиотеки аа, в кторой
> используется INT32, и также методу B из библиотеки bb, в которой int
> объявлен как Int32. Какой тип ты будешь использовать в своём методе?
Без разницы, компилятор приведёт автоматически INT32 к Int32 и наоборот, особенно если они определены через typedef или
#define. А если что-то не так — будет warning.

> _>Ты вообще понимаешь принципиальную (теоретическую) разницу между типом

> int (и ему подобными) и string?
> А ты вообще понимаешь принципиальную (практическиу) разницу между
> наличием одного стандартного типа string и зверинца из std::string,
> LPCTSTR, CString, BSTR, _bstr_t и пр.?
Да. Во-первых, С/С++ многоплатформенный язык, в отличие от яв и .нетов. Правильно это или неправильно — сказать нельзя.
Оба подхода востребованы на практике. Во-вторых, С/С++ — системный язык, а разные системы под строкой понимают
разные вещи.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 18:02
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>
IT>MyMethod(GetCurrentEdge());
IT>

IT>придётся тебе вместо одной строчки писать минимум три.

Нет. Я всегда предпочитаю заводить локальную переменную. Отлаживатся гораздо проще.

Foo *f;
if (!get_curr(f))
  return; // здесь ловить больше нечего. чао бамбино
f->чик(); // 
f->пук(); // f всегда под рукой. смотрим что к чему если нужно



Геометрия штука крайне мутная, посему пишу так чтобы ежели чего по коду без проблем можно было пробежатся дебаггером.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 18:05
Оценка: 8 (1)
IT wrote:

> К тому же шаблоны — это конечно круто, но перегрузка не дасть тебе

> возможности написать, например, такой код.
Шаблоны это даже круче чем ты думаешь.

дописываем шаблонный метод к классу:
bool get_current(Face *&);
bool get_current(CFace *&);
bool get_current(Edge *&);
...
template<class T> T *get_current_anything()
{
   T *obj;
   if(get_current(obj)) return obj;
   else throw something();// или "return NULL;" или, скажем, "return get_default(obj)".
}

и тогда вместо:
> MyMethod(GetCurrentEdge());

будет
MyMethod(get_current_anything<Edge>());

разница в два символа "<" и ">".
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 18:08
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>MyMethod(GetCurrentEdge());
IT>

IT>придётся тебе вместо одной строчки писать минимум три.

В догонку. Можно привести другой пример. Я не люблю итераторы и предпочитаю юзать индексы. Поэтому вместо изврата
BlaBlaBla::iterator it;
if ( obj.end() != (it = find(obj.beg(), obj.end(), item)) )
{
  // чето мутное
}


Юзаю:
int idx;
if ( obj.find(item, idx) )
{
   obj.insert(idx, something);
}


метод find обьявлен как:
bool find(T what, int &idx);


idx вполне может быть нулем, а юзать -1, всяки-разны пары и кортежи изврат.

Т.е вот пример где out параметр правильно by design.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 18:13
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Нет. Я всегда предпочитаю заводить локальную переменную. Отлаживатся гораздо проще.


Я предпочитаю в случае исключительных ситуаций швырять исключения или по возможности применять null-паттерн. Прикладной код становится гораздо чище.

K>
K>Foo *f;
K>if (!get_curr(f))
K>  return; // здесь ловить больше нечего. чао бамбино
f->>чик(); // 
f->>пук(); // f всегда под рукой. смотрим что к чему если нужно

K>

В данном случае вообще напрашивается свойство. Сравни.

if (CurrentEdge == null)
  return; // здесь ловить больше нечего. чао бамбино
CurrentEdge.Чик(); // 
CurrentEdge.Пук(); // CurrentEdge всегда под рукой. смотрим что к чему если нужно
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 18:16
Оценка:
Здравствуйте, kan_izh, Вы писали:

>> А теперь представим, что ты пишешь метод в своём коде, который принимает int, и должен его передать методу A из библиотеки аа, в кторой используется INT32, и также методу B из библиотеки bb, в которой int объявлен как Int32. Какой тип ты будешь использовать в своём методе?

_>Без разницы, компилятор приведёт автоматически INT32 к Int32 и наоборот, особенно если они определены через typedef или #define. А если что-то не так — будет warning.

Тогда нафига козе баян? Или всё же лучше продолжать жрать кактус?

_>Да. Во-первых, С/С++ многоплатформенный язык, в отличие от яв и .нетов. Правильно это или неправильно — сказать нельзя.


JavaScript тоже многоплатформенный язык, только вот со строками в нём почему-то зверинца не наблюдается

_>Оба подхода востребованы на практике. Во-вторых, С/С++ — системный язык, а разные системы под строкой понимают разные вещи.


C/C++ под строкой понимает только массив символов заканчивающихся нулём.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 05.06.06 18:20
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Везде. У него основные слова о типобезопасности и быстродействии.


Так по сравнениею с си С++ кораздо лучше в отношении типобезопасности.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 18:24
Оценка: :)
Здравствуйте, kan_izh, Вы писали:

_>Шаблоны это даже круче чем ты думаешь.


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

_>дописываем шаблонный метод к классу:


Следи за руками. Весь бред с шаблонами удаляем и заменяем многострадальный метод свойством:

и тогда вместо:

_>MyMethod(get_current_anything<Edge>());

будет

MyMethod(CurrentEdge);

_>разница в два символа "<" и ">".

Разница в 17 символов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 18:27
Оценка:
Здравствуйте, Kluev, Вы писали:

K>idx вполне может быть нулем, а юзать -1, всяки-разны пары и кортежи изврат.


По мне так нормально

K>Т.е вот пример где out параметр правильно by design.


Какой же это правильный дизайн? Если тебе нужен лишь факт, что искомый айтем найдён или нет, то всё равно придётся заводить временную переменную.
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 18:30
Оценка:
IT wrote:

>> > А теперь представим, что ты пишешь метод в своём коде, который

> принимает int, и должен его передать методу A из библиотеки аа, в кторой
> используется INT32, и также методу B из библиотеки bb, в которой int
> объявлен как Int32. Какой тип ты будешь использовать в своём методе?
> _>Без разницы, компилятор приведёт автоматически INT32 к Int32 и
> наоборот, особенно если они определены через typedef или #define. А если
> что-то не так — будет warning.
> Тогда нафига козе баян? Или всё же лучше продолжать жрать кактус?
Ну вот и я не знаю, зачем вы возмущаетесь, что баянов не хватает.

> _>Да. Во-первых, С/С++ многоплатформенный язык, в отличие от яв и

> .нетов. Правильно это или неправильно — сказать нельзя.
> JavaScript тоже многоплатформенный язык, только вот со строками в нём
> почему-то зверинца не наблюдается
Скажите это авторам линукса. Какого хера ядро линуха на С пишется?! Давно пора на C# или JS переписать, а то чё они всё
кактусы жрут?
А почему gcc написан на С, а вот javac/jvm не на java, а на том же С?

> _>Оба подхода *востребованы на практике*. Во-вторых, С/С++ — системный

> язык, а разные системы под строкой понимают разные вещи.
> C/C++ под строкой понимает только массив символов заканчивающихся нулём.
Ну да, есть такое, "кавычками отмечается". И чем они тебе не нравятся?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 18:42
Оценка:
Здравствуйте, kan_izh, Вы писали:

>> JavaScript тоже многоплатформенный язык, только вот со строками в нём почему-то зверинца не наблюдается

_>Скажите это авторам линукса. Какого хера ядро линуха на С пишется?! Давно пора на C# или JS переписать, а то чё они всё кактусы жрут?

C — это личные проблемы авторов линукса.

>> C/C++ под строкой понимает только массив символов заканчивающихся нулём.

_>Ну да, есть такое, "кавычками отмечается". И чем они тебе не нравятся?

К кавычкам у меня претензий нет
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 18:43
Оценка:
IT wrote:

> Это уже похоже на оболванивание шаблонами. Всё остальное кроме них мы

> уже просто отказываемся понимать. Это как у некоторых чудо-архитекторов
> с ярковыраженной передозировкой паттернами наблюдается правило "если я
> не могу применить никакой паттерн, то я применяю паттерн визитор" , так
> и у вас с шаблонами.
А по существу? В чём проблема кода? Или использование шаблонов — смертный грех?

> _>дописываем шаблонный метод к классу:

> Следи за руками. Весь бред с шаблонами удаляем и заменяем
> многострадальный метод свойством:

> _>MyMethod(get_current_anything<Edge>());

То что я приписал "_anything" — просто был не уверен, что С++ позволяет писать одноимённые функции и шаблоны. Сейчас
проверил — позволяет, по крайней мере MSVS2003, в стандарт лезть лениво, но скорее всего можно.

> будет

> MyMethod(CurrentEdge);
Уж свойство — точно синтаксический сахар, для меня не проблема набрать "()".

> _>разница в два символа "<" и ">".

> Разница в 17 символов.
А если так написать, то ещё короче:
M(g<E>());

Давайте будем считать количество лексем, а не букв.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 18:52
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>А по существу? В чём проблема кода? Или использование шаблонов — смертный грех?


Проблема не в использовании шаблонов вообще, а в тыкании их куда надо и куда не надо. Именно это я пытался выразить.

>> будет

>> MyMethod(CurrentEdge);
_>Уж свойство — точно синтаксический сахар, для меня не проблема набрать "()".

Зачем, если этого делать не надо. К тому же я получают от использования свойств дополнительные бенефиты. Например, в отладчике в студии достаточно подвести курсор к свойству и я сразу получу тултип со значением свойства. Функции так не работают.

>> _>разница в два символа "<" и ">".

>> Разница в 17 символов.
_>А если так написать, то ещё короче:
_>M(g<E>());

_>Давайте будем считать количество лексем, а не букв.


Давайте. В моём случае их 5, в твоём 10, т.е. в два раза больше.
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 18:54
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Вопрос: какие именно строки? В турбо-паскале, вон, были строки: до 255 символов. Это такие, как надо, или не такие? А сейчас какие они должны быть? CORBA-like, Java-like, C#-like? 16- или 32-битовые символы? Что делать с тем софтом, который уже написан на C и использует const char* ?

VD>Мне тебе рассказать о принципах проектирования?

Проектирования чего? Универсального всего для любых случаев? Расскажи.

VD>>>Это такие же вопросы как "Почему не добавить свойства? Они же никому не помешали бы." или "кому помешали бы функциональные типы?". На эти вопросы есть только отбрехи фанатов С++ и комитета. Отбрехи эти пахнут маргинальностью и старперством.


ГВ>>А требования дать свойства любой ценой пахнут непониманием неоднозначности ответа на это вопрос.

VD>Про цену, плиз, по подробнее. А то ваши слова сами пахнут не очень приятно.

Ну хорошо, не "любой ценой", а со сссылкой на: "у всех же есть".
<< Под музыку: Аквариум — Бессмертная Сестра Хо >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 19:29
Оценка:
IT wrote:

> _>А по существу? В чём проблема кода? Или использование шаблонов —

> смертный грех?
> Проблема не в использовании шаблонов вообще, а в тыкании их куда надо и
> куда не надо. Именно это я пытался выразить.
Ну это тебе понадобилось "bool get(*&)" превратить в "*get()". Если это реально понадобится, это делается очень легко,
притом позволяет управлять ситуацией, если false возвращается. А вот если описать так, как предлагаешь ты, то что будешь
делать в ситуации http://rsdn.ru/forum/?mid=1939558
Автор: Kluev
Дата: 05.06.06
и "do_something_usefull< Face >()"?

>> > будет

>> > MyMethod(CurrentEdge);
> _>Уж свойство — точно синтаксический сахар, для меня не проблема набрать
> "()".
> Зачем, если этого делать не надо. К тому же я получают от использования
> свойств дополнительные бенефиты. Например, в отладчике в студии
> достаточно подвести курсор к свойству и я сразу получу тултип со
> значением свойства. Функции так не работают.
Ладно, один бенефит. Только это бенефит не языка, а среды отладки. Та же студия при отладке JavaScript позволяет и
функции вызывать, а вот с родным "__declspec(property(...))" не умеет работать. А что ещё полезного, но, желательно,
именно для языка программирования?

> Давайте. В моём случае их 5, в твоём 10, т.е. в два раза больше.

В общем, кроме экономии на спичках я тут ничего не вижу, тем более, visual assist сам пустые скобки добавлять умеет,
если у функции нет аргументов.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 19:38
Оценка:
Здравствуйте, IT, Вы писали:

E>>или здесь,


IT>В первой же строчке: so_4::rt::__init_t. Из всего этого чириканья я понял только что такое init. Да и его мне предлагается запомнить с двумя подчёркиваниями, что может оказаться уже выше моих сил.


Это конечно круто, ругать комитет C++ и не знать соглашений о том, что имена с двумя подчеркиваниями означают часть реализации. __init_t в данном случае -- это такой класс специальный, для реализации счетчика Шварца. Объекты этого типа пользователю даже не нужны.

E>>Т.е.

E>>
E>>Face * f;
E>>if( get_current( f ) ) { ... }
E>>

E>>менее читабельно, чем это?
E>>
E>>Face * f = get_current_face();
E>>if( f ) { ... }
E>>

E>>Если да, то почему?

IT>Как минимум есть четыре причины.

IT>1. Вполне возможно, что мне не надо будет создавать промежуточную переменную.
IT>2. Проверка была сделана выше и повторно её делать не имеем смысла.
IT>3. Уровень доверия в моём коде может быть выше необходимости проверять возвращаемое значение.
IT>4. Вместо возврата null вызываемая функция может генерировать исключение.

Ни одной заслуживающей внимания причины. В особенности пункт 4 вообще никаким боком к текущей задаче не относится. Если бы задача допускала порождение исключения вместо возвращения значения, исходная функция get_current не возвращала бы bool.

E>>Зато в таком подходе MyMethod должен ожидать получение нулевого указателя. Если же он на это не расчитан, то по количеству строчек оба подхода не будут сильно различаться.


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


Я же сказал, что метод MyMethod на это может быть не расчитан. Если MyMethod -- это public метод, к которому непосредственно может обращаться пользователь, то проверка аргумента на null в нем обязательна. А вот если он внутренний и снаружи не виден, да еще вызвается очень часто, то такие проверки внутри MyMethod могут оказаться избыточными.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 19:43
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>idx вполне может быть нулем, а юзать -1, всяки-разны пары и кортежи изврат.


IT>По мне так нормально


K>>Т.е вот пример где out параметр правильно by design.


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


А вот и нет Мы unused юзаем.

struct Unused
{
  template <class T> operator T ()
  {
     static T dummy;
     return dummy;
  }
};

extern Unused unused;

//=================================
void test()
{
   if ( obj.find(foo, unused) )
   {
   } 
}
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 19:44
Оценка:
Здравствуйте, IT, Вы писали:

IT>В данном случае вообще напрашивается свойство. Сравни.


IT>
IT>if (CurrentEdge == null)
IT>  return; // здесь ловить больше нечего. чао бамбино
IT>CurrentEdge.Чик(); // 
IT>CurrentEdge.Пук(); // CurrentEdge всегда под рукой. смотрим что к чему если нужно
IT>


Согласен. На строчку кода меньше.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 05.06.06 19:51
Оценка:
Здравствуйте, IT, Вы писали:

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


_>>Шаблоны это даже круче чем ты думаешь.


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


_>>дописываем шаблонный метод к классу:


IT>Следи за руками. Весь бред с шаблонами удаляем и заменяем многострадальный метод свойством:


IT>и тогда вместо:


IT>
_>>MyMethod(get_current_anything<Edge>());
IT>

IT>будет

IT>
IT>MyMethod(CurrentEdge);
IT>

_>>разница в два символа "<" и ">".

IT>Разница в 17 символов.


Ну, имхо, придиратся не стоит.
можно ведь и просто current<Edge>() К томуже если я не ошибаюсь глобальных функций в шарпе нет и потребуется некий класс. т.е.
будет еще синтаксический оверхед (tm) в виде
Globals.CurrentEdge. А если это все по библиотекам раскидано, то тогда еще и прийдется более явно указывать:
Core.Globals.CurrentEdge, etc
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 20:04
Оценка:
Kluev wrote:

> можно ведь и просто current<Edge>() К томуже если я не ошибаюсь

> глобальных функций в шарпе нет и потребуется некий класс. т.е.
> будет еще синтаксический оверхед (tm) в виде
> Globals.CurrentEdge. А если это все по библиотекам раскидано, то тогда
> еще и прийдется более явно указывать:
> Core.Globals.CurrentEdge, etc
Тормозишь, причём тут глобальные переменные? Он говорит, мол, круто, если CurrentEdge будет пропертей. Можно так:
var foo = new Foo();
MyMethod(foo.current<Edge>());
MyMethod(foo.currentEdge);
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 05.06.06 20:15
Оценка:
Здравствуйте, Kluev, Вы писали:

K>А вот и нет Мы unused юзаем.

K>
K>struct Unused
K>{
K>  template <class T> operator T ()
K>  {
K>     static T dummy;
K>     return dummy;
K>  }
K>};

K>extern Unused unused;

K>//=================================
K>void test()
K>{
K>   if ( obj.find(foo, unused) )
K>   {
K>   } 
K>}
K>


Во-первых этот код вобще должен не компилироваться ибо должно быть operator T& ().
Во-вторых даже если его исправить то с многопоточностью у нас будут проблемы в случае если T что-то болие сложное чем Some* или int.
Итого: имеем грабли которые могут привести к рассогласованию внутреннего состояния объекта что может привести к порче памяти и/или утечке памяти в зависимости от фазы луны. Те поймать такую ошибку практически не реально.
Вывод: unsafe вобще и С++ в частности тебе противопоказан.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 20:40
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>А вот если описать так, как предлагаешь ты, то что будешь делать в ситуации http://rsdn.ru/forum/?mid=1939558
Автор: Kluev
Дата: 05.06.06
и "do_something_usefull< Face >()"?


Не совсем понял в какой именно ситуации, но да ладно. Есть куча хороших паттернов. Можно использовать null-паттерн, можно кидать исключение. Выбирай.

_>Ладно, один бенефит. Только это бенефит не языка, а среды отладки. Та же студия при отладке JavaScript позволяет и функции вызывать,


Методы тоже можно вызывать, но не наведением мышкой.

_>а вот с родным "__declspec(property(...))" не умеет работать.


Видимо забили.

_>А что ещё полезного, но, желательно, именно для языка программирования?


Свойства — это удобно. Например, удобно делать отложенную загрузку. Со свойствами хорошо работает баиндинг и куча визуальных компонент. Редактор контролов в студии, например, позволяет редактировать свойства контролов прямо в дизайн тайм. Абстолютно тот же самый редактор можно использовать и в рантайм. Например, на нём сделан редактор настроек в Янусе. Вообще, компонентное программирование слабо мыслимо без свойств. Например, в джаве для этого изобрели специальное соглашение — методы, начинающиеся с get(без параметров)/set(с одним параметром) считаются свойствами и также доступны всяким компонентным приблудам.

>> Давайте. В моём случае их 5, в твоём 10, т.е. в два раза больше.

_>В общем, кроме экономии на спичках я тут ничего не вижу, тем более, visual assist сам пустые скобки добавлять умеет, если у функции нет аргументов.

Я, и не только я, уже где-то в этой теме говорил, что код в несколько раз чаще читается чем пишется. В результате, сэкономив на спичках в одном месте ты получаешь при сопровождении кода экономию дерева. А на большом проекте — это уже целый лес. В общем, убей бобра — спаси дерево.
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 20:55
Оценка:
Здравствуйте, eao197, Вы писали:

E>Это конечно круто, ругать комитет C++ и не знать соглашений о том, что имена с двумя подчеркиваниями означают часть реализации. __init_t в данном случае -- это такой класс специальный, для реализации счетчика Шварца. Объекты этого типа пользователю даже не нужны.


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

IT>>Как минимум есть четыре причины.

IT>>1. Вполне возможно, что мне не надо будет создавать промежуточную переменную.
IT>>2. Проверка была сделана выше и повторно её делать не имеем смысла.
IT>>3. Уровень доверия в моём коде может быть выше необходимости проверять возвращаемое значение.
IT>>4. Вместо возврата null вызываемая функция может генерировать исключение.

E>Ни одной заслуживающей внимания причины.




E>В особенности пункт 4 вообще никаким боком к текущей задаче не относится. Если бы задача допускала порождение исключения вместо возвращения значения, исходная функция get_current не возвращала бы bool.


Если ты фанат кодов возврата, то у тебя больше нет вариантов. Об исключениях ты если и будешь знать, то всё равно защищать коды возврата станешь до посинения.

Возразить на это я могу лишь следующее. Твой bool не несёт никакой информации о том что же такого произошло и почему вызов не удался. Я ещё могу понять такие вещи как
bool int.TryParse(string s, out int n)
Здесь хотя бы понятно, что вызов Try не предполагает слишком подробной информации об ошибке и bool вполне оправдан. Но в твоём случае — это по любому кривой дизайн. Либо надо проверять на null возвращаемое значение, что вполне логично, либо кидать исключение.

Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 21:00
Оценка:
Здравствуйте, Kluev, Вы писали:

K>А вот и нет Мы unused юзаем.


Это попытка выпрямить кривой дизайн линзой с обратной кривизной.
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 21:01
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Согласен. На строчку кода меньше.


Не только. Ещё на одну проверку меньше. Ты в своём варианте тоже должен будешь на null не забыть проверить. А то мало ли что?
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 05.06.06 21:09
Оценка:
IT wrote:

> _>А вот если описать так, как предлагаешь ты, то что будешь делать в

> ситуации http://rsdn.ru/forum/?mid=1939558
Автор: Kluev
Дата: 05.06.06
и "do_something_usefull< Face

> >()"?
> Не совсем понял в какой именно ситуации, но да ладно. Есть куча хороших
> паттернов. Можно использовать null-паттерн, можно кидать исключение.
> Выбирай.
Куча методов, возвращающих почти одно и то же, но в несколько разных видах Face, CFace, QS_Face, QF_Face. Писать кучу
геттеров — решение, но никак не группирует эти геттеры. И не позволяет манипулировать этой кучкой геттеров единообразно.

> _>а вот с родным "__declspec(property(...))" не умеет работать.

> Видимо забили.
Тут проблема в "ассемблерности" С, имхо.

> _>А что ещё полезного, но, желательно, именно для языка программирования?

> Свойства — это удобно. Например, удобно делать отложенную загрузку. Со
? Чем геттер хуже?

> свойствами хорошо работает баиндинг и куча визуальных компонент.

> Редактор контролов в студии, например, позволяет редактировать свойства
> контролов прямо в дизайн тайм. Абстолютно тот же самый редактор можно
> использовать и в рантайм. Например, на нём сделан редактор настроек в
> Янусе. Вообще, компонентное программирование слабо мыслимо без свойств.
Чем геттеры/сеттеры не устраивают?

> Например, в джаве для этого изобрели специальное соглашение — методы,

> начинающиеся с get(без параметров)/set(с одним параметром) считаются
> свойствами и также доступны всяким компонентным приблудам.
Заметь, в яве обошлись, хоть для тебя это и слабо мыслимо, не слышал, чтобы кто-то особо сокрушался по поводу их
отсутствия...
Кстати, там дальше пошли, там понятие bean ввели, более "правильное" для компонентной модели. Но зачем это включать в
язык?.. это мне не совсем кажется большой необходимостью.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[45]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 21:27
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Куча методов, возвращающих почти одно и то же, но в несколько разных видах Face, CFace, QS_Face, QF_Face. Писать кучу геттеров — решение, но никак не группирует эти геттеры. И не позволяет манипулировать этой кучкой геттеров единообразно.


А какая тебе манипуляция нужна?

_>? Чем геттер хуже?

_>Чем геттеры/сеттеры не устраивают?

Мы же уже выяснили. Тем что приходится писать меньше более читабельного кода. В нашем примере это соотношение было 2 раза.

_>Заметь, в яве обошлись, хоть для тебя это и слабо мыслимо, не слышал, чтобы кто-то особо сокрушался по поводу их отсутствия...


Ты же ведь тоже не сокрушается, правда? Потому что трудно сокрушаться об отсутствии того, чего никогда не видел и не пробовал.

_>Кстати, там дальше пошли, там понятие bean ввели, более "правильное" для компонентной модели. Но зачем это включать в язык?.. это мне не совсем кажется большой необходимостью.


Ты у них спроси сколько надо сделать приседаний и сколько раз постучать в бубен, чтобы завернуть обычный джавовский класс в бин. Потом поговорим о более "правильном".
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.06 23:26
Оценка:
Здравствуйте, IT, Вы писали:

IT>А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.


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

Кроме того, апеллируя к личному опыту не надо забывать, что оружие сие — обоюдоострое.
<< Под музыку: Pink Floyd — Shine On You Crazy Diamond (Part Two) >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 23:35
Оценка: -1
Здравствуйте, kedik, Вы писали:

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


K>>>Стандарты то они конечно стандарты... но то что ты перечистил... ты почему-то видимо свято уверен, что жизни за пределами Windows не существует


VD>>Батенька, ды вы совсем дальше своего носа не видите. (с) Дотнет давно в виде Моно живет под Линуксом. Ява на таком количестве платформ, что С++ позавидует. Тут дело в том, что лично нам эти платформы просто не нужны. Ну, не занимаемся мы дешевым хостингом, где Линукс король песочнецы.


K>Сынок, хостингом я тоже не занимаюсь... ни дорогим, ни дешёвым


Мне плевать папать чем ты лично занимашся. Но если это:

K>А под Solaris или HP-UX Mono есть?


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

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


Еще раз. Задачи бывают разные — это столь же бесспорно, как и банально. Так что про это говорить не стоит. Нас же интересуют значительные объемы применения ака мэйнстрим. Так вот значительные объемы применения Линуксов — это исключительно хостинг. По крайней мере пока... но похоже, что и вообще. Радужные прогнозы о захвате Линуксом десктопа оказались мыльным пузырем.

K>Проект в котором в настояшее время я участвую, живет на Win, Linux, Sun, HP, AIX. При разработке используеться С++, TCL, Java...


Рад за тебя. Можешь спросить у своего начальства сколько у них клиентов под Соляркой или ХаПэ. Мой прогноз — еденицы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 05.06.06 23:59
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.


ГВ>И это является основанием для обвинений C++ в куче грехов?


Это является пояснением, что из-за тех самых грехов плюсам не находится места в моих задачах.

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


Да ради бога.

ГВ>Кроме того, апеллируя к личному опыту не надо забывать, что оружие сие — обоюдоострое.


Да я могу если что и вторым остриём...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 05:09
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это конечно круто защищать комитет и не знать, что двойное подчёркивание зарезервировано для разработчиков компиляторов.


Тем не менее, это не имеет никакого отношения к осмысленности выбираемый мной идентификаторов. Так что говори лучше по существу.

E>>В особенности пункт 4 вообще никаким боком к текущей задаче не относится. Если бы задача допускала порождение исключения вместо возвращения значения, исходная функция get_current не возвращала бы bool.


IT>Если ты фанат кодов возврата, то у тебя больше нет вариантов. Об исключениях ты если и будешь знать, то всё равно защищать коды возврата станешь до посинения.


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

Но в данном примере речь не шла о кодах возврата. Речь шла о функии, которая возвращала bool в качестве признака успешности или неудачности завершения. Примером такой функции может быть запрос параметров в диалоге у пользователя, когда bool означает, что пользователь ввел все, что нужно и нажал Ok. Более подробной диагностики здесь не нужно.

IT>Возразить на это я могу лишь следующее. Твой bool не несёт никакой информации о том что же такого произошло и почему вызов не удался. Я ещё могу понять такие вещи как
bool int.TryParse(string s, out int n)
Здесь хотя бы понятно, что вызов Try не предполагает слишком подробной информации об ошибке и bool вполне оправдан. Но в твоём случае — это по любому кривой дизайн. Либо надо проверять на null возвращаемое значение, что вполне логично, либо кидать исключение.


IT>Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.


А вдруг метод вернет указатель на не инициализированную память, но не нулевой указатель? Если мы говорим о C++, то проверка указателя на null -- это иллюзия безопасности.

Самое важное возражение против
bool get_current(Face *&)
-- это отсутствие гарантий в случае возникновения в get_current исключения. Например, get_current создал объект Face, присвоил его out-параметру, начал делать что-то еще и выбросил исключение. Тот, кто вызывал get_current() не может использовать указатель на Face, но он имеет этот указатель. И компилятор не может гарантировать, что этот указатель нигде не будет использоваться.

Это серьезный аргумент против out-параметров, но ты его не озвучил. Кроме того, он не может быть абсолютным законом. Т.к., во-первых, в проекте исключения могут вообще не использоваться. Во-вторых, сама функция может гарантировать строгую гарантию исключений (т.е., что после установки out-параметров исключения порождаться не могут). В-третьих, get_current могла иметь формат
bool get_current(Face &)
-- т.е. ей для изменения передается уже созданный кем-то объект Face. Такой вариант может использоваться, если есть серьезные требования к производительности (когда слишком накладно в get_current вызывать new), либо когда Face является вершиной иерархии наследования и в get_current на самом деле будут передаваться объекты производных от Face типов.

Тем не менее, перечисленные проблемы с гаранитией исключений не имеют отношения к понятности и читабельности кода. А именно об этом я тебя и спрашивал
Автор: eao197
Дата: 05.06.06
.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 06.06.06 06:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


K>>А вот и нет Мы unused юзаем.

K>>
K>>struct Unused
K>>{
K>>  template <class T> operator T ()
K>>  {
K>>     static T dummy;
K>>     return dummy;
K>>  }
K>>};

K>>extern Unused unused;

K>>//=================================
K>>void test()
K>>{
K>>   if ( obj.find(foo, unused) )
K>>   {
K>>   } 
K>>}
K>>


WH>Во-первых этот код вобще должен не компилироваться ибо должно быть operator T& ().

Писал руками поэтому и ошибся. А в коде конечно же юзается T&

WH>Во-вторых даже если его исправить то с многопоточностью у нас будут проблемы в случае если T что-то болие сложное чем Some* или int.

Да ладно сказки рассказывать. Класс заточен под POD параметры:

// проеккция точки на прямую, возвращает расстояние а так же параметрию и точку проекции
double project_to_line(const Point &from, const Point &lineStart, const Point &lineEnd, double &t, Point &projection);


Вот для такихфункций и юзается:
double dist = project_to_line(from, A, B, unused, unused); // нас интересует только расстояние расстояние



WH>Итого: имеем грабли которые могут привести к рассогласованию внутреннего состояния объекта что может привести к порче памяти и/или утечке памяти в зависимости от фазы луны. Те поймать такую ошибку практически не реально.

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

WH>Вывод: unsafe вобще и С++ в частности тебе противопоказан.

Ха Ха Ха.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 06.06.06 07:15
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Kluev wrote:


>> можно ведь и просто current<Edge>() К томуже если я не ошибаюсь

>> глобальных функций в шарпе нет и потребуется некий класс. т.е.
>> будет еще синтаксический оверхед (tm) в виде
>> Globals.CurrentEdge. А если это все по библиотекам раскидано, то тогда
>> еще и прийдется более явно указывать:
>> Core.Globals.CurrentEdge, etc
_>Тормозишь, причём тут глобальные переменные? Он говорит, мол, круто, если CurrentEdge будет пропертей.

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

CONSOLE_CMD(face_test)()
{
  Face *f;
  if ( !get_curr(f) )
     return;
  // отлаживаем методы Face
}


CONSOLE_CMD — это макрос который просто дает функции префикс и добавляет __decslpec(dllexport). Дальше я просто читаю таблицу импорта в экзешнике (эдакий рефлектор кулхакера) и по префиксам вытаскиваю нужные функции, которые делаются доступными во встроенной консоли.
Когда глобальных функций нет и все должно лежать в классах тогда писанины будет больше как ни крути.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 06.06.06 07:40
Оценка:
Здравствуйте, IT, Вы писали:

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


K>>А вот и нет Мы unused юзаем.


IT>Это попытка выпрямить кривой дизайн линзой с обратной кривизной.


А как насчет этого: Например в неком классе Node есть метод соседние-узлы-на-базу-быстро
Node::adjacent_nodes

Пример
vector<Node*> nodes; // временный массив
for (Node *n = face.node_first(); n; n = face.next(n) )
{
   nodes.clear();
   n->adjacent_nodes(nodes);
// далее групируем полученные узлы по какому либо признаку для дальнейшей обработки
   sort(nodes.begin(), nodes.end(), some_criteria);
// дальше поскипано
}


На первой итерации массив nodes заполнится т.е. выделится накая память и если на второй итерации число полученных узлов <= числу узлов на предыдущей то память выделятся не будет, а заюзается то что есть в nodes. Т.е. оптимизация на халяву. А если сделать массив возвращаемым параметром:
vector<Nodes*> Node::adjacent_nodes()

то память будет выделятся по любому. т.е неэффективность на ровном месте на лицо. Иными словами out параметр здесь рулит.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 06.06.06 07:55
Оценка:
IT wrote:
> Свойства — это удобно. Например, удобно делать отложенную загрузку. Со
> свойствами хорошо работает баиндинг и куча визуальных компонент.
Чем отложенная загрузка не живет с get/set-методами?

> Редактор контролов в студии, например, позволяет редактировать свойства

> контролов прямо в дизайн тайм.
Аналогично в Java — в качестве свойств используется комбинация
get/set-методов.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 08:00
Оценка: 26 (6) +1
Здравствуйте, VladD2, Вы писали:

VD>Мне плевать папать чем ты лично занимашся. Но если это:


K>>А под Solaris или HP-UX Mono есть?


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


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

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


VD>Еще раз. Задачи бывают разные — это столь же бесспорно, как и банально. Так что про это говорить не стоит. Нас же интересуют значительные объемы применения ака мэйнстрим. Так вот значительные объемы применения Линуксов — это исключительно хостинг. По крайней мере пока... но похоже, что и вообще. Радужные прогнозы о захвате Линуксом десктопа оказались мыльным пузырем.


Да и ради бога. Лично мне нафиг Linux или FreeBSD на десктопе не нужен без того количества драйверов, которые есть под Windows. Зато мне нафиг не нужны форточки на сервере, для которого вполне достаточно bash, screen и ssh.

K>>Проект в котором в настояшее время я участвую, живет на Win, Linux, Sun, HP, AIX. При разработке используеться С++, TCL, Java...


VD>Рад за тебя. Можешь спросить у своего начальства сколько у них клиентов под Соляркой или ХаПэ. Мой прогноз — еденицы.


Есть такой класс систем -- банковский процессинг. Их продажи не могут исчисляться тысячами в принципе. Но не смотря на то, что у производителей процессинга клиентов едва переваливает за сотню, между самими производителями процессинга идет весьма серьезная конкуренция. И я очень сильно удивлюсь, если серьезные процессинговые системы для крупных банков (хотя бы уровня ведущих Московских банков, не говоря уже про европейские и американские), работающие под Windows.

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

Еще один пример. Есть такая платформа HP NonStop (бывший Tandem). Супер надежная, позиционируется как самая надежная платформа в мире и самая выгодная по соотношению цена/производительность для свого класса систем (хотя все это маркетинг и Sun, и Stratuss здесь приводят совершенно другие показатели). При этом машинка минимальной конфигурации стоит под $150K. И на этой платформе работают практически все крупнейшие банки США и Европы, все биржи в США, большинство европейских бирж, большинство сотовых операторов США. А крупнейший NonStop-ный кластер (вроде из 300 юнитов) работает в AOL.

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

Таких клиентов единицы. Но они требуют гораздо больше, чем все рядовые Windows-юзеры вместе взятые (образно говоря). И на создание подобных систем требуется своя индустрия. Естественно, она не мейнстрим. Ты вот, например, о ней даже не задумываешься (если вообще знаешь). А ведь она есть. И приносит совсем не маленькие деньги.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 06.06.06 08:29
Оценка:
IT wrote:

> _>Куча методов, возвращающих почти одно и то же, но в несколько разных

> видах Face, CFace, QS_Face, QF_Face. Писать кучу геттеров — решение, но
> никак не группирует эти геттеры. И не позволяет манипулировать этой
> кучкой геттеров единообразно.
> А какая тебе манипуляция нужна?
do_something_usefull< Face >(), do_something_usefull< CFace >()...
Это, конечно, обычным наследованием решается, ладно, забудь, ибо шаблонов ты пугаешься.

> _>? Чем геттер хуже?

> _>Чем геттеры/сеттеры не устраивают?
> Мы же уже выяснили. Тем что приходится писать меньше более читабельного
> кода. В нашем примере это соотношение было 2 раза.
На 2 лексемы "()", если по честному сравнивать "obj.edge vs obj.edge()".

> _>Заметь, в яве обошлись, хоть для тебя это и слабо мыслимо, не слышал,

> чтобы кто-то особо сокрушался по поводу их отсутствия...
> Ты же ведь тоже не сокрушается, правда? Потому что трудно сокрушаться об
> отсутствии того, чего никогда не видел и не пробовал.
Понятно, ты, значит, подсел.
Есть проперти — я их использую, нет пропертей — не использую. Особой разницы в этом не вижу.
Разница примерно как ставить ли ";" в конце строки? В JavaScript не ставлю, в Java — ставлю, и ущербности ни того, ни
другого не ощущаю.

> _>Кстати, там дальше пошли, там понятие bean ввели, более "правильное"

> для компонентной модели. Но зачем это включать в язык?.. это мне не
> совсем кажется большой необходимостью.
> Ты у них спроси сколько надо сделать приседаний и сколько раз постучать
> в бубен, чтобы завернуть обычный джавовский класс в бин. Потом поговорим
> о более "правильном".
А сколько нужно чтобы в COM завернуть? Или в webservice? или corba? Дело в том, что модель такая, требует определённый
формат объектов.
Хотя вот VBA классно в COM заворачивается, но толку-то?.. Там, кстати, и твои любимые проперти есть.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[46]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 06.06.06 08:39
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ты у них спроси сколько надо сделать приседаний и сколько раз постучать в бубен, чтобы завернуть обычный джавовский класс в бин.

Ровно 0.

"Бином" (не EJB!) считается любой сериализабельный класс с get/set-методами. Еще бин может опционально поддерживать ноификации о измениниях свойств и рекомендуется иметь конструтор без параметров.

Я уж не говорю, что все уважающие себя IDE давно поддерживают автоматическую генерацию get/set/is-методов.
Sapienti sat!
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 06.06.06 08:44
Оценка:
Kluev wrote:

> Так ведь функции (get_current) глобальные. И вызываются из глобальных

> функций. Вообще вся эта песня с get_current была затеяна для чего? В
Не знаю, странное решение. Когда я решаю использовать глобальную функцию/переменную, я думаю, а может не стоит? Если
всё-таки надумываю что стоит, думаю ещё раз хорошо. И если на этот раз опять решаю, что надо глобальные данные
испольозвать — приходится серьёзно задумываться. И только если после этого решаю, что да, то пишу синлтон.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[47]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 08:48
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>do_something_usefull< Face >(), do_something_usefull< CFace >()...

_>Это, конечно, обычным наследованием решается, ладно, забудь, ибо шаблонов ты пугаешься.

Вобще-то решается. Нужно только, чтобы Face и CFace реализовывали общий базовый интерфейс IFace, а функция do_something_usefull получала фабрику IFace в качестве аргумента. Только совсем не факт, что Face и CFace можно будет от IFace унаследовать. И такой вариант, на основе виртуальных методов и фабрик (т.е. с динамическим выделением памяти), очень вероятно, будет медленнее шаблоного.

Более того, можно и обратный пример, когда есть get_current_face, get_current_edge, get_current_surface (вместо одного перегруженного get_current) с шаблоном do_something_useful подружить. Через специализацию шаблонов:
// Без специализации порождаем ошибку.
template< class T > struct getter {};

// Конкретные специализации.
template<> struct getter< Face > { Face * operator()() { get_current_face(); } };
template<> struct getter< Edge > { Edge * operator()() { get_current_edge(); } };
template<> struct getter< Surface > { Surface * operator()() { get_current_surface(); } };

template< class T >
void do_something_useful() {
  T * t = getter< T >()();
  ...
}

Писанины, однако, явно больше.

Поэтому вариант do_something_useful<> на шаблонах и get_current() с out-параметром, имхо, выглядит самым прагматичным. Более того, если классы Face, Edge, Surface имеют какие-то не очень серьезные различия в интерфейсах (скажем, разные названия некоторых методов) из-за отсутствия общего корня иерархии наследования, то эти различия можно легко скрыть за шаблонами вроде показанного выше getter.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 11:58
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>Это конечно круто защищать комитет и не знать, что двойное подчёркивание зарезервировано для разработчиков компиляторов.


E>Тем не менее, это не имеет никакого отношения к осмысленности выбираемый мной идентификаторов. Так что говори лучше по существу.




E>Но в данном примере речь не шла о кодах возврата. Речь шла о функии, которая возвращала bool в качестве признака успешности или неудачности завершения. Примером такой функции может быть запрос параметров в диалоге у пользователя, когда bool означает, что пользователь ввел все, что нужно и нажал Ok. Более подробной диагностики здесь не нужно.


По существу. get_current_edge — диалог? Ты бы ещё назвал эту функцию оператором ++.

E>Это серьезный аргумент против out-параметров, но ты его не озвучил.


Просто я такими "серьёзными" аргументами уже давно не страдаю, начал подзабывать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 12:07
Оценка:
Здравствуйте, IT, Вы писали:

E>>Но в данном примере речь не шла о кодах возврата. Речь шла о функии, которая возвращала bool в качестве признака успешности или неудачности завершения. Примером такой функции может быть запрос параметров в диалоге у пользователя, когда bool означает, что пользователь ввел все, что нужно и нажал Ok. Более подробной диагностики здесь не нужно.


IT>По существу. get_current_edge — диалог? Ты бы ещё назвал эту функцию оператором ++.


Я же сказал

примером такой функции

.
Например, get_current_edge может возвращать true, если edge с момента последнего обращения к get_current_edge изменился (как раз в результете взаимодействия с пользователем) или false, если edge не изменялся.

E>>Это серьезный аргумент против out-параметров, но ты его не озвучил.


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


Еще скажи, что в managed языках вообще нет необходимости обеспечивать гарантию безопасности исключений.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[47]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 12:14
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Это, конечно, обычным наследованием решается, ладно, забудь, ибо шаблонов ты пугаешься.




_>На 2 лексемы "()", если по честному сравнивать "obj.edge vs obj.edge()".


Не надо нам тут фальсификаций. Было obj.get<edge>().

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

_>Понятно, ты, значит, подсел.

Можно и так сказать. Подсел на удобный и красивый язык без мусора в виде бесконечных преобразований строк, без '->', '::' и прочих птичьих наворотов.

_>Есть проперти — я их использую, нет пропертей — не использую. Особой разницы в этом не вижу.

_>Разница примерно как ставить ли ";" в конце строки? В JavaScript не ставлю, в Java — ставлю, и ущербности ни того, ни другого не ощущаю.

Ради бога, на здоровье. Я же не против. Жалко, конечно, что такие хорошие ребята, вот так запросто так калечат себе судьбы, но... что делать


_>А сколько нужно чтобы в COM завернуть? Или в webservice? или corba? Дело в том, что модель такая, требует определённый формат объектов.


В ком и корба — это да. Вебсервисы или ремоутинг делается в .NET без приседаний. Вебметод делается навещиванием на метод соответствующего атрибута. Через ремоутинг объект делается доступным путём наследования от соответствующего объекта. Но почему это возможно и что такое метадата в .NET тема для отдельного разговора.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[45]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 12:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Еще скажи, что в managed языках вообще нет необходимости обеспечивать гарантию безопасности исключений.


В редких случаях, например, если edge держит какие-то системные ресурсы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 12:26
Оценка:
Здравствуйте, Kluev, Вы писали:

K>то память будет выделятся по любому. т.е неэффективность на ровном месте на лицо. Иными словами out параметр здесь рулит.


Какой же это out параметр. Это обычная ссылка
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[46]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 12:27
Оценка:
Здравствуйте, IT, Вы писали:

E>>Еще скажи, что в managed языках вообще нет необходимости обеспечивать гарантию безопасности исключений.


IT>В редких случаях, например, если edge держит какие-то системные ресурсы.


Интересно. Вот давай представим себе getCurrentEdge, который работает следующим образом (вроде как на Java):
public bool getCurrentEdge( Edge edge ) throws Exception
  {
    // Перед возвратом из getCurrentEdge у объекта edge нужно вызвать два метода: setLength, setWidth.
    // Вызов только одного из них оставляет edge в некорректном состоянии с точки зрения getCurrentEdge.
    ...
    edge.setLength( calculatedLength );
    ... // (1) вот здесь возможно возникновение исключения.
    edge.setWidth( calculatedWidth );
    ...
    return result;
  }


По твоему здесь есть проблемы с обеспечением гарантии безопасности исключений?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[47]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 12:45
Оценка:
Здравствуйте, eao197, Вы писали:

E>По твоему здесь есть проблемы с обеспечением гарантии безопасности исключений?


Это зависит от сценариев использования данного метода. Я бы вряд ли вообще написал бы что-то подобное.

Но, по-моему, во-первых, здесь есть проблемы с наименованием, не отражающим суть, а, во-вторых, это не out параметр, а обычная ссылка.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[48]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 06.06.06 12:51
Оценка: 2 (1)
Здравствуйте, IT, Вы писали:

_>>Есть проперти — я их использую, нет пропертей — не использую. Особой разницы в этом не вижу.

_>>Разница примерно как ставить ли ";" в конце строки? В JavaScript не ставлю, в Java — ставлю, и ущербности ни того, ни другого не ощущаю.

IT>Ради бога, на здоровье. Я же не против. Жалко, конечно, что такие хорошие ребята, вот так запросто так калечат себе судьбы, но... что делать


А чем C# и .NET лучше для судеб? Никакой экзестенциальной разницы на самом деле нет. Разум привязан к идеям, а в чем они выражаются это уже не имеет никакого значения. Реальная альтеранитва — это, как говорят мудрецы: учись умирать для мира чтобы начать тебе жить с Христом. И, можешь грабить — грабь, если добыча Имя Рамы.

А перелезть с С++ на С# — это иллюзия в конечно итоге на самом низком уровне все равно нет ничего кроме нулей и единиц, просто все превратилось в грандиозное шоу.
Re[49]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 06.06.06 13:00
Оценка: -1
Здравствуйте, Kluev, Вы писали:

K>А перелезть с С++ на С# — это иллюзия в конечно итоге на самом низком уровне все равно нет ничего кроме нулей и единиц, просто все превратилось в грандиозное шоу.

Почему ты тогда в машинных кодах не пишешь? Долби нули и единици ибо в конечно итоге на самом низком уровне все равно нет ничего кроме нулей и единиц, просто все превратилось в грандиозное шоу.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 13:05
Оценка:
Здравствуйте, IT, Вы писали:

E>>По твоему здесь есть проблемы с обеспечением гарантии безопасности исключений?


IT>Это зависит от сценариев использования данного метода. Я бы вряд ли вообще написал бы что-то подобное.


Гарантия безопасности исключений относится не к тому, кто вызывает метод. А к тому, что может сделать сам метод. Приведенный метод гарантий безопасности исключений не обеспечивает. И, что самое плохое, такой код может быть написан на автомате на любом языке с исключениями.

IT>Но, по-моему, во-первых, здесь есть проблемы с наименованием, не отражающим суть,


+1
Это да, но я хотел остаться в русле примера с get_current_edge.

IT> а, во-вторых, это не out параметр, а обычная ссылка.


Да в Java, насколько я помню, с out параметрами дело было вообще швах. Лучшее, что я мог тогда придумать, это передавать ссылку на вектор:
public boolean getCurrentEdge( Edge edges[] ) throws Exception
  {
    Edge current = new Edge();
    edges[ 0 ] = current;
    ...
    current.setLength( calculatedLength );
    ...
    current.setWidth( calculatedWidth );
    ...
    return result;
  }
...
Edge current[] = new Edge[1];
getCurrentEdge( current );
...


В таких условиях с out аргументам вообще не захочется связываться.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 06.06.06 13:51
Оценка: +1 :)
IT wrote:

> _>На 2 лексемы "()", если по честному сравнивать "obj.edge vs obj.edge()".

> Не надо нам тут фальсификаций. Было obj.get<edge>().
Эквивалентом "obj.edge" будет именно "obj.edge()", ну или в худшем случае, если следовать спеке бинов (что далеко не
всегда нужно) "obj.getEdge()".
А "obj.get<edge>()" обладает другой семантикой, в яве/.нете аналога нет. Может что-то типа "obj.get(Enum.EDGE)",
а внутри get страшный switch.

>> > Ты же ведь тоже не сокрушается, правда? Потому что трудно сокрушаться

> об отсутствии того, чего никогда не видел и не пробовал.
> _>Понятно, ты, значит, подсел.
> Можно и так сказать. Подсел на удобный и красивый язык без мусора в виде
> бесконечных преобразований строк, без '->', '::' и прочих птичьих наворотов.
А тебя не напрягает разговаривать на русском языке? Английский, вон, безо всяких птичьих наворотов типа падежей и родов,
склонений и окончаний.

> _>Есть проперти — я их использую, нет пропертей — не использую. Особой

> разницы в этом не вижу.
> _>Разница примерно как ставить ли ";" в конце строки? В JavaScript не
> ставлю, в Java — ставлю, и ущербности ни того, ни другого не ощущаю.
> Ради бога, на здоровье. Я же не против. Жалко, конечно, что такие
> хорошие ребята, вот так запросто так калечат себе судьбы, но... что делать
Напоминает аргументы Свидетеля Иеговы, познавшем силу Библии, узнавшем источник Абсолютной Истины.

> _>А сколько нужно чтобы в COM завернуть? Или в webservice? или corba?

> Дело в том, что модель такая, требует определённый формат объектов.
> В ком и корба — это да. Вебсервисы или ремоутинг делается в .NET без
> приседаний. Вебметод делается навещиванием на метод соответствующего
> атрибута. Через ремоутинг объект делается доступным путём наследования
> от соответствующего объекта.
Не поверишь, но в той же яве всё абсолютно так же, и без пропертей.

> Но почему это возможно и что такое метадата

> в .NET тема для отдельного разговора.
А что такое аннотации в яве?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[49]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 14:41
Оценка: :)
Здравствуйте, Kluev, Вы писали:

K>А чем C# и .NET лучше для судеб? Никакой экзестенциальной разницы на самом деле нет.


Лучше тем, что ты не растрачиваешь свою жизнь по мелочам на преобразования строк.

K>Разум привязан к идеям, а в чем они выражаются это уже не имеет никакого значения.


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

K>А перелезть с С++ на С# — это иллюзия в конечно итоге на самом низком уровне все равно нет ничего кроме нулей и единиц, просто все превратилось в грандиозное шоу.


Это всё разговоры, необходимые для самоуспокоения. Ведь гораздо проще уговорить себя, что разницы нет, чем попытаться её найти и прочувствовать.
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 14:48
Оценка: :)
Здравствуйте, kan_izh, Вы писали:

_>А тебя не напрягает разговаривать на русском языке? Английский, вон, безо всяких птичьих наворотов типа падежей и родов, склонений и окончаний.


Руский матерный даже попроще будет.

>> Ради бога, на здоровье. Я же не против. Жалко, конечно, что такие хорошие ребята, вот так запросто так калечат себе судьбы, но... что делать

_>Напоминает аргументы Свидетеля Иеговы, познавшем силу Библии, узнавшем источник Абсолютной Истины.

Мне всегда было жалко ёжиков, продолжающих жрать кактус. Кактус тоже, кстати, жалко.

_>Не поверишь, но в той же яве всё абсолютно так же, и без пропертей.

_>А что такое аннотации в яве?

Как-то ты потихому на джаву переключился. Мы же тут какашками вроде как в C++ кидаемся, а не в джаву
Если нам не помогут, то мы тоже никого не пощадим.
Re[50]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 06.06.06 15:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>Почему ты тогда в машинных кодах не пишешь?


А хрен его знает
Re[51]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 06.06.06 15:42
Оценка: -1
Здравствуйте, Kluev, Вы писали:

WH>>Почему ты тогда в машинных кодах не пишешь?

K>А хрен его знает
Теперь я понял чем ты руководствуешься при разработки программ.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[50]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 06.06.06 15:58
Оценка:
IT wrote:

> _>Не поверишь, но в той же яве всё абсолютно так же, и без пропертей.

> _>А что такое аннотации в яве?
> Как-то ты потихому на джаву переключился. Мы же тут какашками вроде как
> в C++ кидаемся, а не в джаву
Ты сказал, что без пропертей жизнь невозможна, вот я и привёл в пример яву, где пропертей нет, не было, и не
планируется, а жизнь кипит вовсю.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[50]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 06.06.06 15:58
Оценка:
IT wrote:
> _>А тебя не напрягает разговаривать на русском языке? Английский, вон,
> безо всяких птичьих наворотов типа падежей и родов, склонений и окончаний.
> Руский матерный даже попроще будет.
Не проще — грамматика не меняется. Просто некоторые слова заменяются
плейсхолдерами, чье значение зависит от контекста.

Код Хэффмана получается (см. соседнюю ветку)

> _>Не поверишь, но в той же яве всё абсолютно так же, и без пропертей.

> _>А что такое аннотации в яве?
> Как-то ты потихому на джаву переключился. Мы же тут какашками вроде как
> в C++ кидаемся, а не в джаву
Просто Java — это пример того, что свойства в понятии .NET нафиг не
сдались (кроме простого синтаксического сахарка).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[51]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 16:08
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

C>Просто Java — это пример того, что свойства в понятии .NET нафиг не сдались (кроме простого синтаксического сахарка).


Джава — это как раз пример, как вместо того, чтобы сделать нормальные свойства, нужно обязательно извращаться с соглашениями об наименовании.
Если нам не помогут, то мы тоже никого не пощадим.
Re[51]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 16:11
Оценка:
Здравствуйте, kan_izh, Вы писали:

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


Ты как раз привёл пример самой что ни на есть проперти. Только она эмулируется с помощью соглашений об именованиях.

Не надо так сильно стараться себя обмануть. Свойство — это неотъемлемая часть компонентной технологии. И как раз джава очень хорошо демонстрирует необходимость свойств наличием затычки ввиде геттеров и сеттеров.
Если нам не помогут, то мы тоже никого не пощадим.
Re[52]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 06.06.06 16:28
Оценка:
IT wrote:

> Не надо так сильно стараться себя обмануть. Свойство — это неотъемлемая

> часть компонентной технологии. И как раз джава очень хорошо
> демонстрирует необходимость свойств наличием затычки ввиде геттеров и
> сеттеров.
ДА! Часть компонентной технологии! Но это не означает, что это непременно обязательно надо пихать в синтаксис языка.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[53]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 17:17
Оценка:
Здравствуйте, kan_izh, Вы писали:

>> И как раз джава очень хорошо демонстрирует необходимость свойств наличием затычки ввиде геттеров и сеттеров.

_>ДА! Часть компонентной технологии! Но это не означает, что это непременно обязательно надо пихать в синтаксис языка.

Уверен, ты бы сделал хорошую карьеру в комитете по стандартизации C++
Если нам не помогут, то мы тоже никого не пощадим.
Re[50]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 06.06.06 17:30
Оценка: +1
Здравствуйте, IT, Вы писали:

K>>А перелезть с С++ на С# — это иллюзия в конечно итоге на самом низком уровне все равно нет ничего кроме нулей и единиц, просто все превратилось в грандиозное шоу.


IT>Это всё разговоры, необходимые для самоуспокоения. Ведь гораздо проще уговорить себя, что разницы нет, чем попытаться её найти и прочувствовать.


Я пробовал дот-нет и шарп. Некоторые вещи хорошо сделаны, некоторые вызывают только раздражение (например невозможность задать параметр по дефолту). К тому-же проект над которым я сейчас работаю содержит проблемы в основном геометрические (95% всей работы), а шарп здесь неподходит обьективно. Причем не из-за GC и некоторых тормозов в числодроблении, а из-за того что на нем невозможно создать понастоящему удобные структуры данных. Нет там таких развитых и продуманных шаблонов как в С++ и множественного наследования (которое интенсивно юзаем).

P.S. Но если отвлечся в сторону от реальности и была бы возможность делать, что хочешь и на чем хочешь. То я бы пожалуй все равно не стал бы юзать шарп, а скорее бы начал писать свой язык, в духе идей С++ только без legacy bullshit
Re[51]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 17:36
Оценка: -1
Здравствуйте, Kluev, Вы писали:

K>P.S. Но если отвлечся в сторону от реальности и была бы возможность делать, что хочешь и на чем хочешь. То я бы пожалуй все равно не стал бы юзать шарп, а скорее бы начал писать свой язык, в духе идей С++ только без legacy bullshit


Посмотри в сторону Немерле. Духу C++, впрочем так же как и духу C#, до духа Немерле ещё как на четвереньках до Парижа.
Если нам не помогут, то мы тоже никого не пощадим.
Re[52]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 06.06.06 17:41
Оценка: 1 (1)
IT wrote:
> C>Просто Java — это пример того, что свойства в понятии .NET нафиг не
> сдались (кроме простого синтаксического сахарка).
> Джава — это как раз пример, как вместо того, чтобы сделать нормальные
> свойства, нужно обязательно извращаться с соглашениями об наименовании.
НЕТ в .NET "нормальных свойств".

В .NET просто есть соглашение об именах get/set-методов и событий и еще
сахарок, который автоматически эти методы генерирует. Все точно так же
как в Java, только там генерацией занимается IDE.

Причем, на самом деле databinding'у вообще должно быть пофиг к чему
биндиться — ничто не мешает ему завязываться на любой get/set-метод.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[53]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 06.06.06 19:10
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>НЕТ в .NET "нормальных свойств".


RTFM PropertyInfo.

C>В .NET просто есть соглашение об именах get/set-методов и событий и еще сахарок, который автоматически эти методы генерирует. Все точно так же как в Java, только там генерацией занимается IDE.


Свойство в .NET — это самостоятельная сущность, доступная через рефлекшин со всеми вытекающими последствиями. Например, я могу через emit привязать любой подходящий метод к нужному мне свойству. Соглашение об именовании get_/set_ — это всего лишь соглашение конкретного языка, в данном случае C#.

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

C>Причем, на самом деле databinding'у вообще должно быть пофиг к чему биндиться — ничто не мешает ему завязываться на любой get/set-метод.


Вот насчёт public поля я бы с тобой ещё согласился. В BLToolkit я именно так и сделал. А баиндиться к методам?... Сэр редкостный извращенец
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 07.06.06 03:46
Оценка: 19 (2)
eao197,

E>Да в Java, насколько я помню, с out параметрами дело было вообще швах. Лучшее, что я мог тогда придумать, это передавать ссылку на вектор:

E>
E>public boolean getCurrentEdge( Edge edges[] ) throws Exception
E>  {
E>    Edge current = new Edge();
E>    edges[ 0 ] = current;
E>    ...
E>    current.setLength( calculatedLength );
E>    ...
E>    current.setWidth( calculatedWidth );
E>    ...
E>    return result;
E>  }
E>...
E>Edge current[] = new Edge[1];
E>getCurrentEdge( current );
E>...
E>

E>В таких условиях с out аргументам вообще не захочется связываться.

Есть более универсальный и распространённый способ с использованием бинов (бин — это класс, который состоит из пар методов set* и get*). Если где-то фигурирует бин, то как правило у джавистов срабатывает условный рефлекс "О! здесь возвращается значение".
class EdgeBean
{
    private Edge edge;
    public void setEdge(Edge edge) { this.edge = edge; }
    public Edge getEdge()          { return this.edge; }
}

public boolean getCurrentEdge(EdgeBean bean)
{
    bean.setEdge(new Edge());
    return true;
}

Естественно все IDE способны генерировать такие пары методов set/get для поля или нескольких полей нажатием 2х-3х кнопок.

Так что out-параметры есть, просто их не сразу видно .
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[50]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.06.06 06:07
Оценка: :)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Есть более универсальный и распространённый способ с использованием бинов (бин — это класс, который состоит из пар методов set* и get*). Если где-то фигурирует бин, то как правило у джавистов срабатывает условный рефлекс "О! здесь возвращается значение".

<...код поскипан...>
LCR>Естественно все IDE способны генерировать такие пары методов set/get для поля или нескольких полей нажатием 2х-3х кнопок.

LCR>Так что out-параметры есть, просто их не сразу видно .


Да, давно я не брал в руки шашек Уже лет пять


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[54]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.06.06 06:40
Оценка:
Здравствуйте, IT, Вы писали:

IT>Свойство в .NET — это самостоятельная сущность, доступная через рефлекшин со всеми вытекающими последствиями.


Я так и не понял, свойство можно передать в метод как параметр/вернуть из, или нет?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[54]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 07.06.06 07:50
Оценка:
IT wrote:
> C>*НЕТ* в .NET "нормальных свойств".
> RTFM PropertyInfo.
RTFM java.beans.BeanInfo.

> Свойство в .NET — это самостоятельная сущность, доступная через

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

> Вот насчёт public поля я бы с тобой ещё согласился. В BLToolkit я именно

> так и сделал. А баиндиться к методам?... Сэр редкостный извращенец
Ну так свойства реализованы как методы — они НЕ являются
самостоятельными сущностями (рекомендую посмотреть на базовый класс
PropertyInfo).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[50]: Tcl как обоснование ненужности поддержки компонентно
От: Kluev  
Дата: 07.06.06 09:33
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:


LCR>Есть более универсальный и распространённый способ с использованием бинов (бин — это класс, который состоит из пар методов set* и get*). Если где-то фигурирует бин, то как правило у джавистов срабатывает условный рефлекс "О! здесь возвращается значение".

LCR>
LCR>class EdgeBean
LCR>{
LCR>    private Edge edge;
LCR>    public void setEdge(Edge edge) { this.edge = edge; }
LCR>    public Edge getEdge()          { return this.edge; }
LCR>}

LCR>public boolean getCurrentEdge(EdgeBean bean)
LCR>{
LCR>    bean.setEdge(new Edge());
LCR>    return true;
LCR>}
LCR>

LCR>Естественно все IDE способны генерировать такие пары методов set/get для поля или нескольких полей нажатием 2х-3х кнопок.

LCR>Так что out-параметры есть, просто их не сразу видно .


Ужос. Хорошая иллюстрация как под видом простого языка людям впаривается примитивный, в котором даже простые вещи приходится делать через задницу.
Re[55]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 07.06.06 12:39
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>Свойство в .NET — это самостоятельная сущность, доступная через рефлекшин со всеми вытекающими последствиями.


ANS>Я так и не понял, свойство можно передать в метод как параметр/вернуть из, или нет?


Значение свойства? Конечно можно. Или ты о чём то другом?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[55]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 07.06.06 12:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>*НЕТ* в .NET "нормальных свойств".

>> RTFM PropertyInfo.
C>RTFM java.beans.BeanInfo.

Видимо для начала тебя надо попросить дать определение что ты понимаешь под "нормальное свойство". Боюсь, ты себе каких-то глупостей нафантазировал и теперь с ними борешься.

C>Что мешает привязать к обычному методу или переменной? Я не вижу что такого фундаментального дают свойства.


И почему, как ты думаешь, в бинах не привязались к обычному методу или переменной, а ввели кастрированные свойства и привязались к ним?

C>Ну так свойства реализованы как методы — они НЕ являются самостоятельными сущностями (рекомендую посмотреть на базовый класс PropertyInfo).


Классы — это тоже набор методов и полей. Они по твоему тоже не являются самостоятельными сущностями? Поля — это наборы байт, методы — последовательность команд, и что теперь?
Если нам не помогут, то мы тоже никого не пощадим.
Re[56]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 07.06.06 13:22
Оценка:
IT wrote:
>> > RTFM PropertyInfo.
> C>RTFM java.beans.BeanInfo.
> Видимо для начала тебя надо попросить дать определение что ты понимаешь
> под "нормальное свойство". Боюсь, ты себе каких-то глупостей
> нафантазировал и теперь с ними борешься.
Чтобы свойство по поведению не отличалось от обычной переменной.

> C>Что мешает привязать к обычному методу или переменной? Я не вижу что

> такого фундаментального дают свойства.
> И почему, как ты думаешь, в бинах не привязались к обычному методу или
> переменной, а ввели кастрированные свойства и привязались к ним?
В мире Java различные системы привязки не особо используются и
приветствуются, в нормальных системах типа OGNL или JXpath можно
вызывать любые методы. Да и просто система get/set/is оказалась неплохим
соглашением об именах.

Хотя есть исключения — в идиотском JSF слизанном с ASP.NET (вот уж
действительно "death by committee") можно только get/set/is-методы
использовать.

> C>Ну так свойства реализованы как методы — они НЕ являются

> самостоятельными сущностями (рекомендую посмотреть на базовый класс
> PropertyInfo).
> Классы — это тоже набор методов и полей. Они по твоему тоже не являются
> самостоятельными сущностями?
В .NET — являются, так как методы и поля без классов не существуют

А вот в каком-нибудь Lisp'е — не являются.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[55]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 07.06.06 13:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Вот насчёт public поля я бы с тобой ещё согласился. В BLToolkit я именно

>> так и сделал. А баиндиться к методам?... Сэр редкостный извращенец
C>Ну так свойства реализованы как методы — они НЕ являются
C>самостоятельными сущностями (рекомендую посмотреть на базовый класс
C>PropertyInfo).

Ну посмотрел и? Баазовый клас для PropertyInfo это MemberInfo и? От него же наследуются и все остальные *Info (взято с MSDN):

    System.Reflection.MemberInfo
     System.Reflection.EventInfo 
     System.Reflection.FieldInfo 
     System.Reflection.MethodBase 
     System.Reflection.PropertyInfo 
     System.Type

И?
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[57]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 07.06.06 13:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Видимо для начала тебя надо попросить дать определение что ты понимаешь под "нормальное свойство". Боюсь, ты себе каких-то глупостей нафантазировал и теперь с ними борешься.

C>Чтобы свойство по поведению не отличалось от обычной переменной.

Ты сам то хоть понял, что только что сказал? "Он же памятник, кто его посадит?" (c). Это же свойство, а то переменная. Два разных человека. Почему тебе не хочется, например, чтобы интерфейс по поведению не отличался бы от класса. Тогда интерфейс можно было бы наследовать от класса! Офигенная идея! Обошли бы ограничение по множественному наследованию

C>В мире Java различные системы привязки не особо используются и приветствуются


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

>> Классы — это тоже набор методов и полей. Они по твоему тоже не являются самостоятельными сущностями?

C>В .NET — являются, так как методы и поля без классов не существуют
C>А вот в каком-нибудь Lisp'е — не являются.

Потому что .NET — это ОО среда. Ещё она компонентная, поэтому в ней совершенно логично смотрятся свойства как самостоятельная сущность, а не кастрированная симуляция.
Если нам не помогут, то мы тоже никого не пощадим.
Re[56]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 07.06.06 14:06
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:

C>>(рекомендую посмотреть на базовый класс PropertyInfo).


ДА>Ну посмотрел и?


Когда аргументы кончаются, а признаваться в содеянном не хочется, то и начинаются вот такие отфонарные рекомендации
Если нам не помогут, то мы тоже никого не пощадим.
Re[57]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 07.06.06 14:11
Оценка:
Здравствуйте, IT, Вы писали:

C>>>(рекомендую посмотреть на базовый класс PropertyInfo).

ДА>>Ну посмотрел и?
IT>Когда аргументы кончаются, а признаваться в содеянном не хочется, то и начинаются вот такие отфонарные рекомендации

Ну я думал может там чего интересного написано. Пошел MSDN перерывать... а там и нет ничего интересного... Вот спросил может человек угледел там чего-нибуть что я проглядел...
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[56]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.06.06 14:27
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Свойство в .NET — это самостоятельная сущность, доступная через рефлекшин со всеми вытекающими последствиями.


ANS>>Я так и не понял, свойство можно передать в метод как параметр/вернуть из, или нет?


IT>Значение свойства? Конечно можно. Или ты о чём то другом?


Да, это был дурацкий вопрос. Просто для меня "самостоятельная сущность" это только "first class object". Я забыл, что в С# нельзя и поля куда-то передавать.

Что касается полезности свойств, как таковых, то хочу заметить, что в C++ они имели вполне конкретный смысл — доступ напрямую, минуя вызов метода. В нонешнем виде для программистов в свойствах особого смысла нет. Возможно, для гуй-дизайнера и есть некая сомнительная польза, но как по мне, это должно решатся на уровне атрибутов. По крайней мере, возможностей это даёт намного больше, чем использование "свойств".
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[57]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.06.06 14:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Что касается полезности свойств, как таковых, то хочу заметить, что в C++ они имели вполне конкретный смысл — доступ напрямую, минуя вызов метода. В нонешнем виде для программистов в свойствах особого смысла нет. Возможно, для гуй-дизайнера и есть некая сомнительная польза, но как по мне, это должно решатся на уровне атрибутов. По крайней мере, возможностей это даёт намного больше, чем использование "свойств".


Кстати, в документике, ссылку на который привел alexeiz
Автор: alexeiz
Дата: 03.06.06
, есть интересный абзац:

Properties are just syntactic saccharine for getter and setter member functions for individual fields.
C++ experts have spent years trying to educate people NOT to use public data, to use member
functions instead, and now we propose to introduce something that looks just like public data? Do
we really want to try to teach people that public fields are still bad, but properties are good, even
though they look just the same from outside the class? Moreover, these public fields have side
effects!


Было бы любопытно услышать, что по этому поводу думают сторонники properties.



2moderators: может пора дисскусию о свойствах из этой темы в отдельную выделить? Например, как раз с сообщения alexeiz-а.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[57]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 07.06.06 14:48
Оценка: +2
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Что касается полезности свойств, как таковых, то хочу заметить, что в C++ они имели вполне конкретный смысл — доступ напрямую, минуя вызов метода.


Это как? И какие в C++ свойства?

ANS>В нонешнем виде для программистов в свойствах особого смысла нет. Возможно, для гуй-дизайнера и есть некая сомнительная польза, но как по мне, это должно решатся на уровне атрибутов. По крайней мере, возможностей это даёт намного больше, чем использование "свойств".


Атрибуты и свойства нельзя противопоставлять. Это вещи очень хорошо дополняющие друг друга.

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

Когда же я вижу
Edge edge = getEdge();
особенно в C# коде, то моему утончённому, я бы даже сказал музыкальному, кодовосприятию начинает становится плохо и хочется (простите мне мой французский) стошнить на это дерьмо.
Если нам не помогут, то мы тоже никого не пощадим.
Re[58]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 07.06.06 15:04
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Кстати, в документике, ссылку на который привел alexeiz
Автор: alexeiz
Дата: 03.06.06
, есть интересный абзац:

E>

E>Properties are just syntactic saccharine for getter and setter member functions for individual fields.
E>C++ experts have spent years trying to educate people NOT to use public data, to use member
E>functions instead, and now we propose to introduce something that looks just like public data? Do
E>we really want to try to teach people that public fields are still bad, but properties are good, even
E>though they look just the same from outside the class? Moreover, these public fields have side
E>effects!


E>Было бы любопытно услышать, что по этому поводу думают сторонники properties.

Демагогия обыкновенная. Такая "аргументация" в данном форуме очень частое явление. Особенно когда реальных аргументов нет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[56]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 07.06.06 15:55
Оценка:
Дьяченко Александр wrote:
> Ну посмотрел и? Баазовый клас для PropertyInfo это MemberInfo и? От него
> же наследуются и все остальные *Info (взято с MSDN):
> System.Reflection.MemberInfo
> System.Reflection.EventInfo
> System.Reflection.FieldInfo
> System.Reflection.MethodBase
> System.Reflection.PropertyInfo
> System.Type
> И?
Извиняюсь, я стормозил.

Почему-то заклинило, что PropertyInfo наследуется от MethodBase.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[57]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 07.06.06 16:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Извиняюсь, я стормозил.

C>Почему-то заклинило, что PropertyInfo наследуется от MethodBase.

Извенения приняты. Тут помоему уже всех потихоньку клинить начинает... Каждого на своем...
Давайте лучше
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[59]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.06.06 17:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Было бы любопытно услышать, что по этому поводу думают сторонники properties.

WH>Демагогия обыкновенная. Такая "аргументация" в данном форуме очень частое явление. Особенно когда реальных аргументов нет.

Такая "аргументация" в купе с "а мне удобно" здесь не менее частое явление.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.06.06 21:05
Оценка:
Здравствуйте, FR, Вы писали:

FR>Так по сравнениею с си С++ кораздо лучше в отношении типобезопасности.


А в попугаях я гораздо длиннее! (с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.06.06 22:06
Оценка: +1 :))
Здравствуйте, VladD2, Вы писали:

FR>>Так по сравнениею с си С++ кораздо лучше в отношении типобезопасности.

VD>А в попугаях я гораздо длиннее! (с)

Не подменяй тему!
<< Под музыку: Shocking Blue — Never Marry A Railroad Man >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[51]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 08.06.06 05:35
Оценка: +2 -1
Kluev,

LCR>>Так что out-параметры есть, просто их не сразу видно .


K>Ужос. Хорошая иллюстрация как под видом простого языка людям впаривается примитивный, в котором даже простые вещи приходится делать через задницу.


Да, Джава многословна, и это следствие дизайна языка. А основной стержень дизайна Джавы — максимальная, граничащая с дибилизмом, простота.

И это совсем необязательно недостаток.

В качестве контраста: вот C++ простой? Вряд ли, скорее наоборот. А примитивный? Скорее да, там даже нормальных лямбд и замыканий нет.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[57]: Tcl как обоснование ненужности поддержки компонентно
От: Трурль  
Дата: 08.06.06 05:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Классы — это тоже набор методов и полей. Они по твоему тоже не являются

>> самостоятельными сущностями?
C>В .NET — являются, так как методы и поля без классов не существуют

C>А вот в каком-нибудь Lisp'е — не являются.


Пример выбран крайне неудачно.
Re[58]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.06.06 06:44
Оценка: 1 (1) +1 :)
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>>Что касается полезности свойств, как таковых, то хочу заметить, что в C++ они имели вполне конкретный смысл — доступ напрямую, минуя вызов метода.


IT>Это как? И какие в C++ свойства?


Да, я имел ввиду не свойства, а доступ напрямую к полям объекта. Поскольку со временем оказалось, что это таки плохо, то придумали затычку в виде свойств.

ANS>>В нонешнем виде для программистов в свойствах особого смысла нет. Возможно, для гуй-дизайнера и есть некая сомнительная польза, но как по мне, это должно решатся на уровне атрибутов. По крайней мере, возможностей это даёт намного больше, чем использование "свойств".


IT>Атрибуты и свойства нельзя противопоставлять. Это вещи очень хорошо дополняющие друг друга.


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

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


Как по мне, то такую програму гораздо хуже и читать и писать. При написании постоянно нужно обращать внимание, что вызов некоторых методов идёт, как "method(aParam)", а других как "prop = aParam", а эфект один и тот же

Мне трудно даже вообразить глубину падения программиста, которому такое может нравиться

IT>Когда же я вижу
Edge edge = getEdge();
особенно в C# коде, то моему утончённому, я бы даже сказал музыкальному, кодовосприятию начинает становится плохо и хочется (простите мне мой французский) стошнить на это дерьмо.


По крайней мере сразу видно, что вызов может иметь побочные эфекты. При использовании свойств, может показаться что их нет "по-любому". Вот если бы чтение свойства гарантировано не имело побочных эфектов это было бы полезно, а так бессмысленное эстетство.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[59]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 08.06.06 07:52
Оценка: 4 (1) +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


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


ANS>Как по мне, то такую програму гораздо хуже и читать и писать. При написании постоянно нужно обращать внимание, что вызов некоторых методов идёт, как "method(aParam)", а других как "prop = aParam", а эфект один и тот же


ANS>Мне трудно даже вообразить глубину падения программиста, которому такое может нравиться


Ты программировал на C#? Когда начнёшь, то будешь использовать свойства, нравятся они тебе или нет.

Я ещё не разу не видел C# код, в котором вместо свойств сознательно были бы написаны get/set методы. В C# свойства есть, и с ними приходится жить. Причём вырабатывается следующие навыки: когда я вижу "obj.Color = something" или даже "obj.Count", то это автоматически обозначает свойство (хотя бы потому, что никаких публичных полей у класса не может быть), и никаких сомнений не возникает, что при этом вызывается get метод. (Кстати, я часто делаю ошибку, вставляя скобки в obj.Count(), так как мой основной язык всё таки C++) Внутри метода класса у нас принято писать "this.Color = something", потому что просто "Color = something" вызывает затруднения при чтении кода. А в таком коде как "for (int i = 0; i < list.Count; ++i)" ход мыслей примерно такой: "ага, Count — это на самом деле вызов get метода, но его можно делать внутри цикла, так как JIT сделает необходимые оптимизации".

Наверное, можно было бы отвлечься от постоянного выявления вызовов неявных методов. Но дело в том, что я привык сразу при написании кода представлять его алгоритмическую сложность. А такой подход заставляет думать "ага, 'mylist.Capacity = ...' — это не просто присваивание, а вызов метода, в котором может происходить что-то нетривиальное".

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

А вот с индексными свойствами ситуация в C# абсолютно аналогична operator[] в C++. Т.е. и в том и в другом случае точно представляешь, что происходят определённые дополнительные действия, а не просто доступ в массиве по индексу.
Re[60]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.06.06 09:16
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Ты программировал на C#? Когда начнёшь, то будешь использовать свойства, нравятся они тебе или нет.


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

A>Наверное, можно было бы отвлечься от постоянного выявления вызовов неявных методов. Но дело в том, что я привык сразу при написании кода представлять его алгоритмическую сложность. А такой подход заставляет думать "ага, 'mylist.Capacity = ...' — это не просто присваивание, а вызов метода, в котором может происходить что-то нетривиальное".


Блин, и это "простой" язык?

A>А вот с индексными свойствами ситуация в C# абсолютно аналогична operator[] в C++. Т.е. и в том и в другом случае точно представляешь, что происходят определённые дополнительные действия, а не просто доступ в массиве по индексу.


Я и не считаю С++ простым и непротиворечивым языком
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[58]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 08.06.06 10:25
Оценка:
Трурль wrote:
>> > Классы — это тоже набор методов и полей. Они по твоему тоже не являются
>> > самостоятельными сущностями?
> C>В .NET — являются, так как методы и поля без классов не существуют
> C>А вот *в каком-нибудь Lisp'е* — не являются.
> Пример выбран крайне неудачно.
Почему? В качестве примера см. CLOS.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Tcl как обоснование ненужности поддержки компонентно
От: vortex Украина  
Дата: 08.06.06 11:49
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Спасибо, мне эта ссылка на фиг не ппала. Ты дай ссылку на статью на русском. А то я там что-то ничего хорошего не нашел.


Хот я я в форте сильно, но сейчас читаю
Leo Brodie's "Thinking Forth" на английском с картинками
русский перевод с аски артом (cp866)
Основной акцент книги не на форт а на сам процес.

The Book

Thinking Forth is a book about the philosophy of problem solving and programming style, applied to the unique programming language Forth. Published first in 1984, it could be among the timeless classics of computer books, such as Fred Brooks' The Mythical Man-Month and Donald Knuth's The Art of Computer Programming.

Many software engineering principles discussed here have been rediscovered in eXtreme Programming, including (re)factoring, modularity, bottom-up and incremental design. Here you'll find all of those and more — such as the value of analysis and design — described in Leo Brodie's down-to-earth, humorous style, with illustrations, code examples, practical real life applications, illustrative cartoons, and interviews with Forth's inventor, Charles H. Moore as well as other Forth thinkers.

If you program in Forth, this is a must-read book. If you don't, the fundamental concepts are universal: Thinking Forth is meant for anyone interested in writing software to solve problems. The concepts go beyond Forth, but the simple beauty of Forth throws those concepts into stark relief.

So flip open the book, and read all about the philosophy of Forth, analysis, decomposition, problem solving, style and conventions, factoring, handling data, and minimizing control structures. But be prepared: you may not be able to put it down.

This book has been scanned, OCR'd, typeset in LaTeX, and brought back to print (and your monitor) by a collaborative effort under a Creative Commons license.

Re[59]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 08.06.06 12:11
Оценка:
Andrei N.Sobchuck,

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


ANS>Как по мне, то такую програму гораздо хуже и читать и писать. При написании постоянно нужно обращать внимание, что вызов некоторых методов идёт, как "method(aParam)", а других как "prop = aParam", а эфект один и тот же


ANS>Мне трудно даже вообразить глубину падения программиста, которому такое может нравиться


Странное возражение. Почему же тебя не напрягает, что
a + b

тоже является вызовом внутреннего метода Integer.__add__(int a, int b)? И в случае перегруженных операторов это будет вызов юзерского метода. Перегруженные операторы маст дай?

MyInteger.add(a, b);  // vs a + b
c.add(a);             // vs c + a

Имхо выглядит по-уродски, а вторая строка — вообще косяк с идеологической т.з.

Вообще, перегрузка операторов, свойства, параметризуемые типы, наследование и наконец, макросы (в некоторых языках) — это необходимые строительные блоки для внутреннего ДСЛ. И принципиально достижимое удобство данного ДСЛ (и как частный случай — АПИ) напрямую зависит от возможностей, предоставляемых языком.

Напоследок.
MyDoubleMatrix c = new MyDoubleMatrix();
int i, j, k;
for (i = 0; i < m; i++)
    for (j = 0; j < n; j++) {
        c.getAt(i, j).resetWith(0);
        for (k = 0; k < t; k++)
            c.setAt(i, j, Matrix.multiply(c.getAt(i, k), c.getAt(k, j));
    }
return c;

Словами этого не описать... Мало того, что выть хочется от одного вида, так ещё этот Matrix нужно подтачивать для случая:
1. другой размерности
2. другого типа элементов
3. дополнительной операции.
А если ещё и индексы нецелые (экземляры каких-нибудь классов), то я не смогу начать работу без предварительной блевни (изучаю корейский).

matrix<double> c; // typedef для vector< vector<T> >
int i, j, k;
for (i = 0; i < m; ++i)
    for (j = 0; j < n; ++j) {
        c[i ][j]  = 0;
        for (k = 0; k < t; ++k)
            c[i ][j] += a[i ][k] * b[k][j];
    }
return c;

Заметим, что n-мерные матрицы, другой тип элементов и другие операции хэндлятся элементарным образом.
И это всего-лишь перегрузка операторов (как частный случай макросов)!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[60]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.06.06 12:55
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>тоже является вызовом внутреннего метода Integer.__add__(int a, int b)? И в случае перегруженных операторов это будет вызов юзерского метода. Перегруженные операторы маст дай?


Ай-я-я. Давай не будем передёргивать. Речь не шла о какой-то перегрузке операторов. Меня они ни капельки не интересуют и не волнуют.

LCR>Вообще, перегрузка операторов, свойства, параметризуемые типы, наследование и наконец, макросы (в некоторых языках) — это необходимые строительные блоки для внутреннего ДСЛ.


Ты не мудри, ты пальцем покажи.

LCR>Напоследок.

LCR>
LCR>        c.getAt(i, j).resetWith(0);
LCR>


LCR>
LCR>        c[i ][j]  = 0;
LCR>


Это, типа, небольшое преувеличение?

LCR>Заметим, что n-мерные матрицы, другой тип элементов и другие операции хэндлятся элементарным образом.


Вопрос-уточнение: "c[i][j]" соответсвует "c.get(i).get(j)" или "c.get(i,j)"?

LCR>И это всего-лишь перегрузка операторов (как частный случай макросов)!


С концовкой ты ошибся, нужно было так: "Это демонстрация мощи макросов в частности и немерле в общем."
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: Gaperton http://gaperton.livejournal.com
Дата: 08.06.06 13:14
Оценка: +4
Здравствуйте, WolfHound, Вы писали:

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


FR>>Вот если брать именно мета, то forth вполне достойный конкурент Nemerle.

WH>Ну повтори на forth'е примеры из этой
Автор: WolfHound
Дата: 26.05.06
ветки. Посмотрим насколько они будут понятны.


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

Пример на форте будет, разумеется, гораздо проще и понятнее. Для человека, знающего оба языка, а не для любителей Немерле. Форт вообще прост как отбойный молоток. Если ты не знаешь форта и не понимаешь его — это не может быть записано в минус Форту. У него другие минусы.
Re[60]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 08.06.06 14:11
Оценка:
Lazy Cjow Rhrr wrote:
> Странное возражение. Почему же тебя не напрягает, что
> a + b
> тоже является вызовом внутреннего метода Integer.__add__(int a, int b)?
Э, нет. a+b — примитивная операция, которая имеет свою инструкцию в MS IL.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[61]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 08.06.06 16:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Э, нет. a+b — примитивная операция, которая имеет свою инструкцию в MS IL.


Которую можно всегда перегрузить для нужных типов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[62]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 08.06.06 20:34
Оценка:
IT wrote:
> C>Э, нет. a+b — примитивная операция, которая имеет свою инструкцию в MS IL.
> Которую можно всегда перегрузить для нужных типов.
Для других типов — это уже будет другая операция.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[61]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 09.06.06 05:52
Оценка:
Andrei N.Sobchuck,

LCR>>Вообще, перегрузка операторов, свойства, параметризуемые типы, наследование и наконец, макросы (в некоторых языках) — это необходимые строительные блоки для внутреннего ДСЛ.


ANS>Ты не мудри, ты пальцем покажи.


Свойства можно считать перегрузкой неявных операторов "взять значение" и "положить значение". Когда ты пишешь
a.x = 5;

то эту операцию можно мыслить как
a.x._set_( 5._get_() );

Вот мы эти неявные операторы _set_ и _get_ можем перегрузить для пользовательских классов.

Я возражал против этого:

ANS>При написании постоянно нужно обращать внимание, что вызов некоторых методов идёт, как "method(aParam)", а других как "prop = aParam", а эфект один и тот же


Из чего я делаю вывод, что "если присутствует вызов метода, то оно и должно выглядеть как вызов метода". С чем я категорически не согласен. Если все неявные вызовы методов писать в виде явных вызовов, то программа потеряет во всём, и я привёл соответствующий пример.

ANS>Это, типа, небольшое преувеличение?

Да ты знаешь, реальность ещё более интересна:
    BigInteger bi1 = new BigInteger("1234567890123456890");
    BigInteger bi2 = BigInteger.valueOf(123L);
    bi1 = bi1.add(bi2);
    bi1 = bi1.multiply(bi2);
    bi1 = bi1.subtract(bi2);
    bi1 = bi1.divide(bi2);
    bi1 = bi1.negate();
    int exponent = 2;
    bi1 = bi1.pow(exponent);

Возмьмём теперь какой-нибудь целочисленный алгоритм, и перепишем с использованием BigInteger

LCR>>И это всего-лишь перегрузка операторов (как частный случай макросов)!

ANS>С концовкой ты ошибся, нужно было так: "Это демонстрация мощи макросов в частности и немерле в общем."
Про немерле я даже не заикался. Поскольку мы здесь говорим о шарпе с джавой, то я просто ограничился замечанием того, что перегрузка является частным случаем.

И вообще мне больше нравится подход Лиспа и J .
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[61]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 09.06.06 06:32
Оценка:
Cyberax,

>> Странное возражение. Почему же тебя не напрягает, что

>> a + b
>> тоже является вызовом внутреннего метода Integer.__add__(int a, int b)?
C>Э, нет. a+b — примитивная операция, которая имеет свою инструкцию в MS IL.

Упс. В этом моменте ты прав.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[62]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 06:52
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Свойства можно считать перегрузкой неявных операторов "взять значение" и "положить значение". Когда ты пишешь

LCR>
LCR>a.x = 5;
LCR>

LCR>то эту операцию можно мыслить как
LCR>
LCR>a.x._set_( 5._get_() );
LCR>


Можно, но не нужно. А если именно нужно, то тяжело вам там в С#. Это во-первых. Во-вторых, мне эти аналогии кажутся притянутыми за уши. По-этому сформулируй правило, когда используются методы, а когда свойства. Например:
* Свойства используются вместо методов с одним параметром

И когда сформулируеш правило так же мне объясни, если у меня есть метод который возвращает строку — конкатенированое значение полей класса — то это должно быть ro свойство, обычный метод, некий унарный оператор? С обоснованием.

LCR>Я возражал против этого:

LCR>

ANS>>При написании постоянно нужно обращать внимание, что вызов некоторых методов идёт, как "method(aParam)", а других как "prop = aParam", а эфект один и тот же


Я обратил внимание на то, что меня реально раздражало.

LCR>Из чего я делаю вывод, что "если присутствует вызов метода, то оно и должно выглядеть как вызов метода". С чем я категорически не

LCR>согласен. Если все неявные вызовы методов писать в виде явных вызовов, то программа потеряет во всём, и я привёл соответствующий пример.

ST живёт и ничего. А пример был так себе, не убедительно Вот с BigInteger более жизненно. Увы, это всего лиш один случай.
И с операторами есть один момент. Арифметические операторы не мутирующие. Но, компилятор, увы, гарантий никаких не даёт. По-этому, для операторов, по крайней мере, можно сформулировать правило: их применять нельзя, если у метода есть побочные эфекты. Жду правило для свойств.

LCR>>>И это всего-лишь перегрузка операторов (как частный случай макросов)!

ANS>>С концовкой ты ошибся, нужно было так: "Это демонстрация мощи макросов в частности и немерле в общем."
LCR>Про немерле я даже не заикался. Поскольку мы здесь говорим о шарпе с джавой, то я просто ограничился замечанием того, что перегрузка является частным случаем.

(см. свой первый комент в этом абзаце) что за макросы в C#? А к java vs. C# это вы свели. Меня раздражуют свойства и в C# и в COM Просто вдруг оказалось, что при всех недостатках, Java это еще не самый тяжолый случай.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[63]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 09.06.06 08:01
Оценка: 4 (1)
Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>Можно, но не нужно. А если именно нужно, то тяжело вам там в С#. Это во-первых. Во-вторых, мне эти аналогии кажутся притянутыми за уши. По-этому сформулируй правило, когда используются методы, а когда свойства. Например:

ANS>* Свойства используются вместо методов с одним параметром

В D очень интересно свойства сделаны. Чистейший синтаксический сахар над функциями без аргументов и такой же функцией с одним аргументом и возвращающей тот же тип что и аргумент(если одной из функций нет, то будет или realonly или writeonly свойство):
struct Foo
{
    int data() { return m_data; }    // read property

    int data(int value) { return m_data = value; } // write property

  private:
    int m_data;
}


int test()
{
    Foo f;

    f.data = 3;        // same as f.data(3);
    return f.data + 3;    // same as return f.data() + 3;
}
Re[64]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 08:42
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>В D очень интересно свойства сделаны. Чистейший синтаксический сахар над функциями без аргументов и такой же функцией с одним аргументом и возвращающей тот же тип что и аргумент(если одной из функций нет, то будет или realonly или writeonly свойство):


Это действительно интересно, но не более Типа, у многих есть анонимные функции, а сантехники изголились и сделали целые анонимные классы. Решение интересное, но назвать его удачным язык не поварачивается.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[63]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 09.06.06 09:03
Оценка: -1
Andrei N.Sobchuck,

LCR>>Свойства можно считать перегрузкой неявных операторов "взять значение" и "положить значение". Когда ты пишешь

LCR>>
LCR>>a.x = 5;
LCR>>

LCR>>то эту операцию можно мыслить как
LCR>>
LCR>>a.x._set_( 5._get_() );
LCR>>

ANS>Можно, но не нужно. А если именно нужно, то тяжело вам там в С#. Это во-первых.
Нет, тяжело нам там в Java, где свойства есть только в качестве соглашений. В C# ситуация полегче.

ANS> Во-вторых, мне эти аналогии кажутся притянутыми за уши. По-этому сформулируй правило, когда используются методы, а когда свойства. Например:

ANS>* Свойства используются вместо методов с одним параметром
ANS>И когда сформулируеш правило так же мне объясни, если у меня есть метод который возвращает строку — конкатенированое значение полей класса — то это должно быть ro свойство, обычный метод, некий унарный оператор? С обоснованием.
ANS>... И с операторами есть один момент. Арифметические операторы не мутирующие. Но, компилятор, увы, гарантий никаких не даёт. По-этому, для операторов, по крайней мере, можно сформулировать правило: их применять нельзя, если у метода есть побочные эфекты. Жду правило для свойств.

Оки-доки. Решение о том, будет ли "XXX" свойством или нет должно определяться на основании предполагаемого использования класса.

Моё видение свойств: чистый (т.е. side-effect free) эффективный доступ к данным.

Следствия:
В свойствах нежелателен доступ к несвязанным со этим свойством данных.
В свойствах нежелательно выполнение длительных операций.
В свойствах не рекомендуется броски исключений.

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

LCR>Если все неявные вызовы методов писать в виде явных вызовов, то программа потеряет во всём, и я привёл соответствующий пример.

ANS>ST живёт и ничего. А пример был так себе, не убедительно Вот с BigInteger более жизненно. Увы, это всего лишь один случай.
Ну можно ещё написать MyDouble1, где не будет арифметических нулей, или MyDouble2, где не будет ошибок округления при выполнении арифметических операций, или MyDouble3, где числа 0.9999999.. и 1 будут представлять одно и то же число и т.п. Так что не согласен насчёт одного случая. Ну и конечно nth-мерный массив всегда

Да кста, не мог бы ты привести пример как ST живёт, и как там "a (+|-|*|%) b" в виде вызова метода поживает?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[64]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 09:57
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Нет, тяжело нам там в Java, где свойства есть только в качестве соглашений. В C# ситуация полегче.


Это одна из тех немногих вещей, что мне нравится в Жабке

LCR>Оки-доки. Решение о том, будет ли "XXX" свойством или нет должно определяться на основании предполагаемого использования класса.


LCR>Моё видение свойств: чистый (т.е. side-effect free) эффективный доступ к данным.


LCR>Следствия:

LCR>В свойствах нежелателен доступ к несвязанным со этим свойством данных.

??? То есть свойство всегда должно быть связано с одним полем?

LCR>В свойствах нежелательно выполнение длительных операций.


fire event можно делать или нельзя?

LCR>В свойствах не рекомендуется броски исключений.


Хм. А о (не)валидности как сигнализировать?

LCR>Как только ни одно из следствий не выполняется, то это свойство должно быть рассмотрено как кандидат для конвертации в метод.


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

ЗЫ Подключайтесь, господа. Сформулируйте, в конце концов, какая суть свойства (я не имею в виду определение типа "свойство это нечто у чего есть либо геттер, либо сеттер, либо и то и то"). Кстати, когда-то видел упоминание того, что C# легко с COM работает благодаря свойствам. Работа с легаси — согласен, хорошая причина. Но хотелось бы более "современного" объяснения.

ЗЫЫ Видел еще одно обяснение: если использовать аксесоры, то возникает отличие в синтаксисе. То есть внутри методов класса используется синтаксис доступа к полям, а с наружи — вызов методов-аксесоров. А это, типа, неудобно. А как по мне, то это самое оно. Так и должно быть.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[64]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 09:57
Оценка: 1 (1)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Да кста, не мог бы ты привести пример как ST живёт, и как там "a (+|-|*|%) b" в виде вызова метода поживает?


А эти значки это имена сообщений и есть. В ST есть 3 типа сообщений:
* унарные — не имеют параметров, напр. 3 sqrt — отправка числу 3 сообщения #sqrt.
* бинарные — с хитрозначками, всегда имеют ровно один параметр, зачастую в диалектах присутствуют различные ограничения на имена таких сообщений, так, в VisualWorks максимальная ддлина бинарного сообщения — два значка. Пример: 3 + 4 — отправка числу 3 сообщения #+ с одним аргументом — 4, или 'qwerty' , 'asdfg' — отправка строке (коллекции) 'qwerty' сообщения #, с аргументом 'asdfg', результат выполнения метода — конкатенация.
* ключевые — любое количество аргументов. Напр. aDictionary at: x — отправка сообщения #at: с одним аргументом x, aDictionary at: x ifAbsentPut: [Object new] — отправка сообщения #at:ifAbsentPut: с двумя аргументами.

Первым стоит всегда получатель сообщения, все методы всегда возвращают значение, если возвращаемое значение не указано, то нейвно возвращается self (типа this). Бинарные сообщения это именно сообщения, а не операторы, и никаких спец приоритетов у них нет. То есть a+b*c это (a+b)*c. Приоритеты разные только у разных типов сообщений — унарные наивысший приоритет, потом бинарные, и у ключевых наинизший. Круглые скобки традиционно используются для управления порядком вычисления.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[65]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 09.06.06 10:19
Оценка:
Andrei N.Sobchuck,

LCR>>Моё видение свойств: чистый (т.е. side-effect free) эффективный доступ к данным.


LCR>>Следствия:

LCR>>В свойствах нежелателен доступ к несвязанным со этим свойством данных.
ANS>??? То есть свойство всегда должно быть связано с одним полем?
Свойство может быть связано со множеством полей.

LCR>>В свойствах нежелательно выполнение длительных операций.

ANS>fire event можно делать или нельзя?
Зависит от. Обычно можно.

LCR>>В свойствах не рекомендуются броски исключений.

ANS>Хм. А о (не)валидности как сигнализировать?
Если ситуация с невалидными данными — достаточно редка, то можно использовать свойство. Если данный прилетают извне, то валидацию следует проводить в методе.

Вообще, в этом случае работает правило: Данные извне должны проверяться на корректность. Как только они попали внутрь системы, они должны быть корректными, и внутреннее мясо работает в предположении, что данные корректны.

LCR>>Как только ни одно из следствий не выполняется, то это свойство должно быть рассмотрено как кандидат для конвертации в метод.


ANS>маловато будет.

Практически больше и не надо.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[66]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 10:45
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>>>В свойствах нежелателен доступ к несвязанным со этим свойством данных.

ANS>>??? То есть свойство всегда должно быть связано с одним полем?
LCR>Свойство может быть связано со множеством полей.

Как это увязывается с твоим начальным утверждением? Как устанавливается связанность со свойством?

LCR>>>В свойствах нежелательно выполнение длительных операций.

ANS>>fire event можно делать или нельзя?
LCR>Зависит от. Обычно можно.

Но время работы то будет неопределено.

LCR>>>В свойствах не рекомендуются броски исключений.

ANS>>Хм. А о (не)валидности как сигнализировать?
LCR>Если ситуация с невалидными данными — достаточно редка, то можно использовать свойство. Если данный прилетают извне, то валидацию следует проводить в методе.

А почему не вызывать метод валидации из свойства?

ANS>>маловато будет.

LCR>Практически больше и не надо.

"Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на объяснении сути свойств. А то пока я только понял, что у них синтаксис удобный, а отчего, почему — не ясно.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[66]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 09.06.06 10:47
Оценка: +1
Lazy Cjow Rhrr wrote:
> LCR>>Следствия:
> LCR>>В свойствах нежелателен доступ к несвязанным со этим свойством данных.
> ANS>??? То есть свойство всегда должно быть связано с одним полем?
> Свойство может быть связано со множеством полей.
Как? Если это "вычисляемое свойство" — делаем его методом.

> LCR>>В свойствах нежелательно выполнение длительных операций.

> ANS>fire event можно делать или нельзя?
> Зависит от. Обычно можно.
side-effect, причем нехилый.

Иногда приводит к трудноуловимым багам, если обработчики событий что-то
меняют в состоянии объекта.

Пример:
Iterator i=someObject.iterate();
while(i.hasNext())
{
    SomeAnotherObject o=(SomeAnotherObject)i.next();
    o->setSomething(1234);
}

И иногда получали в зубы ConcurrentModificationException так как
обработчик setSomething вызывал notify, которое обрабатывалось в совсем
левом модуле и меняло коллекцию во время итерации.

Поэтому лично мне такая автоматика очень не нравится — совершенно
невозможно становится понять что с чем связано.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 09.06.06 11:15
Оценка: +1
Andrei N.Sobchuck wrote:

> "Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на

> объяснении сути свойств. А то пока я только понял, что у них синтаксис
> удобный, а отчего, почему — не ясно.
Объясняю, свойства — сокращение записи "obj.getValue()" до "obj.value" или "obj.setValue(val)" до "obj.value = val".
Больше ничего.
Для чего это так необходимо — не знаю, некоторым так нравится.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[65]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 09.06.06 14:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ЗЫ Подключайтесь, господа. Сформулируйте, в конце концов, какая суть свойства (я не имею в виду определение типа "свойство это нечто у чего есть либо геттер, либо сеттер, либо и то и то"). Кстати, когда-то видел упоминание того, что C# легко с COM работает благодаря свойствам. Работа с легаси — согласен, хорошая причина. Но хотелось бы более "современного" объяснения.


Сколько понаписали не лень? (Это ко всем а не к вам персонально)

Далее по делу:
  1. Свойство это не просто 2 метода — это концептуально более широкое понятие, т.е. не все можно/удобно определять на уровне методов, есть вещи которые относяться целиком к свойству, о чем почему-то никто не упомянул. Например такие аттрибуты, как BrowsableAttribute, DefaultValueAttribute, DesignerSerializationVisibilityAttribute, CategoryAttribute, DescriptionAttribute (это пришедшие в голову прямо сейчас, к чему их писать к Get или к Set, а если нет Set или того хлеще нет Get тогда что?)
  2. Посмотрите в сторону BLToolkit вот где свойство выступает именно как единая концептуальная единица (Мапинг и вещи с ним связанные). Пытаться выразить это без понятия свойства как концептуальной единицы просто застрелиться.
  3. Вобщем под свойство попадает почти все что чтение/установка внутриннего состояния обьекта. Всякие туманные преобразования чего-либо в нечто другое это методы (даже если при этом изменяется внутреннее состояние обекта).
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[66]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 09.06.06 15:02
Оценка: 1 (1)
Дьяченко Александр wrote:
> 1. Свойство это не просто 2 метода — это концептуально более широкое
> понятие, т.е. не все можно/удобно определять на уровне методов,
> есть вещи которые относяться целиком к свойству, о чем почему-то
> никто не упомянул. Например такие аттрибуты, как
> BrowsableAttribute, DefaultValueAttribute,
> DesignerSerializationVisibilityAttribute, CategoryAttribute,
> DescriptionAttribute (это пришедшие в голову прямо сейчас, к чему
> их писать к Get или к Set, а если нет Set или того хлеще нет Get
> тогда что?)
К _полям_ класса! Или к get/set-методам для дизайнеров.

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

Например, предположим у нас есть объект с тремя свойствами:
1. Значение
2. Процент.
3. Результат.
Они связаны отношением "Результат"="Процент"*"Значение"/100

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

Как хорошие программисты, мы добавляем валидацию — если процент равен
нолю, то при изменении результата кидаем исключение (так как имеем
деление на ноль).

Внимание вопрос! Что произойдет, если при сериализации восстановится
сначала поле с процентом?

> 2. Посмотрите в сторону BLToolkit вот где свойство выступает именно

> как единая концептуальная единица (Мапинг и вещи с ним связанные).
> Пытаться выразить это без понятия свойства как концептуальной
> единицы просто застрелиться.
Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно живут.

> 3. Вобщем под свойство попадает почти все что чтение/установка

> внутриннего состояния обьекта.
Проблема в том, что любители свойств используют их для достижения
side-effect'ов. Например, запись в свойство изменяет значение поля на форме.

Свойства хороши только если они не изменяют инвариант объекта. Но вот
только оказывается, что ради этого не имеет смысла городить огород, а
можно использовать get/set-методы.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 09.06.06 15:04
Оценка:
Cyberax wrote:
> Внимание вопрос! Что произойдет, если при сериализации восстановится
> сначала поле с процентом?
Очепятка, читать как "поле с результатом".
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 09.06.06 15:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Дьяченко Александр wrote:

>> 1. Свойство это не просто 2 метода — это концептуально более широкое
>> понятие, т.е. не все можно/удобно определять на уровне методов,
>> есть вещи которые относяться целиком к свойству, о чем почему-то
>> никто не упомянул. Например такие аттрибуты, как
>> BrowsableAttribute, DefaultValueAttribute,
>> DesignerSerializationVisibilityAttribute, CategoryAttribute,
>> DescriptionAttribute (это пришедшие в голову прямо сейчас, к чему
>> их писать к Get или к Set, а если нет Set или того хлеще нет Get
>> тогда что?)
C>К _полям_ класса! Или к get/set-методам для дизайнеров.

Ну допустим DefaultValueAttribute его к чему к get или к set методу?

C>Сериализация работает с графом объектов, и с ее точки зрения объекты

C>рассматриваются как просто данные. Попытки добавить туда поведение дадут
C>только минусы.

Граф еще построить надо.

C>Например, предположим у нас есть объект с тремя свойствами:

C>1. Значение
C>2. Процент.
C>3. Результат.
C>Они связаны отношением "Результат"="Процент"*"Значение"/100

C>Если мы меняем результат, то автоматически пересчитываются проценты,

C>если меняем проценты, то пересчитывается результат и т.п. Представим,
C>что это сделано в виде свойств.

C>Как хорошие программисты, мы добавляем валидацию — если процент равен

C>нолю, то при изменении результата кидаем исключение (так как имеем
C>деление на ноль).

C>Внимание вопрос! Что произойдет, если при сериализации восстановится

C>сначала поле с процентом?

Ну есть несколько вариантов:
  1. Сериализовать только 2 из 3 — "Процент" и "Значение" (я так и зделал бы).
  2. Сделать методы., типа Begin/End которые отключают проверки.
  3. Осуществлять присвоение только в случае другого значения (обычно так и делается). Т.е.:
        public double Result
        {
            get { return _result; }
            set
            {
                if (_result != value)
                {
                    // Тут все остально (проверки, события и т.д.)
                }
            }
        }

>> 2. Посмотрите в сторону BLToolkit вот где свойство выступает именно

>> как единая концептуальная единица (Мапинг и вещи с ним связанные).
>> Пытаться выразить это без понятия свойства как концептуальной
>> единицы просто застрелиться.
C>Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно живут.

Пусть живут дальше . Ктомуже почти уверен что свойства как концепция там тоже есть, может она не выражается на уровне языка, но тем не менее на уровне соглашения наверняка есть (далее обсуждение по этому направлению попрошу не продолжать, так как всеравно яву знаю крайне поверхностно и про iBatis'а, Hibernate (и даже EJB CMP) вобще знать не знаю), NHibernate смотрел один раз и то с год назад и очень поверхностно, поэтому продолжать обсуждение в этом направлении тяжело.

>> 3. Вобщем под свойство попадает почти все что чтение/установка

>> внутриннего состояния обьекта.
C>Проблема в том, что любители свойств используют их для достижения
C>side-effect'ов. Например, запись в свойство изменяет значение поля на форме.

Ну использовать через задницу можно почти все .

C>Свойства хороши только если они не изменяют инвариант объекта. Но вот

C>только оказывается, что ради этого не имеет смысла городить огород, а
C>можно использовать get/set-методы.

К томуже объединяя в свойство 2 метода мы автоматом снижаем концептуальную слложность в 2 раза (2 метода -> 1 свойство) вот.
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[68]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 09.06.06 15:59
Оценка:
Дьяченко Александр wrote:
> C>К _полям_ класса! Или к get/set-методам для дизайнеров.
> Ну допустим DefaultValueAttribute его к чему к get или к set методу?
К полю. А вообще, для defval придуманы были конструкторы (в том числе и
анонимные).

> C>Сериализация работает с графом объектов, и с ее точки зрения объекты

> C>рассматриваются как просто данные. Попытки добавить туда поведение дадут
> C>только минусы.
> Граф еще построить надо.
Для постройки свойства не нужны. Достаточно полей (только некоторые поля
надо помечать как transient).

> Ну есть несколько вариантов:

> 1. Сериализовать только 2 из 3 — "Процент" и "Значение" (я так и
> зделал бы).
В этом примере все просто — а в более сложных случаях получается
сложнее. Особенно когда нельзя (или трудоемко) четко разделять на
вычислямые данные и исходные.

> 2. Сделать методы., типа Begin/End которые отключают проверки.

И получаем взрывы в runtime, если что-то не так сработает.

> 3. Осуществлять присвоение только в случае другого значения (обычно

> так и делается). Т.е.:
Ага, только тогда теряем гарантию семантической целостности графа. Тоже
неприятно.

> C>Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно

> живут.
> Пусть живут дальше . Ктомуже почти уверен что свойства как концепция там
> тоже есть, может она не выражается на уровне языка, но тем не менее на
> уровне соглашения наверняка есть (далее обсуждение по этому направлению
> попрошу не продолжать, так как всеравно яву знаю крайне поверхностно и
> про iBatis'а, Hibernate (и даже EJB CMP) вобще знать не знаю)
В Java есть простое соглашение — для доступа к данным используются
методы без параметра с префиксом "get" (или "is" для булевских типов),
для присвоения — методы с префиксом "set" и одним параметром.

Почти все известные мне системы в Java замечательно могут работать с
любыми именами методов (за исключением уродцев типа JSF).

> C>Проблема в том, что любители свойств используют их для достижения

> C>side-effect'ов. Например, запись в свойство изменяет значение поля на
> форме.
> Ну использовать через задницу можно почти все .
А если это "что-то" специально предназначалось для такого использования?

> C>Свойства хороши только если они не изменяют инвариант объекта. Но вот

> C>только оказывается, что ради этого не имеет смысла городить огород, а
> C>можно использовать get/set-методы.
> К томуже объединяя в свойство 2 метода мы автоматом снижаем
> концептуальную слложность в 2 раза (2 метода -> 1 свойство) вот.
Концепетуальную сложность мы, наоборот, увеличиваем. Так как появляются
два типа синтаксически одинаковых, но семантически неэквивалентных
конструкций.

А уменьшаем мы только синтаксический оверхед (сахарком посыпаем код).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[69]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 16:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А уменьшаем мы только синтаксический оверхед (сахарком посыпаем код).


Настолько незначительно, что даже уменьшение оверхеда очень спорно.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[65]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 09.06.06 16:04
Оценка: +1 -1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ЗЫ Подключайтесь, господа. Сформулируйте, в конце концов, какая суть свойства (я не имею в виду определение типа "свойство это нечто у чего есть либо геттер, либо сеттер, либо и то и то").


Видишь ли какое дело? Ты ищешь эту самую суть в другом месте. Ты пытаешься найти разницу в использовании геттера и метода без параметров, не можешь её найти и объявляешь свойства бесполезной фенькой. А меня, например, прежде всего интересует синтаксическая составляющая. Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля, а не метода без параметров. Объяснять и доказывать в данном случае что-либо бесполезно. Я уже пробовал. На прошлом проекте мне довелось работать с джавщиками, они все свойства объявляли по привычке как методы. Когда я сделал замечание, то мы долго смотрели друг на друга как идиотов. Я не мог смотреть без слёз на этот код, они апеллировали как и ты тем, что не видят принципиальной разницы. Остались каждый при своём, привычка и предпочтения всё же страшная сила.

Так что доказывать что-то тебе — это бесполезное занятие. Ты сам должен это прочувствовать. Я прочувствовал.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 09.06.06 16:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Внимание вопрос! Что произойдет, если при сериализации восстановится сначала поле с процентом?


Сериализация (если ты о сериализации) восстанавливает значения переменных не вызывая никакого кода. Так что ничего страшного не случится.

>> 2. Посмотрите в сторону BLToolkit вот где свойство выступает именно

>> как единая концептуальная единица (Мапинг и вещи с ним связанные).
>> Пытаться выразить это без понятия свойства как концептуальной
>> единицы просто застрелиться.
C>Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно живут.

В BLToolkit тоже можно без свойств. Публичные поля вполне подойдут.

C>Проблема в том, что любители свойств используют их для достижения side-effect'ов. Например, запись в свойство изменяет значение поля на форме.


Я тебе даже больше скажу. Большие любители свойств доходят до того, что изменение свойства на форме меняет саму форму, как то скрывает контролы, дизэйблит/энейблит поля. Называется это — ability to reuse UI logic. Вещь по своей сути без копипейста трудно достижимая.

C>Свойства хороши только если они не изменяют инвариант объекта. Но вот только оказывается, что ради этого не имеет смысла городить огород, а можно использовать get/set-методы.


Да ладно тебе фантазёрствовать. Я уже 4 года как изменяю инварианты и живу не тужу.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[66]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 16:19
Оценка:
Здравствуйте, IT, Вы писали:

IT> Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля


Блин, ты говориш "есть поле", а откуда оно взялось? С чего ты взял, что это именно поле? Стандарт кодирования у вас, что говорит?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[69]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 09.06.06 16:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>К _полям_ класса! Или к get/set-методам для дизайнеров.

>> Ну допустим DefaultValueAttribute его к чему к get или к set методу?
C>К полю. А вообще, для defval придуманы были конструкторы (в том числе и
C>анонимные).

Ну к полю это еще туда сюда (Дизайнер должен сам догадываться к которому полю, или опять соглашение?). А с конструктором это вобще не катит — например класc Color у каждого Control-а несколько разных Color-ов и че в конструкторе?

>> C>Сериализация работает с графом объектов, и с ее точки зрения объекты

>> C>рассматриваются как просто данные. Попытки добавить туда поведение дадут
>> C>только минусы.
>> Граф еще построить надо.
C>Для постройки свойства не нужны. Достаточно полей (только некоторые поля
C>надо помечать как transient).

>> Ну есть несколько вариантов:

>> 1. Сериализовать только 2 из 3 — "Процент" и "Значение" (я так и
>> зделал бы).
C>В этом примере все просто — а в более сложных случаях получается
C>сложнее. Особенно когда нельзя (или трудоемко) четко разделять на
C>вычислямые данные и исходные.

Пример нарисуешь? А то у меня че-то не приходит в голову ничего.

>> 2. Сделать методы., типа Begin/End которые отключают проверки.

C>И получаем взрывы в runtime, если что-то не так сработает.

Я не говорил что это лучший вариант. Но он есть.

>> 3. Осуществлять присвоение только в случае другого значения (обычно

>> так и делается). Т.е.:
C>Ага, только тогда теряем гарантию семантической целостности графа. Тоже
C>неприятно.

В смысле? Нафига че-то делать если там и так тоже самое значение?

C>В Java есть простое соглашение — для доступа к данным используются

C>методы без параметра с префиксом "get" (или "is" для булевских типов),
C>для присвоения — методы с префиксом "set" и одним параметром.

Я же говорил что как концепция свойство все равно есть. Плюс такое раздвоение усложняет рефакторинг. Или ты против отображения этой концепции в синтаксисе языка?

>> C>Проблема в том, что любители свойств используют их для достижения

>> C>side-effect'ов. Например, запись в свойство изменяет значение поля на
>> форме.
>> Ну использовать через задницу можно почти все .
C>А если это "что-то" специально предназначалось для такого использования?

В смысле?

>> C>Свойства хороши только если они не изменяют инвариант объекта. Но вот

>> C>только оказывается, что ради этого не имеет смысла городить огород, а
>> C>можно использовать get/set-методы.
>> К томуже объединяя в свойство 2 метода мы автоматом снижаем
>> концептуальную слложность в 2 раза (2 метода -> 1 свойство) вот.
C>Концепетуальную сложность мы, наоборот, увеличиваем. Так как появляются
C>два типа синтаксически одинаковых, но семантически неэквивалентных
C>конструкций.

В смысле? В C# напрямую нельзя вызвать get/set. Или ты про что?
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 09.06.06 16:30
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>> Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля


ANS>Блин, ты говориш "есть поле", а откуда оно взялось? С чего ты взял, что это именно поле? Стандарт кодирования у вас, что говорит?


Пардон, вычисляемое свойство.
Если нам не помогут, то мы тоже никого не пощадим.
Re[68]: Tcl как обоснование ненужности поддержки компонентно
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.06.06 16:49
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Andrei N.Sobchuck, Вы писали:


IT>>> Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля


ANS>>Блин, ты говориш "есть поле", а откуда оно взялось? С чего ты взял, что это именно поле? Стандарт кодирования у вас, что говорит?


IT>Пардон, вычисляемое свойство.


Я его и имел ввиду. Читай просто вместо "поле", "свойство".
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:19
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>boost::function отлично выполняет эту функцию.


1. boost::function не является примитивом языка.
2. Он не компилируется на некоторых компиляторах, а значит доступен не везде.
3. Он имеет ряд проблем в применении.
4. Примеры с тем что ты называшь лямбдами вообще никуда не годятся.
5. Реализация этого дела ужасна. Она значительно увеличиывает время компиляции и ухудшает понятность сообщений об ошибках.

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

В общем, если даже принять во внимане boost::function, все равно в языке остается слишком много лишнего сахара который вообще не реализовать средствами языка, и средства изменения языка очень окграничены. Как иминимум нет возможности изменить синтаксис. А изменение семантики сложно, неполноценно и чревато проблемами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:19
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Есть свойства языка, которые можно выразить через другие свойства — это

C>сахар. Операции циклов — сахар над if/goto, а вот switch — уже нет, так
C>как это абстракция таблицы переходов.

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

C>Точно так же — в C++ не являются сахаром шаблоны, исключения,

C>автоматические классы, и т.п.

C>Сахар — это перегрузка операторов, implicit-преобразования и т.п.


А while и for тоже сахаром значит не являются?

C>В связи с (повторным) увлечением Emacs'ом, мне стало интересно как же

C>используются макросы в Emacs'е. Оказалось, что почти никак.

И? Я еще проще могу пример привести. У меня в телевизоре тоже скорее всего ни одого макроса.

C>Я честно говоря, не могу представить где мне нужны будут нетривиальные

C>метапрограммы. Простенькие типа "кастануть к типу из списка с номером N"
C>- неплохо, но чего-то большего не особо хочется.

Это проблемы твоей фантации. У нас на сабмит через раз приходят статьи "вроде сериализация на С++ — вариант 325" или "конечные автоматы на шаблонном метапрограммировании через зад автогеном". Потом вот тут рядом про буст говорили. В нем почти все резальтат метапрограммирования. Только сделанного через зад автогеном.

>> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член

>> C>класса я могу взять ссылку (в С++).
>> Понимшь, С++ с его догами идет в лес.
C>Изначально IT привел отсутствие свойств как пример отстоев С++.

Если из С++ выбросить догмы и добавить нужный фанкционал, то олучился бы современный язык. Вот ИТ и говорил об этом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: О языках для численных расчетах.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:19
Оценка:
Здравствуйте, FR, Вы писали:

FR>Не помню, помню только прагму: #pragma inline_recursion(on)


Это значит ключик? Не, так дело не пойдет. Давай я тоже такой же ключик задейстую? У меня он называется Memoize macro. И по соревнуемся.

При каком-то значении рекурсии ты получашь просто константу. Ясно, что предрассчитанный результат будет быстрее.

VD>>Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?


FR>Ну у gcc тоже много ключиков, надо поискать которые за инлайнинг отвечают.


Ну, так кайди. Или это неподемная задача?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:19
Оценка: +1 :)
Здравствуйте, FR, Вы писали:

Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.

На маем ноуте Nemerle показывает 3.25 сек, а твой тест на VC 2.86. Другие компиляторы вообще сливают. Так о какой медленности менеджед-кода тут идет речь?

Твой же любимый Питон вообще лег на данной операции.

В общем, получается забавная ситуация. Вы сравниваете Немерле с каким-то мифическим языком краткойть которого как у Руби, а скорость как у С++. Но помилуйте, таким средством является только Немерле. С++ запутан, сложен, неуклюж и опасен. Даже статическая типизация не спасает от моря проблем. Руби медленен и требует больше отладки и тестирования в следствии отсуствия статической типизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:19
Оценка:
Здравствуйте, eao197, Вы писали:

E>Это похоже на сравнение выпуска легковых автомобилей и аэробусов.


Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:19
Оценка:
Здравствуйте, eao197, Вы писали:

E>Да и ради бога. Лично мне нафиг Linux или FreeBSD на десктопе не нужен без того количества драйверов, которые есть под Windows. Зато мне нафиг не нужны форточки на сервере, для которого вполне достаточно bash, screen и ssh.


Я не собираюсь спорить на тему что лучше Баш или терминал-сервис. Поверь просто, что управлять виндой удаленно не сложнее, но и даже проще чем Линуксом. И многих это более чем устраивает. Так что основной критерий выбора Линукса — это банальная дешевизна. Никто не спорит, что Линукс серьезный игрок в области дешевых серверных решений. Но рынок софта сильно больше чем этот рунок.

E>Есть такой класс систем -- банковский процессинг. Их продажи не могут исчисляться тысячами в принципе. Но не смотря на то, что у производителей процессинга клиентов едва переваливает за сотню, между самими производителями процессинга идет весьма серьезная конкуренция. И я очень сильно удивлюсь, если серьезные процессинговые системы для крупных банков (хотя бы уровня ведущих Московских банков, не говоря уже про европейские и американские), работающие под Windows.


У меня счета в двух банках. Везде Винда. Плюс еще в качестве банк-клиента ДОС.

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


Опять же. В офисе MTS на десктопе Винда.

E>Еще один пример. Есть такая платформа HP NonStop (бывший Tandem). Супер надежная, позиционируется как самая надежная платформа в мире и самая выгодная по соотношению цена/производительность для свого класса систем (хотя все это маркетинг и Sun, и Stratuss здесь приводят совершенно другие показатели). При этом машинка минимальной конфигурации стоит под $150K. И на этой платформе работают практически все крупнейшие банки США и Европы, все биржи в США, большинство европейских бирж, большинство сотовых операторов США. А крупнейший NonStop-ный кластер (вроде из 300 юнитов) работает в AOL.


Да, да. Вот например НАСДАК видимо именно на этом сервере Винду ганяет. А главное, что все его брокеры конечно из под нее пашут. Короче качай выдумывать. Банки работают на разном софте. И у нас, и у них. И поять же чем крупнее сервер, тем меньше софта для него требуется. Ведь сервер есть только у едениц. Итого массовый софт под виндой. А экзотика есть экзотика. Ее доли процента, но она почему-то гроче всех.

E>И знаешь, что объединяет все приведенные примеры -- высокие требования к надежности и отказоустойчивости. Это какой-нибудь хостер может выпасть на пару часов в осадок. А вот банк не может остановить свой процессинг. Мобильный оператор не может перестать обслуживать своих абонентов.


Это решается другими средствами. Железо на сегодня не так трудно сделать надежным. А вот софт есть софт. И будучи написанным на С++ он скорее выпаст в осадок.

E>Таких клиентов единицы. Но они требуют гораздо больше, чем все рядовые Windows-юзеры вместе взятые (образно говоря). И на создание подобных систем требуется своя индустрия. Естественно, она не мейнстрим. Ты вот, например, о ней даже не задумываешься (если вообще знаешь). А ведь она есть. И приносит совсем не маленькие деньги.


Их еденицы и они никого кроме себя не волнуют. Никакая вся индустрия тут не требуется. Это узкий сегмент рынка не видный в микроском. Прибыльный наверно, но очень узкий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 09.06.06 21:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.

+1

Я больше скажу — на одной из моих домашних машин вариант с прагмой разворота рекурсии проигрывает Nemerle. Проблема таких агрессивных и тупых оптимизаций в том, что они могут выйти боком при определенных обстоятельствах.

А вот Memoize в Nemerle это пример умной и хорошо подходящей для данного случая оптимизации. И выигрыш по сравнению с разворотом рекурсии просто огромный — в десятки раз. И естественно не зависит от особенностей конкретного железа и прогноза погоды.

На C++ без изменения кода самой функции такое просто не написать, если не использовать грязные и небезопасные методы вроде препроцессора.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 23:53
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

VK>В Nemerle с этим кстати проблем нет. Только вместо out параметра нужно передавать функцию-setter.


Не пререстаю удивляться прозорливости создателей языка. В Шарпе этого иногда нехватало. По имени конечно можно, но ведь проверки автоматом переводятся в рантайм. Что не зашибись.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 10.06.06 03:47
Оценка: -1
Andrei N.Sobchuck,

ANS>"Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на объяснении сути свойств. А то пока я только понял, что у них синтаксис удобный, а отчего, почему — не ясно.


Потому что синтаксический сахар does matter. Даже если убрать лишнюю пару скобок, то это уже существенно повлияет на нагруженность синтаксиса при систематическом применении.

Программы тэ пишутся людьми и для людей.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[68]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 10.06.06 04:00
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

ANS>>"Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на объяснении сути свойств. А то пока я только понял, что у них синтаксис удобный, а отчего, почему — не ясно.


LCR>Потому что синтаксический сахар does matter.


В данном случае мы столкнулись с феноменом непонимания этого простого факта. Видимо этот феномен витает и в комитете стандартизации C++
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 10.06.06 06:29
Оценка:
Здравствуйте, VladD2, Вы писали:

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


A>>boost::function отлично выполняет эту функцию.


VD>1. boost::function не является примитивом языка.

VD>2. Он не компилируется на некоторых компиляторах, а значит доступен не везде.
VD>3. Он имеет ряд проблем в применении.
VD>4. Примеры с тем что ты называшь лямбдами вообще никуда не годятся.
VD>5. Реализация этого дела ужасна. Она значительно увеличиывает время компиляции и ухудшает понятность сообщений об ошибках.

Мне всегда хотелось узнать, какие претензии программисты на C# имеют к boost::function. Спасибо за исчерпывающий список.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.06.06 06:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>У меня счета в двух банках. Везде Винда. Плюс еще в качестве банк-клиента ДОС.


Ты бывал в серверных этих банков? Или только видел терминалы в банковских РКЦ?

Если эти сообщения читают мужики из Питерского OpenWay или Магнитогорского КомпасПлюс, то они сейчас, наверное, широко улыбаются.

VD>Опять же. В офисе MTS на десктопе Винда.


Ага, и девочка из офиса МТС со своего десктопа непосредственно софтом SMS-центра управляет.

VD>Да, да. Вот например НАСДАК видимо именно на этом сервере Винду ганяет. А главное, что все его брокеры конечно из под нее пашут. Короче качай выдумывать. Банки работают на разном софте. И у нас, и у них.


А я и не утверждал, что используется только одна платформа и только одна ОС. Однако, для критически важной функциональности (а не для клиентских мест) используются дорогие серверные платформы. На которых пока Windows не видно.

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


На счет громче всех, то ты с рекламой Windows и пропагандой Nemerle здесь вообще вне конкуренции. Так что не обвиняй других участников форума в собственных грехах.

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

VD>А вот софт есть софт. И будучи написанным на С++ он скорее выпаст в осадок.


На этом месте я всегда плачу...

E>>Таких клиентов единицы. Но они требуют гораздо больше, чем все рядовые Windows-юзеры вместе взятые (образно говоря). И на создание подобных систем требуется своя индустрия. Естественно, она не мейнстрим. Ты вот, например, о ней даже не задумываешься (если вообще знаешь). А ведь она есть. И приносит совсем не маленькие деньги.


VD>Их еденицы и они никого кроме себя не волнуют. Никакая вся индустрия тут не требуется. Это узкий сегмент рынка не видный в микроском. Прибыльный наверно, но очень узкий.


Так я не понял, в темах с твоим участием про этот сегмент рынка вообще заикаться нельзя?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.06.06 06:52
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Это похоже на сравнение выпуска легковых автомобилей и аэробусов.


VD>Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.


Какой изящный переход на личности


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: О языках для численных расчетах.
От: FR  
Дата: 10.06.06 08:49
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Не помню, помню только прагму: #pragma inline_recursion(on)


VD>Это значит ключик? Не, так дело не пойдет. Давай я тоже такой же ключик задейстую? У меня он называется Memoize macro. И по соревнуемся.


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

VD>При каком-то значении рекурсии ты получашь просто константу. Ясно, что предрассчитанный результат будет быстрее.


Нет, я проверял со вводом числа из командной строки и смотрел ассемблерный листинг.

VD>>>Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?


FR>>Ну у gcc тоже много ключиков, надо поискать которые за инлайнинг отвечают.


VD>Ну, так кайди. Или это неподемная задача?


Жарко, охота в тенечке лежать а не за компом сидеть
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.06.06 08:49
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


VD>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.


Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение

VD>На маем ноуте Nemerle показывает 3.25 сек, а твой тест на VC 2.86. Другие компиляторы вообще сливают. Так о какой медленности менеджед-кода тут идет речь?


VD>Твой же любимый Питон вообще лег на данной операции.


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

VD>В общем, получается забавная ситуация. Вы сравниваете Немерле с каким-то мифическим языком краткойть которого как у Руби, а скорость как у С++. Но помилуйте, таким средством является только Немерле. С++ запутан, сложен, неуклюж и опасен. Даже статическая типизация не спасает от моря проблем. Руби медленен и требует больше отладки и тестирования в следствии отсуствия статической типизации.


А почему бы и не сравнивать если я как раз и использую связку python + С++.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.06.06 08:49
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

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


VD>>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.

VK>+1

VK>Я больше скажу — на одной из моих домашних машин вариант с прагмой разворота рекурсии проигрывает Nemerle. Проблема таких агрессивных и тупых оптимизаций в том, что они могут выйти боком при определенных обстоятельствах.


Что-то не верится я асм. листинг смотрел.

VK>А вот Memoize в Nemerle это пример умной и хорошо подходящей для данного случая оптимизации. И выигрыш по сравнению с разворотом рекурсии просто огромный — в десятки раз. И естественно не зависит от особенностей конкретного железа и прогноза погоды.


В питоне та же оптимизация тоже очень легко делается.

VK>На C++ без изменения кода самой функции такое просто не написать, если не использовать грязные и небезопасные методы вроде препроцессора.


Еще можно на ассемблерных вставках сделать
Re[70]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 10.06.06 11:17
Оценка:
Дьяченко Александр wrote:
> C>К полю. А вообще, для defval придуманы были конструкторы (в том числе и
> C>анонимные).
> Ну к полю это еще туда сюда (Дизайнер должен сам догадываться к которому
> полю, или опять соглашение?).
Зачем дизайнеру о чем-то догадываться? Он или ищет поле по какому-то
атрибуту, или ему его указывает пользователь.

> А с конструктором это вобще не катит — например класc Color у каждого

> Control-а несколько разных Color-ов и че в конструкторе?
public class Blah
{
    public int someInt=123;
    public double someDbl;
    {
        someDbl=Math.sin(Something);
    }
    
    Blah()
    {
        //Тут someDbl уже будет иметь нужное значение
    }
};


> C>В этом примере все просто — а в более сложных случаях получается

> C>сложнее. Особенно когда нельзя (или трудоемко) четко разделять на
> C>вычислямые данные и исходные.
> Пример нарисуешь? А то у меня че-то не приходит в голову ничего.
Система рассчета налогов, например, (привет kan_izh!). Связи между
полями могут быть весьма сложными.

>> > 3. Осуществлять присвоение только в случае другого значения (обычно

>> > так и делается). Т.е.:
> C>Ага, только тогда теряем гарантию семантической целостности графа. Тоже
> C>неприятно.
> В смысле? Нафига че-то делать если там и так тоже самое значение?
Теряем автоматическое обнаружение ошибок. Кроме того, здесь это не
поможет — ошибка происходит из-за того, что нужное для вычислений поле
еще не загружено.

> C>В Java есть простое соглашение — для доступа к данным используются

> C>методы без параметра с префиксом "get" (или "is" для булевских типов),
> C>для присвоения — методы с префиксом "set" и одним параметром.
> Я же говорил что как концепция свойство все равно есть.
Так все get/set-методы можно "свойствами" обозвать.

> Плюс такое раздвоение усложняет рефакторинг.

Де-факто, не усложняет.

> Или ты против отображения этой концепции в синтаксисе языка?

Да. Так как отображение противоречиво и концептуально неправильно.

>> > Ну использовать через задницу можно почти все .

> C>А если это "что-то" специально предназначалось для такого использования?
> В смысле?
Свойства и задумывались ради side-эффектов.

> C>Концепетуальную сложность мы, наоборот, увеличиваем. Так как появляются

> C>два типа синтаксически одинаковых, но семантически неэквивалентных
> C>конструкций.
> В смысле? В C# напрямую нельзя вызвать get/set. Или ты про что?
Я про то, что обращение к полю выглядит точно так же, как и обращение к
свойству. Но свойство нельзя передать как out-параметр и операция
присвоения свойству имеет непредсказуемые характеристики.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[71]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 10.06.06 15:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Ну к полю это еще туда сюда (Дизайнер должен сам догадываться к которому

>> полю, или опять соглашение?).
C>Зачем дизайнеру о чем-то догадываться? Он или ищет поле по какому-то
C>атрибуту, или ему его указывает пользователь.

В случае просто публичного поля все и так ясно. А в случае свойства как просто набора get/set к чему?

>> А с конструктором это вобще не катит — например класc Color у каждого

>> Control-а несколько разных Color-ов и че в конструкторе?
C>
Код вырезан
C>


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

>> Пример нарисуешь? А то у меня че-то не приходит в голову ничего.

C>Система рассчета налогов, например, (привет kan_izh!). Связи между
C>полями могут быть весьма сложными.

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

>> C>Ага, только тогда теряем гарантию семантической целостности графа. Тоже

>> C>неприятно.
>> В смысле? Нафига че-то делать если там и так тоже самое значение?
C>Теряем автоматическое обнаружение ошибок. Кроме того, здесь это не
C>поможет — ошибка происходит из-за того, что нужное для вычислений поле
C>еще не загружено.

Для самых зверских случаев есть загрузка руками что бы сделать все в том порядке в каком надо.

>> C>В Java есть простое соглашение — для доступа к данным используются

>> C>методы без параметра с префиксом "get" (или "is" для булевских типов),
>> C>для присвоения — методы с префиксом "set" и одним параметром.
>> Я же говорил что как концепция свойство все равно есть.
C>Так все get/set-методы можно "свойствами" обозвать.

И что? В Framework-е не такуж и много таких функций особенно с параметрами.

>> Плюс такое раздвоение усложняет рефакторинг.

C>Де-факто, не усложняет.

Ну ладно пусть не усложняет (что-то придумать ничего не могу спать охота).

>> Или ты против отображения этой концепции в синтаксисе языка?

C>Да. Так как отображение противоречиво и концептуально неправильно.

Можешь предложить лучше?

>> В смысле?

C>Свойства и задумывались ради side-эффектов.

Ну side-эфект понятие растяжимое. Плюс мне почему-то кажется что side-эффект это не основное ради чеего они задумывались.

>> В смысле? В C# напрямую нельзя вызвать get/set. Или ты про что?

C>Я про то, что обращение к полю выглядит точно так же, как и обращение к
C>свойству. Но свойство нельзя передать как out-параметр и операция
C>присвоения свойству имеет непредсказуемые характеристики.

Ну так и метод тоже имеет те же самые характеристики. И что? Не делай из этого трагедии и страшного секрета и все будет нормально.
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.06 18:23
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Мне всегда хотелось узнать, какие претензии программисты на C# имеют к boost::function. Спасибо за исчерпывающий список.


На С++ я программировал 13 лет. На C# 4 года. Так что это еще большой вопрос кто из нас на чем программист. И кстати, boost::function появился уже тогда когда С++ стал становиться мне менее и менее интересен.

Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями. В прочем, то уже проблемы всего С++ в целом. Ну, да и boost::function это чисто его порождение. Такого извращения нет ни в одном языке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.06 18:23
Оценка:
Здравствуйте, FR, Вы писали:

VD>>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.


FR>Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение


А что и кого обошло? GCC слил? VC6 тоже сольет. У Vermicious Knid вот и VC на машине сливает. Твоеи любимые языки сольют так что мама не горюй. Так чем ты тут пыташся подколоть?

Вопрос повышения качества оптимизации управляемых сред — это вопрос времени.

FR>Ну и что, я его для такой дурости не использую


Действительно! Не программировать же на нем? Так скриптики не критичные писать, чтобы время потянуть.

FR>Да и не так и лег если на нем оказалось несложно повторить без всяких макросов легендарный и всемогущий Memoize


Да, лег, лег. (3, 12) не выполнится вообще.

VD>>В общем, получается забавная ситуация. Вы сравниваете Немерле с каким-то мифическим языком краткойть которого как у Руби, а скорость как у С++. Но помилуйте, таким средством является только Немерле. С++ запутан, сложен, неуклюж и опасен. Даже статическая типизация не спасает от моря проблем. Руби медленен и требует больше отладки и тестирования в следствии отсуствия статической типизации.


FR>А почему бы и не сравнивать если я как раз и использую связку python + С++.


Ну, давай сравним. С Питомном по скорости, и с С++ по выразительности. А то что-то странноая какая-то игра идет. Немреле конечно кокурент обих, так как смело их может заменить во многих задачах. Но сравнивать то нужно честно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.06 18:23
Оценка:
Здравствуйте, FR, Вы писали:

FR>В питоне та же оптимизация тоже очень легко делается.


Языком. Так как пред тем как заморозить нужно еще посчитать. У Немерла есть отличный компилятор и время компиляции. А что есть у Питона?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.06 18:23
Оценка: :)
Здравствуйте, eao197, Вы писали:

VD>>Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.


E>Какой изящный переход на личности


Ага. Какая подлость осбуждение личности твоего сервера.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.06.06 19:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>В питоне та же оптимизация тоже очень легко делается.


VD>Языком. Так как пред тем как заморозить нужно еще посчитать. У Немерла есть отличный компилятор и время компиляции. А что есть у Питона?


Ну конечно куда нам убогим до всемогущего N
У питона есть возможность записать в файл и потом просто прочитать оттуда, и все это делается легко и быстро, как я тут уже показывал.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.06.06 19:02
Оценка: -1
Здравствуйте, VladD2, Вы писали:


FR>>Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение


VD>А что и кого обошло? GCC слил? VC6 тоже сольет. У Vermicious Knid вот и VC на машине сливает. Твоеи любимые языки сольют так что мама не горюй. Так чем ты тут пыташся подколоть?


Я ничем, это тут у вас война со всем миром.
Я думаю Vermicious Knid просто ошибся.

VD>Вопрос повышения качества оптимизации управляемых сред — это вопрос времени.


Угу и возможно бесконечно большого

FR>>Ну и что, я его для такой дурости не использую


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


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

FR>>Да и не так и лег если на нем оказалось несложно повторить без всяких макросов легендарный и всемогущий Memoize


VD>Да, лег, лег. (3, 12) не выполнится вообще.


Угу а N лег на 3, 13 а VC8 спокойно вычислил 3, 14

VD>>>В общем, получается забавная ситуация. Вы сравниваете Немерле с каким-то мифическим языком краткойть которого как у Руби, а скорость как у С++. Но помилуйте, таким средством является только Немерле. С++ запутан, сложен, неуклюж и опасен. Даже статическая типизация не спасает от моря проблем. Руби медленен и требует больше отладки и тестирования в следствии отсуствия статической типизации.


FR>>А почему бы и не сравнивать если я как раз и использую связку python + С++.


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


Угу час разбежался, у меня есть инструмент и он состоит именно из связки двух языков, и я неплохо на нем решаю свои задачи.
А сравнить можно и по отдельности, но не так как хочется тебе, а в области применения этих инструментов.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.06.06 19:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.


E>>Какой изящный переход на личности


VD>Ага. Какая подлость осбуждение личности твоего сервера.


Видишь ли, такой вещи, как "мой сервер приложений" нет в природе.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 10.06.06 20:42
Оценка: +2
Здравствуйте, FR, Вы писали:

FR>Я думаю Vermicious Knid просто ошибся.

Нет, я не ошибся. Повторяю еще раз. На некоторых(слабых) процессорах оптимизация раскрытием рекурсии делает код на C++ медленнее кода на Nemerle, и довольно заметно сильно. При этом без нее тот же код на C++ слегка опережает Nemerle.

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

Я такое наблюдал однажды когда писал один небольшой парсер на C++. Для его оптимизации я активно юзал как раз раскрытие рекурсивных функций. После очередной совсем небольшой и незначительной доработки я вдруг получил резкое падение производительности. От раскрытия рекурсии естественно пришлось отказаться, так как падение производительности было более сильным, чем в случае отказа от этой оптимизации.

FR>Ну конечно самая важная задача в программировании это вычисление функции Аккермана, ты мне просто глаза раскрыл, большое спасибо

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

И тут важно не то, что Nemerle идет почти наравне с C++, а то что он опережает C#. На C++ мне уже как-то вообще наплевать, он меня мало интересует.

Правда я считаю, что никакая низкоуровневая оптимизация компилятором и предварительная оптимизация человеком не сможет заменить целевую оптимизацию основанную на профилинге живого приложения. Но раз уж эти тесты кто-то широко использует, то почему бы и не сравнить. Тем более что Nemerle, версия 0.1 которого появилась всего два года тому назад, и в котором пока практически отсутствует оптимизация как таковая, уже сейчас показывает на этих тестах производительность сравнимую с C++.

На самом деле все еще только начинается. Если победа будет не за Nemerle, то в любом случае за управляемыми языками. И случится это еще при нашей жизни. У C++ останется только совсем крохотная ниша.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 10.06.06 21:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


A>>Мне всегда хотелось узнать, какие претензии программисты на C# имеют к boost::function. Спасибо за исчерпывающий список.


VD>На С++ я программировал 13 лет. На C# 4 года. Так что это еще большой вопрос кто из нас на чем программист. И кстати, boost::function появился уже тогда когда С++ стал становиться мне менее и менее интересен.


Неважно сколько ты лет программировал на C++. С boost::function ты явно не знаком.

VD>Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями.


Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 10.06.06 21:34
Оценка: :)
Здравствуйте, alexeiz, Вы писали:

A>Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.

А что с ним знакомиться? Замыканий в С++ всеравно нет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.06 22:27
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Неважно сколько ты лет программировал на C++. С boost::function ты явно не знаком.


Интересный вывод. А теперь сделай поиск по этому сайту.
Просто я кроме того знаком и с прямыми решенияи.

VD>>Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями.


A>Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.


Серьезно? Ну, давай передай сслку на метод в другую ДЛЛ не используя описание в виде исходников.

Я уже не говорю о супер синтаксисе все эти _1, _2... и:
f = (&var ->* &someclass::foo);

колдовство на марше да и только.

Сравни ради хохмы свой пример с немерлом:
foo(_ : int) : void {}
bar(_ : char) : void {}
// бред пропускаем struct functor : std::unary_function<int, void> {...};
class someclass { foo(_ : int) : void {} };

// straight forward call
mutable f = foo;
f(1); // -> foo(1)

// parameter types don't have to match
f = bar;
f(2); // до этой строчки не дойдет. :)

// lambda tricks - здесь не лямбд, ни трюков не нужно! Функция ведь первокласный объект в языке. :)
f = Console.Write;
f(10); // -> Console.Write(10)

// functors - идут в лес как левый рудимент. :(
//f = functor();
//f(10); // -> functor().operator(10);

// member functions
def var = someclass();
f = var.foo;
f(10); // -> var.foo(10)

Но это в общем-то детство. А вот так уже куда интереснее.
def add = _ + _; // частичное применение. Преобразуем оператор в функцию с двумя параметрами. 
WriteLine(add(1, 2)); // выводит 3

def inc = add(_, 1); // частичное применение фукнции полученной в результате аналогичного процесса :)
WriteLine(inc(3)); // выводит 4

// Локальная функция с замыканием на лексический контекст. 
// Функция Add5AndInc исползует функции inc и add объявленные в локальном контексте.
def Add5AndInc(x) { inc(add(x, 5)) }
WriteLine(2)  // выведет "8"
...

class Test
{
    // метод возвращающий функцию принимающую int и возвращающую string.
    public Method1(prefix : string) : int -> string
    {
        x => $"$prefix: $x" // в качестве фукнции возвращаем настоящую лябду ссылающуюся на лексический контекст.
    }
}
...
def test = Test();

def f1 = test.Method1("prefix 1");
def f2 = test.Method1("prefix 2");
WriteLine(f1(5));  // выведет "prefix 1: 5"
WriteLine(f2(5));  // выведет "prefix 2: 5"
WriteLine(f1(10)); // выведет "prefix 1: 10"


Все это не требует левых библиотек для компиляции. Компилируется в мгновении ока. Быстро работает. Не приводит к необъяснимым сообщениям об ошибках при опечатках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 10.06.06 22:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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


A>>Неважно сколько ты лет программировал на C++. С boost::function ты явно не знаком.


VD>Интересный вывод. А теперь сделай поиск по этому сайту.

VD>Просто я кроме того знаком и с прямыми решенияи.

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

VD>>>Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями.


A>>Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.


VD>Серьезно? Ну, давай передай сслку на метод в другую ДЛЛ не используя описание в виде исходников.


Передам. В чём проблема?

VD>Я уже не говорю о супер синтаксисе все эти _1, _2... и:

VD>
VD>f = (&var ->* &someclass::foo);
VD>

VD>колдовство на марше да и только.

VD>Сравни ради хохмы свой пример с немерлом:


При чём здесь Nemerle? Если ты не в состоянии запомнить о чём идет речь в этой ветке, напомню, что мы обсуждаем свойства и делегаты применительно к C++.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.06.06 22:54
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

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


FR>>Я думаю Vermicious Knid просто ошибся.

VK>Нет, я не ошибся. Повторяю еще раз. На некоторых(слабых) процессорах оптимизация раскрытием рекурсии делает код на C++ медленнее кода на Nemerle, и довольно заметно сильно. При этом без нее тот же код на C++ слегка опережает Nemerle.

На каком именно процессоре и точные цифры можешь привести? а также код и ключи с которыми компилировалось?

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


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

VK>Я такое наблюдал однажды когда писал один небольшой парсер на C++. Для его оптимизации я активно юзал как раз раскрытие рекурсивных функций. После очередной совсем небольшой и незначительной доработки я вдруг получил резкое падение производительности. От раскрытия рекурсии естественно пришлось отказаться, так как падение производительности было более сильным, чем в случае отказа от этой оптимизации.


FR>>Ну конечно самая важная задача в программировании это вычисление функции Аккермана, ты мне просто глаза раскрыл, большое спасибо

VK>Конечно функия Аккермана не самая полезная рекурсивная функция. Но по таким бенчмаркам можно косвенно судить о том как поведут себя различные рекурсивные обходы деревьев, парсинг и тому подобные алгоритмы.

По таким тестам мало о чем можно судить, так как для реальные функции не сводятся в основном к вызовам, они еще рабочее тело имеют

VK>И тут важно не то, что Nemerle идет почти наравне с C++, а то что он опережает C#. На C++ мне уже как-то вообще наплевать, он меня мало интересует.


Ну а мне наплевать на C#

VK>Правда я считаю, что никакая низкоуровневая оптимизация компилятором и предварительная оптимизация человеком не сможет заменить целевую оптимизацию основанную на профилинге живого приложения. Но раз уж эти тесты кто-то широко использует, то почему бы и не сравнить. Тем более что Nemerle, версия 0.1 которого появилась всего два года тому назад, и в котором пока практически отсутствует оптимизация как таковая, уже сейчас показывает на этих тестах производительность сравнимую с C++.


Угу только не забудь что очень большой процент этой производительности заслуга разработчиков NET, и поэтому оптимизация в N очень даже присутствует. Так что сравнивать надо не N vs C++ а NET + N vs C++.

VK>На самом деле все еще только начинается. Если победа будет не за Nemerle, то в любом случае за управляемыми языками. И случится это еще при нашей жизни. У C++ останется только совсем крохотная ниша.


Я бы так не надеялся вполне возможно проиграют обе стороны
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 11.06.06 00:26
Оценка: 5 (1) +1
Здравствуйте, FR, Вы писали:

FR>На каком именно процессоре и точные цифры можешь привести? а также код и ключи с которыми компилировалось?

Ты мне не веришь? Процессор Celeron, архитектуры P3. Код твой, с прагмой inline_recursion(on), ключ /Ox. На P4/K8 этот же код естественно выигрывает с большим отрывом.

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

FR>Если рекурсивная функция сложнее аккермана, есть очень большая вероятность что цена вызова не будет играть большой роли и будут иметь значение совсем другие оптимизации.

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

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

FR>Ну а мне наплевать на C#

Ну а мне наплевать на сравнение производительности C++ и Nemerle, сравнение Питона и Nemerle, и так далее. Это вообще не важно. Nemerle не претендует на нишу этих языков. Его конкуренты это C#, Java и тому подобные языки.

Из этого можно сделать один вывод — ты пока не являешься потенциальным пользователем Nemerle. Я скажем года три-четыре назад тоже не являлся. Для меня основными и главными преимуществами моего любимого на тот момент языка программирования были шаблоны и возможность добиться максимально возможной производительности и эффективности. Что за язык я думаю ты догадаешься с первой попытки.

Я правда никогда особо не увлекался динамическими языками вроде Питона. Как выясняется наличие таких языков почему-то может служить оправданием недостатков C++ и аргументом против Nemerle/C# у программистов на C++.

FR>Я бы так не надеялся вполне возможно проиграют обе стороны

Проиграют кому/чему?

Динамическим языкам? Ну во-первых это все таки тоже управляемые языки. Но я бы на победу динамических языков все равно бы не надеялся. Было время когда динамические языки вообще были самыми лучшими и продвинутыми языками. Я имею в виду Common Lisp и Smalltalk. Когда эти языки появились они были на острие технологий, они предлагали действительно новые и революционные на тот момент концепции. Закончилось это все многочисленными пародиями, аналогами и вариациями, которые с каждым годом все плодятся и конца этому процессу не видно. А пока самые продвинутые из популярных Руби с Питоном вместе пока не могут сравниться по популярности даже с JavaScript. Но если это все таки случится и динамическим языкам проиграет Java/C#, то это все равно будет победа управляемых сред.

Другому неуправляемому низкоуровневому языку? D? Другому аналогу C++? Все это очень сомнительно. К D я честно говоря до сих пор питаю некоторые симпатии, но в его победу я практически не верю. По-моему беда D это недостаточная открытость. Он разрабатывается уже черти сколько лет и его судьба остается весьма туманна. Скорее я поверю в то, что новая ревизия стандарта C++ будет очень хороша и позволит языку вернуть потерянные позиции с лихвой.

Нативному функциональному языку? Haskell? OCaml? Подобным языкам пророчат победу уже много лет. Но что-то никакого прогресса не видно. Единственное что видно — таких же ярых фанатов как у C++, абсолютно уверенных в непогрешимости и тотальном превосходстве Функциональной парадигмы.

Все остальное что приходит на ум это управляемые около-функциональные языки. Во-первых для CLR/JVM. Во-вторых для собственных управляемых сред, например Erlang.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 11.06.06 07:14
Оценка: -1
Здравствуйте, Vermicious Knid, Вы писали:

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


FR>>На каком именно процессоре и точные цифры можешь привести? а также код и ключи с которыми компилировалось?

VK>Ты мне не веришь? Процессор Celeron, архитектуры P3. Код твой, с прагмой inline_recursion(on), ключ /Ox. На P4/K8 этот же код естественно выигрывает с большим отрывом.

Сейчас уже нет , но я ни в чем ни обвиняю, с этими тестами очень легко что-то перепутать, сам не раз попадался.
Просто тот же p3 Celeron недавно был моей основной целевой платформой и я много что на нем тестировал.

VK>Цифры мне лень проверять и приводить, тем в данный момент времени это почти невозможно. Суть не в них, а в том что это неоднозначная оптимизация и в зависимости от обстоятельств она будет приводить лишь к замедлению.


Может и к замедлению если функция перестанет лезть в кеш, но это не тот случай тут код получается много меньше 128Kb.

FR>>Если рекурсивная функция сложнее аккермана, есть очень большая вероятность что цена вызова не будет играть большой роли и будут иметь значение совсем другие оптимизации.

FR>>По таким тестам мало о чем можно судить, так как для реальные функции не сводятся в основном к вызовам, они еще рабочее тело имеют
VK>Я тебе уже привел пример функции сложнее аккермана, когда эта оптимизация приносила существенное увеличение производительности, но только до тех пор пока совокупный размер раскрываемого кода не превысил определенный порог. Для определенных процессоров даже функция аккермана с такой оптимизацией может вызвать проблемы.

Извини я не могу делать какие-то выводы на умозрительных примерах.

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


Решающим может быть размер кеша, так же может повлиять предсказатель переходов, но это уже для P4. Для P3 сильное замедление может быть из-за непоследовательного обращения к большим объемам данных в памяти.

FR>>Ну а мне наплевать на C#

VK>Ну а мне наплевать на сравнение производительности C++ и Nemerle, сравнение Питона и Nemerle, и так далее. Это вообще не важно. Nemerle не претендует на нишу этих языков. Его конкуренты это C#, Java и тому подобные языки.

Классно всем на все наплевать, но все равно сравниваем

VK>Из этого можно сделать один вывод — ты пока не являешься потенциальным пользователем Nemerle. Я скажем года три-четыре назад тоже не являлся. Для меня основными и главными преимуществами моего любимого на тот момент языка программирования были шаблоны и возможность добиться максимально возможной производительности и эффективности. Что за язык я думаю ты догадаешься с первой попытки.


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

VK>Я правда никогда особо не увлекался динамическими языками вроде Питона. Как выясняется наличие таких языков почему-то может служить оправданием недостатков C++ и аргументом против Nemerle/C# у программистов на C++.


Вот дурдом. Питон для меня не оправдание а рабочий инструмент.

FR>>Я бы так не надеялся вполне возможно проиграют обе стороны

VK>Проиграют кому/чему?

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

VK>Динамическим языкам? Ну во-первых это все таки тоже управляемые языки. Но я бы на победу динамических языков все равно бы не надеялся. Было время когда динамические языки вообще были самыми лучшими и продвинутыми языками. Я имею в виду Common Lisp и Smalltalk. Когда эти языки появились они были на острие технологий, они предлагали действительно новые и революционные на тот момент концепции. Закончилось это все многочисленными пародиями, аналогами и вариациями, которые с каждым годом все плодятся и конца этому процессу не видно. А пока самые продвинутые из популярных Руби с Питоном вместе пока не могут сравниться по популярности даже с JavaScript. Но если это все таки случится и динамическим языкам проиграет Java/C#, то это все равно будет победа управляемых сред.


Как ты думаешь что победит сверло или стамеска? А может кувалда всех уделает? Хотя вряд-ли, настоящие пацаны все делают только топором и без единого гвоздя
Я думаю будут нужны разные инструменты. А популярность вещь относительная, убери использование в браузерах и что останется от популярности JavaScript? Да мне в общем и не важна популярность.

VK>Другому неуправляемому низкоуровневому языку? D? Другому аналогу C++? Все это очень сомнительно. К D я честно говоря до сих пор питаю некоторые симпатии, но в его победу я практически не верю. По-моему беда D это недостаточная открытость. Он разрабатывается уже черти сколько лет и его судьба остается весьма туманна. Скорее я поверю в то, что новая ревизия стандарта C++ будет очень хороша и позволит языку вернуть потерянные позиции с лихвой.


Здесь согласен

VK>Нативному функциональному языку? Haskell? OCaml? Подобным языкам пророчат победу уже много лет. Но что-то никакого прогресса не видно. Единственное что видно — таких же ярых фанатов как у C++, абсолютно уверенных в непогрешимости и тотальном превосходстве Функциональной парадигмы.


У N тоже самое наблюдается

VK>Все остальное что приходит на ум это управляемые около-функциональные языки. Во-первых для CLR/JVM. Во-вторых для собственных управляемых сред, например Erlang.


Тебе 3 года назад N на ум пришел бы?
Re[69]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 11.06.06 13:50
Оценка:
IT wrote:

> LCR>Потому что синтаксический сахар /does matter/.

> В данном случае мы столкнулись с феноменом непонимания этого простого
> факта. Видимо этот феномен витает и в комитете стандартизации C++
Если пихать всё, получится perl 6.
Вот мне не нравится ; ставить в конце каждой строки. А зачем? Вот javascript рулит. И что теперь? Почему эти
стандартизаторы c#/java и даже немерла такие косные, что не понимают что мне нравится?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 11.06.06 13:53
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Сейчас уже нет

Да ради бога. Убеждать тебя в чем-то или доказывать что-то у меня нет ни малейшего желания. Я все равно не обладаю даром убеждения.

FR>Извини я не могу делать какие-то выводы на умозрительных примерах.

Это был не умозрительный пример, это пример из моей практики. Это было давно, но я это помню довольно отчетливо.

FR>Классно всем на все наплевать, но все равно сравниваем

Я уже не сравниваю. А вот ты был тем самым человеком которому показалась, что стоит продолжить сравнивание, так как у твоего любимого C++ не было безоговорочной победы.

FR>Откуда ты знаешь может я не недозрел, а перезрел?

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

FR>Я вообще тут с ужасом обнаружил что мне станвится все интересней и интересней написать что-то серьезное на лиспе

Ну и? У меня тоже был такой этап в жизни. Мне вообще на очень многих языках было интересно что-то написать и часто я пробовал это делать.

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

FR>Здесь согласен
Это была всего лишь метафора. В смысле скорее рак на горе свистнет(ревизия стандарта C++ будет очень хороша). То есть этого не будет.

FR>У N тоже самое наблюдается

Может у N тоже самое и наблюдается, а у вот у Nemerle не наблюдается. Что такое N вообще? Я о таком не слышал.
Шутка конечно, просто я не люблю такие сокращения и меня это немного раздражает.

FR>Тебе 3 года назад N на ум пришел бы?

Нет не пришел бы, и не прийдет сейчас. А Nemerle три года назад просто не существовало. Но уже были языки, которые во-многом были похожи на Nemerle и мне нравились уже тогда, например OCaml, Scala.

А вообще я не являюсь фанатом ни одного языка. У меня широкий кругозор и постоянно интересуюсь новыми и старыми языками программирования. Мне кстати нравится время от времени писать на языках, которые я знаю очень плохо или совсем не знаю. Это доставляет мне гораздо большее удовольствие чем программирование на уже знакомых и хорошо освоенных инструментах.

А вот Nemerle меня привлекает совсем не новизной и оригинальностью(тем более что я знаком с ним с выхода самой первой версии), а именно как практический инструмент для разработки на .NET. Тем более что он действительно на порядок лучше всего того, что есть для этой платформы.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 11.06.06 15:07
Оценка: :)
Здравствуйте, Vermicious Knid, Вы писали:

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


FR>>Сейчас уже нет

VK>Да ради бога. Убеждать тебя в чем-то или доказывать что-то у меня нет ни малейшего желания. Я все равно не обладаю даром убеждения.

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

FR>>Извини я не могу делать какие-то выводы на умозрительных примерах.

VK>Это был не умозрительный пример, это пример из моей практики. Это было давно, но я это помню довольно отчетливо.

Бывает
Но причина тормозов могла быть совсем в другом, как уже говорил эта не та область где авторитетны примеры из жизни.

FR>>Классно всем на все наплевать, но все равно сравниваем

VK>Я уже не сравниваю. А вот ты был тем самым человеком которому показалась, что стоит продолжить сравнивание, так как у твоего любимого C++ не было безоговорочной победы.

Если бы Влад не любил безапеляционно кричать слова типа "слил" ничего бы не было
Ну у него работа такая, надо же форум поактивнее делать

FR>>Я вообще тут с ужасом обнаружил что мне станвится все интересней и интересней написать что-то серьезное на лиспе

VK>Ну и? У меня тоже был такой этап в жизни. Мне вообще на очень многих языках было интересно что-то написать и часто я пробовал это делать.

Ну у меня тоже, просто я всегда думал что лисп не для меня

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

FR>>Здесь согласен
VK> Это была всего лишь метафора. В смысле скорее рак на горе свистнет(ревизия стандарта C++ будет очень хороша). То есть этого не будет.

Вообще-то я был согласен с тем что как мне ни симпатичен D ему мало что светит.
А с C++ похоже все-таки что ты тоже прав, хотя поживем — увидим.

FR>>У N тоже самое наблюдается

VK>Может у N тоже самое и наблюдается, а у вот у Nemerle не наблюдается. Что такое N вообще? Я о таком не слышал.
VK>Шутка конечно, просто я не люблю такие сокращения и меня это немного раздражает.

Во-во я же говорю религиозные чувства
Тут например многих коробит что C++ называют плюсами, я думаю тоже самое чувство виновато
А сокращать полезно, у меня тут автокомплита нет

FR>>Тебе 3 года назад N на ум пришел бы?

VK>Нет не пришел бы, и не прийдет сейчас. А Nemerle три года назад просто не существовало. Но уже были языки, которые во-многом были похожи на Nemerle и мне нравились уже тогда, например OCaml, Scala.

Ocaml из совсем другой оперы, а про Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования

VK>А вообще я не являюсь фанатом ни одного языка. У меня широкий кругозор и постоянно интересуюсь новыми и старыми языками программирования. Мне кстати нравится время от времени писать на языках, которые я знаю очень плохо или совсем не знаю. Это доставляет мне гораздо большее удовольствие чем программирование на уже знакомых и хорошо освоенных инструментах.


Это да
Только если добровольно

VK>А вот Nemerle меня привлекает совсем не новизной и оригинальностью(тем более что я знаком с ним с выхода самой первой версии), а именно как практический инструмент для разработки на .NET. Тем более что он действительно на порядок лучше всего того, что есть для этой платформы.


Может быть.
Но мне кажется как про практический инструмент говорить про него рано. Все еще есть вероятность что он останется академической недоделкой, или большим долгостроем (как D).
Re[70]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 11.06.06 15:30
Оценка:
Здравствуйте, kan_izh, Вы писали:

_>Если пихать всё, получится perl 6.

У перла 6 я думаю тоже найдутся свои фанаты.

_>Вот мне не нравится ; ставить в конце каждой строки. А зачем? Вот javascript рулит. И что теперь? Почему эти

_>стандартизаторы c#/java и даже немерла такие косные, что не понимают что мне нравится?
Во-первых в Nemerle не всегда обязательно ставить ; в конце строки, а только когда нужно отделить одно выражение от другого. Зачастую функция вообще может состоять из одного выражения. Еще после объявления локальной функции ; не обязательно ставить. В подветках паттерн-мэтчинга и других составных выражений ; ставить не нужно.

Вот кусочек кода в качестве иллюстрации:
variant BinarySearchTree[T] : IEnumerable[T]
    where T : IComparable[T]
{
    | Node
        {
            left : BinarySearchTree[T];
            element : T;
            right : BinarySearchTree[T];
        }
    | Nil
    // ...
    public Add(newElement : T) : BinarySearchTree[T]
    {
        match(this)
        {
            | Node(left, element, right) =>
                match(newElement.CompareTo(element))
                {     
                    | 0  => Node(left, element, right)
                    | c when (c <= -1) => Node(left.Add(newElement), element, right) 
                    | _  => Node(left, element, right.Add(newElement))
                }
            | Nil => Node(Nil(), newElement, Nil())
        }
    }
    // ...
    public static FromList(lst : list[T]) : BinarySearchTree[T]
    {
        lst.FoldLeft(Nil(), (e,a) => a.Add(e))
    }
}


Кроме в Nemerle есть так называемый синтаксис основанный на отступах, как в Питоне. Там ни в каких случаях не нужно ставить ; в конце строки, и даже не нужно пользоваться фигурными скобками. Мне например это не нравится, но судя по Питону и подобным языкам есть любители и такого изврата.
Re[70]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 11.06.06 16:03
Оценка: -1 :)
Здравствуйте, kan_izh, Вы писали:

_>Если пихать всё, получится perl 6.


Если пихать всё, кроме того что нужно, то получится C++.

_>Вот мне не нравится ; ставить в конце каждой строки. А зачем? Вот javascript рулит. И что теперь? Почему эти стандартизаторы c#/java и даже немерла такие косные, что не понимают что мне нравится?


А ты спроси у комитетчиков, почему такого нет в C++.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 11.06.06 17:59
Оценка:
Здравствуйте, FR, Вы писали:

FR>Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования


Про Scala есть статья на RSDN здесь
Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.
. Интересный язык вобщем-то.
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 11.06.06 18:35
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:

FR>>Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования


ДА>Про Scala есть статья на RSDN здесь
Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.
. Интересный язык вобщем-то.


Спасибо я знаю, просто тогда я ничего не понял из их полоумной призентации
Re[45]: Tcl как обоснование ненужности поддержки компонентно
От: Дьяченко Александр Россия  
Дата: 11.06.06 18:50
Оценка:
Здравствуйте, FR, Вы писали:

FR>Спасибо я знаю, просто тогда я ничего не понял из их полоумной призентации


Статья вполне вменяемая, а призентации никакой я не видел поэтому ничего сказать немогу.
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 11.06.06 19:11
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ocaml из совсем другой оперы, а про Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования

Нет, Ocaml это не из другой оперы. Из функциональных языков это самый идейно близкий к Nemerle язык и один из языков наиболее сильно повлиявших на синтаксис и возможности Nemerle. Более того изначально Nemerle выглядел более похоже на Ocaml, но в последствии синтаксис переработали и сделали ближе к C#. Например в первых версиях вместо оператора '=' использовался '<-'(в Ocaml для присваивания полям класса используется такой же оператор). Ключевое слово mutable тоже кстати позаимствованно из Ocaml.

Кроме того Nemish, REPL утилита для Nemerle, практически полностью содрана с оболочки интерпретатора Ocaml(я имею в виду в первую очередь принцип ввода кода и формат в котором она выводит информацию). Я даже думаю создателей Nemerle вдохновило появление F#, клона Ocaml для .NET. Они хотели сделать похожий язык, но более хорошо совместимый с другими языками для CLR. По-моему даже сейчас, когда F# тоже прошел немаленький путь развития, Nemerle проще использовать из C# и наооборот, чем F#.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.06.06 19:41
Оценка: +1 :)))
Здравствуйте, eao197, Вы писали:

Тема плавно и закономерно в очередной раз перетекла к обсуждению софта для АЭС и баллистических ракет.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 11.06.06 22:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>Тема плавно и закономерно в очередной раз перетекла к обсуждению софта для АЭС и баллистических ракет.


Ну дык! Все кругом занимаются исключительно рокет сайнс.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


Сделаем вид, что я не заметил перехода на личности и просто проигнорируем эту детскую демогогию.

VD>>Серьезно? Ну, давай передай сслку на метод в другую ДЛЛ не используя описание в виде исходников.


A>Передам. В чём проблема?


Языком.

VD>>Я уже не говорю о супер синтаксисе все эти _1, _2... и:

VD>>
VD>>f = (&var ->* &someclass::foo);
VD>>

VD>>колдовство на марше да и только.

VD>>Сравни ради хохмы свой пример с немерлом:


A>При чём здесь Nemerle?


При том, что в нем функци первоклассые сущьности.

A> Если ты не в состоянии запомнить о чём идет речь в этой ветке, напомню, что мы обсуждаем свойства и делегаты применительно к C++.


Сделаем вид, что второй раз не заметили переходы на личность оппонента и посоветуем не волне вменяемым оппонентам открыть корень темы и перехти туда откуда она родилась.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка:
Здравствуйте, FR, Вы писали:


FR>Ну конечно куда нам убогим до всемогущего N

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

Да, уж чтение с диска и вычисления если там чего-то нету это очень быстро.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка: :)
Здравствуйте, FR, Вы писали:

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



FR>>>Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение


VD>>А что и кого обошло? GCC слил? VC6 тоже сольет. У Vermicious Knid вот и VC на машине сливает. Твоеи любимые языки сольют так что мама не горюй. Так чем ты тут пыташся подколоть?


FR>Я ничем, это тут у вас война со всем миром.


А как воспринимать твою фразу (выделенно жирным)? Спонтайнной невменяемостью?

FR>Я думаю Vermicious Knid просто ошибся.


Ну, соотвествующую оценку ты за это уже от него получил.

VD>>Вопрос повышения качества оптимизации управляемых сред — это вопрос времени.


FR>Угу и возможно бесконечно большого


Вряд ли. Феникс не ради развлечения делается. Думаю, следующая версия VS после Оркас будет его содержать.

FR>Ну конечно самая важная задача в программировании это вычисление функции Аккермана, ты мне просто глаза раскрыл, большое спасибо


Нет боже упаси. Самые главные задачи конечно же решаются на Питоне.

VD>>Да, лег, лег. (3, 12) не выполнится вообще.


FR>Угу а N лег на 3, 13 а VC8 спокойно вычислил 3, 14


О... серьезный аргумент.

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


FR>Угу час разбежался,


Ну, а тогда нечего выступать.

FR> у меня есть инструмент и он состоит именно из связки двух языков, и я неплохо на нем решаю свои задачи.


"Не плохож" понятие относительное.

FR>А сравнить можно и по отдельности, но не так как хочется тебе, а в области применения этих инструментов.


Ну, и? Уж сколько не сравнивали, а все одно приходим к выводу, что 99% использования С++ есть результат фобий и фанатичной привязанности к нему.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка:
Здравствуйте, FR, Вы писали:

VK>>А вот Nemerle меня привлекает совсем не новизной и оригинальностью(тем более что я знаком с ним с выхода самой первой версии), а именно как практический инструмент для разработки на .NET. Тем более что он действительно на порядок лучше всего того, что есть для этой платформы.


FR>Может быть.

FR>Но мне кажется как про практический инструмент говорить про него рано. Все еще есть вероятность что он останется академической недоделкой, или большим долгостроем (как D).

Вряд ли. Его авторы активны, вменяемы и грамотны. Уверен, что самой большой проблемой Немерла станет скорость компиляции, так как их алгоритм вывода типов чертовски сложен. Это дествительно думатель. Еще одна проблема — это ошибки. Но тут виден огромный прогресс.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

VK>Нет, Ocaml это не из другой оперы. Из функциональных языков это самый идейно близкий к Nemerle язык и один из языков наиболее сильно повлиявших на синтаксис и возможности Nemerle. Более того изначально Nemerle выглядел более похоже на Ocaml, но в последствии синтаксис переработали и сделали ближе к C#. Например в первых версиях вместо оператора '=' использовался '<-'(в Ocaml для присваивания полям класса используется такой же оператор). Ключевое слово mutable тоже кстати позаимствованно из Ocaml.


Скажу больше. Мимикрия под C# — это пожалуй самый правильный ход Немерловцев. Причем общаясь с ними понимаешь, что сами они не люди дотнета. Но именно так язык может освоить действительно значителная часть программистов. Ведь на Немерле можно начать писать как на Шарпе и постепенно въезжать в ФЯ и метапрограммирование. И при этом минимум функционального булшита которым даже этот форум забит по уши.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка:
Здравствуйте, eao197, Вы писали:

E>Видишь ли, такой вещи, как "мой сервер приложений" нет в природе.


Смешно звучит на фоне подписи: " SObjectizer: <микро>Агентно-ориентированное программирование на C++."

... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.06.06 23:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Тема плавно и закономерно в очередной раз перетекла к обсуждению софта для АЭС и баллистических ракет.


Видимо есть всетаки недостаток в том, что эти вещи не работают на С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 11.06.06 23:41
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


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


VD>Сделаем вид, что я не заметил перехода на личности и просто проигнорируем эту детскую демогогию.


Я не виноват. Эту детскую демагогию начал ты своими бесмысленными заявлениями.

VD>>>Серьезно? Ну, давай передай сслку на метод в другую ДЛЛ не используя описание в виде исходников.


A>>Передам. В чём проблема?


VD>Языком.


Тебя трудно понять. Приведи пример проблемы.

VD>>>Я уже не говорю о супер синтаксисе все эти _1, _2... и:

VD>>>
VD>>>f = (&var ->* &someclass::foo);
VD>>>

VD>>>колдовство на марше да и только.

VD>>>Сравни ради хохмы свой пример с немерлом:


A>>При чём здесь Nemerle?


VD>При том, что в нем функци первоклассые сущьности.


A>> Если ты не в состоянии запомнить о чём идет речь в этой ветке, напомню, что мы обсуждаем свойства и делегаты применительно к C++.


VD>Сделаем вид, что второй раз не заметили переходы на личность оппонента и посоветуем не волне вменяемым оппонентам открыть корень темы и перехти туда откуда она родилась.


И плавно перетекла в обсуждение делегатов в C++. Так что советую тебе придерживаться этой темы, потому что обсуждать Nemerle я не намерен.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 12.06.06 00:29
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

VD>>Сделаем вид, что второй раз не заметили переходы на личность оппонента и посоветуем не волне вменяемым оппонентам открыть корень темы и перехти туда откуда она родилась.

A>И плавно перетекла в обсуждение делегатов в C++.
А в соседней подветке она перетекла в обсуждение АЭС и баллистических ракет. Так что же теперь обсуждать баллистические ракеты? Вроде бы это не форум по C++ и не форум по rocket science. Так что обсуждение делегатов в C++ это оффтопик, а вот обсуждение сравнения "делегатов" в C++ и Nemerle это как раз соответствует теме форума.

А>Так что советую тебе придерживаться этой темы, потому что обсуждать Nemerle я не намерен.

За что же ты его так ненавидишь?
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 12.06.06 01:05
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

А>>Так что советую тебе придерживаться этой темы, потому что обсуждать Nemerle я не намерен.

VK>За что же ты его так ненавидишь?

За правду матку в нелестной форме и отсутсвие у себя любимого весомых контраргументов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 04:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Тема плавно и закономерно в очередной раз перетекла к обсуждению софта для АЭС и баллистических ракет.


Потому что AndrewVK включил демагогию на полную и заговорил о вещах, про которых здесь никто, ничего не говорил.
Внимательно перечитай мое сообщение и упоминания в нем систем банковкого процессинга, софта SMS-центров и серверной платформы NonStop.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 04:06
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Видишь ли, такой вещи, как "мой сервер приложений" нет в природе.


VD>Смешно звучит на фоне подписи: " SObjectizer: <микро>Агентно-ориентированное программирование на C++."


Может быть это от незнания того, что такое Application Server?
Так вот SObjectizer сервером приложений не является:

1.5.3 SObjectizer не является сервером приложений

SObjectizer не является сервером приложений. Он не является готовым продуктом
промежуточного слоя (middle tier). SObjectizer — это инструмент для разработки
приложений, в том числе и распределенных. Но SObjectizer не имеет готовых средств
для обеспечения развертывания (deployment) приложений и не обеспечивает, например,
таких сервисов промежуточного слоя, как безопасность (security), маршрутизация
запросов и балансировка нагрузки (load balancing), доступ к корпоративным данным,
долговременное хранение состояний объектов (stateful objects), восстанавливаемость
(fail-over) и пр.

(Е.Охотников, SObjectizer-4 Book)


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 04:08
Оценка: +1 :))
Здравствуйте, VladD2, Вы писали:

AVK>>Тема плавно и закономерно в очередной раз перетекла к обсуждению софта для АЭС и баллистических ракет.


VD>Видимо есть всетаки недостаток в том, что эти вещи не работают на С++.


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



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 12.06.06 04:42
Оценка: +2 -1 :))
Здравствуйте, VladD2, Вы писали:


FR>>>>Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение


VD>>>А что и кого обошло? GCC слил? VC6 тоже сольет. У Vermicious Knid вот и VC на машине сливает. Твоеи любимые языки сольют так что мама не горюй. Так чем ты тут пыташся подколоть?


FR>>Я ничем, это тут у вас война со всем миром.


VD>А как воспринимать твою фразу (выделенно жирным)? Спонтайнной невменяемостью?


Это демонстрация поведения некторых моих опонентов. Хотя если честно сам этим тоже бывает страдаю

FR>>Я думаю Vermicious Knid просто ошибся.


VD>Ну, соотвествующую оценку ты за это уже от него получил.


Я уже отвечал ему, такие вещи нужно подтверждать с цифрами, и еще проверять самому, я давно научился доверять только тестам и профайлеру.

VD>>>Вопрос повышения качества оптимизации управляемых сред — это вопрос времени.


FR>>Угу и возможно бесконечно большого


VD>Вряд ли. Феникс не ради развлечения делается. Думаю, следующая версия VS после Оркас будет его содержать.


Посмотрим.

FR>>Ну конечно самая важная задача в программировании это вычисление функции Аккермана, ты мне просто глаза раскрыл, большое спасибо


VD>Нет боже упаси. Самые главные задачи конечно же решаются на Питоне.


Да нет ты что только на Nemerle

VD>>>Да, лег, лег. (3, 12) не выполнится вообще.


FR>>Угу а N лег на 3, 13 а VC8 спокойно вычислил 3, 14


VD>О... серьезный аргумент.


Конечно, такой же серъезный как и ваш

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


FR>>Угу час разбежался,


VD>Ну, а тогда нечего выступать.


Ну тогда меняй правила и переименуй "философию программирования", например в "оду немерле"

FR>> у меня есть инструмент и он состоит именно из связки двух языков, и я неплохо на нем решаю свои задачи.


VD>"Не плохож" понятие относительное.


Угу, я ужу отучаюсь хвалебные песни чему либо петь

FR>>А сравнить можно и по отдельности, но не так как хочется тебе, а в области применения этих инструментов.


VD>Ну, и? Уж сколько не сравнивали, а все одно приходим к выводу, что 99% использования С++ есть результат фобий и фанатичной привязанности к нему.


По моему ты сильно преувеличиваешь. Раз примерно в 100.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.06.06 06:46
Оценка:
Здравствуйте, eao197, Вы писали:

E>Потому что AndrewVK включил демагогию на полную и заговорил о вещах, про которых здесь никто, ничего не говорил.


Плохо у тебя с чувством юмора. Это была метафора.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 12.06.06 10:37
Оценка: +2
eao197,

VD>>Видимо есть всетаки недостаток в том, что эти вещи не работают на С++.


E>Ты будешь сильно удивлен.

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

На мой взгляд с существованием супернадёжного (или просто надёжного) софта на C++ никто не спорит. Просто этот софт очень дорогой (или просто дорогой).

Принципы построения такого ПО (да и любого другого ПО) просты как двери: нужно выбрать полный непротиворечивый базис абстракций, и эти абстракции реализовать надёжным способом. Абстракции уровня N+1 базируются на абстракциях уровня N. Перефразирую немного с другой стороны: абстрактный слой N выступает в качестве сэндбокса для слоя N+1. Получается некоторое подобие пирамиды, опирающейся на свою вершину.

Если не "срезать углы", то есть из N+1-го слоя _не_ лезть в N-1-й, то всё будет в порядке.

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

(Вероятно "высота/ширина" пирамиды как то будут зависеть от платформы...)

PS: Прошу прощения, что пишу такие банальные вещи.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 12.06.06 10:52
Оценка: +2
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

E>>Ты будешь сильно удивлен.

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

LCR>На мой взгляд с существованием супернадёжного (или просто надёжного) софта на C++ никто не спорит. Просто этот софт очень дорогой (или просто дорогой).


Мне кажется супернадежный софт будет очень дорогим не только на C++. И вполне возможна что его цена такова что вполне позволяет написать специализированный язык только для одной программы, как например тут Еще про ОС
Автор: Cyberax
Дата: 10.06.06
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 11:16
Оценка: 8 (1) +1 -1
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>На мой взгляд с существованием супернадёжного (или просто надёжного) софта на C++ никто не спорит.


На мой взгляд, это как раз не так. Некоторые не только спорят, но прямо таки вопят о том, что это невозможно.

LCR>Просто этот софт очень дорогой (или просто дорогой).


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

Чуть в офтопик. Когда-то давно, году в 93-м попалась мне статья в каком-то компьютерном журнале. В ней рассказывалось о конференции, посвященной созданию надежного программного обеспечения. Во время одного из выступлений докладчик предложил слушателями прочувствовать на себе, что значит разработка надежного софта для опасных производств. Нужно было набросать реализацию контроля температуры парового котла с реакцией на выходы температуры за пределы нормы. Оказалось, что из всех примерно пятнадцати предложенных решений только одно или два были корректны. Подавляющее большинство решений имели серьезные просчеты. В частности, автор статьи ошибочно предположил, что температура котла не может быть отрицательной. Вывод состоял в том, что для создания надежного ПО критически важно создать адекватную модель предметной области. Что и составляет основную сложность. А уже перенос этой модели на конкретную реализацию во многом является делом техники. Кроме того еще более важную роль, чем язык и технология программирования, будет являться система верификации, тестирования и приемки в эксплуатацию.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 12.06.06 12:27
Оценка: +1 -1
Здравствуйте, eao197, Вы писали:

E>Надежный софт не может быть дешевым просто по определению.


Тут хорошо бы услышать определение "надёжный".

E>Имхо, язык программирования в таких задачах добавляет в общую стоимость совсем небольшой процент.


Это заблуждение. Язык программирования, точнее платформа, играет самую непосредственную роль в соотношении качество/цена/сложность. Например, решения на опасных языках вполне может быть надёжным. Но, либо совсем простеньким, либо запредельно дорогим.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 12:44
Оценка: +1 :))
Здравствуйте, IT, Вы писали:

E>>Надежный софт не может быть дешевым просто по определению.


IT>Тут хорошо бы услышать определение "надёжный".


http://en.wikipedia.org/wiki/Reliability_(engineering)

IT>Например, решения на опасных языках вполне может быть надёжным.


Интересное утверждение для того, кто тебовал определение "надежности".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 12.06.06 13:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>Надежный софт не может быть дешевым просто по определению.


IT>>Тут хорошо бы услышать определение "надёжный".


E>http://en.wikipedia.org/wiki/Reliability_(engineering)


Wikipedia does not have an article with this exact name


IT>>Например, решения на опасных языках вполне может быть надёжным.


E>Интересное утверждение для того, кто тебовал определение "надежности".


Возможно мы его по разному понимаем. По крайней мере вы с викой точно не одного мнения
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 13:22
Оценка:
Здравствуйте, IT, Вы писали:

E>>http://en.wikipedia.org/wiki/Reliability_(engineering)


IT>

IT>Wikipedia does not have an article with this exact name


Закрывающая круглая скобка не попадает в URL (тем не менее он правильный).
Попробуй так или так. Только похоже, что именно сейчас Wika в дауне.

IT>По крайней мере вы с викой точно не одного мнения


Откуда ты знаешь, ты же не читал?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 12.06.06 14:02
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>По крайней мере вы с викой точно не одного мнения


E>Откуда ты знаешь, ты же не читал?


Как я могу прочитать, ты же ссылку кривую дал
Если нам не помогут, то мы тоже никого не пощадим.
Re[45]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.06 14:05
Оценка:
Здравствуйте, IT, Вы писали:

IT>Как я могу прочитать, ты же ссылку кривую дал


Ссылка правильная http://en.wikipedia.org/wiki/Reliability_(engineering) -- это у вас какой-то распознаватель URL в текстах сообщений не надежный


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 12.06.06 14:08
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ссылка правильная http://en.wikipedia.org/wiki/Reliability_(engineering) -- это у вас какой-то распознаватель URL в текстах сообщений не надежный


Самый что ни на есть надёжный. Работает в точности как предполагалось дизайном. Просто вы его готовить не умеете
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.06.06 02:24
Оценка: -1
Здравствуйте, alexeiz, Вы писали:

VD>>Сделаем вид, что я не заметил перехода на личности и просто проигнорируем эту детскую демогогию.


A>Я не виноват. Эту детскую демагогию начал ты своими бесмысленными заявлениями.


Если у тебя проблемы с вменяемостью, то у нас есть средство поставить тебя на место.
Достаточно мне или другому модератору заметить твои переходны на личность. Так что предлагаю не доводя до помывочных мероприятий вернуться в конструктивное русло.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.06.06 02:24
Оценка:
Здравствуйте, eao197, Вы писали:

E>Может быть это от незнания того, что такое Application Server?


Точно! Ты угадал!

E>Так вот SObjectizer сервером приложений не является:

E>

E>1.5.3 SObjectizer не является сервером приложений

E>SObjectizer не является сервером приложений. Он не является готовым продуктом
E>промежуточного слоя (middle tier). SObjectizer — это инструмент для разработки
E>приложений, в том числе и распределенных. Но SObjectizer не имеет готовых средств
E>для обеспечения развертывания (deployment) приложений и не обеспечивает, например,
E>таких сервисов промежуточного слоя, как безопасность (security), маршрутизация
E>запросов и балансировка нагрузки (load balancing), доступ к корпоративным данным,
E>долговременное хранение состояний объектов (stateful objects), восстанавливаемость
E>(fail-over) и пр.

E>(Е.Охотников, SObjectizer-4 Book)
E>

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

Вобщем, можешь дальше заниматься поисками слов для докапывания и других весомый аргументов для того, чтобы закрывать глаза на тот факт, что выбранные тобой инструменты явно не для твоего бютжета.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 13.06.06 03:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Сделаем вид, что я не заметил перехода на личности и просто проигнорируем эту детскую демогогию.


A>>Я не виноват. Эту детскую демагогию начал ты своими бесмысленными заявлениями.


VD>Если у тебя проблемы с вменяемостью, то у нас есть средство поставить тебя на место.

VD>Достаточно мне или другому модератору заметить твои переходны на личность. Так что предлагаю не доводя до помывочных мероприятий вернуться в конструктивное русло.

что и тебе советую вместо того, чтобы прятаться за нравоучениями.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.06.06 08:18
Оценка: 6 (2)
Здравствуйте, VladD2, Вы писали:

E>>Может быть это от незнания того, что такое Application Server?


VD>Точно! Ты угадал!


Это было не сложно.

E>>Так вот SObjectizer сервером приложений не является:

E>>

E>>1.5.3 SObjectizer не является сервером приложений

E>>SObjectizer не является сервером приложений. Он не является готовым продуктом
E>>промежуточного слоя (middle tier). SObjectizer — это инструмент для разработки
E>>приложений, в том числе и распределенных. Но SObjectizer не имеет готовых средств
E>>для обеспечения развертывания (deployment) приложений и не обеспечивает, например,
E>>таких сервисов промежуточного слоя, как безопасность (security), маршрутизация
E>>запросов и балансировка нагрузки (load balancing), доступ к корпоративным данным,
E>>долговременное хранение состояний объектов (stateful objects), восстанавливаемость
E>>(fail-over) и пр.

E>>(Е.Охотников, SObjectizer-4 Book)
E>>

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


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

Если погуглить, то получается интересная подборка определений:
1.

Application Server: A software platform that provides the services and infrastructure required to develop and deploy middle-tier applications. Middle-tier applications perform the business logic necessary to provide web clients with access to enterprise information systems. In a multi-tier architecture, an application server sits beside a web server or between a web server and enterprise information systems. Application servers provide the middleware for enterprise systems.


2

Application server. Also called an appserver. A program that handles all application operations between users and an organization's backend business applications or databases. Application servers are typically used for complex transaction-based applications. To support high-end needs, an application server has to have built-in redundancy, monitors for high-availability, high-performance distributed application services and support for complex database access.


3

Application server definition

An application server is a component-based product that resides in the middle-tier of a server centric architecture. It provides middleware services for security and state maintenance, along with data access and persistence.


4 про J2EE сервера и контейнеры от Sun:

J2EE Server

The J2EE server provides the following services:

* Naming and Directory — allows programs to locate services and components through the Java Naming and Directory InterfaceTM (JNDI) API
* Authentication — enforces security by requiring users to log in
* HTTP — enables Web browsers to access servlets and JavaServer PagesTM (JSP) files
* EJB — allows clients to invoke methods on enterprise beans

EJB Container

Enterprise bean instances run within an EJB container. The container is a runtime environment that controls the enterprise beans and provides them with important system-level services. Since you don't have to develop these services yourself, you are free to concentrate on the business methods in the enterprise beans. The container provides the following services to enterprise beans:

* Transaction Management
* Security
* Remote Client Connectivity
* Life Cycle Management
* Database Connection Pooling



Не мог бы ты показать, по каким признакам SObjectizer попадает хотя бы под одно из этих определений?

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


Можно ли раскрыть мысль об "инструментах не для моего бюджета"? А то я смысла последней фразы совсем не уловил.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.06.06 00:28
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>что и тебе советую вместо того, чтобы прятаться за нравоучениями.


Заметь, я тебя ничему не учитл, и вместо обсуждения проблемы на твою личность не переключался.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.06.06 00:28
Оценка:
Здравствуйте, eao197, Вы писали:


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


Да, нет. Класс, если не ошибаюсь более точно называется "MOM Message Oriented Middleware".
Ну, да спорить о термирах мне не интересно. Готов называть его хоть горшом при условии, что мы сойдеся на том, что это серверный софт разрабатываемый в условиях очень ограниченных ресурсов.

E> И, кстати, лично я не представляю себе сервер приложений, который не обеспечивает deployment-а.


Хм. Таких хватает. MSMQ, например, не обеспечивает. Ему и не надо. Его задача сообщения пересылать.

E>Можно ли раскрыть мысль об "инструментах не для моего бюджета"? А то я смысла последней фразы совсем не уловил.


Думаю ты его и сам понимаешь. Серверный софт на С++ требует огромных вложений на тестирование и разработку (ведь какое количество обвязки прийдется создать). Я уже не говорю о вложениях в разработку интерфейса к массовым средствам разработки прикладных решений. Ведь если твое ришение не является приклдным, то решения создаваемые с его использованием являются таковыми. И как я понял из твоей статьи, ты предпологашь создавать их тоже на С++. А это себе уже мало кто может позволить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.06.06 04:04
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Да, нет. Класс, если не ошибаюсь более точно называется "MOM Message Oriented Middleware".


Не более точно, а по другому. MOM и Application Server-а -- это два разных типа продукта. Хотя в Application Server может входить и поддержка MOM. Например, в виде реализации спецификации JMS в EJB контейнерах.

MOM -- это действительно ниша, с которой SObjectizer довольно сильно пересекается. Пока что больше всего общих черт у SObjectizer обнаружилось с TIB/Rendezvous, краткое сравнение можно найти здесь
Автор: eao197
Дата: 22.05.06
. Более полное и подробное сравнение сделаю когда дочитаю документацию по Rendezvous.

VD>Ну, да спорить о термирах мне не интересно. Готов называть его хоть горшом при условии, что мы сойдеся на том, что это серверный софт разрабатываемый в условиях очень ограниченных ресурсов.


Сам по себе SObjectizer не является серверным софтом. Он может использоваться для создания серверного софта. А может для создания вычислительных распределенных приложений (вместо MPI или VPM). А может и для создания standalone приложений, например, софта для работы с каким-нибудь оборудованием вроде SmartCard-ридеров.

E>> И, кстати, лично я не представляю себе сервер приложений, который не обеспечивает deployment-а.


VD>Хм. Таких хватает. MSMQ, например, не обеспечивает. Ему и не надо. Его задача сообщения пересылать.


MSMQ это не сервер приложений.

E>>Можно ли раскрыть мысль об "инструментах не для моего бюджета"? А то я смысла последней фразы совсем не уловил.


VD>Думаю ты его и сам понимаешь. Серверный софт на С++ требует огромных вложений на тестирование и разработку (ведь какое количество обвязки прийдется создать). Я уже не говорю о вложениях в разработку интерфейса к массовым средствам разработки прикладных решений. Ведь если твое ришение не является приклдным, то решения создаваемые с его использованием являются таковыми. И как я понял из твоей статьи, ты предпологашь создавать их тоже на С++. А это себе уже мало кто может позволить.


Это все так (за исключением слишком больших затрат на тестирование, тестирование и Java приложений требует аналогичных вложений). Поэтому SObjectizer и не применяется для разработки ПО, для которого предназначены те же самые J2EE технологии. Однако не только Enterprise нуждается в server side решениях.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: [Benchmark] Еще раз про Аккерман на разных языках
От: Андрей Хропов Россия  
Дата: 15.06.06 20:19
Оценка: 7 (2)
Ежели кому интересно, сегодня проверил еще на альтернативном компиляторе для D

GDC (front-end от Digital Mars, back-end от GCC)

gdmd.pl akk.d -O -release -inline -ofakk-gdc.exe



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

Так что проблема в плохо оптимизирующем back-end от Digital Mars.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.06 01:13
Оценка:
Здравствуйте, IT, Вы писали:

IT>Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.

Кстати, только вчера нарвался на аналогичные чудеса.
Вызываем IXMLDocument::selectSingleNode().
Проверяем его результат на SUCCEEDED.
Пытаемся работать с out-параметром.
Упс! Оказывается, эти орлы возвращают S_FALSE, который считается успешным результатом. Ну и получаем классической ASSERT p!=0.
Коды ошибок — отстой.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[58]: Tcl как обоснование ненужности поддержки компонентно
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.06 01:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>Было бы любопытно услышать, что по этому поводу думают сторонники properties.

Все очень просто. Дело в том, что с точки зрения теории кристалла, у объекта есть состояние (скрытое) и поведение (публичное).
Инкапсуляция требует, чтобы о состоянии объекта (например, значениях его приватных полей) можно было узнать только через его поведение (методы).
Ну вот рассмотрим объект Вася. У него есть метод Подшутить. В полном соответствии с ООП его поведение в ответ на этот метод (некоторые предпочитают трактовать метод как посылку Васе сообщения "шутка") зависит от его состояния. Предположим, что Вася может находиться только в двух состояниях: "веселый" и "злой". Внешнему наблюдателю не дано узнать о состоянии Васи напрямую, зато он может узнать о нем опосредованно: "веселый" Вася в ответ засмеется, а "злой" обидится и даст шутнику в репу.

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

Но дело в том, что практика показала частое наличие потребности все же управлять состоянием объекта. Возьмем, к примеру, автомобиль. У него довольно сложное состояние, которое управляется более-менее широким интерфейсом. Но мы можем выделить некую относительно изолированную часть состояния, например bool "двигатель запущен". И возникает желание добавить к публичному интерфейсу автомобиля способ получать и менять это состояние. И вот такое поведение объекта, служащее для контроля за изолированной частью состояния, и есть свойство. Это ничему не противоречит. Во-первых, эта часть состояния вовсе не обязана соответствовать никакому физическому полю. Это абстракция. Во-вторых, в отличие от физического поля, попытка изменить состояние не является нарушением инкапсуляции.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[67]: Tcl как обоснование ненужности поддержки компонентно
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.06 01:13
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Внимание вопрос! Что произойдет, если при сериализации восстановится

C>сначала поле с процентом?

А вот этот вопрос — прямое следствие заблуждения. Почему-то некоторые люди доводят утверждение "Свойство — это интерфейс объекта, отвечающий за управление изолированной частью его состояния" до абсурда: "Всё состояние объекта полностью описывается его свойствами". Из этого фундаментального заблуждения сразу же следует еще одно: "Для сериализации обхекта достаточно сериализовать значения всех его свойств".
Ребята, сериализация как таковая не имеет никакого отношения к свойствам. Это же всего лишь превращение состояния объекта в поток байт.

Иногда полезно иметь свойства ортогональными. Но это не обязательно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Tcl как обоснование ненужности поддержки компонентно
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.06 03:52
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Вот мне и интересно, что под этим можно понимать? Под термином "данные объекта", или "функция объекта", или "класс" ясно, что скрывается. А вот что такое "свойство"? Класс? Или не класс?

Свойство — это, вообще говоря, паттерн.
Вот его примерное определение: свойство — это часть контракта объекта, обеспечивающая управление изолированной частью его состояния.
Подробнее: если удается выделить некоторую изолировнную часть состояния объекта (например, Height), и ей имеет смысл управлять отдельно, то можно дать доступ на чтение к этим данным и на запись этих данных.

Реализация этого паттерна существенным образом зависит от языка. В примитивных языках приходится извращаться при помощи функций типа GetWindowText/SetWindowText.
В более продвинутых языках паттерн реализуется методами класса.
В совсем продвинутых языках этот паттерн поддерживается напрямую и не требует никаких соглашений, что упрощает читаемость кода, снижает количество случайных ошибок, и предоставляет метаданные о реализации данного паттерна средствам метапрограммирования.

IT>>И дальше что? Как ты собираешься это использовать?


ГВ>Да как-как. Вот так, к примеру:

Не вижу в примере упоминаний ни Property, ни AdvancedProperty.
Собственно, фундамент непонимания происходит именно от того, что не вполне оправданно реализовывать свойство в виде отдельного класса. Значение свойства — пожалуйста. Впрочем, проблема понятна — нельзя выразить в терминах С++ то, чего в нем нету. Принципиально нету.
Кстати, на досуге советую помедитировать также над паттерном Event, который является несколько более сложным аналогм паттерна Property.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: icWasya  
Дата: 07.07.06 07:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Понимаешь, свойство выглядит и ведет себя как член класса. На член

C>класса я могу взять ссылку (в С++).
А на метод ???
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 07.07.06 11:27
Оценка: -1
icWasya wrote:

> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член

> C>класса я могу взять ссылку (в С++).
> А на метод ???
Да.
typedef Result Object::*MethodRef(Param);

MethodRef — указатель на возвращающй Result метод объекта Object с параметром типа Param.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.06 00:22
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

ГВ>>Вот мне и интересно, что под этим можно понимать? Под термином "данные объекта", или "функция объекта", или "класс" ясно, что скрывается. А вот что такое "свойство"? Класс? Или не класс?

S>Свойство — это, вообще говоря, паттерн.
S>Вот его примерное определение: свойство — это часть контракта объекта, обеспечивающая управление изолированной частью его состояния.

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

S>Подробнее: если удается выделить некоторую изолировнную часть состояния объекта (например, Height), и ей имеет смысл управлять отдельно, то можно дать доступ на чтение к этим данным и на запись этих данных.


Интересно, а read-only часть состояния "Perimeter" связана с Height или нет?

S>Реализация этого паттерна существенным образом зависит от языка. В примитивных языках приходится извращаться при помощи функций типа GetWindowText/SetWindowText.

S>В более продвинутых языках паттерн реализуется методами класса.

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


Как известно, паттерн на то и паттерн, что подразумевает много реализаций. Реализация классом — одна из них.

S>Собственно, фундамент непонимания происходит именно от того, что не вполне оправданно реализовывать свойство в виде отдельного класса. Значение свойства — пожалуйста. Впрочем, проблема понятна — нельзя выразить в терминах С++ то, чего в нем нету. Принципиально нету.


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

S>Кстати, на досуге советую помедитировать также над паттерном Event, который является несколько более сложным аналогм паттерна Property.


Чтобы тебе не соврать... Года четыре-пять назад тут много над ним медитировали. Ключевое слово: "делегаты". Дальше — в поиск.
<< Под музыку: Башня Rowan — Марш уродов >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.06 05:00
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Свойство — это, вообще говоря, паттерн.


Ты не верно интерпретируешь понятие "паттерн".

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

Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу. Вопрос только в качестве и простоте этого изменения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 08.07.06 07:41
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Ты не верно интерпретируешь понятие "паттерн".


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


А по моему ты неверно привязываешь понятие паттерн к конкретным языкам. Мне кажется паттерн более общее понятие не зависящее от языков. В той же бандитской книге есть много оговорок что например данный патерн реализуется в смаллток просто конструкциями языка, но паттерном от этого быть не перестает.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: alexeiz  
Дата: 08.07.06 09:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


IT>>Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.

S>Кстати, только вчера нарвался на аналогичные чудеса.
S>Вызываем IXMLDocument::selectSingleNode().
S>Проверяем его результат на SUCCEEDED.
S>Пытаемся работать с out-параметром.
S>Упс! Оказывается, эти орлы возвращают S_FALSE, который считается успешным результатом. Ну и получаем классической ASSERT p!=0.
S>Коды ошибок — отстой.

Сначала я думал, что виноваты коды ошибок. На самом деле здесь виноват ты в том, что не прочёл документации, и не знаешь, что возвращаемый resultNode может быть NULL.

Ты хочешь, чтобы функция возвратила ошибочный код, если node не найден. Если такое поведение перевести на язык C#, например, то это будет эквивалентно выбрасыванию исключения. Такой подход не имеет смысла, потому что ситуация, когда node не может быть найден в xml документе, типична, а вовсе не исключительна. Поэтому использование исключения (в варианте C#) как и ошибочного кода возврата (в варианте C++) здесь не правомерно.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.06 11:23
Оценка:
Здравствуйте, FR, Вы писали:

FR>А по моему ты неверно привязываешь понятие паттерн к конкретным языкам. Мне кажется паттерн более общее понятие не зависящее от языков. В той же бандитской книге есть много оговорок что например данный патерн реализуется в смаллток просто конструкциями языка, но паттерном от этого быть не перестает.


Это только по-твоему. Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.

Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 08.07.06 11:32
Оценка:
kan_izh wrote:

>> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член

>> C>класса я могу взять ссылку (в С++).
>> А на метод ???
> Да.
> typedef Result Object::*MethodRef(Param);
> MethodRef — указатель на возвращающй Result метод объекта Object с
> параметром типа Param.
Э... Что неправильно? Почему "-", VladD2?

Если вопрос заключался в "а на метод объекта", то достаточно запомнить пару — this и указатель на метод класса. В
качестве удобной реализации этой идеомы можно boost::function взять.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 08.07.06 11:42
Оценка:
kan_izh wrote:
>> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
>> C>класса я могу взять ссылку (в С++).
>> А на метод ???
> Да.
> typedef Result Object::*MethodRef(Param);
> MethodRef — указатель на возвращающй Result метод объекта Object с
> параметром типа Param.
А теперь вызови его без указателя this

Что-то с boost::function было бы более похоже на правду, но там от
семантики ссылки уже мало что останется.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 08.07.06 12:37
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это только по-твоему. Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.


Смысл паттернов не зависит от того реализованы или нет они на каком-то языке, это влияет только на легкость исползования.

VD>Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.


И что? Скажем так, это деталь реализации данного патерна для некторых языков
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 08.07.06 13:13
Оценка:
Cyberax wrote:

>> > C>Понимаешь, свойство выглядит и ведет себя как член класса. На член

>> > C>класса я могу взять ссылку (в С++).
>> > А на метод ???
>> Да.
>> typedef Result Object::*MethodRef(Param);
>> MethodRef — указатель на возвращающй Result метод объекта Object с
>> параметром типа Param.
> А теперь вызови его без указателя this
Тоже путаем класс и объект?

> Что-то с boost::function было бы более похоже на правду, но там от

> семантики ссылки уже мало что останется.
Т.е.?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: Cyberax Марс  
Дата: 08.07.06 13:33
Оценка:
kan_izh wrote:
>> А теперь вызови его без указателя this
> Тоже путаем класс и объект?
Нет, прочитай топик сначала — флейм был о свойствах (которые не добавили
тупые стандартизаторы С++).

>> Что-то с boost::function было бы более похоже на правду, но там от

>> семантики ссылки уже мало что останется.
> Т.е.?
Свойство обладает, фактически, семантикой обычной ссылки. То есть
маскируется под обычную переменную.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.06 14:12
Оценка: :)
Здравствуйте, VladD2, Вы писали:

A>>boost::function отлично выполняет эту функцию.


VD>1. boost::function не является примитивом языка.


Очень хорошо.

VD>2. Он не компилируется на некоторых компиляторах, а значит доступен не везде.


Беда компиляторов.

VD>3. Он имеет ряд проблем в применении.


Основная, как я понимаю — невозможность неожиданно изменить время жизни объектов, вовлекаемых в замыкание. Нормальная деталь программирования на C++ — контроль жизненного цикла объекта.

VD>4. Примеры с тем что ты называшь лямбдами вообще никуда не годятся.


Ну в качестве примеров они вполне годятся.

VD>5. Реализация этого дела ужасна. Она значительно увеличиывает время компиляции и ухудшает понятность сообщений об ошибках.


Субъективные факторы, кроме времени компиляции. Мне вот, например, сообщения понятны.

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


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

VD>В общем, если даже принять во внимане boost::function, все равно в языке остается слишком много лишнего сахара который вообще не реализовать средствами языка, и средства изменения языка очень окграничены.


А зачем менять синтаксис языка? Задача как правило состоит в реализации тех или иных концепций и подходов, как с теми же замыканиями.

VD>Как иминимум нет возможности изменить синтаксис.


Это недостаток?

VD>А изменение семантики сложно, неполноценно и чревато проблемами.


Если ты про изменение семантики операторов, то оно происходит по вполне точным "законам жанра": чего-то можно, чего-то нельзя.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[59]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.06 14:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>

E>>[...]Moreover, these public fields have side effects!


E>>Было бы любопытно услышать, что по этому поводу думают сторонники properties.

WH>Демагогия обыкновенная. Такая "аргументация" в данном форуме очень частое явление. Особенно когда реальных аргументов нет.

Насчёт побочных эффектов невинного "obj.val = 123" всё правильно сказано.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[59]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.06 14:47
Оценка:
Здравствуйте, Sinclair,

Так в чём, всё-таки, глобальный дифференс между свойством "bool engine_active" и функцией "bool is_engine_active() const"? Кроме подслащения синтаксиса, разумеется.

И ещё, кстати, инкапсуляция сама по себе от пользователей ничего не требует. Вот такое обращение:

SomeClass *p = ...;

p->internal_data_ = 0;


означает прямое изменение инкапсулированных данных, а не "нарушение инкапсуляции". SomeClass как инкапсулировал (содержал) internal_data_, так и продолжает это делать. Правда такое обращение противоречит концепции скрытия данных. Разницу между "скрытием" и "содержанием" объяснять нужно?
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: kan_izh Великобритания  
Дата: 08.07.06 16:04
Оценка:
Cyberax wrote:

>> > А теперь вызови его без указателя this

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

>> > Что-то с boost::function было бы более похоже на правду, но там от

>> > семантики ссылки уже мало что останется.
>> Т.е.?
> Свойство обладает, фактически, семантикой обычной ссылки. То есть
> маскируется под обычную переменную.
Вроде, не семантикой. Семантически — это метод, который синтаксически выглядит как переменная.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.06 16:18
Оценка:
Здравствуйте, FR, Вы писали:

FR>Смысл паттернов не зависит от того реализованы или нет они на каком-то языке, это влияет только на легкость исползования.


Ошибаешся. Паттерн это именно прием эмуляции недостающей функциональности. Если же фукнциональность есть, то нужны ее эмулировать нет. И стало быть писать код проще.

VD>>Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.


FR>И что? Скажем так, это деталь реализации данного патерна для некторых языков


Ты серьезно считашь паттерн-матнчинг реализацией Посетителя? Я вот так не считаю. Однако нужда в Посетителе при этом отпадает. Причем код при этом получается более высокоуровневым. А ведь паттерн-матчинг не более чем сахар. Все что он делает можно сэмулировать паттернами проектирования на if-ах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 08.07.06 16:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Смысл паттернов не зависит от того реализованы или нет они на каком-то языке, это влияет только на легкость исползования.


VD>Ошибаешся. Паттерн это именно прием эмуляции недостающей функциональности. Если же фукнциональность есть, то нужны ее эмулировать нет. И стало быть писать код проще.


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

VD>>>Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.


FR>>И что? Скажем так, это деталь реализации данного патерна для некторых языков


VD>Ты серьезно считашь паттерн-матнчинг реализацией Посетителя? Я вот так не считаю. Однако нужда в Посетителе при этом отпадает. Причем код при этом получается более высокоуровневым. А ведь паттерн-матчинг не более чем сахар. Все что он делает можно сэмулировать паттернами проектирования на if-ах.


Нет. Патерн-матчинг не может полностью заменить посетителя (вот мультиметоды могут) с его помощью просто удобно решать многие из тех задач для решения которых был придуман посетитель.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 08.07.06 17:29
Оценка: +1
Здравствуйте, VladD2, Вы писали:

FR>>А по моему ты неверно привязываешь понятие паттерн к конкретным языкам. Мне кажется паттерн более общее понятие не зависящее от языков. В той же бандитской книге есть много оговорок что например данный патерн реализуется в смаллток просто конструкциями языка, но паттерном от этого быть не перестает.


VD>Это только по-твоему.


По-моему тоже.

VD>Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.


Под оными ты понимаешь паттерны, правильно?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.06 17:41
Оценка: 1 (1) +1 :))
Здравствуйте, VladD2, Вы писали:

VD>Ну, и? Уж сколько не сравнивали, а все одно приходим к выводу, что 99% использования С++ есть результат фобий и фанатичной привязанности к нему.


А 99% обвинений в адрес C++ следствие патологического неумения им пользоваться.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.06 19:17
Оценка: +1
Здравствуйте, VladD2, Вы писали:

S>>Свойство — это, вообще говоря, паттерн.

VD>Ты не верно интерпретируешь понятие "паттерн".

Синклер как раз паттерн и описал.

VD>По-моему, паттерн — это некий стандартный способ эмуляции некоего подразумеваемого поведения или свойства.


Паттерн — просто общая схема.

VD>Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка.


Ну, поехали противопоставлять не противопоставимое.

VD>А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.


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

VD>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.


В C++ нету паттернов, потому что паттерны не являются частью спецификации C++. Смекаешь?

VD>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.


Хм. Сам-то понял, что сказал? Как это можно встроить "паттерн", который не является частью спецификации языка? Чё-то тут не так в консерватории.

VD>Вопрос только в качестве и простоте этого изменения.


Прежде чем говорить о "качестве" неплохо определиться с показателями этого самого "качества".
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 00:37
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А 99% обвинений в адрес C++ следствие патологического неумения им пользоваться.


Ты уже доказал, что я там, IT или Вольфхаунд паталогически неумеем им пользоваться? Раз нет, то будем придерживаться мнения, что пользоваться им неумешь ты или еще кто. ОК?

К тому же тут не обвиняется сам С++. Глупо обвинять продукт. Обвиняются те дуболомы которые пишут на нем прикладной софт и тот дуболом который его спроектировал.

Сам же С++ нормальный продукт рекламы. Массам влили в уши что писать нужно на нем они и повелись. Сейчас слава богу вливают более разуный выбор. Будем надеяться, что результат повторится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 00:37
Оценка:
Здравствуйте, FR, Вы писали:

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


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

VD>>Ты серьезно считашь паттерн-матнчинг реализацией Посетителя? Я вот так не считаю. Однако нужда в Посетителе при этом отпадает. Причем код при этом получается более высокоуровневым. А ведь паттерн-матчинг не более чем сахар. Все что он делает можно сэмулировать паттернами проектирования на if-ах.


FR>Нет. Патерн-матчинг не может полностью заменить посетителя (вот мультиметоды могут) с его помощью просто удобно решать многие из тех задач для решения которых был придуман посетитель.


Акстись. Посетитель идет лесом при наличии паттерн матчинга. Этот ублюдочный паттерн нужен исключительно потому, что в современных ООЯ нет полноценных и выразительных средств распознования полиморфных объектов.

Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 00:37
Оценка:
Здравствуйте, IT, Вы писали:

VD>>Это только по-твоему.


IT>По-моему тоже.


Ну, и зря.

VD>>Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.


IT>Под оными ты понимаешь паттерны, правильно?


Вот определения паттерна проектирования:
http://en.wikipedia.org/wiki/Special:Search?search=pattern+GOF

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0201633612) is a software engineering book proposing standard solutions and naming conventions to common problems in software design.


Так вот если в языке есть средства позволяющие не прибегать к "стандартным решениям и солашениям по именованию", то глупо называть их паттернами. Например, паттерн-матчинг имеет мало общего с паттерном проектирования Посетитель. Однако при наличии первого второй теряет смысл. В принципе теряет. Так как то что получается с помощью "стандартного решения и солашений по именованию" нманого менее удобно и более трудоемко чем стандартная возможность языка которая ко всему прочему являюется куда более универсальным решением.

Другой пример — итераторы. Когда в Яве (до 1.5) я вынужден прибегать к "стандартным решениям и солашениям по именованию" для того чтобы и реализовать нужное мне поведение и использовать его, то я имею дело с чистым паттерном проектирования. В коде я виже не этот паттерн, а код его реализующий. При этом я вынужден мысленно декодировать паттерн в код, и наоборот воссоздовать по коду паттерн (хотя бы уметь разглядеть паттерн в коде).
В C# 1.х мне уже проще. Я могу переложить отвественность за перебор последовательностей на компилятор. Причем он сам разберется использовать ли паттерн проектирования Итератор (т.е.е IEnulerable/IEnumerator) или просто переписать код в паттерн кодирования:
for (int i = 0; i < array.Length; i++)
{
    SomeType elem = array[i];
    ...
}

и так далее.
Однако я по прежнему обязан использовать паттерн проектирования Итератон чтобы реализовать возможность перебора значений своей коллекции. Задача конечно может быть облегчена наличием базовых классов, но в общем случаея я вынужден опять же кодировать паттерн и распозновать его в коде.
В C# 2.0 я получаю ко всему прочему возможность под названием Итератор:
IEnulerable Xxx(...)
{
    ...
  yield ...
}

Это паттерн? Мне не нужно что либо декодировать или распозновать в коде. Я имею дело с конструкцией языка. Да его идея основан на паттерне, но для меня это уже не паттерн — это уже часть языка. Итераторы C# 2.0 позволяют мне оперировать более высокоуровневыми сущьностями нежели "стандартным решениям и солашениям по именованию". Они вводят синтаксис в язык и берут на себя заботу о реализации.

Вот что отличает возможность языка от паттерна проектирования.

Мне не нужно уже оперировать понятием паттернв в языке где есть нужные возможности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 00:37
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Паттерн — просто общая схема.


Именно. И если схемы нет, а есть конкретный синтаксис, то о паттерне уже говорить глупо. Иначе можно говорить о паттерне statment, expression, if, while, for и т.п.

VD>>Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка.


ГВ>Ну, поехали противопоставлять не противопоставимое.


Тебе показалось.

VD>>А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.


ГВ>А вот если ещё не забывать, что термин "паттерн" широко используется в психологии, откуда, подозреваю, он и перекочевал в программирование...


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

VD>>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.


ГВ>В C++ нету паттернов, потому что паттерны не являются частью спецификации C++. Смекаешь?


В С++ нет: свойств, интерфейсов, указателей на функции объектов и т.п. И когда кто-то говорит о данных сущьностях в языке, то имеет в виду как раз паттерн. А говорят о них много и часто. Многие свято уверены, что в С++ есть те же интерфейсы, как не странно. А многие считают boost::lambda частью С++, хотя это тоже только лишь паттерн реализованный во внешней библиотеке.

VD>>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.


ГВ>Хм. Сам-то понял, что сказал?


Да. Но ты не расстраивайся. Без некоторой подготовки это можно легко не понять.

ГВ> Как это можно встроить "паттерн", который не является частью спецификации языка? Чё-то тут не так в консерватории.


Вот так. Если язык позволяет расширение синтаксиса и семантики, то с разным успехом можно встроить паттерн в язык.

VD>>Вопрос только в качестве и простоте этого изменения.


ГВ>Прежде чем говорить о "качестве" неплохо определиться с показателями этого самого "качества".


А они очевидны:
1. Бесшовность интеграции с другими возможностями языка.
2. Неотличимость встаеваемого паттерна от встроенных возможностей языка.
3. Отсуствие значительного снижения скорости компиляции.
4. Качественные сообещения об ошибках и дагностичесие сообщения.
5. Гибкость решений которые можно получить таким образом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.06 03:47
Оценка: +1
Здравствуйте, VladD2, Вы писали:

ГВ>>Паттерн — просто общая схема.

VD>Именно. И если схемы нет, а есть конкретный синтаксис, то о паттерне уже говорить глупо. Иначе можно говорить о паттерне statment, expression, if, while, for и т.п.

Ничего подобного. Паттерн продолжает болтаться в стороне от языка, как и болтался изначально.

VD>>>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

ГВ>>В C++ нету паттернов, потому что паттерны не являются частью спецификации C++. Смекаешь?
VD>В С++ нет: свойств, интерфейсов, указателей на функции объектов и т.п. И когда кто-то говорит о данных сущьностях в языке, то имеет в виду как раз паттерн. А говорят о них много и часто.

Почти всё почти так, за исключением указателей на функции объектов, кои в C++ есть.

VD>Многие свято уверены, что в С++ есть те же интерфейсы, как не странно. А многие считают boost::lambda частью С++, хотя это тоже только лишь паттерн реализованный во внешней библиотеке.


Верно. Именно реализованный во внешней библиотеке.

VD>>>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.

ГВ>>Хм. Сам-то понял, что сказал?
VD>Да. Но ты не расстраивайся. Без некоторой подготовки это можно легко не понять.

Паттерны можно реализовать на ассемблере. Ergo, ассемблер — высокоуровневый и выразительный язык.

Ладно, приоткрою тебе карты, а то что-то понесло тебя куда-то в совсем уж неизвестность.

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

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

ГВ>> Как это можно встроить "паттерн", который не является частью спецификации языка? Чё-то тут не так в консерватории.

VD>Вот так. Если язык позволяет расширение синтаксиса и семантики, то с разным успехом можно встроить паттерн в язык.

Это означает, что базовым языком является не тот, который изменяется, а тот, на чём эти изменения написаны, только и всего. Полученное подмножество суть domain-specific language, хоть ты тресни.

VD>>>Вопрос только в качестве и простоте этого изменения.

ГВ>>Прежде чем говорить о "качестве" неплохо определиться с показателями этого самого "качества".
VD>А они очевидны:

А вот это уже интересно.

VD>1. Бесшовность интеграции с другими возможностями языка.


Что есть "шов" в данном случае? Если взять аналогичный термин из лексикона интеграторов, то они так обозначают необходимость писать некий софт для связи программ между собой. Очевидно, что, например, при использовании boost::function подобного шва и в помине нет.

VD>2. Неотличимость встаеваемого паттерна от встроенных возможностей языка.


В чём заключена "отличимость" в таком случае?

VD>3. Отсуствие значительного снижения скорости компиляции.


Странный критерий, ну он хоть более или менее предметный.

VD>4. Качественные сообещения об ошибках и дагностичесие сообщения.


Ну давай, раскрывай тему о качественных сообщениях.

VD>5. Гибкость решений которые можно получить таким образом.


Здесь поконкретнее, плз. Например, функторы STL можно передать по ссылке, создать, удалить и т.п. Никаких ограничений.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[40]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.06 03:47
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

ГВ>>А 99% обвинений в адрес C++ следствие патологического неумения им пользоваться.

VD>Ты уже доказал, что я там, IT или Вольфхаунд паталогически неумеем им пользоваться?

Ты апеллируешь к "фобиям" и "фанатизму", я — к "патологическому неумению". Это просто симметричная формулировка. На самом деле и то и другое обвинение — глупости.

VD>Раз нет, то будем придерживаться мнения, что пользоваться им неумешь ты или еще кто. ОК?


Можно поиграться, но и ты тогда докажи, что у твоих оппонентов именно "фобии" и "фанатическая привязанность". А мы до тех пор будем считать истинным утверждение, что фобии и фанатическая ненависть (или паче чаяния — привязанность?) — у тебя. И от такого славного персонажа, богатого фобиями и ненавистью я вполне принимаю обвинения в том, что не умею пользоваться C++.

А ещё есть конструктивный вариант: откажемся от таких утверждений на паритетной основе. Но тебе придётся отказаться первому.

VD>К тому же тут не обвиняется сам С++. Глупо обвинять продукт. Обвиняются те дуболомы которые пишут на нем прикладной софт и тот дуболом который его спроектировал.


Что там у нас по поводу поворачивания субъектных утверждений на 180 градусов?

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


Знаешь, иногда меня просто шокируют такие рассуждения. На самом деле, продуктом рекламы является психоз вокруг .Net/Java и никто из этого не делает ни тайны, ни открытия. Но назвать С++ продуктом рекламы — это ты сильно загнул!
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 09.07.06 04:35
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>>>Это только по-твоему.

IT>>По-моему тоже.
VD>Ну, и зря.

Это не то, чтобы "и зря", это не только не зря, это просто — правильно.

IT>>Под оными ты понимаешь паттерны, правильно?


VD>Вот определения паттерна проектирования:

VD>http://en.wikipedia.org/wiki/Special:Search?search=pattern+GOF
VD>

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0201633612) is a software engineering book proposing standard solutions and naming conventions to common problems in software design.


Это не определение паттерна проектирования. Это краткое описание книжки, в которой описан набор наиболее общих паттернов проектирования.

Вот правильная ссылка Design pattern (computer science)

In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design.


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


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

VD> Например, паттерн-матчинг имеет мало общего с паттерном проектирования Посетитель. Однако при наличии первого второй теряет смысл. В принципе теряет.


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

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


С этим никто не спорит. Спорят тут с тем, что ты неверно для себя сформулировал понятие паттерн проектирования и совершенно необоснованно ограничил его примерами из книжки GOF.

VD>Вот что отличает возможность языка от паттерна проектирования.


Эти вещи нельзя сравнивать. От реализации паттерна средствами языка, паттерн не исчезает. Он просто реализуется средствами языка.

VD>Мне не нужно уже оперировать понятием паттернв в языке где есть нужные возможности.


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

Да-да, я знаю о чём ты подумал И я с тобой полностью в этом согласен. Немерле как раз то самое средство. Именно в этом я вижу его наибольшую ценность. Библиотеки макросов Немерле — это ни что иное как библиотеки паттернов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 09.07.06 05:40
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>Понимаш ли, если я могу выразить мысль кратко и доступно, применив при этом возможности языка описанные во введение в этот язык, то "типовых решений" мне не нужно. Типовые решения нужны там где язык не предоставляет удобного и простого способа решения проблемы. Посетитель как раз тот случай. Паттерн в принципе не нужен в более мощьных языках. Именно по этом все функциональщики в один голос говорят, что созадние парсеров и компиляторов на ФЯ получается лучше всего.


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


VD>Акстись. Посетитель идет лесом при наличии паттерн матчинга. Этот ублюдочный паттерн нужен исключительно потому, что в современных ООЯ нет полноценных и выразительных средств распознования полиморфных объектов.


Интересно

VD>Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.


Покажи мне там же хоть один объект.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 15:28
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Можно поиграться, но и ты тогда докажи, что у твоих оппонентов именно "фобии" и "фанатическая привязанность".


Я как истенный джентелмен предоставляю првао нести бремя оказательства тем кто обвиняет своих оппонентов в некомпетентности, то есть тебе.

А вообще, людей реально можно оценить толкьо в деле. К сожалению, я даже не надеюсь, что увижу от тебя хоть какое-то дело. Хотя было бы забавно поглядеть.

ГВ> А мы до тех пор будем считать истинным утверждение, что фобии и фанатическая ненависть (или паче чаяния — привязанность?) — у тебя. И от такого славного персонажа, богатого фобиями и ненавистью я вполне принимаю обвинения в том, что не умею пользоваться C++.


Ну, это понты и пустословье. Оставим это.

ЗЫ

И вообще, у меня складывается впечатление, что переписку с вашей групой давно читает только эта самая группа. И я ловлю себя на мысли, что занимаюсь развлечением этой группы хотя в этом нет ни малейшего смысла.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 15:28
Оценка:
Здравствуйте, FR, Вы писали:

VD>>Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.


FR>Покажи мне там же хоть один объект.


http://nemerle.org/svn/nemerle/trunk/ncc/passes.n

Твой ход.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 15:28
Оценка:
Здравствуйте, IT, Вы писали:

VD>>>>Это только по-твоему.

IT>>>По-моему тоже.
VD>>Ну, и зря.
IT>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.

В столь конструктивной беседе могу только продолжить ряд — не правильно.

IT>Это не определение паттерна проектирования. Это краткое описание книжки, в которой описан набор наиболее общих паттернов проектирования.


IT>Вот правильная ссылка Design pattern (computer science)


IT>

In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design.


Что в лоб, что полбу. Смысл не изменяется.

IT>От того что некоторые паттерны непосредтственно реализуются языковыми конструкциями они не перестают быть паттернами.


Перестают. Они перестают быть "repeatable solution". Они превращаются в синтаксис языка. К тому же речь не идет о тупом переносе паттернов в язык. Речь идет о создании более высокоуровневых решений.


IT> Те 26 (или сколько их там) паттернов из книжки GOF — это не все возможные паттерны, это лишь их небольшое множество.


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

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


Всякая иделогия вгоняет в свои рамки. Ты слишком погрузился в рамки паттернов. Оторвись от нее и просто скажи будешь ли ты мыслить паттернами описывая арефмитическое выражение, например?

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

VD>> Например, паттерн-матчинг имеет мало общего с паттерном проектирования Посетитель. Однако при наличии первого второй теряет смысл. В принципе теряет.


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


Смысл теряет вообще думать о паттерне. Все становится очевидно. Мы просто пишем код:
match (comeObj)
{
    A => действия для A
    B => действия для B
    C => действия для C
    _ => действия по-умолчанию
}


Ну не будеш же ты думать как о паттерне, скажем, о switch-е или if-е?

IT> Но сам паттерн никуда не девается.


Да, в том то и дело что девался! Он просто стал не нужен. Нет задачи кторую нужно им решать! Неужели это не очевидно?!

Поттерн решает некую задачу. Это стандартное решение для часто встречающихся задач. И если задачи эти больше решать не надо, то и паттерн теряет смысл.

Опять же я не говорю о том, что паттерны вовсе не нужны и сто все можно впихнуть в язык. Я просто говорю о том, что более мощьный язык позволяет избежать оперирование некоторыми паттернами. Вместо этого он позволяет оперировать куда более высокоуровневыми абстракциями. Паттерн-матчинг только один пример. В общем, грамотнй и не тривиальный синтаксический сахар может легко сделать не нужными многие паттерны.

IT> Я, например, склонен относить к паттернам даже такие вещи как наследование и инкапсуляцию.


И зря. Потому что они явно реализованы в ООЯ. А вот в С это действительно будет паттерн. В ООЯ я выражаю наследование настолько просто, что мне не нужно думать о нем как о паттерне: "class A : B { }" все! А вот на С я обязан буду надолбить кучу кода и решить ряд не тривильных задач. Тут паттерн очень нужен, так как до всех тонкостей нужно еще додуматься.

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

В общем, это уже скорее терминалогический спор.

IT> И что с того, что они встроены в языки и про них написана куча толстых книжек? Мне пофиг, для меня это лишь хорошие шаблоны, используемые мной в качестве элементов моего дизайна. Типовые идеи и типовые решения проблем.


Да то что они попросту не нужны.

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

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


IT>С этим никто не спорит. Спорят тут с тем, что ты неверно для себя сформулировал понятие паттерн проектирования


Я его не формулировал. Ты и сам его привел — "repeatable solution to a commonly-occurring problem in software design". Так вот я просто говорю о том, что если у меня нет проблем, то и выражать их в виде паттерна мне не нужно.

IT>и совершенно необоснованно ограничил его примерами из книжки GOF.


Ну, извини GoF ввели этот термин. К тому же твое определение мало чем отличается. Важно то, что паттерн — подразумевает проблему и решение. А я уже устал повторять, что есть языки для которых проблемы решаемые некоторыми паттернами выглядят просто смешно. Эти паттерны прикрывают недостатки языков в которых одни были придуманы. И думать ими просто глупо если есть более простые и эффективные решения.

VD>>Вот что отличает возможность языка от паттерна проектирования.


IT>Эти вещи нельзя сравнивать. От реализации паттерна средствами языка, паттерн не исчезает. Он просто реализуется средствами языка.


Ну, повторяться 25-ый раз я пожалуй не буду. См. выше.

VD>>Мне не нужно уже оперировать понятием паттернв в языке где есть нужные возможности.


IT>Оперировать понятиями паттерн нужно всегда, только не так как это делаешь ты. Паттерн — это типовое решение определённой задачи, выявленный и сформированный подход к решнию повторяющихся задач дизайна приложения.


Мне ответят на вопрос? Зачем мне типовоер решение для тривильных задач? Зачем мне типовое решение для операции сложения? Зачем мне типовое решение для условного перехода? Я могу думать о задаче проще и я буду это делать. Паттерн устраняет сложность, а если нет сложности, то нет... Хотя опять повторяюсь.

IT>Да-да, я знаю о чём ты подумал И я с тобой полностью в этом согласен.


Я рад, что ты подумал о том о том, что я подумал, о том о чем подумал ты. И я согласен, что паттерны можно автоматизировать. Но я то говорил все же о другом. Жаль что ты присоеденился к группе Блабл-программистов которе смотрят на проблемы только с известных им колоколен. Меж тем мир шире и многогранее.

IT> Немерле как раз то самое средство. Именно в этом я вижу его наибольшую ценность. Библиотеки макросов Немерле — это ни что иное как библиотеки паттернов.


Немерле еще к тому еж и язык в котром изначально больше средств. И именно это дает возможность ему напрочь отказаться от многих паттернов необъодимых в современных ООЯ. Но это не его заслуга. Он просто грамотно впитал в себя более высокоуровневые и мощьные конструкции.

Меня отровенно радуют некоторые случаи в которых макаронный код получается переписать кратче и понятнее. Вот например такой код:
internal set_unparsed_state () : void
{
    mutable fileList : list[string * string] = [];

    foreach (file in sources)
        match (file.Value)
        {
        | Parsed as p => fileList ::= (file.Key, p.code);
        | _ => ();
        }

    foreach (item in fileList)
        sources [item [0]] = ParsedFile.NotParsed (item [1]);
}

я с большим удовольствием переписал так:
internal set_unparsed_state () : void
{
    foreach ((fileName, Parsed(_, code)) in _sources.KeyValuePairs)
        _sources[fileName] = ParsedFile.NotParsed(code);
}

А вот такой же код на C# (декомпиляция предыдущего варианта подправленная для читаемости):
internal void set_unparsed_state()
{
  foreach (Tuple<string, ParsedFile> elem in this._sources.KeyValuePairs)
  {
    if (elem.field1 is ParsedFile.Parsed)
    {
      string code = ((ParsedFile.Parsed) elem.field1).code;
      this._sources[elem.field0] = new ParsedFile.NotParsed(code);
    }
  }
}

Точнее это я уже распознал один паттерн. Декомпилированный код был таким:
internal void set_unparsed_state()
{
  Tuple<string, ParsedFile>[] cached_collection = this._sources.KeyValuePairs;
  for (int i = 0; i < cached_collection.Length; i++)
  {
    Tuple<string, ParsedFile> elem = cached_collection[i];
    if (elem.field1 is ParsedFile.Parsed)
    {
      string code = ((ParsedFile.Parsed) elem.field1).code;
      this._sources[elem.field0] = new ParsedFile.NotParsed(code);
    }
  }
}

Вот и спрашивается нафига мне выглядывать паттерны в макаронном коде когда я могу исходно думать более высокоуровневыми конструкциями.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 09.07.06 16:25
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.


FR>>Покажи мне там же хоть один объект.


VD>http://nemerle.org/svn/nemerle/trunk/ncc/passes.n


VD>Твой ход.


Для парсера на ФЯ там слишком много internal mutable
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 09.07.06 17:16
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>>>>>Это только по-твоему.

IT>>>>По-моему тоже.
VD>>>Ну, и зря.
IT>>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.
VD>В столь конструктивной беседе могу только продолжить ряд — не правильно.

Продолжаем — это твоё заблуждение

IT>>Вот правильная ссылка Design pattern (computer science)

IT>>

In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design.


VD>Что в лоб, что полбу. Смысл не изменяется.


Очень даже изменяется. Судя по твоей ссылке, для тебя паттерн — это один из перечисленных в книжке паттернов. Это — заблуждение. Паттерн — более широкое понятие.

IT>>От того что некоторые паттерны непосредтственно реализуются языковыми конструкциями они не перестают быть паттернами.


VD>Перестают. Они перестают быть "repeatable solution". Они превращаются в синтаксис языка. К тому же речь не идет о тупом переносе паттернов в язык. Речь идет о создании более высокоуровневых решений.


А языковые решения ты используешь не как "repeatable solution"?

IT>> Те 26 (или сколько их там) паттернов из книжки GOF — это не все возможные паттерны, это лишь их небольшое множество.


VD>И, что? Никто и не говорит о том, что можно вообще жить без паттернов. Но если язык предоставляет средства делающий конкретный паттерн не нужным, то зачем мне он?


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

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


VD>Всякая иделогия вгоняет в свои рамки. Ты слишком погрузился в рамки паттернов.


Какая ещё идеология, какие рамки? Я просто называю вещи своими именами.

VD>Оторвись от нее и просто скажи будешь ли ты мыслить паттернами описывая арефмитическое выражение, например?


В арифметических выражениях тоже можно выявлять паттерны, но эти паттерны не являются паттернами проектирования.

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


Ты путаешь понятие паттерна и его реализации. Попытайся это понять.

VD>Ну не будеш же ты думать как о паттерне, скажем, о switch-е или if-е?


Как о паттерне проектирования? Вряд ли. Как о паттерне вообще, конечно же буду. Просто центр принятия решения об использовании этих паттернов у меня уже давно находится не в голове, а на кончиках пальцев.

IT>> Но сам паттерн никуда не девается.

VD>Да, в том то и дело что девался! Он просто стал не нужен. Нет задачи кторую нужно им решать! Неужели это не очевидно?!

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

VD>Поттерн решает некую задачу. Это стандартное решение для часто встречающихся задач. И если задачи эти больше решать не надо, то и паттерн теряет смысл.


И куда по твоему подевались задачи?

IT>> Я, например, склонен относить к паттернам даже такие вещи как наследование и инкапсуляцию.


VD>И зря. Потому что они явно реализованы в ООЯ. А вот в С это действительно будет паттерн.


Я же говорю, ты путаешь понятия паттерн и реализация паттерна.

VD>Короче, ИТ, ответь на простой вопрос. Нафига мне Посетитель если те же задачи я могу решить проще и эффективнее?


Решай, кто тебе не даёт Речь ведь не об этом.

IT>>С этим никто не спорит. Спорят тут с тем, что ты неверно для себя сформулировал понятие паттерн проектирования


VD>Я его не формулировал. Ты и сам его привел — "repeatable solution to a commonly-occurring problem in software design". Так вот я просто говорю о том, что если у меня нет проблем, то и выражать их в виде паттерна мне не нужно.


Если паттерн уже выражен другими средствами, то, конечно, не нужно.

IT>>и совершенно необоснованно ограничил его примерами из книжки GOF.


VD>Ну, извини GoF ввели этот термин.


Но они нигде не утверждали, что паттерн — это только то, что описано у них в книжке.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.06 19:48
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>> А мы до тех пор будем считать истинным утверждение, что фобии и фанатическая ненависть (или паче чаяния — привязанность?) — у тебя. И от такого славного персонажа, богатого фобиями и ненавистью я вполне принимаю обвинения в том, что не умею пользоваться C++.


VD>Ну, это понты и пустословье. Оставим это.


Не уходи от ответа. Ну так что, обоюдно укорачиваем языки? Ты — на "фобии", "фанатизм" и прочее подобное, я — на ответные обвинения в паталогической неспособности к C++ (сиречь — необоснованные обвинения в некомпетености)? Ы?
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 22:48
Оценка:
Здравствуйте, IT, Вы писали:

label1:

VD>>>>>>Это только по-твоему.
IT>>>>>По-моему тоже.
VD>>>>Ну, и зря.
IT>>>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.
VD>>В столь конструктивной беседе могу только продолжить ряд — не правильно.

IT>Продолжаем — это твоё заблуждение

goto label1; // :)


IT>Очень даже изменяется. Судя по твоей ссылке, для тебя паттерн — это один из перечисленных в книжке паттернов.


Тебе показалось. Просто это перво что нашлось.

IT>А языковые решения ты используешь не как "repeatable solution"?


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

label2:

VD>>И, что? Никто и не говорит о том, что можно вообще жить без паттернов. Но если язык предоставляет средства делающий конкретный паттерн не нужным, то зачем мне он?

IT>Ещё раз попытайся понять то, что я уже устал повторять.


А ты не повторяй. Я и с первого раза неплохо слышу.

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


Извини, но еще раз:
goto label2; // просьба вникнуль в написанное.


IT>Какая ещё идеология, какие рамки? Я просто называю вещи своими именами.


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

IT>В арифметических выражениях тоже можно выявлять паттерны,


Нет, нет. Речь не о паттернах в выражениях. А о самих выражениях. Ну, там паттерн сложения. Или паттерн деления.

IT> но эти паттерны не являются паттернами проектирования.


А чем собственно сложение отличается от оперетора switch?


VD>>Ну не будеш же ты думать как о паттерне, скажем, о switch-е или if-е?


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


Ну, вот и славненко. Теперь осталось только понять, что switch от match отличается только тем, что match делает ненужным применение паттернов вроде Посетителя.

Собстевенно ты все сказал сам. Проблема в том, что ты пока неосознаешь того что конструкции языка могут быть настолкьо высокоуровневыми, что к чертям собачим отменяют некоторые паттерны проектирования.

Паттерны проектирования ведь в первую очередь нужны для понимания между людьми. Думаю, ты и раньше (до ГоФ) применял разные паттерны незадумываясь о том, что это паттерн. А ГоФ предожили дать им имена. Это позволяет мне только произнести к примеру Фабрика или Посетитель и ты понимашь в общих чертах о каком примере я говорю. Так вот имея паттерн-матчинг просто нет смыла говорить Посетител. Он вообще не нужен, так как то зачем он предназначен решается применением одного единственного универсального оператора. Еще глупее будет говорить паттерн "match". Ведь это оператор. И нет проблем говорить "оператор match".

Так что проектируя с прицелом на язык с поддержкой паттерн-матчинга ты просто скажешь "для каждого воплощения типа сделать то-то-то". Собственно это и есть главный выигрышь от применения более мошьного языка. Но еще важнее, что потом в коде мне не прийдется высматривать тот самый паттерн. Я просто увижу что "для каждого воплощения типа сделать то-то-то".

Так что я все же остаюсь при своем мнении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 22:48
Оценка: -1
Здравствуйте, FR, Вы писали:

VD>>http://nemerle.org/svn/nemerle/trunk/ncc/passes.n


VD>>Твой ход.


FR>Для парсера на ФЯ там слишком много internal mutable


И тем неменее это парсер на ФЯ в котором нет ни одного Посетителя и от этого только проще становится. Так что ход неудачный. Гейм овер.

А вообще свои догмы нужно разрушать. Чистых ФЯ практически нет. Хаскель, Схема... что там еще? Все остальные ФЯ поддерживают императивные возможности, но ФЯ от этого быть не перестают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.06 22:48
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не уходи от ответа. Ну так что, обоюдно укорачиваем языки? Ты — на "фобии", "фанатизм" и прочее подобное, я — на ответные обвинения в паталогической неспособности к C++ (сиречь — необоснованные обвинения в некомпетености)? Ы?


Назвать твой лепет обвинениями слишком много чести откровенно говоря. Про фанатизм тут тоже не я первый заговорил.

А что до фобий. Что вижу о том и говорю. Если вижу ничем не оправданные домыслы и паталогическую боязнь чего-то то и говорю — фобии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 09.07.06 23:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>
VD>label1:
VD>

VD>>>>>>>Это только по-твоему.
IT>>>>>>По-моему тоже.
VD>>>>>Ну, и зря.
IT>>>>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.
VD>>>В столь конструктивной беседе могу только продолжить ряд — не правильно.

IT>>Продолжаем — это твоё заблуждение

VD>
VD>goto label1; // :)
VD>


Почему goto, а не функция с концевой рекурсией?

VD>
VD>label2:
VD>

VD>>>И, что? Никто и не говорит о том, что можно вообще жить без паттернов. Но если язык предоставляет средства делающий конкретный паттерн не нужным, то зачем мне он?

VD>Извини, но еще раз:

VD>
VD>goto label2; // просьба вникнуль в написанное.
VD>


Сколько раз вникаю, столько раз и вижу, что ты путаешь понятия паттерн и реализация паттерна.

VD>Нет. Ты начианашь называть и другие вещи одним и тем же именем.


Какие такие другие вещи?

VD>Если трактовать термины слишком широко то начинается полная неразбериках. Все же есть язык и его конструкуции, а есть паттерны которые позволяют выразить с помощью несколькоих конструкций языка то, что нельзя выразить одной.


Если очень узко трактовать, то получается, что паттерны — это только то, что описали GoF в своей книжке.

IT>>В арифметических выражениях тоже можно выявлять паттерны,


VD>Нет, нет. Речь не о паттернах в выражениях. А о самих выражениях. Ну, там паттерн сложения. Или паттерн деления.


Не пойму причём тут операции

IT>> но эти паттерны не являются паттернами проектирования.


VD>А чем собственно сложение отличается от оперетора switch?


В каком плане?

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


VD>Ну, вот и славненко. Теперь осталось только понять, что switch от match отличается только тем, что match делает ненужным применение паттернов вроде Посетителя.


Да мне всё равно чем отличается switch от match. А то, что им очень удобно реализуется паттерн вроде посетителя так это вообще здорово.

VD>Паттерны проектирования ведь в первую очередь нужны для понимания между людьми.


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

VD>Так что я все же остаюсь при своем мнении.


OK.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Tcl как обоснование ненужности поддержки компонентно
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.06 03:36
Оценка: +3
Здравствуйте, VladD2, Вы писали:
VD>Ты не верно интерпретируешь понятие "паттерн".
Верно.
VD>По-моему, паттерн — это некий стандартный способ эмуляции некоего подразумеваемого поведения или свойства. Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка. А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.
И чем это противоречит моему определению? Влад, "его нет" в большинстве мейнстримовых языков. А в тех, которых есть, оно почему-то реализовано существенно по-разному. Например, в Delphi определялось отображение свойства на независимо существующие методы и поля. В шарпе уже ничего такого нет. Что из этого является свойством? Кроме того, в Delphi есть вшитая реализация паттерна Factory. Ты, я надеюсь, не предлагаешь под этим предлогом выкинуть этот паттерн из всех учебников и заменить его ссылкой на virtual constructor?

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

VD>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

Совершенно верно.
VD>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык.
На 100% согласен.
VD>В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.
Даже на 150%. Вообще возникает вопрос: а стоит ли встраивать в язык все известные паттерны? Не сделает ли это язык громоздким и неудобным в изучении? С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются, и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++
VD>Вопрос только в качестве и простоте этого изменения
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: WolfHound  
Дата: 10.07.06 06:20
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Даже на 150%. Вообще возникает вопрос: а стоит ли встраивать в язык все известные паттерны? Не сделает ли это язык громоздким и неудобным в изучении? С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются, и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++

Но реализовать это смогли польские студенты.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.07.06 06:33
Оценка: -2
Здравствуйте, VladD2, Вы писали:

FR>>Для парсера на ФЯ там слишком много internal mutable


VD>И тем неменее это парсер на ФЯ в котором нет ни одного Посетителя и от этого только проще становится. Так что ход неудачный. Гейм овер.


mutable убивает ФЯ. Так что ФЯ там и не пахнет, просто императивный язык с патерн матчингом.

VD>А вообще свои догмы нужно разрушать. Чистых ФЯ практически нет. Хаскель, Схема... что там еще? Все остальные ФЯ поддерживают императивные возможности, но ФЯ от этого быть не перестают.


Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.06 18:09
Оценка:
Здравствуйте, FR, Вы писали:

FR>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.


Это пустобрехство. ОКамл ничем не отличается от Немарал и писать на нем можно как угодно. Если пимеративный вариант оказывается быстрее и/или понятнее/удобнее, то его игнорирование и демонстративное предпочтение функционального стиля является пижонством и глупостью.

Хотя собственно это все к рассматреваемому аспекту отношения не имеет. Ты в очередной раз хочешь уйти от сути. А суть прстоа. В языке могут быть мощьные конструкции делающие ненужными те или ниые паттерны проектирования. Это факт и никуда от этого не деться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.06 18:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>И чем это противоречит моему определению? Влад, "его нет" в большинстве мейнстримовых языков.

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

S> А в тех, которых есть, оно почему-то реализовано существенно по-разному. Например, в Delphi определялось отображение свойства на независимо существующие методы и поля. В шарпе уже ничего такого нет. Что из этого является свойством?


Свойством является свойство. А разница наблюдаемая тобой — это разница в синтаксисе языков. Функции ты тоже по разному описываешь в разных языках. Ты же не считашь при этом функцию паттерном?

S> Кроме того, в Delphi есть вшитая реализация паттерна Factory. Ты, я надеюсь, не предлагаешь под этим предлогом выкинуть этот паттерн из всех учебников и заменить его ссылкой на virtual constructor?


А причем тут учебники? Для дельфи существует понятие метакласса и говоря в терминах дельфи смысла в использовании паттерна фабрика действительно нет. Ты конечно можешь оперировать паттерном фабрика просто ради того, что бы определить дизайн приложения в срассчете на самый убогий язык из некоторого списка. Но при переходе к дельфи ты будешь оперировать понятием метакласса, а частности паттерна тебе будут по барабану.

Или уж тогда давай говорить, что все конструкции языка — это паттрены. Паттрен if, паттерн switch, паттерн "+"... А что? Для ассемблера или, к примеру, Форта это действительно будут паттерны проектирования. Ну, а для Немерла, например, исчезает паттерн проектирования Посетитель.

S>Так что ключевое слово property или определенный синтаксис являются реализацией паттерна. А сам паттерн существует совершенно независимо от языка. Свойство можно реализовать даже на ассемблере.


И if, как я уже сказал, можно реализовать на Ассемблере. Но ты же не оперируешь с ним как с паттерном? И не делашь ты это только потому, что if на языке высокого уровня для небя не паттерн, а первоклассаная операция. Точно так же свойство для тебя первоклассная сущность и думаь о нем как о паттерне прото неразумно. Нет главной составляющей паттерна "repeatable solution to a commonly-occurring problem" так как нет самой проблемы. Она становится тривиальной и описывается тривиально. То етсь нет ни проблемы, ни решения. Есть просто синтаксическая конструкция.

VD>>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

S>Совершенно верно.
VD>>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык.
S>На 100% согласен.

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

VD>>В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.

S>Даже на 150%. Вообще возникает вопрос: а стоит ли встраивать в язык все известные паттерны?

Все, наверно, нет. Хотя вопрос откровенно говоря стоит отдельного анализа. По карйней мере я еще не видел проблем от того, что в язык был включен тот или ной паттерн в виде высокоуровневой конструкции.

S> Не сделает ли это язык громоздким и неудобным в изучении?


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

Хотя понятие громоздкость плохо детерминировано. Возможно луче подходит термин "выразительность".

С точки зрения кривой обучения вопрос не столь очевиден. Потяно, что чем больше понятий впитал в себя язык тем сложнее его выучить. Но тут играет роль то, что для начальной стадии обучения все потятия могут оказаться не нужны. Меж тем те же приемы описанные в ГоФ являются пожалуй необходимым минимумо и хороший программист о них должен знать. И я не вижу ничего плохого если им будет придана краткая и простая форма.

S> С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются,


Очень редко. Но другое дело что есть прикладные паттерны. Вроде тех что хотят охватить в LINQ. Вот их действительно масса и для них действительно лучше иметь расширяемый язык. Но именно расширяемый язык, а не отверстие в заднем проходе.

S> и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++


Не, они этим отмазываются. А сам С++ имеет только одно штатное средство расширения — свои убогие макросы. Все остальное через зад. Результат соотвествующий.

Так что дух в С++ правильный, а вот реализация ни к черту.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.07.06 18:22
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.


VD>Это пустобрехство. ОКамл ничем не отличается от Немарал и писать на нем можно как угодно. Если пимеративный вариант оказывается быстрее и/или понятнее/удобнее, то его игнорирование и демонстративное предпочтение функционального стиля является пижонством и глупостью.


Тогда не надо было про ФЯ заявления делать.

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


Только от этого паттерны и польза от них не исчезают.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 10.07.06 18:23
Оценка: 31 (1) +1
Здравствуйте, FR, Вы писали:

FR>mutable убивает ФЯ. Так что ФЯ там и не пахнет, просто императивный язык с патерн матчингом.

Очередное безответственное заявление. В таком случае "неубитые" ФЯ можно буквально пересчитать по пальцам(практически всем критериям неубитости соответсвует только Haskell). На самом деле во всем мире используется такая терминология как pure functional и non-pure functional. Так вот Nemerle это non-pure functional language, так же как и OCaml.

FR>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.

Что значит "нормальный"? Громадное количество кода на OCaml в таком случае это ненормальный код или как(включая код из стандартной библиотеки)? Я например видел парсеры на OCaml в которых было очень много императивного. С какой стати это ненормально?

На Nemerle тоже можно писать код не использующий императивные возможности, в том числе и парсеры, с неменьшим успехом чем на OCaml. Только это уже фанатизм, а Nemerle создавался не как язык для фанатов ФП.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.07.06 18:50
Оценка: -1
Здравствуйте, Vermicious Knid, Вы писали:

FR>>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.

VK>Что значит "нормальный"? Громадное количество кода на OCaml в таком случае это ненормальный код или как(включая код из стандартной библиотеки)? Я например видел парсеры на OCaml в которых было очень много императивного. С какой стати это ненормально?

Нормально только это уже не ФЯ а ИЯ.
Вот у меня в одном проекте на питоне процентов 60 кода функционально, но я бы не стал его приводить как пример ФЯ.

VK>На Nemerle тоже можно писать код не использующий императивные возможности, в том числе и парсеры, с неменьшим успехом чем на OCaml. Только это уже фанатизм, а Nemerle создавался не как язык для фанатов ФП.


Так я не против пишите как удобно.

Вообще разговор про ФЯ начался с того что Влад мне предложил найти хоть один паттерн посетитель в коде гипотетического парсера на ФЯ (подерживающим паттерн матчинг). Я ему предложил найти там хоть один объект (так как паттерны сильно привязаны именно к ООП). После чего был предложен код на Nemerle не имеющий никакого отношения к ФЯ. Давай теперь из этого будем раздувать ФЯ vs ИЯ, предлагаю еще добавить сюда же еше и safe vs unsafe для полного комплекта.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.06 18:58
Оценка:
Здравствуйте, FR, Вы писали:

FR>Тогда не надо было про ФЯ заявления делать.


Ты пыташся одной ошибочной мыслью обосновать вторую не мнее ошибочную. Причем между ними просто нет связи.
Все что я тебе тут сказал верно. Немерле это ФЯ и в основном код его компилятора тяготеет к ФС. И в его компиляторе нет ни одного Посетителя. Но ты совершенно прав в том аспекте, что нет Посетителей не потому, то немерле ФЯ, а потому что в нем есть мощьный паттерн-матчинг делающий примененение паттерна Посетитель неразумным. Вот только другие ФЯ я привел исключительно из-за того, что паттерн-матчинг есть исключительно в ФЯ. Собственно сам Немерле это ФЯ. Просто в очередной раз ты не верно понимашь терминлогию. Vermicious Knid верно заметил, что функциональным является любой язык хорошо поддерживающий функциональный стиль и позволяющий писать программы исключительно в его рамках. И это не противоречит ни тому, что на этом же языке можно писать императивный код, ни тому, с какой частатой на языке пишут в том или ином стиле.

Забавно, что я лично выбрасывал функциональные навороты в Немерлевом коде только потому, что они были более громоздкими и непонятными нежели императивный аналог. Например, я как-то написал код испльзующих метод Fold для фильтрации содержимого массива (выборки ненулевых элементов), а потом заменил его на foreach с if-ом так как это оказалось проще и понятнее.

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

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


FR>Только от этого паттерны и польза от них не исчезают.


В языках поддерживающих паттерн-матчинг исчезает на прочь. А для более низкоуровневых языков естественно смысл в Посетителе остается. Это единственный способ вывести полиморфизм за пределы класса в таких языках. Причем способ спорный. Используя Посетителя мы с одной стороны получаем приемущество так как не требуется расширять иерархию классов для введения новой обработки, но получаем нехилый геморрой при добавление нового вида обработки (ведь нужно менять уже не только классы, но и все посетители). Причем нет никакой возможности осуществлять обработку по умолчанию, а конролировать полноту обработчиков можно только в рантайме.

Паттерн-матчинг же в сочетании с алгеброическими типами позволяет решить проблему намного лучше и обеспечивает отличный контроль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Tcl как обоснование ненужности поддержки компонентно
От: FR  
Дата: 10.07.06 20:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Тогда не надо было про ФЯ заявления делать.


VD>Ты пыташся одной ошибочной мыслью обосновать вторую не мнее ошибочную. Причем между ними просто нет связи.


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

VD>Все что я тебе тут сказал верно. Немерле это ФЯ и в основном код его компилятора тяготеет к ФС. И в его компиляторе нет ни одного Посетителя. Но ты совершенно прав в том аспекте, что нет Посетителей не потому, то немерле ФЯ, а потому что в нем есть мощьный паттерн-матчинг делающий примененение паттерна Посетитель неразумным. Вот только другие ФЯ я привел исключительно из-за того, что паттерн-матчинг есть исключительно в ФЯ. Собственно сам Немерле это ФЯ. Просто в очередной раз ты не верно понимашь терминлогию.


Ладно здесь я заспорился, но ты тоже невнятно формулировал свои мысли. Терминологию я вполне нормально понимаю, просто тебе не надо было про ФЯ говорить, сказал бы только про паттерн матчинг.

VD> Vermicious Knid верно заметил, что функциональным является любой язык хорошо поддерживающий функциональный стиль и позволяющий писать программы исключительно в его рамках. И это не противоречит ни тому, что на этом же языке можно писать императивный код, ни тому, с какой частатой на языке пишут в том или ином стиле.


VD>Забавно, что я лично выбрасывал функциональные навороты в Немерлевом коде только потому, что они были более громоздкими и непонятными нежели императивный аналог. Например, я как-то написал код испльзующих метод Fold для фильтрации содержимого массива (выборки ненулевых элементов), а потом заменил его на foreach с if-ом так как это оказалось проще и понятнее.


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

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


Да ладно

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


FR>>Только от этого паттерны и польза от них не исчезают.


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


Не единственный есть еще мультиметоды и замена посетителя на замыкания и рекурсию.
Re[38]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.06 21:10
Оценка: +1
Здравствуйте, FR, Вы писали:

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


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

FR>Ладно здесь я заспорился, но ты тоже невнятно формулировал свои мысли. Терминологию я вполне нормально понимаю, просто тебе не надо было про ФЯ говорить, сказал бы только про паттерн матчинг.


Хм. Какие проблемы? Я сказал то что есть на самом деле. Я не виноват, что паттерн-матчинг родился в ФЯ. И в том что Немреле по стечению обстоятельств тоже ФЯ, хотя и не чистый (как и 90 других ФЯ).

FR>А мне забавно, что я переписав чисто императивный код на питоне в фунукциональном стиле наоборот получил выигрыш и в объеме и в простоте.


Дык я и не пытаюсь этому возражать. Просто по жизни бывают разные случаи. Когда-то удобно одно, когда-то другое. А вот догмы вроде ФС форева они и есть догмы.

FR>Не единственный есть еще мультиметоды и замена посетителя на замыкания и рекурсию.


Мультиметодов практически нигде нет. Разве что в эксперементальных реализациях. Рельно они есть в Клосе, но он сам по себе основан на Лиспе и откровенно говоря стоит очень далеко от классических концепций ООП. Уж точно сильно дальше чем Смолток или Питон.

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

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

ЗЫ

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

Посему это спор, как в прочем и многие здешние споры, скорее носит терминалогический характер. Однако мне кажется, что все же уровень точки зрения здесь играет определяющее значение. Мою точку зрения можно понять только если начать смотреть на проблему с совершенно другой стороны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: Vermicious Knid  
Дата: 10.07.06 22:00
Оценка: 3 (1) +2
Здравствуйте, FR, Вы писали:

FR>Нормально только это уже не ФЯ а ИЯ.


Рекомендую в comp.lang.functional создать тему "OCaml is not a functional programming language" и посмотреть на ответы.

FR>Вот у меня в одном проекте на питоне процентов 60 кода функционально, но я бы не стал его приводить как пример ФЯ.


Nemerle к сожалению(к моему) как и OCaml пропагандирует именно ФП. Предпочтение отдаваемое неизменяемым значения, неизменяемым полям объектов по умолчанию(и как следствие объектам без состояния), отсутствию циклов как таковых(имеется в виду core language, без стандартных макросов), отсутствию return, неизменяемым односвязным спискам как доминирующей структуре данных говорит именно об этом. С Питоном ситуация совершенно противоположная. В Nemerle императивное программирование это всего лишь опциональная возможность. Была бы моя воля я бы внес в язык послабления для императивного программирования(например поменял бы ключевое слово mutable на var, перенес бы макросы return, continue и break из пространства имен Nemerle.Imperative в глобальный контекст, сделал паттерн-мэтчинг для любых коллекций, задвинул односвязные списки на задний план и подумал бы о частичной(или полной) замене их в коде компилятора на что-то еще, сделал бы кортежи опционально изменямыми и так далее)

А в данный момент Nemerle не нравится и большинству фанатов ФП, и большинству законченных мэйнстримщиков, которые дальше Java, C# и C++ ничего не видят. Я думаю не в последнюю очередь из-за такой немотивированной любви разработчиков к функциональному программированию. Меньше нужно было делать реверансов в сторону ФП, все равно фанатов ФП меньшинство и у Nemerle все равно нет шансов в этой нездоровой, в основном академической среде. Т.е. вся функциональные возможности которые есть в Nemerle должны там быть, но дизайн и особенно синтаксис языка не должен навязывать функциональное программирование в той степени, как это сделано сейчас. Но сейчас я думаю это уже невозможно изменить, так как дизайн самого языка теперь более менее стабилизировался и развивается в основном только компилятор.

Поэтому я думаю первыми гибридными мэйнстрим языками возможно будут Fortress и C# 4.0(если он вообще будет; в последнее время я даже сомневаюсь в судьбе C# 3.0), и будет это очень не скоро. У Nemerle мало шансов стать мэйнстрим языком. Зато вероятен переход разработчиков языка на работу в Microsoft Research, может быть они будут работать и над C# 4.0, или косвенно на него повлияют.

FR>Я ему предложил найти там хоть один объект (так как паттерны сильно привязаны именно к ООП).


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

FR> После чего был предложен код на Nemerle не имеющий никакого отношения к ФЯ.


Мне кажется ты путаешь ФЯ и ФП. Согласен, к функциональному программированию предложенный фрагмент кода имеет мало отношения. Компилятор Nemerle вообще написан в очень смешанном стиле, но однозначно сказать чего там больше нельзя. Там очень много такой хардкорной функциональщины, которая ни в каком императивном языке просто невозможна. Если бы разработчики как раз придерживались принципов ООП, возможно код был бы и лучше и чище.
Re[39]: Tcl как обоснование ненужности поддержки компонентно
От: IT Россия linq2db.com
Дата: 11.07.06 00:10
Оценка: 10 (2) +4 :)))
Здравствуйте, VladD2, Вы писали:

VD>Все равно как ассемблерщик пересевший на С и видящий за кадой командой С набор ассемблерных инструкций.


Ассемблершик? Ха! Я по образованию — радиоинженер, и компрьютеры начиал изучать с распиленных попалам микросхем. Так что мне не чужды не только ассемблерные инструкции, но и то, как они бегают по шине и считаются во всяких АЛУ. И тот же твой паттерн-матчинг, что бы его начать эффективно использовать, придётся сначала разобрать на запчасти, подуть внутрь, понять физику процесса и собрать обратно. По другому никак

Тоже самое касается и дизайн-паттернов. Непонимание того, зачем они предназначены и какие решают задачи, приводит к их использованию не по назначению. Чем более эти паттерны встроены в язык, и чем больше призывающих не задумываться о них, тем более всяких чудовищ рождается на свет. Те же наследование и инкапсуляция тому живой пример. Вот теперь ещё паттерн-матчинг на подходе
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.07.06 01:32
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

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


ГВ>>Не уходи от ответа. Ну так что, обоюдно укорачиваем языки? Ты — на "фобии", "фанатизм" и прочее подобное, я — на ответные обвинения в паталогической неспособности к C++ (сиречь — необоснованные обвинения в некомпетености)? Ы?


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


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

VD>А что до фобий. Что вижу о том и говорю. Если вижу ничем не оправданные домыслы и паталогическую боязнь чего-то то и говорю — фобии.


...рассуждая сугубо логически, легко прийти к выводу, что ты, VladD2, сам полон фобий и фанатизма. Отсюда следует, что нельзя доверять субъектным характеристикам (всему спектру: от "боязни" до "МДП"), даваемым тобой, например, мне.

Рассуждение очень простое.

Ты не имеешь возможности поставить гарантированный психологический диагноз в смысле "фобий", "фанатических устремлений", "боязни" и тому подобных характеристик. Следовательно, то, что ты с лёгкостью приписываешь участникам дискуссии — вымысел чистой воды. Однако, сказать, что это просто "вымысел" хоть и корректно, но не позволяет "одёрнуть" измышляющего.

Поэтому экономичнее пойти слегка некорректным, но по-житейски логичным путём: перенести такие субъектные характеристики на того, кто их употребляет. Раз кто-то говорит "фобия!", значит, его "диагноз" является следствием того, что он сам этих фобий полон. Раз бросает в чей-то адрес "фанатик", значит сам является фанатиком. Ведь действительно, что-то же не даёт спорщику сосредоточиться на ratio, которое предъявляют оппоненты и продолжать извергать потоки домыслов? Исходя из принципа исключения лишних сущностей ответное рассуждение ограничивается характеристиками, явно сформулированными атакующим. В твоём случае это "фобии", "фанатизм", "боязнь". Здесь, кстати, важно не вносить дополнительных характеристик и не пускаться в квазипсихологию, дабы не уподобиться. Поэтому — бритва Оккама.

Смягчения ради можно допустить, что ты просто ругаешься. Кстати, как правило, твои оппоненты реагируют на твои высказывания так, как принято реагировать на ругань, если нет желания обострить конфликт: с той или иной степенью иронии. Но судя по всему, называть это просто руганью не правильно. Если бы ты просто ругался, то не стал бы настаивать на том, что: "вижу... паталогическую боязнь чего-то...", не стал бы подводить основания под свои диагнозы. Ergo — см. выше.

Короче, есть некая мудрость в этом стишке:

Строг закон самурая:
Кто произносит обидное слово,
Сам называется так.


(c) не-помню-чей.

P.S.: Но это всё не относится к сугубо объектным и объективным рассуждениям: замерам скорости, сравнениям языков и т.п. Ключевое слово: "субъект".
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Tcl как обоснование ненужности поддержки компонентно
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.07.06 05:13
Оценка: 22 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>"В большинстве" это явное преувеличение.

Увы.
VD> Но это по сути не важно. Главное, что есть языки (пофигу мэйн-они-стрим или еще что) в которых свойство это первоклассная сущьность. И применять некий паттерн для их реализации нет смысла.
Нет, Влад. Как раз главное — то, что есть языки, в которых свойства НЕТ.
S>> А в тех, которых есть, оно почему-то реализовано существенно по-разному. Например, в Delphi определялось отображение свойства на независимо существующие методы и поля. В шарпе уже ничего такого нет. Что из этого является свойством?

VD>Свойством является свойство. А разница наблюдаемая тобой — это разница в синтаксисе языков.

Хрен там. Еще и семантика отличается. К примеру, в шарпе нельзя замапить свойство напрямую на поле, а в Delphi — можно. И у него еще и адрес можно будет взять!
VD>Функции ты тоже по разному описываешь в разных языках. Ты же не считашь при этом функцию паттерном?
Ну конечно же считаю! Просто сейчас это настольно популярный паттерн, что тяжело найти язык без функций. Впрочем, есть и пример: bat-файлы. В них функции не встроены, и приходится их эмулировать при помощи определенной последовательности действий. Т.е. имеем паттерн.
S>> Кроме того, в Delphi есть вшитая реализация паттерна Factory. Ты, я надеюсь, не предлагаешь под этим предлогом выкинуть этот паттерн из всех учебников и заменить его ссылкой на virtual constructor?

VD>А причем тут учебники? Для дельфи существует понятие метакласса и говоря в терминах дельфи смысла в использовании паттерна фабрика действительно нет.

Влад, я тебя разочарую: в Delphi паттерн "фабрика" используют чаще, чем где бы то ни было (кроме, разве что, COM). Просто Delphi делает его применение а)простым б)удобным и в) контролируемым компилятором. Но паттерн никуда не девается.
VD>Ты конечно можешь оперировать паттерном фабрика просто ради того, что бы определить дизайн приложения в срассчете на самый убогий язык из некоторого списка.

VD>Или уж тогда давай говорить, что все конструкции языка — это паттрены.

Совершенно верно. Ну, не все...
VD>Паттрен if, паттерн switch,
Ветвление как ращ уж очень фундаментальная конструкция для программирования, ее сложно объявить паттерном.
VD>паттерн "+"... А что? Для ассемблера или, к примеру, Форта это действительно будут паттерны проектирования.
А ты, кстати, навскидку нарисуешь полный сумматор на логических элементах? Я вот полусумматор помню.
VD>Ну, а для Немерла, например, исчезает паттерн проектирования Посетитель.
S>>Так что ключевое слово property или определенный синтаксис являются реализацией паттерна. А сам паттерн существует совершенно независимо от языка. Свойство можно реализовать даже на ассемблере.

VD>И if, как я уже сказал, можно реализовать на Ассемблере. Но ты же не оперируешь с ним как с паттерном? И не делашь ты это только потому, что if на языке высокого уровня для небя не паттерн, а первоклассаная операция. Точно так же свойство для тебя первоклассная сущность и думаь о нем как о паттерне прото неразумно.

VD>Нет главной составляющей паттерна "repeatable solution to a commonly-occurring problem" так как нет самой проблемы.
Есть, Влад, есть. Просто если ты замыкаешься на 1 языке, то нихрена кроме него не видишь. Ни паттернов, ни иных конструкций.
VD>Она становится тривиальной и описывается тривиально. То етсь нет ни проблемы, ни решения.
Влад, ну это же бред! Как это нет проблемы? Вот есть у нас например проблема: порождать объекты различных классов в зависимости от чего-то. Типичная проблема ООП. Есть и решение: паттерн Фабрика.
VD> Есть просто синтаксическая конструкция.
А она, Влад, для чего? Правильно, для решения некой проблемы. Тебя послушать, так всякие синтаксические конструкции существуют эдак сами для себя, как каприз создателей языка. Первичны именно паттерны. Самые удачные и востребованные из них оказывают влияние на синтаксис разрабатываемых языков. И мы по-прежнему можем видеть за синтаксисом паттерн, и говорить об удачной или неудачной реализации данного паттерна в том или ином языке.

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

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


VD>Хотя понятие громоздкость плохо детерминировано. Возможно луче подходит термин "выразительность".


VD>С точки зрения кривой обучения вопрос не столь очевиден. Потяно, что чем больше понятий впитал в себя язык тем сложнее его выучить. Но тут играет роль то, что для начальной стадии обучения все потятия могут оказаться не нужны. Меж тем те же приемы описанные в ГоФ являются пожалуй необходимым минимумо и хороший программист о них должен знать. И я не вижу ничего плохого если им будет придана краткая и простая форма.


S>> С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются,


VD>Очень редко. Но другое дело что есть прикладные паттерны. Вроде тех что хотят охватить в LINQ. Вот их действительно масса и для них действительно лучше иметь расширяемый язык. Но именно расширяемый язык, а не отверстие в заднем проходе.


S>> и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++


VD>Не, они этим отмазываются. А сам С++ имеет только одно штатное средство расширения — свои убогие макросы. Все остальное через зад. Результат соотвествующий.


VD>Так что дух в С++ правильный, а вот реализация ни к черту.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
От: zabivator  
Дата: 14.09.06 07:38
Оценка:
Здравствуйте, eao197, Вы писали:
E>Нет, наличие чего-нибудь в стиле лямбд меня бы не покоробило. Но этого пока нет. Поэтому я не сильно переживаю об его отсутствии.
А как же boost::lambda?
http://www.boost.org/libs/lambda/index.html
Re[30]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.09.06 07:53
Оценка: +2
Здравствуйте, zabivator, Вы писали:

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

Z>А как же boost::lambda?
Z>http://www.boost.org/libs/lambda/index.html

После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

О том, как бы мне хотелось видеть lambda в C++ я писал: здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
и здесь
Автор: eao197
Дата: 11.10.05
. Только для этого нужна поддержка на уровне компилятора, а не библиотек.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: zabivator  
Дата: 14.09.06 08:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>Совсем? Назови хоть один.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: zabivator  
Дата: 14.09.06 08:22
Оценка: -1
Здравствуйте, zabivator, Вы писали:

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


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


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


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

Smalltalk
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: zabivator  
Дата: 14.09.06 08:29
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


E>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

E>О том, как бы мне хотелось видеть lambda в C++ я писал: здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
и здесь
Автор: eao197
Дата: 11.10.05
. Только для этого нужна поддержка на уровне компилятора, а не библиотек.

Чем хуже поддержка на уровне библиотек?
Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.09.06 08:41
Оценка: +4
Здравствуйте, zabivator, Вы писали:

E>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

Z>Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

Кхе... Давно это было, не помню уже, что за ответы я получал. Может ссылочки подскажите?

E>>О том, как бы мне хотелось видеть lambda в C++ я писал: здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
и здесь
Автор: eao197
Дата: 11.10.05
. Только для этого нужна поддержка на уровне компилятора, а не библиотек.

Z>Чем хуже поддержка на уровне библиотек?

Не знаю, зачем поднимать этот вопрос в очередной раз. Но, есть языки, в которых поддержка lambda сделана на уровне языка. Посмотрите, например, на блоки кода в Ruby и Smalltalk, на Scala, на Nemerle (не говоря уже про Lisp и сонмище функциональных языков). Использование lambda в них -- это вполне естественный и удобный процесс. К которому быстро привыкаешь.

После такого опыта хочется иметь в C++ нормальную реализацию, нормальную. А не имеющиеся сейчас костыли. Просто хочется. Просто потому, что уже привык к хорошему.

Z>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.


Да ради бога. Мне еще ни разу не пришлось использовать списки типов. А вот функторы с STL-левскими алгоритмами постоянно. И тянуть в проект boost::lambda для того, чтобы получить жалкую кальку с нормальной лябды не хочется.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: zabivator  
Дата: 14.09.06 08:45
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Кхе... Давно это было, не помню уже, что за ответы я получал. Может ссылочки подскажите?

Трэд выше пролистайте

Z>>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.

А вы посмотрите его реализации абстрактной фабрики и паттерна визитор. И все станет на свои места. После этого кажется что остальные все реализации фабрик ( как на С++, так и в других языках ) — костыли.
Re[10]: Tcl как обоснование ненужности поддержки компонентно
От: _rasta  
Дата: 14.09.06 08:45
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Ну, а теперь подытоживаем... Мы получили такой же дизайнер как в C# с мааааленькими оговорочками.


имхо обратно. это дизайнер C# получился такой же, но с оговорочками.

VD>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.


это вопрос с создателям "нового"... уж никак не к tcl/tk имхо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Programmierer AG  
Дата: 14.09.06 08:53
Оценка: +3 :))) :))
zabivator wrote:
> Z>>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.
> А вы посмотрите его реализации абстрактной фабрики и паттерна визитор. И все станет на свои места. После этого кажется что остальные все реализации фабрик ( как на С++, так и в других языках ) — костыли.
Восхищение Александреску -это нормально. Как и последующее разочарование
и трезвая оценка границ C++. Не беспокойтесь за ув. eao197, у него уже и
так все на местах .
Posted via RSDN NNTP Server 2.0
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.09.06 10:01
Оценка: 15 (1) +1
Здравствуйте, zabivator, Вы писали:

E>>Кхе... Давно это было, не помню уже, что за ответы я получал. Может ссылочки подскажите?

Z>Трэд выше пролистайте

Полистал, адекватных ответов по поводу именно лямбды не увидел. Покажите ссылкой, если не сложно.
Зато нашел несколько собственных фраз: "Лямбды так же нужны не всем" и "И еще не факт, что лямбды на самом деле так удобны, как об этом говорят" которые выглядят излишне категоричными. Думаю, нужно из пояснить.

Итак, лябмды в Ruby очень удобны, когда нужно обработать какую-то коллекцию элементов. Например, написать выражение вида:
items.inject( {} ) { bla-bla-bla }.sort { bla-bla-bla }.collect { bla-bla-bla }.each { bla-bla-bla }

Очень удобно. Так же удобно параметризовать какую-то операцию лямбдой:
def do_import( params, inserter )
  ... inserter.call( data ) ...
end

def initiate_import( params )
  inserter = if params.dry_run # реального импорта быть не должно
      lambda { puts "inserting " + ... }
    else
      # Для реального импорта используем SQL.
      lambda { dbh.execute "INSERT INTO ..." }
    end
  do_import( params, inserter )
end

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

Но все это хорошо в managed языках со сборкой мусора. В них, например, если мы перемещаем объекты между несколькими коллекциями в серии inject/sort/collect мы, по крайней мере, уверены, что они не станут мусором. Поэтому легко из lambda возвратить какое-то значение, сохранить его и использовать дальше. Так же, лямбды используют (если не путаюсь в терминах) лексическое замыкание, т.е. сохраняют возможность доступа к переменным в той области видимости, в которой определена lambda. И опять же благодоря сборке мусора мы не заботимся о том, что эти ссылки станут невалидными.

В C++ иная ситуация, сборки мусора нет. Из-за этого нужно проявлять осторожность при возврате лямбды из какого-то контекста. Что уже снижает удобство использования. Так же в C++ не просто организовать цепочки inject/sort/collect. Это связано как с организацией стандартных контейнеров и алгоритмов, так и с отсутствием сборки мусора. Например, если в результате сортировки у меня получается временный объек-контейнер из которого мне нужно взять указатель на один из элементов. Время действия этого указателя будет гораздо меньше, чем в языке со сборкой мусора. Поэтому я считаю, что ценность лямбды в C++ (даже если она будет сделана на уровне языка, но без сборки мусора) ниже, чем тех же делегатов в C# или в D.

И еще одно замечание. Имхо, C++ не сильно подходит для программирование в функциональном стиле. Все эти std::for_each, std::accumulate, std::find_if -- это конечно хорошо и часто они улучшают читабельность кода. Но, имхо, все-таки выглядят бледной тенью аналогов из языков, в которых функциональный стиль поддерживается более естественным образом. Кроме того, сейчас, когда managed языки (в первую очередь Java и C#, а так же Smalltalk, и функциональные языки, вроде OCaml) благодоря достижениям в области JIT-а и агресивной оптимизации показывают очень высокую производительность, но при этом делают разработку более комфортной (за счет сборки мусора и типобезопасности), главная ниша C++ -- это высокопроизводительные и нересурсоемкие приложения. И вот здесь оказывается, что писать на C++ быстрые программы в стиле "C with classes" с разумным использованием шаблонов гораздо проще, чем нагромождая подобие функционального стиля из алгоритмов и функторов. В частности, проще затем оптимизировать, когда весь код как на ладони и не нужно погружаться в дебри деталей работы сложных шаблонных конструкций.

Z>>>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.

Z>А вы посмотрите его реализации абстрактной фабрики и паттерна визитор. И все станет на свои места. После этого кажется что остальные все реализации фабрик ( как на С++, так и в других языках ) — костыли.

Интересно, а с какими языками вы сравнивали решение Александреску?
Мне, например, нравится реализация фабрики в Ruby:
def factory klass, *args
    klass.new *args
end

class A
    def hello
        "#{self.class.name}: hello"
    end
end

class B
    def initialize greeting
        @greeting = greeting
    end

    def hello
        "#{self.class.name}: #{@greeting}"
    end
end

class C
    def initialize greeting, a, b
        @greeting = greeting
        @a = a
        @b = b
    end

    def hello
        "#{self.class.name}: #{@greeting}, and: #{@a.hello} and #{@b.hello}"
    end
end

objs = [
    factory( A ),
    factory( B, 'have a nice day' ),
    factory( C, 'kill yourself!', factory( B, 'good morning' ), factory( A ) )
]

objs.each { |o| puts o.hello }

В результате получаем:
A: hello
B: have a nice day
C: kill yourself!, and: B: good morning and A: hello

Довольно просто и симпатично, не находите?


Можно ли узнать, зачем вы подняли это обсуждение и, в частности, завели разговор про лямбды в C++?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: Klapaucius  
Дата: 14.09.06 12:36
Оценка: +2
Здравствуйте, zabivator, Вы писали:

E>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

Z>Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.

E>>О том, как бы мне хотелось видеть lambda в C++ я писал: здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
, здесь
Автор: eao197
Дата: 11.10.05
и здесь
Автор: eao197
Дата: 11.10.05
. Только для этого нужна поддержка на уровне компилятора, а не библиотек.

Z>Чем хуже поддержка на уровне библиотек?
Z>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.

Лет 10 назад была какая-то такая передача на ТВ и в ней рубрика "очумелые ручки". Там людей учили делать цветочные горшки из виниловых лонгплеев.
Между прочим, изобретатели LP в свое детище такой функциональности не закладывали.
И что Вы думаете? Наведываясь в гости к друзьям и знакомым я стал с удивлением обнаруживать забавные но странные цветочные горшки. К счастью, через некоторое время увлечение прошло, как пройдет, наверное, и мода на наколеночное изготовление лямбд в C++.
Туда ей и дорога!
Мало того, что базовое средство языка (что-то более базовое, чем лямбда лично мне придумать очень сложно) реализовывать в библиотеке немного не логично, да и сделать нормальные замыкания без GC едва ли возможно.

Suum cuique, господа.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[33]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.09.06 12:46
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

Z>>Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

K>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.


Это кто?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 15.09.06 08:43
Оценка:
eao197,

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


Хм. Подумалось, что если вызывать другие функции из лямбд, то этой проблемы не будет. Я не прав?

E>Интересно, а с какими языками вы сравнивали решение Александреску?

E>Мне, например, нравится реализация фабрики в Ruby:
E>def factory klass, *args
E>    klass.new *args
E>end
...
E>objs = [
E>    factory( A ),
E>    factory( B, 'have a nice day' ),
E>    factory( C, 'kill yourself!', factory( B, 'good morning' ), factory( A ) )
E>]

E>objs.each { |o| puts o.hello }


Ммм, красота! А вот так вот можно:
objs = 
{[
    a = factory(A),
    b = factory(B, 'have a nice day'),
    c = factory( 'kill yourself!', b, a)
]}

?
(Я обернул список лямбдой, чтобы переменные a, b и c снаружи были не видны.)
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[34]: Tcl как обоснование ненужности поддержки компонентно
От: Klapaucius  
Дата: 15.09.06 12:03
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

K>>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.

E>Это кто?

Это Вы, alexeiz, Cyberax

Имеется в виду обсуждение, начинающееся отсюда
Автор: alexeiz
Дата: 11.10.05
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[35]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.09.06 12:17
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.

E>>Это кто?

K>Это Вы, alexeiz, Cyberax


K>Имеется в виду обсуждение, начинающееся отсюда
Автор: alexeiz
Дата: 11.10.05


А, я-то думал, что вы про обсуждение в "Tcl как обоснование..." (придумали ж тему, однако).
Только почему же у вас сложилось мнение, что хуже про C++ больше нигде не говорили?
Имхо, нормально пообсуждали то, чего в C++ нет.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[36]: Tcl как обоснование ненужности поддержки компонентно
От: Klapaucius  
Дата: 18.09.06 12:32
Оценка: +2 :)
Здравствуйте, eao197, Вы писали:

K>>>>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.

E>>>Это кто?
K>>Это Вы, alexeiz, Cyberax
K>>Имеется в виду обсуждение, начинающееся отсюда
Автор: alexeiz
Дата: 11.10.05


E>Только почему же у вас сложилось мнение, что хуже про C++ больше нигде не говорили?


Может и говорили, но я не читал.

E>Имхо, нормально пообсуждали то, чего в C++ нет.


Так не в том проблема, что чего-то где-то нет. В данном случае проблема с тем, что есть.
А есть такой мегарулез как boost, который делает C++ современным, высокоуровневым и выразительным.
Читаю я, допустим такие слова:

Право слово, доисторический код какой-то. Так уже никто не пишет.

И что я должен ждать? Наверное что-то модерновое, прогрессивное. Клеймит, понимаете ли, автор пещерный стиль, а потом выдает вот такое:
int a[] = {1, 2, 3, 2, 4, 5, 7, 6, 7, 2};
typedef map<int, int> map_t;
typedef map_t::value_type val_t;
map_t occur;

for_each(begin(a), end(a),
        if_(_1 < 7) [ bind(&map_t::operator[], &occur, _1)++ ]);

for_each(begin(occur), end(occur),
        cout << bind(&val_t::first, _1) << ":" << bind(&val_t::second, _1) << "\n");

Красотища-то какая! Вот это, значит то, что в этом сезоне comme il faut? На это надо ровняться?
Увольте.
Тут бы самое время посмеяться — но как-то даже и не удобно. Горе ведь у человека. Пусть даже он об этом и не подозревает.
Если это будущее C++, то оно, право, какое-то гм... мрачноватое что-ли. Как минимум безрадосное.
Я никого запинывать не хочу, у C++ есть своя область применения, но когда дело доходит до таких вот вещей он бледнеет и держится за стенку. Любому, кто видел более элегантные решения претензии С++ + boost на сверхвысокоуровневость и ФП кажутся не то, чтобы очень обоснованными. Но Вам-то я думаю эту позицию нет нужды пояснять.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: О языках для численных расчетах.
От: thesz Россия http://thesz.livejournal.com
Дата: 18.09.06 21:43
Оценка:
АХ>Ну а вообще в этой области (number crunching) начинают рулить шейдеры : ( здесь )
АХ>и соответственно такие языки как Cg, DirectX HLSL и GLSL.

BrookGPU рекомендую.

Шейдеры ОЧЕНЬ ограничены. Например, они не умеют делать scatter (помещение результата в нужное место). Обратная операция gather — забор элемента из нужного места.

Brook (kernel-stream based computation) это шаг вперед, но очень маленький.

Вообще, все успешные попытки распараллеливания с изменением фон-неймановскому стилю отказываются либо от scatter (GPU), либо от gather (есть тут такие).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[31]: Tcl как обоснование ненужности поддержки компонентно
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.09.06 23:10
Оценка: :)))
Здравствуйте, eao197, Вы писали:

E>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.


За подобные слова несколько лет назад меня здесь закидали какашками. Все же прогрес не стоит на месте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Tcl как обоснование ненужности поддержки компонентно
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.09.06 04:08
Оценка: :))
Здравствуйте, VladD2, Вы писали:

E>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.


VD>За подобные слова несколько лет назад меня здесь закидали какашками. Все же прогрес не стоит на месте.


Во-первых, вряд ли я принимал участие в этом процессе.
Во-вторых, boost::lambda мне вообще никогда не нравился, даже когда я еще на Ruby не программировал.
В-третьих, те, кто кидался в тебя за такие слова тогда, вероятно, повторят это и сейча. А заодно и в меня



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.