Delphi vs C++ , часть 2

[archimed7592]

Цитата --Ins-- @ 11.03.08, 15:14

А у меня на Delphi 15-20 минут бы занял полиморфный код сериализации объектов. Ну, универсальный код, который позволяет сохранить/восстановить состояние любого объекта, который бы ты ему не подсунул. Причем в классах этих объектов не нужно было бы писать какой-либо специальный код А смог бы ты это сделать на C++? Я это к тому, что может не стОит меряться таким способом, у слона все равно длиннее.

Ins, что ты всё из моего разговора с Ромкиным пытаешься контекст выдрать? Он утверждает, что я заставляю его переписывать COM. Я ему говорю, что на то что я прошу его сделать уйдёт 15-20 минут - нужно лишь вчитаться в то, что я прошу. Где ты тут увидел меряние слонами?


Так как насчёт "где взять спецификацию по Delphi Language не скачивая саму IDE"?

Это сообщение было перенесено сюда или объединено из темы "Delphi vs C++"

[archimed7592]

Часть 1.

[--Ins--]

Цитата

Так как насчёт "где взять спецификацию по Delphi Language не скачивая саму IDE"?

Не знаю, меня этот вопрос не интересовал Так как мне для работы нужен только один компилятор языка. Кстати, неужели различные компиляторы C++ не вносят в язык свои дополнения/изменения? Ну там всякие директивы...

[Romkin]

Цитата archimed7592 @ 11.03.08, 15:26

Ins, что ты всё из моего разговора с Ромкиным пытаешься контекст выдрать? Он утверждает, что я заставляю его переписывать COM. Я ему говорю, что на то что я прошу его сделать уйдёт 15-20 минут - нужно лишь вчитаться в то, что я прошу. Где ты тут увидел меряние слонами?

У меня ушел час. Плюс сделано как курица лапой Если ты напишешь такое за 15-20 минут - честь и хвала.
Правда, я запутался немного, что именно тебе хочется, я там еще имена экземпляров приплел. Рефлекс.
Код

var
  V1, V2, V3: variant;
begin
  V1 := CreateELOObject('Class1');
  V3 := CreateELOObject('Class1');
  V2 := CreateELOObject('Class2');
  V1.Foo(12);
  V1.Bar('asdfr', 23, Date);
  V2.FooBar('Yess!');
  V3.Bar;
end;

Дает выдачу:
Class:Class1 Obj:First1 Metod:FOO Args: 12
Class:Class1 Obj:First1 Metod:BAR Args: asdfr 23 11.03.2008
Class:Class2 Obj:Second1 Metod:FOOBAR Args: Yess!
Class:Class1 Obj:First2 Metod:BAR Args:
Так примерно требовалось-то? нет?

[--Ins--]

archimed7592, ты не по тем мишеням стреляешь В ЯЗЫКЕ Delphi ЕСТЬ некоторые достаточно серьезные на мой взгляд проблемы. Они носят тот же характер, что и в C++. Т.е. позволено то, что на самом деле позволять нельзя И использование этих возможностей дает небольшой выигрыш, но потенциально может привести к очень серьезным проблемам. Конечно, таких мест в языке куда меньше, чем в C++, у которого дать такую возможность - основная концепция Но они есть. Предлагаю сделку: я тебе об одной из них рассказываю (чтобы тебе было что возразить на аргументы о вседозволенности в C++ и строгости Delphi), а ты признаешь, что наличие таких возможностей не есть гуд На том и разойдемся, так как мне честно говоря уже немного надоело. Наверное все, что можно было переосмыслить и вынести из данного обсуждения, я уже вынес (не совсем правда уверен в своих оппонентах).

[Romkin]

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

Сообщение отредактировано: Romkin - 12.03.08, 07:51

Прикреплённый файлvarFoo.zip (1.49 Кбайт, скачиваний: 253)

[Flex Ferrum]

Цитата

Особенно умиляют попытки компиляции проектов разными компиляторами, постоянно появляются какие то мистические глюки. Не так давно просматривал тему, об эмуляции BGI-графики. Меня до слез прошибала "совместимость" различных компиляторов, а порой и вообще мистические требования, вроде тех, что бы последняя строка в сорсах обязательно заканчивалась <CR>, или просьбой убрать определенные конструкции, хоть и в соответствии со стандартом, но вносящие определенные проблемы в разных компиляторах И это компиляторы, поддерживающие стандарт Да ладно бы не компилилось, а то ведь и скушает компилятор, а прога не пашет, хотя другой компилер выдал рабочий код И это нормально? Главное причина то на поверхности - слишком объемный стандарт, на изучение которого нужна уйма времени, отсюда и ошибки растут. Что нет? А как тогда объяснить нарушение принципа блочной структуры программ, это когда операторы, которые должны принадлежать к одному блоку программы(тот же switch...case), можно смело разнести в разные блоки? И компилятор обязан это проглотить, поскольку этот баг обнаружили слишком поздно, вот и внесли в стандарт, для совместимости Вообще это неправильно как то. Если утверждается, что плюсы новый язык, то зачем было вводить в него поддержку Си? Наверное просто побоялись, что новый язык не приживется, вот и кинули косточку Сишникам, для безболезненного перехода

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

Добавлено 11.03.08, 19:04
Кстати, больше, чем уверен, что код, который разрабатывается в рамках темы First Contact мне удастся перетащить на Linux без особого труда.

[AndNot]

Цитата Flex Ferrum @ 11.03.08, 19:03

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

Опыт не пропьешь Но ведь его в магазине не купиш Вот кстати, совсем свеженькое, оттуда же:

Цитата oldsoldier @ 11.03.08, 19:12

я все сделал по туториалу. скомпилилось, но дальше никакой реакции не было. и почему-то не компилилось "в режиме окна" . (//#define DGML_IN_WINDOW )

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

Добавлено 11.03.08, 20:52

Цитата Flex Ferrum @ 11.03.08, 19:03

Кстати, больше, чем уверен, что код, который разрабатывается в рамках темы First Contact мне удастся перетащить на Linux без особого труда.

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

[Flex Ferrum]

Цитата AndNot @ 11.03.08, 20:51

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

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

Цитата AndNot @ 11.03.08, 20:51

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

Кроссплатформенный кодинг - это, в определенных случаях, своего рода высший пилотаж. Особенно когда ты пытаешься написать такой текст, который будет одинаково хорошо "понимаем" широким спектром компиляторов. Тут действительно нужен большой опыт и знания многих аспектов и особенностей. Если же речь заходит о конкретном компиляторе и платформе, то все становится гораздо проще.

[AndNot]

Цитата Flex Ferrum @ 11.03.08, 20:58

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

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

Цитата Flex Ferrum @ 11.03.08, 20:58

Тут действительно нужен большой опыт и знания многих аспектов и особенностей.

Про что и речь. Но вопрос то в другом, почему это происходит? Ведь есть вполне определенный стандарт. Или возьми такие приколы - gcc иногда может компилить нерабочий код, но стоит поменять параметры компиляции и все становится рабочим А это как понимать?

Цитата Flex Ferrum @ 11.03.08, 20:58

Кроссплатформенный кодинг - это, в определенных случаях, своего рода высший пилотаж.

Смотря что понимать под этим термином. Я без проблем напишу код, который можно компильнуть под линукс и винду, даже на асме. Но почему то сразу начинают кричать, что это не истинная кроссплатформенность Так что ты вложил в этот термин?

[Flex Ferrum]

Цитата AndNot @ 11.03.08, 21:10

Про что и речь. Но вопрос то в другом, почему это происходит? Ведь есть вполне определенный стандарт. Или возьми такие приколы - gcc иногда может компилить нерабочий код, но стоит поменять параметры компиляции и все становится рабочим А это как понимать?

На первую часть вопроса - "не все компиляторы одинаково хороши". А именно - не все одинаково хорошо могут поддерживать стандарт. В частности, этого не стоит ждать от компиляторов, год выпуска которых меньше, чем 2002-2003. Только последние года компиляторы примерно в равной степени поддерживают стандарт. На вторую часть вопроса (по gcc) - это вообще отдельный случай, т. к. этот компилятор весьма хитрый, и действительно может работать в разных режимах, в том числе и совместимости. А что он позволяет вытворять в "голом" С-коде, так это мама дорогая...

Цитата AndNot @ 11.03.08, 21:10

Так что ты вложил в этот термин?

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

[Romkin]

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

Добавлено 12.03.08, 09:02
Напоминаю: сие сделано по просьбе Архимеда из первой части:

Цитата

Romkin, ты не понял. Ок, более конкретно.
Есть два класса: Class1 и Class2.
Я должен мочь создавать объекты этих классов в неограниченном количестве(посредством ф-ции CreateELOObject).
Я должен мочь вызывать методы Foo и Bar класса Class1 и метод FooBar класса Class2. Причём, особенностью технологии будет то, что можно будет неспецифицировать кол-во аргументов для метода. Т.о. методы должны принимать все переданные аргументы и выводить их(в порядке передачи ) в текстовый файлик. Также они должны выводить что вызван конкретно этот метод(Foo, Bar или FooBar), имя типа(Class1 или Class2) и номер объекта(в порядке их создания).

Во втором варианте нумерацию объектов я выкинул. Сделать несложно, впрочем. Но не считаю нужным.
Данный пример показывает реализацию позднего связывания через Variant, то есть, Архимед попросил, чтобы было так как здесь.
Употребление:

var
  V1, V2, V3: variant;
const
  FileName = 'c:\varFoo.txt';
begin
  V1 := CreateELOObject('TFooInvoke', FileName);
  V3 := CreateELOObject('TFooInvoke', FileName);
  V2 := CreateELOObject('TFooBarInvoke', FileName);
  V1.Foo(12, V2);
  V1.Bar('asdfr', 23, Date);
  V2.FooBar('Yess!');
  V3.Bar;
end;

В результате у меня в файле
Class:TFooInvoke Metod:FOO Args: 12 TFooBarInvoke
Class:TFooInvoke Metod:BAR Args: asdfr 23 12.03.2008
Class:TFooBarInvoke Metod:FOOBAR Args: Yess!
Class:TFooInvoke Metod:BAR Args:
Прикреплённый файлDummyVar.zip (1.79 Кбайт, скачиваний: 269)

[Romkin]

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

Цитата Romkin

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

...

Цитата archimed7592

Сообщ. #1702 от Вчера, 15:12
Потому и спрашиваю, что знаю, что там никаких проблем с потоками нет. Точнее говоря, QString не является thread-safe, но CoW там реализован потоко-безопасно.

Хм. QDeepCopy Не знаю, что там насчет коровы, но в третьей версии таки можно было влететь. В четвертой версии, похоже, сделали постоянную поддержку многопоточности. Но ведь особенности все же надо знать! Одно дело я, который соприкасался с Qt давно и неправда, и другое дело - программист, работавший с ней.
Ужас.

Сообщение отредактировано: Romkin - 12.03.08, 12:59

[archimed7592]

Цитата Romkin @ 12.03.08, 12:58

Не знаю, что там насчет коровы, но в третьей версии таки можно было влететь.

Действительно
v3

Цитата

Threads and Shared Data

Qt provides many implicitly shared and explicitly shared classes. In a multithreaded program, multiple instances of a shared class can reference shared data, which is dangerous if one or more threads attempt to modify the data. Qt provides the QDeepCopy class, which ensures that shared classes reference unique data.

See the description of implicit sharing for more information.

v4

Цитата

Threads and Implicit Sharing

Qt uses an optimization called implicit sharing for many of its value class, notably QImage and QString. In many people's minds, implicit sharing and multithreading are incompatible concepts, because of the way the reference counting is typically done. One solution is to protect the internal reference counter with a mutex, but this is prohibitively slow. Earlier versions of Qt didn't provide a satisfactory solution to this problem.

Beginning with Qt 4, implicit shared classes can safely be copied across threads, like any other value classes. They are fully reentrant. The implicit sharing is really implicit. This is implemented using atomic reference counting operations, which are implemented in assembly language for the different platforms supported by Qt. Atomic reference counting is very fast, much faster than using a mutex (see also Implementing Atomic Operations).

This having been said, if you access the same object in multiple threads simultaneously (as opposed to copies of the same object), you still need a mutex to serialize the accesses, just like with any reentrant class.

To sum it up, implicitly shared classes in Qt 4 are really implicitly shared. Even in multithreaded applications, you can safely use them as if they were plain, non-shared, reentrant classes.

Но извини меня, я же тебе не тычу пальцем на недостатки 3-й версии Delphi(которая является ровесницей Qt-v3). Раз уж сравниваем текущие преимущества и недостатки, то уж давай продолжать в том же русле .

Цитата Romkin

Напоминаю: сие сделано по просьбе Архимеда из первой части:

Угумс, спасибо, сейчас буду изучать (правда, за отсутствием IDE и хэлпа).

Цитата --Ins--

Предлагаю сделку: я тебе об одной из них рассказываю (чтобы тебе было что возразить на аргументы о вседозволенности в C++ и строгости Delphi), а ты признаешь, что наличие таких возможностей не есть гуд

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