идеальный язык программирования , каким он должен быть?

Цитата AndNot @ 21.10.06, 11:44

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

Блин, в смысл ВЧИТЫВАЙСЯ
Я ГОВОРЮ О ТОМ, ЧТО ПРИ ДАННОЙ МОЩНОСТИ ГРАФИКИ ОПТИМИЗАЦИЯ ПРОВОДИЛАСЬ БЕЗ ЕДИНОЙ СТРОЧКИ АСМА
А НЕ ПРО КАЧЕСТВО ГРАФИКИ ,
ТЫ НЕ ВЫНОСИМ !!!!
ПОСТОЯННО ОТВЕЧАЕШЬ НЕ В ТУ СТЕПЬ
РАЗГОВОР У НАС О КАЧЕСТВЕ ОПТИМИЗАЦИИ КОМПИЛЯТОРА Си

Добавлено 21.10.06, 12:45

Цитата AndNot @ 21.10.06, 11:44

то разжуй уж мне, для чего собственно нужна венгерская нотация,

ДА БЛИН НЕ ПОЛЬЗУЙСЯ ЕЙ
БОЛЬШАЯ ЧАСТЬ ПРОГРАММИСТОВ ЕЙ НЕ ПОЛЬЗУЕТСЯ И ЖИВЕТ НОРМАЛЬНО
ТЕМ БОЛЕЕ НИКАКОЙ СЛОЖНОСТИ В ВЕНГЕРСКОЙ ЗАПИСИ НЕТ

разницы между m_Size и просто Size при названии переменной класса нет

Добавлено 21.10.06, 12:47

Цитата AndNot @ 21.10.06, 11:44

пригодиться множественное наследие

Для качественного моделирования системы и построения связей между элементами
в качестве примера иерархии объектов компьтерный играх

Сообщение отредактировано: impik777 - 21.10.06, 12:47

Цитата impik777 @ 21.10.06, 12:37

РАЗГОВОР У НАС О КАЧЕСТВЕ ОПТИМИЗАЦИИ КОМПИЛЯТОРА Си

Это очень хитрая штука. Прежде всего C переносим, а уже затем речь идет об эффективности. На разных платформах с этим по-разному. На x86 более-менее хорошие оптимизирующие компиляторы (gcc, icc, msvc) (особенно учитывая такое малое число регистров); на x86 писать более оптимальный код на асме — ИМХО слишком сложно. На x86-64 с этим должно быть получше.

Цитата impik777 @ 21.10.06, 13:02

ТЫ НЕ ЗАМЕТИЛ, ЧТО НАРОД, ПОБЕСЕДОВАВ С ТОБОЙ, УХОДИТ ИЗ ЭТОЙ ТЕМЫ

Не, это я с тобой побеседовал

Цитата wormball @ 21.10.06, 13:44

Не, это я с тобой побеседовал

Тебя тогда вообще не было видно

Сообщение отредактировано: impik777 - 21.10.06, 15:09

Цитата impik777 @ 21.10.06, 15:06

Тебя тогда вообще не было видно

Вот потому и не было.

Цитата impik777 @ 21.10.06, 12:37

Я ГОВОРЮ О ТОМ, ЧТО ПРИ ДАННОЙ МОЩНОСТИ ГРАФИКИ ОПТИМИЗАЦИЯ ПРОВОДИЛАСЬ БЕЗ ЕДИНОЙ СТРОЧКИ АСМА

Причем здесь графика и оптимизация? В 3Д рулят акселераторы и FPU,XMM,3DNOW наконец. А это еще со времен царя Гороха компиляторы неплохо оптимизировали, т.к. там и оптимизировать то почти и нечего, правила очень простые.

Цитата impik777 @ 21.10.06, 12:37

РАЗГОВОР У НАС О КАЧЕСТВЕ ОПТИМИЗАЦИИ КОМПИЛЯТОРА Си

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

Цитата impik777 @ 21.10.06, 12:37

Добавлено Сегодня, 15:45
Цитата (AndNot @ Сегодня, 14:44)
то разжуй уж мне, для чего собственно нужна венгерская нотация,

ДА БЛИН НЕ ПОЛЬЗУЙСЯ ЕЙ
БОЛЬШАЯ ЧАСТЬ ПРОГРАММИСТОВ ЕЙ НЕ ПОЛЬЗУЕТСЯ И ЖИВЕТ НОРМАЛЬНО
ТЕМ БОЛЕЕ НИКАКОЙ СЛОЖНОСТИ В ВЕНГЕРСКОЙ ЗАПИСИ НЕТ

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

Цитата impik777 @ 21.10.06, 12:37

Для качественного моделирования системы и построения связей между элементами
в качестве примера иерархии объектов компьтерный играх

Не вижу, что здесь даст множественное наследие, по сравнению с простым ООП.

Цитата mo3r @ 21.10.06, 12:52

на x86 писать более оптимальный код на асме — ИМХО слишком сложно. На x86-64 с этим должно быть получше.

Но с каждым поколением ситуация изменяется, сейчас уже намного легче, чем под те же 386-Пентиум ММХ.

Цитата impik777 @ 21.10.06, 13:02

ты бы не обращал внимания, потому что понимал их бессмысленность

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

Цитата impik777 @ 21.10.06, 13:02

то ты Си знаешь,
то не можешь разобраться в элементарных вещах
типа курса тугриков, и причем тут контроль типов

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

Цитата impik777 @ 21.10.06, 13:02

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

Только так и выясняется, что в языке необходимо, а что мусор. Если ты не заметил, то здесь выясняется, что в идеальном языке действительно должно быть, а что не нужно.

Цитата impik777 @ 21.10.06, 13:02

СКАЖИ, ЧТО-НИБУДЬ ПОЛЕЗНОЕ
А НЕ ГОВОРИ ВСЯКИЕ ГЛУПОСТИ

Без дураков жить будет скучно Я много глупостей могу наговорить, но цель оправдывает средства
Хотя бы:

Цитата impik777 @ 21.10.06, 13:02

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

Я не понимаю самого механизма множественного наследования С++, вот и просил нормально пояснить, что за штука и с чем ее едят, как реализована. Ну не увидел я в С++ простого способа управления такими объектами. И не ты ли доказывал, что:

Цитата impik777 @ 21.10.06, 15:06

Цитата (AndNot @ 30.09.06, 19:24)
Можно ли объекту TDvoechnik указать, что отныне его родитель TPerson? ну или TPredok? А потом восстановить "справедливость".

укажи пример такой необходимости

[.....]

Цитата (AndNot @ 2.10.06, 10:21)
не появились ли в С подобные возможности манипуляций с объектами

таких манипуляций нет, потому что в них нет необходимости на С++

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

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

ЗЫ: Раз уж речь зашла об оптимизации, не мог бы кто скомпилить следующее, очень уж хочется узнать, насколько продвинулись компиляторы, по сравнению с VC++ 6.0

void __cdecl c_sort(int *src, int n)
{
int a; int t; int f;
if (n<2)
return; // Меньше двух элементов сортировать нельзя!
do{
f=0; // устанавливаем флаг сортировки в нуль
// Перебираем все элементы один за другим
for (a=1; a<n; a++)
// если следующий элемент меньше предыдущего
// меняем их местами и устанавливаем флаг
// сортировки в единицу
if (src[a 1]>src[a])
{
t=src[a 1];
src[a 1]=src[a];
src[a]=t;
f=1;
}
// повторять сортировку до тех пор, пока не дождемся
// первого "чистого" прохода, т.е. прохода без изменений
} while(f);
}

А я сравню с асмом. У VC++ 6.0 отставание было небольшим.
ЗЗЫ: И не обязательно на VC.

Цитата AndNot @ 21.10.06, 19:26

и не надо кричать

Пока не покричишь, к теме обсуждения людей не вернешь
заметь, я делаю,это уже второй или третий раз, ТОЛЬКО ТОГДА
народ возвращается к дискуссии, а не продолжает холивар

Так, все теперь только по теме

Добавлено 22.10.06, 09:32
Про венгерскую нотацию:
это просто, люди пытались придумать способ, чтобы имя переменной отражало не только смысл
(семантику),но и например тип.
вот есть переменная Size, по названию видно, что она отражает размер(тут не важно чего),
а по венгерке можем написать, iSize, явно показав, что это целое число, это бывает удобно
в больших листингах, но еще раз повторяю, что забивать этим голову не стоит, т.к.
многие программисты этим не пользуются, в основном венгерка распостранена на
С++ и Java, причем в Микрософтовских версиях(очень они уж любят это дело)

Добавлено 22.10.06, 09:43
Про множественное наследование:
вот посмотри такую часть иерархии объектов игрового мира

OBJECT - просто интерфейс и набор общих параметров(например, высота положение)
//-----------------
STATIC->OBJECT - статический объект(не может двигаться и анимироваться)
//--------------------
DYNAMIC->OBJECT - динамический(реализует движение и анимацию)
//--------------------
EVENT->STATIC
EVENT->SCRIPT

- это невидимое событие , которое активизуруется при столкновении с ним и выполняет
какой-нибудь скрипт Lua

есть еще пример в Страуструпе
там одна ветка предоставляет интерфейс, а другая реализацию
(это 15 глава 3 издания)

НО В ПРИНЦИПЕ
и это не обязательно знать
любое наследование(пусть немного криво)
можно обойти простым агрегированием

Добавлено 22.10.06, 09:54
//--------------------------------------
Я ведь чего пытаюсь вам показать
С++ такой язык, который поддерживает мультипарадигменность
а значит множество возможностей решения одной и той же задачи

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

Поэтому и злюсь, когда вы упираетесь в какую-то непонятную вам часть
да забейте на нее, и смотрите другие возможности
А если она позарез необходима, то просто
берете НОРМАЛЬНУЮ библиотеку,
слава Богу, их сейчас достаточно и пользуйтесь
простым и удобным интерфейсом

самые лучшие программисты на С++ знают его
максимум на 60-70% и прекрасно живут,
причем каждый разбирается хорошо в своей части






Добавлено 22.10.06, 10:05

Цитата best_lamer @ 12.10.06, 07:02

По САБЖу
Идеального нет! И быть не может впринципе. Ибо идеальный должен учитывать все эти подходы а именно:
1) Процедурное программирование
2) Объектно-ориентированное программирование
3) Функциональное программирование
4) Логическое программирование
т.е. такой язык говоря языком простым должен быть повернут и в сторону машины и в сторону человека одновременно! А это невозможно. Пока...

Тут к слову, в С++ есть пока только 1 - 3 пункты
(думаю объяснять не надо)

а вот 4 пункта я не вижу, или я ошибаюсь ???

Цитата

идеальный язык программирования, каким он должен быть?

для меня такой уже есть - дельфи (хотя не всё там идеально). Вобщето посматриваю в сторону Free Basic Compiler однако нерадует портация сишных фич навроде тогоже
-> в доступе к структурам.
Зачем лишние телодвижения на -> ? вон в дельфе-то всё одной точкой.

Добавлено 22.10.06, 11:14
по идеи видеться некий компилирующий в native- p-cod "движок" с мощной настраиваемой конфигурацией и стратегией -например тойже стековой или там хешами. Хотя насчет стека ассоциируеться ужасненький FPU - по сравнению с котором MMX/SSE выглядит более человечно.

Цитата AndNot @ 21.10.06, 19:26

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

А что ты понимаешь под "привязкой к типам"?

Цитата Hryak @ 18.10.06, 17:22

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

Не читал весь флейм, но осуждаю. inc/dec не заполняют CF, OF и еще какие-то, но ZF будет установлен в случае чего, так что (особенно на 32-битных операндах) лучше использовать inc/dec, чем add/sub, т. к. короче => быстрее декодируется.

А че, тут уже забили на обсуждение ЯП? Я смотрю, вовсю низкоуровневую оптимизацию x86 обсуждают. Для фанатегов асма и им подобных хочу сказать, что в разработке любого приложения есть три этапа, которые должны происходить вот в такой последовательности:
1. программа работает
2. программа работает правильно
3. программа работает еще и быстро
Так что (без обид) asm безбожно сосет, когда речь идет о настоящем бизнесс-процессе. Никто не будет разрабатывать приложение целиком на asm.

О C/C++ -- они потихоньку начинают сворачиваться, ибо железо достигло того уровня, когда можно многие приложения писать на .NET/Java/Python без заметного ухудшения скорости, а вот надежности прибавляется и практически исчезает проблема с ликами. Конечно, я не думаю, чтобы эти языкик так просто взяли и отмерли -- нет, они займут свою узкую нишу, причем, скорее всего, займут ее в силу инертности человеческого мышления (все мы знаем, что люди не любят осваивать новое).

Цитата

1. программа работает
2. программа работает правильно
3. программа работает еще и быстро

Make in run,
make in right,
make in fast,
make in small.
(Copyright Kent Beck)

Сообщение отредактировано: BugHunter - 22.10.06, 13:07

Таки выкинули. (и не надо говорить, что holy wars - это не корзина!)
Теперь надо переименовать в "asm vs c++"

Цитата AndNot @ 21.10.06, 19:26

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

Не всякую задачу правильно затпихивать в рамки парадигмы ООП. Не знаю как в мире, но у нас в универе на многих специальностях решат тем, что не читают о том, как правильно проектировать, а читают лишь как разрабатывать с использованием определенных инструментальных средств. Это в корне неправильный подход. Настоящий разработчик должен обладать достаточно общирными знаниями в области инструментальных средств, которые можно использовать для решения той или иной задачи, чтобы оптимально выбирать инструмент (или комбинировать их) для решения поставленной задачи. Что я вижу сейчас: ставится задача и люди, даже не задумываясь, начинают воротить плюсовые классы, строить иерархию наследования и т. д., вместо того, чтобы провести декомпозицию задачи и прикинуть, а нельзя ли написать часть задачи на пионе, часть на перле, критичные по скорости участки на C, а потом соединить это все. Так ведь нет, негодяи пихают всюду C++ как универсальный инструмент для решения любой задачи. Я н спорю, на плюсах можно написать почти все что угодно. На асме тоже можно написать все что угодно, вопрос лишь в затраченном времени и т. н. «человеко-часах».
У меня есть перед глазами один пример, когда решили разрабатывать нативное приложение вместо пхпшной веб-морды. Конечно, получается красивее, да и функционал потенциально больше, но переносимость нулевая, куча багов, которых по определению не может возникнуть на интерпретируемых языках. О расширяемости тоже ничего сказать не могу, но интуитивно догадываюсь, что с учетом часто (а порой и кардинально) меняющихся требований, написать приличный расширяемый продукт на C/C++/Delphi/whatever черезвычайно проблематичено, т. к. проектирование сверху-вниз приводит просто напросто к периодическому рефакторингу. Знаю, что это решается хорошей четкой постановкой задачи, но ведь пользователю не будешь объяснять, что чтобы реализовать то, что ему хочется, надо впихнуть в фундамент новый кирпичик, а там все дырки уже замазаны цементом.

Добавлено 22.10.06, 13:18

Цитата wormball @ 22.10.06, 13:14

(и не надо говорить, что holy wars - это не корзина!)

не корзина.

Цитата wormball @ 22.10.06, 13:14

Теперь надо переименовать в "asm vs c++"

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

#include <iostream>
#include <cstdlib>
 
int main()
{
  std::cout << "Random is " << random() << std::endl;
  return 0;
}

Начнется все с попытки реализовать random, закончится выводом. Даже если взять всю libc и заюзать prntf, все равно получется дольше и больше букафф

Цитата linuxfan @ 22.10.06, 13:15

О расширяемости тоже ничего сказать не могу, но интуитивно догадываюсь, что с учетом часто (а порой и кардинально) меняющихся требований, написать приличный расширяемый продукт на C/C++/Delphi/whatever черезвычайно проблематичено, т. к. проектирование сверху-вниз приводит просто напросто к периодическому рефакторингу.

А вот это очень сильно зависит от того, как писать. И от того, что ты понимаешь под "приличным расширяемым продуктом".

Цитата

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

Хм. Придерживаясь определённого набора правил расширяемые приложения писать легко.
Именно такой чёткий набор правил я нашёл в своей инструкции программиста, которую здесь, к сожалению, опубликовать не могу, но было бы ОЧЕНЬ пользительно... но не всё в наших руках, к сожалению