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

S>Hello, zaiats_2k!
S>You wrote on Wed, 22 Oct 2003 11:57:46 GMT:

S>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>> окна. Например так, как это сделано в wxWindows.

zk>> Я только одного не понимаю, кто мешает вам изобрести порох
zk>> непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема волнует!

S>Написано уже. Но не для Delphi.

Кем, когда, для чего, где взять, сколько стоит, как называется?

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

S>Hello, Sinclair!
S>You wrote on Wed, 22 Oct 2003 12:03:43 GMT:

S>> Здравствуйте, Sergey, Вы писали:
S>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>> окна. Например так, как это сделано в wxWindows.
S>> Хм, может быть. Можно немного поподробнее?
S>> Моя проблема в том, что я не понимаю, как это layout может быть оторван
S>> от окна. Вот допустим у нас есть два окна, которые сами уже окон не
S>> содержат. Мы хотим расположить их внутри родительского окна, одно слева
S>> и одно справа. При этом разделитель между ними должен вести себя как
S>> обычный сплиттер.

S>Или не должен вести себя как обычный сплиттер,
В каком это смысле? Я хочу дать пользователю возможность управлять не только общим размером контейнера, но и взаимными размерами его элементов.
S>или вовсе разделителя никакого быть не должно — просто контролы в диалоге при ресайзе должны определенным образом менять свои размеры.
Не согласен. Одного ресайза недостаточно.

S>Сплиттер может быть окном и сам получать сообщения мыши,
Получаем VCL. Сплиттер — не самостоятельный объект. Он всего лишь "ручка" к функциональности Layout Manager.
S>может быть окном и отдавать сообщений родителю,
А родитель что будет с ними делать?
S>может вообще не быть самостоятельным окном (но выглядеть точно так же) и отрисовываться контейнером.
Ну вот что-то типа этого я себе и представляю. Но при этом контейнер обязан знать о том, что за layout у него внутри.
S>Конечно. В wxWindows у него мембер такой есть — m_windowSizer. А вот что это за сайзер, оно знать не должно. Что обеспечивает большую гибкость и расширяемость.
Интересно, и какую функциональность на себя берет этот Sizer?
S>Посылать сообщения окнам, например. Или напрямую вызывать методы классов, реализующих окна. (что по сути одно и то же). Смысл в том, чтобы это был отдельный объект, который можно менять независимо от окон — тогда реализовать любой нужный пользователю вариант лэйаута можно не ломая существующего кода.
Это-то понятно. Вопрос в том, как он сам будет получать сообщения? У нас получается некоторое противоречие, т.к. сам набор сообщений, которые мы собираемся послать этому нашему виртуальному мемберу, зависит от того, какого он типа.

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

S>Написано уже. Но не для Delphi.

Уж не про джавовский ли ты говоришь?

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

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

S>Нет уж увольте. к IDispatch это не имеет никакого отношения. Я бы простил, если бы они так обходились с переменными типа IDispatch. Но когда компилируется вот такой код:
S>var
S>  A: variant;
S>begin
S>  A:= 5;
S>    A.LateBoundCall(SomeValue).OtherCall;
S>end;
S>

S>я считаю это преступлением.

Просто для variant действуют неявные преобразования типов (которые, кстати, любят в C++).

Тогда уж не меньшим преступлением можно считать и следующий код:

var
  A: variant;
  B : integer;
begin
  A:= '3.5';
  B := A;
end;

Тут еще и от локали зависит. Так что ошибку тоже можно не сразу найти.
Если DecimalSeparator='.', то все хорошо, а иначе ... ошибка конвертации строки в булевский тип !
Просто это нужно знать и не допускать таких ошибок.
Variant — это разумное послабление строгих правил языка во избежание работы руками.
Разумеется, руки не должны впереди головы бежать.

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 12:33:43 GMT:

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

А я иногда не хочу. Например, мне просто надо, чтобы строчки на любом из поддерживаемых программой языков для любого шрифта всегда влазили в диалог . Еще вопрос, что требуется чаще — сплиттеры или такие вот неуправляемые пользователем сайзеры.
Желательно, что бы библиотека поддерживала оба случая.
Кстати, сплиттеры в wxWindows сделаны не на основе сайзеров. IMHO, зря — хотя есть аргументы и в пользу именно такого решения.

S>> или вовсе разделителя никакого быть не должно — просто контролы в
S>> диалоге при ресайзе должны определенным образом менять свои размеры.
S> Не согласен. Одного ресайза недостаточно.

Разумеется. Я привел лишь один частный случай.

S>> может быть окном и отдавать сообщений родителю,
S> А родитель что будет с ними делать?

Ресайзить детишек, вестимо, и менять положение сплиттера.

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

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

S>> Конечно. В wxWindows у него мембер такой есть — m_windowSizer. А вот
S>> что это за сайзер, оно знать не должно. Что обеспечивает большую
S>> гибкость и расширяемость.
S> Интересно, и какую функциональность на себя берет этот Sizer?

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

S> Это-то понятно. Вопрос в том, как он сам будет получать сообщения?

Его методы будет вызывать оконный класс — он должен знать о существовании сайзера. Просто декомпозиция на два объекта. Грубо говоря, обработчики нескольких оконных сообщений вынесли в отдельный класс.

S> У нас
S> получается некоторое противоречие, т.к. сам набор сообщений, которые мы
S> собираемся послать этому нашему виртуальному мемберу, зависит от того,
S> какого он типа.

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

Best regards,
Sergey.

Hello, zaiats_2k!
You wrote on Wed, 22 Oct 2003 12:32:48 GMT:

S>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>> окна. Например так, как это сделано в wxWindows.

zk>>> Я только одного не понимаю, кто мешает вам изобрести порох
zk>>> непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема
zk>>> волнует!

S>> Написано уже. Но не для Delphi.

zk> Кем, когда, для чего, где взять, сколько стоит, как называется?

Называется, как я уже говорил, wxWindows, брать на www.wxwindows.org, на остальные вопросы сам ответы найдешь — если оно тебе надо.



Best regards,
Sergey.

Hello, Lloyd!
You wrote on Wed, 22 Oct 2003 12:44:16 GMT:

S>> Написано уже. Но не для Delphi.

L> Уж не про джавовский ли ты говоришь?

Плюсовый. Но на джавовский, AFAIK, сильно похож.


Best regards,
Sergey.

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

S>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>> окна. Например так, как это сделано в wxWindows.
_>Кем, когда, для чего, где взять, сколько стоит, как называется?
Тебе уже сказали. Воспользуйся google'ом. А вобще это кроссплатформенная ГУИ библиотека для С++.

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

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

S>>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>>> окна. Например так, как это сделано в wxWindows.
_>>Кем, когда, для чего, где взять, сколько стоит, как называется?
WH>Тебе уже сказали. Воспользуйся google'ом. А вобще это кроссплатформенная ГУИ библиотека для С++.

VC 6.0 я не готов ради него юзать, а 7й в списке поддерживаемых отсутствует... ;(

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


S>Не вижу никакого противоречия. В принципе, для общего интерфейса сайзера вполне хватает функциональности обычного окна (WM_SIZE, WM_GETMINMAXINFO и т.п.) — просто не удобно использовать окна там где они не нужны (где можно обойтись более легковесными объектами).
А-а. Просто когда я вижу что-то, что выглядит как окно и ведет себя как окно, я говорю "это-окно". Даже если у него нету хэндла

S>Best regards,
S> Sergey.

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 14:13:41 GMT:

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

S>> Не вижу никакого противоречия. В принципе, для общего интерфейса
S>> сайзера вполне хватает функциональности обычного окна (WM_SIZE,
S>> WM_GETMINMAXINFO и т.п.) — просто не удобно использовать окна там где
S>> они не нужны (где можно обойтись более легковесными объектами).
S> А-а. Просто когда я вижу что-то, что выглядит как окно и ведет себя как
S> окно, я говорю "это-окно". Даже если у него нету хэндла

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

Best regards,
Sergey.

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

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

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

S>>>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>>>> окна. Например так, как это сделано в wxWindows.
_>>>Кем, когда, для чего, где взять, сколько стоит, как называется?
WH>>Тебе уже сказали. Воспользуйся google'ом. А вобще это кроссплатформенная ГУИ библиотека для С++.

_>VC 6.0 я не готов ради него юзать, а 7й в списке поддерживаемых отсутствует... ;(

Можно попробовать C++BuilderX — она туда прикручена.

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

А>Здравствуйте, zaiats_2k, Вы писали:
WC>>>Что ж делать, если Delphi специально предназначен для написания крутых GUI-программ?

Z2>>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?
А>Посмотри Магнат-софт! Система автоматизации производства:
А>1 — работает на 500 рабочих мест.
А>2 — 13 немецких заводов работают именно под ней.
А>Имеет внутренний макро язык. ну и т.д.
А>Dmitriy

А вы знаете, что ИНФИН (основной конкурент 1С) — написан на Delphi. Нет? Ну, тогда знайте же. Работает по всей россии и у нас на предприятии в частности на 32-компьютерных местах.

_silent

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

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

S>>По-вашему, чем вызвано такое негативное отношение?

DG>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

Здравствуйте, Vyacheslav A. Sartin, Вы писали:

S>>>По-вашему, чем вызвано такое негативное отношение?

DG>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
VAS>Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
VAS>Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

Забавный миф.

Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
Квалификация у ВСВ-шника — "выше". Так? Из чего будут складываться умения этих двух программистов на этом этапе?
Из знаний
1) Языков: OP,C++
2) Библиотек: VCL ну и пусть немного ADO.
3) Зачатков алгоритмов.

Выкинем за скобки общее, что остаётся? Различие в языках.

Другой пример:
Две группы начали с нуля и сотворили два аналогичных больших и сложных проекта.
В результате, "квалификация" ВСВ-шников по-прежнему "выше"?
Если убрать за скобки общие необходимые знания и умения, необходимые для создания таких проектов,
в чём будут различия? В знании языков программирования.

Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
Ну, с таким определением можно согласится, если оно будет использоваться только в указанном смысле.

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

M>Забавный миф.
Увы, это не миф.

M>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
BCB — то же самое, что и дельфи, только немного с другим синтаксисом. Возьми хотя бы MSVC. Убогий MFC заставит поковыряться в исходниках, чтобы понять, как он работает, и в WinAPI, чтобы обойти ограничения.
M>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
Естественно. А если бы кто-то отколбасил эту же простенькую программу на асме, то его квалификация (в кодерском смысле) будет неизмеримо выше, чем у MSVC девлопера. Потому, что кроме WinAPI придется еще и поизучать Intel, модели памяти, и подучить алгоритмы. Там, где на Delphi пишем Strings.Sorted:= True, на асме надо знать, что такое сортинг.
M>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
Да. Для BCB/Delphi это именно так. Но никто BCB с Delphi сравнивать и не берется.
Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей.

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

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

M>Здравствуйте, Vyacheslav A. Sartin, Вы писали:

S>>>>По-вашему, чем вызвано такое негативное отношение?

DG>>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
VAS>>Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
VAS>>Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

M>Забавный миф.

M>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
Делфи и билдер, с небольшой натяжкой, можно считать равнозначными языками.

M>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
M>Квалификация у ВСВ-шника — "выше". Так?
Да, так как C++ более сложен для восприятия, посравнению с ОР.

M>Из чего будут складываться умения этих двух программистов на этом этапе?
M>Из знаний
M>1) Языков: OP,C++
M>2) Библиотек: VCL ну и пусть немного ADO.
для простенькой программы понимания VCL не требуется, может только самую малость.

M>3) Зачатков алгоритмов.
И что, теперь можно гордо кричать Я ПРОГРАММИСТ?

M>Выкинем за скобки общее, что остаётся? Различие в языках.
Это не мало важно, так как в MSDN все описания функций и тогоже ADO приведены в С-шной натации, а большинство примеров написаны на С++.
А без умения читать MSDN далеко не уйдёшь.

M>Другой пример:
M>Две группы начали с нуля и сотворили два аналогичных больших и сложных проекта.
M>В результате, "квалификация" ВСВ-шников по-прежнему "выше"?
M>Если убрать за скобки общие необходимые знания и умения, необходимые для создания таких проектов,
M>в чём будут различия? В знании языков программирования.
Данный пример мне кажется не уместным, поскольку я писал именно про начинающих.

M>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
M>Ну, с таким определением можно согласится, если оно будет использоваться только в указанном смысле.

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

PS: Сам пишу на дельфях и очень от них тащюсь , при этом наравится писать чистом асм'е. В С++ не нравится синтаксис, но без него не куда.

PSS: не кого не хотел обидить, если когото обидел извените.

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

M>>Забавный миф.
S>Увы, это не миф.

M>>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
S>BCB — то же самое, что и дельфи, только немного с другим синтаксисом. Возьми хотя бы MSVC. Убогий MFC заставит поковыряться в исходниках, чтобы понять, как он работает, и в WinAPI, чтобы обойти ограничения.
M>>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
S>Естественно. А если бы кто-то отколбасил эту же простенькую программу на асме, то его квалификация (в кодерском смысле) будет неизмеримо выше, чем у MSVC девлопера. Потому, что кроме WinAPI придется еще и поизучать Intel, модели памяти, и подучить алгоритмы. Там, где на Delphi пишем Strings.Sorted:= True, на асме надо знать, что такое сортинг.
M>>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
S>Да. Для BCB/Delphi это именно так. Но никто BCB с Delphi сравнивать и не берется.
S>Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей.

S>Можно сравнить это с приготовлением еды супротив открывания консервов.
S>Если мы даем человеку возможность при приготовлении еды вскрыть банку или разогреть блины в микроволновке, то можно легко получить целую армию "поваров". И фаст-фуды именно это и делают. Но очень немногие из этих поваров задумаются над тем, откуда берутся блины и банки. И это ограничение их квалификации. Дело не в том, что они беспомощны без блинов и банок. Дело в том, что в некоторых случаях блинов и банок недостаточно. И если поварское мышление ограничено содержимым холодильника, то он всемерно будет избегать каких-либо новых решений. Просто потому, что он никогда их не делал. В клинических случаях он будет бояться посолить блюдо, потому что все, что он до сих пор "готовил", было магически посолено до него.

Аналогия понятна и принята.

<off>
Следуя ей, получается, что "эксклюзивный" повар в дорогом ресторане, имеющий в своём распоряжении обученный штат помошников, пользующийся посудой за $5000, а не за $3, и т.п., — в "кодерском" смысле неизмеримо ниже, чем первобытный человек с каменным ножом, поджаривающий на костре мамонта, которого сам перед этим и убил? И единственный способ у такого повара повысить свою квалификацию — это перебраться в тайгу? А для программиста С++ — перейти исключительно на ассемблер?

Другой пример:
В определённой конфигурации 1С надо чуть изменить алгоритм проводки определённого документа. Что сделает "малоквалифицированный" программист? Он изменит/добавит пару строчек в конфигурацию. И всё. А "высококвалифицированный"? Сваяет на VC+ATL ActiveX объект, реализует в нём трубеумую функциональность и вызовет этот объект из нужного места? Правильно?
<on>

А если серьёзно, я согласен с тем, что квалификация С++-ника выше дельфиста. Но только (удачный термин!) в кодерском смысле.

"Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей."

Вот именно — прокалывание — кодирование. Не всякий сможет/возьмётся. А вот насчёт "готов к написанию и значительно более сложных вещей" — не обязательно. Можно так и остаться прокалывателем дырочек.

Здравствуйте, Vyacheslav A. Sartin, Вы писали:

S>>>>>По-вашему, чем вызвано такое негативное отношение?

DG>>>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
VAS>>>Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
VAS>>>Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

M>>Забавный миф.

M>>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
VAS>Делфи и билдер, с небольшой натяжкой, можно считать равнозначными языками.

Несколь странно. Как мне кажется, различие ВСВ и VC — только в IDE и используемых библиотеках.

M>>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
M>>Квалификация у ВСВ-шника — "выше". Так?
VAS>Да, так как C++ более сложен для восприятия, посравнению с ОР.

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

M>>Из чего будут складываться умения этих двух программистов на этом этапе?
M>>Из знаний
M>>1) Языков: OP,C++
M>>2) Библиотек: VCL ну и пусть немного ADO.
VAS>для простенькой программы понимания VCL не требуется, может только самую малость.

M>>3) Зачатков алгоритмов.
VAS>И что, теперь можно гордо кричать Я ПРОГРАММИСТ?

Точно также может кричать начинающий ВСВ-шник. Поэтому, имхо, претензии должны быть к людЯм, а не к ЯП.

M>>Выкинем за скобки общее, что остаётся? Различие в языках.
VAS>Это не мало важно, так как в MSDN все описания функций и тогоже ADO приведены в С-шной натации, а большинство примеров написаны на С++.
VAS>А без умения читать MSDN далеко не уйдёшь.

Умение/неумение читать MSDN — имхо, не зависит от языка программирования.

M>>Другой пример:
M>>Две группы начали с нуля и сотворили два аналогичных больших и сложных проекта.
M>>В результате, "квалификация" ВСВ-шников по-прежнему "выше"?
M>>Если убрать за скобки общие необходимые знания и умения, необходимые для создания таких проектов,
M>>в чём будут различия? В знании языков программирования.
VAS>Данный пример мне кажется не уместным, поскольку я писал именно про начинающих.

Согласен. Я просто хотел продемонстрировать частный случай.

M>>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
M>>Ну, с таким определением можно согласится, если оно будет использоваться только в указанном смысле.

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

VAS>PS: Сам пишу на дельфях и очень от них тащюсь , при этом наравится писать чистом асм'е. В С++ не нравится синтаксис, но без него не куда.

Собственно, полагаю, что наши мнения сходятся.
А по-поводу исходного вопроса, думаю, правильно будет так:
Из-за более "низкого старта" в Delphi — программистов на нём — больше.
Соответсвенно, низкоквалифицированных — тоже больше.
И, следовательно, встречаются они чаще.
А?

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

M>>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
S>BCB — то же самое, что и дельфи, только немного с другим синтаксисом. Возьми хотя бы MSVC. Убогий MFC заставит поковыряться в исходниках, чтобы понять, как он работает, и в WinAPI, чтобы обойти ограничения.
M>>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
S>Естественно. А если бы кто-то отколбасил эту же простенькую программу на асме, то его квалификация (в кодерском смысле) будет неизмеримо выше, чем у MSVC девлопера. Потому, что кроме WinAPI придется еще и поизучать Intel, модели памяти, и подучить алгоритмы. Там, где на Delphi пишем Strings.Sorted:= True, на асме надо знать, что такое сортинг.

Да все-то верно...
Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством? Допустим такая сложность заставит начинающего программиста разобраться во многих нюансах, но почему я должен снова и снова сталкиваться с этой сложностью, когда мне необходимо в сжатые сроки разработать некоторую программу?
XXI век на дворе, а я должен тратить время на написание алгоритма сортировки, потому что это повысит мою квалификацию?
Профессионал обязан иметь в своем распоряжении удобный инструмент, позволяющий быстро и качественно решить поставленную задачу.

M>>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
S>Да. Для BCB/Delphi это именно так. Но никто BCB с Delphi сравнивать и не берется.
S>Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей.

Опять-таки верно, Delphi допускает низкий старт. Но давайте не перекладывать с больной головы на здоровую. Никто не мешает повышать свою квалификацию, программируя на том же Delphi, только теперь это становится необязательно. А настоящие профессионалы, уж будьте уверены, знают и про модели памяти, и про алгоритмы сортировки и не только про это. Язык программирования тут ни при чем.