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

Цитата AndNot @ 07.10.06, 13:55

Что такое '<<'? Ведь логически это обозначает только сдвиг. И человеку не знакомому с С++ не понять, что это всего лишь вывод (на экран, файл или куда угодно). Выбивается эта конструкция из ряда логичных. И подобного хватает.

Для незнающего ЯП человека программа на форте — это вообще непонятное что.

Цитата AndNot @ 07.10.06, 13:55

Идеология С++ - как ни крути а сводится к удобной работе с указателями

Цитата AndNot @ 07.10.06, 13:55

А подавляющее количество программеров начав изучение С++ привыкают писать на авось. Мол нахрена мне проверять длину буфера перед передачей scanf, авось никто его не переполнит.

Цитата AndNot @ 07.10.06, 15:43

А ты хочешь сказать что в С++ нет указателей???? Да вся работа с объектами ведется через указатели. И явно и косвенно.

А ты не путаешь C и C++? Какие еще scanf? Под C++ он особо-то и не нужен. А при чем указатели? Объекты — отдельно, указатели — отдельно. На C++ можно писать очень сложные программы, вообще явно не затрагивая указатели.

Цитата AndNot @ 07.10.06, 15:43

Цитата Hryak @ 07.10.06, 15:37

сплошные указатели?

А ты хочешь сказать что в С++ нет указателей???? Да вся работа с объектами ведется через указатели. И явно и косвенно.

Конечно, я не хочу этого сказать.
Они есть, но это не значит, что всё основывается на них (по-крайней мере, в конечном коде).

#include <iostream>
#include <string>
using namespace std;
int main()
{
  string s;
  cout << "Input text: ";
  getline(cin, s);
  cout << "You typed: " << s << "\n";
}

1. Где тут указатели?
2. Как пользователь проги, сделай-ка тут buffer overrun.

-Added 07.10.06, 16:02

Цитата mo3r @ 07.10.06, 16:00

Какие еще scanf?

Я уже задал ему этот вопрос.

Я тут наткнулся на старинную книжечку. Хочу показать несколько цитат, не для утверждения того или иного мнения. А просто что говорит человек пишущий очень малые и заумные программы.

Цитата

В свое время программы на Форте управляли подводными лодками, искавшими "Титаник", телескопами, и т. д.; экспертная система, написанная на Форте, искала неисправности в оборудовании фирмы General Electric; GraForth управлял трехмерной графикой на ПК IBM PC/XT/AT и он один из немногих языков, удостоившихся чести быть воплощенными "в металле" - созданы Форт-процессоры, воспринимающие Форт как родной машинный язык. Существуют многозадачные версии Форта.

Цитата

Самым часто упоминаемым недостатком Форта является использование в нем стека в явном виде для передачи параметров. Что очень удобно в калькуляторах МК-61 и аналогичных. Это приводит к плохой читаемости программ, так как манипуляции со стеком трудно проследить. Это, без сомнения, является для многих программистов очень сильным отпугивающим средством, им и без стека проблем хватает. Однако данный недостаток не является таким уж страшным, и при программировании на Форте стек кажется вполне удобной структурой данных. Дает преимущества при программировании рекурсивных алгоритмов. В Форте передача по стеку сделана явно, что дает неограниченные возможности оптимизации. Человек в вопросах оптимизации намного искусен, чем самые умные трансляторы.
Другой недостаток, ограничение Форта на работу в адресном пространстве 64К, что явно не согласуется с большими обьемами памяти современных ПК. Но если вам все же удастся подойти к пределу памяти 64К на Форте, то лично для вас я напишу 32 разрядную версию Форта. Мне кажется маловероятным исчерпание лимита 64К по следующим причинам:
1. Форт порождает весьма компактный шитый код, при хорошем стиле программирования, маленькая программа будет обладать очень большими возможностями.
2. Такую большую программу может написать только очень хороший программист. Быстродействие программы не снизится, если редко используемые части программы подгружать по необходимости. Форт дает много средств для быстрой работы с дисками. Кроме того в памяти, в разных сегментах, могут работать несколько программ, написанных на Форте, взоимодействующих с помощью прерываний или других средств межсегментного обмена.
3. Полное отсутствие стандартных средств для работы с вещественной арифметикой. Это непривычно для простого смертного и ставит его в тупик.

Цитата

Приемущества форта: Форт очень легко расширяемый язык. Все новые средства определенные программистом, вводятся в словарь форта и используются на ровне с остальными стандартными средствами. Форт не знает, что в нем относится к стандарту, а что к расширению. Можно написать свои версии стандартных слов., например оператора IF или KEY. И Форт автоматически начнет использовать новую версию, а не свою. Или пока не будет дано разрешение использовать старую версию. Возможности полиморфизма, одним словом. В то время как программы на Си или Паскале практически инертны. Ну максимум можно породить новый объект со старыми методами. Или считать из файла ресурсов новый метод.
В Турбо Паскале новый объект порождается только функцией New, и ничем больше, - в Форте отсутствуют какие либо ограничения: программа может писать "сама себя". Считывать с любого входного потока данные и команды, причем эти данные могут сразу выполнятся. Так и компилироваться для использования сразу же (прямо при загрузке). Программа может удолять часть своего кода и заменять его новым, причем он может поступать откуда угодно, в любом виде.
И для реализации каждой возможности, в стандартном формате объемом 6К, существует масса средств.
В Форте, строго говоря, данных как таковых вообще нет (в обычном понимании): даже константы и переменные, определяемые в Форте словами CONSTANT и VARIABLE, не пассивны, а выполняют некоторые действия. Конструкция CREATE … DOES> , определяющая данные и одновременно действия к ним, используется в Форте испокон веков, а сейчас нам пытаются преподнести это как нечто новое и нарекли умным словом “инкапсуляция”. Инкапсуляция, полиморфизм и наследование считаются сейчас наимоднейшей сейчас технологией программирования, называемой ООП. Думали ли создатели Форта, что эти идеи пролежат на полке невостребованными, как минимум 12-15 лет!
Самый простой пример: можете ли вы на C++ или Паскале изменить семантику константы в период выполнения? – например, заставить эту константу (которая стоит у вас в какой то формуле) выдавать число 6 вместо 5, или читать эту константу с диска (прямо во время вычисления формулы заставить константу читать саму себя с диска!), или, что совсем покажется невероятным, выполнить какое-либо совсем постороннее действие и при этом исправно давая той формуле то, что требуется ей для вычислений – какое-то число. Вы не сделаете этого на традиционных языках, а на форте это займет одну строчку. Дело в том что полиморфизм в Форте распространяется как на данные так и на процедуры в равной степени. Если во всех языках ООП полиморфизм задается жестко на этапе компиляции и зависит от наличия слова virtual в описании процедуры, то в Форте эту ситуацию можно менять в любой момент. Это дает широкие возможности, что осмыслить традиционному программисту сразу невозможно.
Наследование прекрасно реализуется на Форте в виде так называемых “контекстных словарей”. Можете считать словарь объектом, каждый новый словарь, определенный внутри него самого словом VOCABULARY, будет его потомком и будет наследовать его методы (в Форте как помните нет обычных данных). Более того, для каждого метода, используемого внутри нового объекта, вы можете указать объекта-хозяина, указав его имя (из контекстного словаря). Объект потомок видит все методы и данные в ветви каждого из своих предков, вплоть до корневого объекта с именем FORTH, и может их использовать. Причем в одном и том же словаре (объекте) могут быть слова (методы), перекрывающие сами себя. Описание полиморфизма Форта уже было дано.

И многое другое…
Источник, - энциклопедия компьютерных вирусов 2001 год.
Извините, некоторые цитаты писал сокращенно.

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

Цитата S6T6N6 @ 07.10.06, 19:21

что нельзя написать на ассемблере то вообще нельзя написать

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

Цитата mo3r @ 07.10.06, 19:22

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

а я разве не про это говорил ?

Цитата mo3r @ 07.10.06, 16:00

А ты не путаешь C и C++? Какие еще scanf?

Не знаю как это в нынешнем С++ обзывается, но под сайсом частенько встречал нечто весьма похожее на Сишный scanf. Опять же под дебагом хорошо просматриваются strcat, strcpy и тд. А в них в принципе никакую проверку не воткнешь.

Цитата mo3r @ 07.10.06, 16:00

Для незнающего ЯП человека программа на форте — это вообще непонятное что.

В этом плане паскаль всем фору даст.

Цитата mo3r @ 07.10.06, 16:00

А при чем указатели? Объекты — отдельно, указатели — отдельно

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

Цитата Hryak @ 07.10.06, 16:01

1. Где тут указатели?

Под отладчиком взгляни.

Цитата Hryak @ 07.10.06, 16:01

#include <iostream>
#include <string>
using namespace std;
int main()
{
  string s;
  cout << "Input text: ";
  getline(cin, s);
  cout << "You typed: " << s << "\n";
}

1. Где тут указатели?
2. Как пользователь проги, сделай-ка тут buffer overrun.

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

var s: String;
begin
  writeln("Input text: ");
  readln(s);
  writeln("You typed: ",s);
end.

Цитата S6T6N6 @ 07.10.06, 19:21

Что невозможно написать на СИ то можно написать на фортране

Потому он еще и жив

Цитата S6T6N6 @ 07.10.06, 19:21

что нельзя написать на ассемблере то вообще нельзя написать

На самом деле на асме можно все, если запастись десятком жизней Не знаешь где дают?

Цитата S6T6N6 @ 07.10.06, 19:21

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

Собственно я уже и высказал мнение, что должна быть "3. Расширяемость синтаксиса. Должна быть возможность создавать свой, для каждой конкретной задачи"
Вместо того чтоб языками чесать, лучше бы свои предложения внесли. Хотя не спорю, именно в спорах о достоинствах (и недостатках) языков и рождаются хорошие идейки.

Цитата S6T6N6 @ 07.10.06, 20:03

а я разве не про это говорил ?

Нет. Некоторые вещи написать можно, но не ассемблере. Например, только в машинных кодах.

Цитата AndNot @ 07.10.06, 21:33

Не знаю как это в нынешнем С++ обзывается, но под сайсом частенько встречал нечто весьма похожее на Сишный scanf. Опять же под дебагом хорошо просматриваются strcat, strcpy и тд. А в них в принципе никакую проверку не воткнешь.

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

std::string s1="ABC";
std::string s2="DEF";
std::string s3=s1+s2;
std::cout << s3 << std::endl;

? Многие компиляторы очень хорошо оптимизируют код (но при этом не нарушая корректности кода, т.е., например, stringstream или string никогда не дадут переполнение буфера (если исключить совсем уж маловероятные случаи, что компилятор и его библиотека написаны из рук вон плохо)), так что под отладчиком/дизассемблером нифига ты не увидишь.

Цитата AndNot @ 07.10.06, 21:33

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

Объекты в C++ бывают как в динамической памяти (free store) так и в автоматической (т.е., в стеке) — не надо путать с дельфой (т.е., недоязыком). И передавать их можно по значению. Структуры тоже можно передавать по значению. А еще есть ссылки (которые очень сильно отличаются от указателей). Еще раз говорю: в C++ можно спокойно обойтись без «сырых» указателей.

Добавлено 08.10.06, 03:43

Цитата AndNot @ 07.10.06, 13:55

1. Малый размер компилятора (чтоб свой проект всюду таскать с собой на дискетке).
2. Компактный синтаксис. Т.е. что бы на экране увидеть как можно больше, а не убивать жизнь, листаю сорсы вверх-вниз.
3. Расширяемость синтаксиса. Должна быть возможность создавать свой, для каждой конкретной задачи, и убирать ненужный.
4. Средства для тестирования, как на уровне модулей, так и отдельных подпрограмм (для этого лучше интерпритатора еще ничего не придумали).
5. Удобные средства обработки ошибок времени исполнения программы (которыми можно удобно управлять, изменять, добавлять, убирать).
6. Возможность использовать наработки с других языков.
7. Хорошая документация, с примерами

Рассмотрим лисп (точнее, Common Lisp):
1. 15Мб — это размер среды clisp (вместе со всеми библиотеками и полной документацией). Думаю, что интерпретатор для core language лиспа очень маленький.
2. Синтаксис — компактней некуда.
3. Макросы лиспа — мощнейшее средство расширения синтаксиса.
4. REPL
5. Система событий лиспа (LISP Conditions) позволяет организовать очень мощную обработку ошибок (и не только) (гораздо мощнее C++ исключений); для обработки ошибки не нужно раскручивать стек, как это происходит во многих языках: обработчик события вызываетс сразу же и решает, что делать: раскрутить стек, игнорировать событие, продолжить выполнение, сделать что-то еще. Например, если при чтении файла встречается запись, которая не соответствует синтаксису, но которую можно исправить обработчик соответствующего события может решить, что делать: считать это ошибочной ситуацией, игнорировать эту запись, исправить запись и прочитать ее, и т.п.
6. Это имеется.
7. Документация есть.

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

Цитата AndNot @ 07.10.06, 17:54

На самом деле на асме можно все

теоретически.

Цитата mo3r @ 08.10.06, 03:32

Нет. Некоторые вещи написать можно, но не ассемблере. Например, только в машинных кодах.

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

Сообщение отредактировано: S6T6N6 - 08.10.06, 06:17

Цитата S6T6N6 @ 08.10.06, 06:16

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

Под машинным кодом я понимаю ту последовательность битов/байтов, которую выполняет процессор/процессоры. Ассемблер — это штука повыше уровнем. AFAIU, не всякий машинный код можно представить на ассемблере.

Цитата AndNot @ 07.10.06, 21:33

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

1. есть такое понятие как статическая память
2. указатель и адрес разные вещи

Добавлено 08.10.06, 09:21

Цитата AndNot @ 07.10.06, 13:55

Идеология С++ - как ни крути а сводится к удобной работе с указателями.

и кто это тебе сказал ???

Добавлено 08.10.06, 09:24

Цитата AndNot @ 07.10.06, 13:55

А если есть указатели, то возможны очень мистические глюки.

именно для этого придумали ссылки

Добавлено 08.10.06, 09:26

Цитата S6T6N6 @ 07.10.06, 20:03

Под отладчиком взгляни.

причем тут отладчик ????????????????????????????????????????????????????????????????

Добавлено 08.10.06, 09:27

Цитата AndNot @ 07.10.06, 21:33

На самом деле на асме можно все, если запастись десятком жизней

Добавлено 08.10.06, 09:28

Цитата mo3r @ 08.10.06, 07:04

Под машинным кодом я понимаю ту последовательность битов/байтов, которую выполняет процессор/процессоры. Ассемблер — это штука повыше уровнем

поясни пож примером, а то я тоже не врубаюсь

Добавлено 08.10.06, 09:31

Цитата AndNot @ 07.10.06, 13:55

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

раньше проги были в сотни раз меньше
сравни размеры хотя бы ВИНДЫ и ДОСА

Добавлено 08.10.06, 09:33

Цитата AndNot @ 07.10.06, 13:55

1. Малый размер компилятора (чтоб свой проект всюду таскать с собой на дискетке).
2. Компактный синтаксис. Т.е. что бы на экране увидеть как можно больше, а не убивать жизнь, листаю сорсы вверх-вниз.
3. Расширяемость синтаксиса. Должна быть возможность создавать свой, для каждой конкретной задачи, и убирать ненужный.
4. Средства для тестирования, как на уровне модулей, так и отдельных подпрограмм (для этого лучше интерпритатора еще ничего не придумали).
5. Удобные средства обработки ошибок времени исполнения программы (которыми можно удобно управлять, изменять, добавлять, убирать).
6. Возможность использовать наработки с других языков.
7. Хорошая документация, с примерами

это далеко не самое главное

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

Добавлено 08.10.06, 09:35

Цитата AndNot @ 07.10.06, 13:55

Это С был понятен даже тем, кто его не знал. А вот С++ , по моему, этим уже не блещет

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

Добавлено 08.10.06, 09:37

Цитата AndNot @ 07.10.06, 13:55

А подавляющее количество программеров начав изучение С++ привыкают писать на авось. Мол нахрена мне проверять длину буфера перед передачей scanf, авось никто его не переполнит.

как раз таких СИшников расстреливают на месте, без права оправдания
на авось писать никогда нельзя, тем более на С++

Добавлено 08.10.06, 09:38
//--------------------------------------------
и можно без "нахрена" ?????

Цитата mo3r @ 08.10.06, 03:32

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

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

Цитата mo3r @ 08.10.06, 03:32

Еще раз говорю: в C++ можно спокойно обойтись без «сырых» указателей

Только почему то очень мало кто обходится. Вся беда в том, что С++ ОЧЕНЬ сложный, и не вникнув во все тонкости невозможно написать качественную программу, но ведь пишут не только профессионалы.

Цитата mo3r @ 08.10.06, 03:32

Синтаксис — компактней некуда.

Это ты про скобки то?

Цитата mo3r @ 08.10.06, 03:32

Макросы лиспа — мощнейшее средство расширения синтаксиса.

Макросы с подобными возможностями никому не помешали бы.

Цитата mo3r @ 08.10.06, 03:32

Система событий лиспа (LISP Conditions) позволяет организовать очень мощную обработку ошибок (и не только) (гораздо мощнее C++ исключений);

А что в этом плохого?

Цитата mo3r @ 08.10.06, 03:32

Что, получается, что лисп — идеальный язык??

Для своих целей - да.

Цитата mo3r @ 08.10.06, 03:32

15Мб — это размер среды clisp

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

Цитата mo3r @ 08.10.06, 03:32

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

Для этого и обсуждаем. Предложи свои.

Цитата mo3r @ 08.10.06, 07:04

Под машинным кодом я понимаю ту последовательность битов/байтов, которую выполняет процессор/процессоры.

Вообщето в асм это и есть мнемоники машинных команд. А довески типа SEGMENT MODEL и т.д. просто для удобства.

Цитата mo3r @ 08.10.06, 07:04

Ассемблер — это штука повыше уровнем. AFAIU, не всякий машинный код можно представить на ассемблере

Например? Когда конкретная реализация языка не знает какойто команды нового процессора, ее просто заменяешь последовательностью байт. Например:

db 0fh,33h   ; RDPMC

Более сложные команды оформляют в виде макроса.

  macro XMM op:req,dst:req,src:req,imm8
    local x,y
    if (SYMTYPE(dst)) and 00010000b ; регистр
    x:
        cmpxchg src,dst
    y:
        org x
        db 0Fh,op&_ld
        org y
        ifnb <imm8>
          if (SYMTYPE(imm8)) and 00000100b ; константа
            if imm8 le 255
            db imm8
            else
            err 'Константа "&imm8" вне диапозона!'
            endif
          else
            err 'Аргумент "&imm8" должен быть константой!'
          endif
        endif
    else
      ifndef op&_st
    err 'Аргумент "&dst" должен быть регистром!'
    exitm
      else
    if ((SYMTYPE(src)) and 00010000b) eq 10000b ; регистр ?
      x:                        ; да!
          cmpxchg dst,src
      y:
          org x
          db 0Fh,op&_st
          org y
    else                        ; нет!
      err 'Неправильное использование памяти'
    endif
      endif
    endif
  endm
 
  macro addps dst:req,src:req
    XMM opc_Add,dst,src
  endm
  macro mulps dst:req,src:req
    XMM opc_Mul,dst,src
  endm

Так что нет ничего невозможного.

Добавлено 08.10.06, 09:51

Цитата impik777 @ 08.10.06, 09:17

1. есть такое понятие как статическая память
2. указатель и адрес разные вещи

На машинном уровне одно и то же.

Цитата impik777 @ 08.10.06, 09:17

и кто это тебе сказал ???

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

Цитата impik777 @ 08.10.06, 09:17

раньше проги были в сотни раз меньше
сравни размеры хотя бы ВИНДЫ и ДОСА

Раньше и ресурсы были в ТЫСЯЧИ раз меньше, и ничего, выкручивались. К тому же писали далеко не только на С, частенько и на асме.

Цитата impik777 @ 08.10.06, 09:17

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

Это как раз и вытекает из синтаксиса языка.

Цитата impik777 @ 08.10.06, 09:17

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

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

Цитата impik777 @ 08.10.06, 09:17

как раз таких СИшников расстреливают на месте, без права оправдания
на авось писать никогда нельзя, тем более на С++

Однако батенька. Нельзя же так с начинающими. Другое дело в С++ процесс обучения затягивается на долго, благодаря его сложности.

Цитата AndNot @ 08.10.06, 09:44

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

Дык по стандарту так положено. Или мы уже «не читали, но осуждаем» (© LOR)?. В целом, вероятность этого гораздо меньше, чем ты можешь себе представить.

Цитата AndNot @ 08.10.06, 09:44

Только почему то очень мало кто обходится. Вся беда в том, что С++ ОЧЕНЬ сложный, и не вникнув во все тонкости невозможно написать качественную программу, но ведь пишут не только профессионалы.

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

Цитата AndNot @ 08.10.06, 09:44

Это ты про скобки то?

Про них.

Цитата AndNot @ 08.10.06, 09:44

А что в этом плохого?

Ничего. Это наоборот хорошо.

Цитата AndNot @ 08.10.06, 09:44

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

1) Дисковода у меня нет и не предполагается быть. 2) Был приведен размер ВСЕЙ среды clisp; готовые проги весят меньше.

Цитата AndNot @ 08.10.06, 09:44

Цитата (impik777 @ Сегодня, 12:17)
раньше проги были в сотни раз меньше
сравни размеры хотя бы ВИНДЫ и ДОСА

Раньше и ресурсы были в ТЫСЯЧИ раз меньше, и ничего, выкручивались. К тому же писали далеко не только на С, частенько и на асме.

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

Добавлено 08.10.06, 10:03

Цитата AndNot @ 08.10.06, 09:44

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

мы говорим о том, что видит программист, а не машина
на форте тоже все реализовано через указатели, и что, так устроена машина

Добавлено 08.10.06, 10:10

Цитата AndNot @ 08.10.06, 09:44

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

КТО ТЕБЕ СКАЗАЛ ЧТО ЭТО ИДЕОЛОГИЯ ЯЗЫКА ?????????????

Добавлено 08.10.06, 10:10
ты можешь прямо отвечать на вопросы ????????

Добавлено 08.10.06, 10:12

Цитата mo3r @ 08.10.06, 09:59

Цитата (AndNot @ Сегодня, 12:44)
Так в том и суть, у тебя нет гарантии в корректной реализации. Ну не захочет XXXX вставить проверку на переполнение, и формально к ним не придерешся, стандарт не предусматривает.

не корректные библиотеки тут же отправляются в топку и ими никто не пользуется

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

Цитата mo3r @ 08.10.06, 09:59

Дык по стандарту так положено. Или мы уже «не читали, но осуждаем» (© LOR)?. В целом, вероятность этого гораздо меньше, чем ты можешь себе представить.

Может просматривал бегло, но ничего я там не заметил.

Цитата mo3r @ 08.10.06, 09:59

Так далеок не все же пишут так, как икземплы в МСДНе написаны

Уже одно присутствие этих ексамплов говорит кое о чем. И как учиться, если не по примерам?

Цитата mo3r @ 08.10.06, 09:59

Цитата (AndNot @ Сегодня, 12:44)
А что в этом плохого?

Ничего. Это наоборот хорошо.

Так, один пункт определили. Идем дальше.

Цитата mo3r @ 08.10.06, 09:59

2) Был приведен размер ВСЕЙ среды clisp; готовые проги весят меньше.

Так разговор не про готовые проги а про инструменты для их создания. Или я чего то не допонял?

Цитата impik777 @ 08.10.06, 10:01

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

Хорошо. Возьми старенькую игрушку Чесм. Она на 70% написана на асме (30% на паскале). Возьми Кваку, написанную на С. После сравнения поймешь о чем я хотел сказать.

Цитата impik777 @ 08.10.06, 10:01

мы говорим о том, что видит программист, а не машина

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

Цитата impik777 @ 08.10.06, 10:01

ты можешь прямо отвечать на вопросы

Хорошо, вот нашел:

switch (len % 8) {
  case 0: {
    do { HAL_IO_PORT = *pSource++;
      case 7: { HAL_IO_PORT = *pSource++; }
      ...
      case 1: { HAL_IO_PORT = *pSource++; }
    } while (--n > 0);
  }
}

Что на это скажешь? Пример вполне реальный.
А вот насчет излишней сложности С++, высказывание Строуструпа:
"В начале своей деятельности я мечтал, что настанет время, когда компьютером будет также легко пользоваться как и телефоном. Мне удалось дожить до осуществления моей мечты. Теперь, прежде чем первый раз позвонить по телефону новой конструкции я должен изучить 500-страничную инструкцию"
No comments;

Цитата impik777 @ 08.10.06, 10:01

на форте тоже все реализовано через указатели, и что, так устроена машина

С чего ты взял? Как реализуешь, так и будет. Сам по себе Форт очень примитивен. Но его гланое достоинство неограниченная расширяемось. Программист может работать на своем любимом паскале, не подозревая что работает на Форте.
В общем, ИМХО идеальный язык должен быть низкоуровневым, но с возможностью легко превратить его в высокоуровневый. Причем под нужную тебе задачу.