Войти
ФлеймФорумПрограммирование

Очень Красивый Дельфи! (5 стр)

Страницы: 14 5 6 7392 Следующая »
#60
5:58, 20 сен. 2004

Хоть это и флейм, но зачем писать пустые сообщения (21, 22, 29, 58)? В таком споре можно попытаться хотя бы выяснить истоки и причины разных предпочтений программистов.

Скажу, почему не люблю Delphi:
1. Win SDK, DirectX SDK и некоторые другие (Notes CPP API, к примеру), все заголовки на C/C++. Чтобы их перевести на Delphi потребуется немало времени, чем Borland и занималась много лет. :)
2. Сама среда плохо приспособлена для разделения проектирования и реализации (*.h и *.cpp файлы). Неудобно документировать код (не комментарии, а сопроводительная документация), т.к. реализация в одном месте с описанием (можно и разделить, но сама среда призывает именно к такому подходу, и именно так многие поступают).

Всё остальное, это сам синтаксис языка, дело вкуса. Я работаю вместе как с дельфистами, так и с приверженцами C++. Можно сказать и о недостатках: для сравнимой с Delphi скорости программирования на C++, нужен немного больший опыт программиста. Но это субъективное восприятие.


#61
9:28, 20 сен. 2004

Lyger
>2. Сама среда плохо приспособлена для разделения проектирования и реализации
>(*.h и *.cpp файлы). Неудобно документировать код (не комментарии, а
>сопроводительная документация), т.к. реализация в одном месте с описанием
>(можно и разделить, но сама среда призывает именно к такому подходу, и именно
>так многие поступают).
По смыслу h+cpp=pas, а документирование (и процесс разработки) - TODO List.

Всем: давайте в http://www.gamedev.ru/forum/?group=9&topic=46 перейдем - кто 2048 запостит?

#62
10:35, 20 сен. 2004

stopkin

>По смыслу h+cpp=pas,

Пусть так. Проблема в нахождении h (т.е. h = pas - cpp).

>а документирование (и процесс разработки) - TODO List.

Я говорю о документировании, имея в виду составление такого документа, в котором описывается написанный код наиболее компактным и доступным образом. Это необходимо для сопровождения идальнейших разработок. В С++ документацию можно писать по *.h файлам, с кодом Дельфи это получается сложнее.

#63
11:22, 20 сен. 2004

Lyger
>Проблема в нахождении h (т.е. h = pas - cpp).
h=от interface до implementation

>В С++ документацию можно писать по *.h файлам,
>с кодом Дельфи это получается сложнее.
Чем не документация:
{ TODO -oэто мое -cдокументация : Здесь описание }

#64
11:46, 20 сен. 2004

stopkin

>h=от interface до implementation

Но в том же файле. Можно выделить?

>Чем не документация: { TODO -oэто мое -cдокументация : Здесь описание }

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

#65
12:32, 20 сен. 2004

Ха ха ха... Не удержался, напишу... =)
По поводу того что круче писать не буду, так как всё всем надеюсь и так понятно...
ДЛЯ РАЗНОГО РОДА ЗАДАЧ НУЖНО ВЫБИРАТЬ ОПТИМАЛЬНЫЕ ДЛЯ ВЫПОЛНЕНИЯ ЭТИХ ЗАДАЧ ИНСТРУМЕНТЫ!
(но это совсем не значит что данную задачу нельзя будет выполнить с использованием неоптимального инструмента)

Но вот интересный факт:
Во все топики Delphi vs С++ пишут одни и те же люди...
По-моему это о чем то говорит...
Интересно о чем? =)))

#66
12:41, 20 сен. 2004

Lyger
>Но в том же файле. Можно выделить?
можно include, тогда получится совсем как в Си. Но как ты правильно заметил, так почти не делают

>>Чем не документация: { TODO -oэто мое -cдокументация : Здесь описание }
>Не знаю, может и пойдет. Нужен такой документ, посмотрев на который, можно
>понять работу программы без заглядывания в код.
Все TODO можно собрать по фильтру в таблицу (html), например.

dust
>Но вот интересный факт:
>Во все топики Delphi vs С++ пишут одни и те же люди...
>По-моему это о чем то говорит...
>Интересно о чем? =)))
Ну есть у людей тяга к общению. Человек - животное коллективное, и интересуется, кто чем занимается. Сишники такими темами на самом деле Delphi изучают.

#67
12:41, 20 сен. 2004

Это конец. Мира не будет.

Я из принципа останусь с Delphi(Object Pascal).

P.S.
Так как я человек разумный, то объясню почему.
1. Это хобби а не работа, я могу себе позволить программировать на чем мне удобней.
2. Привычка сильная. Прямо подсел я на синтаксис Pascal'я.
3. В совокупности первых двух пунктов - "А оно мне надо?(C++)"

P.P.S.
И Delphi далеко не игрушка. :)

#68
12:59, 20 сен. 2004

TIFA
Да-да-да, от синтаксиса многое зависит, мне begin удобнее написать, чем шифт-{. На счет обиды - если вспомните глобальную тему 46, то там встречались ложные компроментирующие сведения о Паскалях. Угадайте, кто распускал такое?

#69
13:10, 20 сен. 2004

Вот блин. Недавно прожект крупный закончили. На самом низком уровне embeded системы на специализированных х86 почти-совместимых процессорах+несколько АРМовских+х51 совместимые( но это не важно). Ни ОС, ни фига нету. Ну, взяли мы несколько Сшных компилеров( некоторые специализируются для встраиваемых приложений). Написали, короче и обомлели. Ни удобства написания-линковки, ни качества кода( не надо говорить о ламерстве---тут люди по 10-15 лет для этих самых эмбедид программируют.). Я уж не говорю о надёжности.  Полная лажа. Пришлось переделывать. Замутили всё х86 совместимое на фасме( кто на асме сейчас работает-поймёт что за компилер)+ специализированных ассемблерах для АРМ и 51х. Вот я блин и думаю, нафиг С придумали????
Всем этим набором должно было управлять несколько серверов под Вин2003. Взяли ВС 2003 и давай собирать( в поставке шло несколько либов специализированных без сырцов,--как их прикрутили в ВС2003 я не говорю, ведро валерьяны ушло). В общем заделали эту штуку, да ещё и интеловским компилером компильнули. Вроде работает, но только как-то медленно. Переделали на структуры с поинтерами на функции( ушли короче от ООП в исполнении компилера). Больше ничего не трогали. Прирост 6%. Ну и нафиг нам ООП С++????
Для управления( удалённого и локального) всем этим написали клиентскую распределённую автоматизированную систему на Делфи( без ВЦЛ, на ВИНАПИ), который ещё и на Юникс системы портируем)( фрипаскаль в подмогу). И всё это прекрасно работает.

Как выводы могу сказать следующее:
1) Применение ЯВУ для эмбедидов--смерти подобно
2) ООП в исполнении С++ для высокопроизводительных приложений--как якорь на шею. Со всеми его проверками, автоматическими вещами и т.д. и т.п.
3) Если человек говорит, что вызов метода free  после метода Create  его напрягает, можно ли говорить о его компетентности, как программиста? Позволять компилятору автоматически делать некоторые вещи, без возможности запрещения этого ,-- непростительно и смертиподобно)( по крайней мере там где есть критерии надёжности, скорости и отказоустойчивости. Написание всяких демок по типу один раз запустилось, второй вылетело--не в счёт).

Тут всё ещё говорят, что STL часть С++. Простите, если метаязыковые вещи вставляют в обычный язык программирования, то можно ли этого "метиса" называть языком программирования???? Я думаю нет. Тогда, что ж вы сравниваете обыкновенный язык программирования Паскаль( Object Pascal-не важно) с этим монстрообразным гибридом? Это как минимум не корректно.

Тут люди говорят ещё, что поскольку WinApi, OGL, DirectX и иже с ними написаны на С(С++), так зачем писать проги на каком-то другом языке. Но простите, процессор CPU выполняет х86 коды, GPU свои , им по барабану из чего получены эти коды. Так давайте тогда писать на ассемблере или сразу в машкодах???
Вся эта ваша ООП-СТЛ наворочка С++ им по барабану, они и понятия не имеют, что вызывают прайвет метод какого-то класса( к примеру).


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

#70
13:16, 20 сен. 2004

stopkin
>Ну есть у людей тяга к общению. Человек - животное коллективное, и
>интересуется, кто чем занимается.

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

#71
13:41, 20 сен. 2004

dust
>=) А по-моему дело не в этом... Просто каждый хочет доказать что у него
>длинее... =)
Ну, это слишком тривиально и уже говорилось. Надо же что-то новенькое придумать.

Disabled
Добавлю, все микроконтроллеры (а их не мало используется) программируются ассемблером. Есть, конечно, и Си-подобные языки, но их не используют (я не видел) из-за неэффективности компиляторов. При чем тут игры? На PIC`е можно сделать теннис с выводом прямо на AV телевизора.

#72
14:04, 20 сен. 2004

stopkin, тут уже скотились до обычного С++ версус паскаль(Делфи), даже возможности "todo" обсуждают.
А тебе не кажется что в игре тоже достаточно жёсткие требования к скорости и надёжности? По сему и говорю, что ООП-СТЛ ная надстройка С++ --якорь в ж., нет якорь на шею. Даже, если посмотреть на игры, которые, чего скрывать, почти все делаются на С++. Посмотри на количество патчей, которое вываливается после выхода игры. И это всё при том, что применяются все "фишки" С++. К тому же многие вещи не оптимизированны( лень программиста и расчёт на компилятор С++). Как результат -- гейма требует мошнейших вычислительных ресурсов, чтоб нормально работать. Я лично не считаю, что это хорошо. На паскале же мозги всегда работают правильно, всегда надо стремится к оптимизации. Это позволяет программисту оставаться программистом, а не крякозяброй по написанию иерархии классов и шаблонов.

Остальные комментарии смотри в 69

#73
14:13, 20 сен. 2004

ДЭЛФИСТАМ!!

А почему же большинство проектов написано на С++???

#74
14:21, 20 сен. 2004

Disabled
>Вот блин. Недавно прожект крупный закончили. На самом низком уровне embeded
На счет ембедед систем не скажу ибо дел с ними не имел.

>Всем этим набором должно было управлять несколько серверов под Вин2003. Взяли
>ВС 2003 и давай собирать( в поставке шло несколько либов специализированных без
>сырцов,--как их прикрутили в ВС2003 я не говорю, ведро валерьяны ушло).
Что за либы?
>В общем заделали эту штуку, да ещё и интеловским компилером компильнули. Вроде
>работает, но только как-то медленно. Переделали на структуры с поинтерами на
>функции( ушли короче от ООП в исполнении компилера). Больше ничего не трогали.
>Прирост 6%. Ну и нафиг нам ООП С++????
А можно пример?
>Для управления( удалённого и локального) всем этим написали клиентскую
>распределённую автоматизированную систему на Делфи( без ВЦЛ, на ВИНАПИ),
>который ещё и на Юникс системы портируем)( фрипаскаль в подмогу). И всё это
>прекрасно работает.
А я тут серваки на С++ пишу и ни чего все прекрасно работает.

>3) Если человек говорит, что вызов метода free после метода Create его напрягает, можно ли говорить о его компетентности, как программиста?
Те ты считаешь что С++ программисты которые используют смартпоинтеры не компетентны? Смелое заявление.

struct test
{
	__declspec(noinline)//подрезаем крылья оптимизатору...
		static test* create(){std::cout<<"c\n";return 0;}
	__declspec(noinline)
	void free(){std::cout<<"f\n";}
};

template<class T>
struct smart_ptr
{
	smart_ptr(T* ptr)
		:ptr(ptr)
	{}
	~smart_ptr()
	{
		ptr->free();
	}
	T* ptr;
};

void test_fn1()
{
	test* t=test::create();
	t->free();
}
void test_fn2()
{
	smart_ptr<test> t=test::create();
}
?test_fn1@@YAXXZ PROC NEAR				; test_fn1, COMDAT

; 25   : 	test* t=test::create();

	call	?create@test@@SAPAU1@XZ			; test::create

; 26   : 	t->free();

	mov	ecx, eax
	jmp	?free@test@@QAEXXZ			; test::free
?test_fn1@@YAXXZ ENDP					; test_fn1
?test_fn2@@YAXXZ PROC NEAR				; test_fn2, COMDAT

; 30   : 	smart_ptr<test> t=test::create();

	call	?create@test@@SAPAU1@XZ			; test::create

; 31   : }

	mov	ecx, eax
	jmp	?free@test@@QAEXXZ			; test::free
?test_fn2@@YAXXZ ENDP					; test_fn2
(C) VC++7.1
Разницу в ассемблерном коде видишь? Я нет.
>Позволять компилятору автоматически делать некоторые вещи,
А почему бы и нет? Особенно если у него это получается не хуже?
>без возможности запрещения этого
Ха! В С++ какраз можно отключить все что не нужно.
>,-- непростительно и смертиподобно)( по крайней мере там где есть критерии надёжности, скорости и отказоустойчивости.
А ручное дерганье за free повышает вероятность ошибки. Как следствие снижает надежность.
На счет скорости смотри код выше.

>Тут всё ещё говорят, что STL часть С++.
STL входит в стандарт языка.
>Простите, если метаязыковые вещи вставляют в обычный язык программирования, то можно ли этого "метиса" называть языком программирования????
>Я думаю нет.
А я думаю можно.
>Тогда, что ж вы сравниваете обыкновенный язык программирования Паскаль( Object Pascal-не важно) с этим монстрообразным гибридом? Это как минимум не корректно.
Но можно _стандартную_ библиотеку и не привлекать. У С++ и так преймуществ хватает.
Шаблоны и автоматические деструкторы паскалю крыть нечем.
>Тут люди говорят ещё, что поскольку WinApi, OGL, DirectX и иже с ними написаны на С(С++),
Для них сделаны SDK на С/С++.

Страницы: 14 5 6 7392 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.