Это кто там не знает что String без параметров в Turbo Pascal займет 256 байт, а с параметрами займет столько байт сколько установят?
Причем строка не может занимать больше 255 символов. Если не согласны так хоть поясните с чем. Конечно можно извратиться и работать с указателями, но это неудобно. 

Раньше я програмил тока на Паскале, я его неплохо знаю.

Потом я изучил си. Мне он кажется намного логичнее и проще!

В Паскале процедуры лишняя констроукция в си и без неё ниплохо.
{} - быстрей писать.
В си нинужно писать then.
В Паскале строгая типизация - это минус для меня.
В си нет тупова булевого типа!
% круче чем div, | круче чем or, ! круче not, & круче.
for в си намного ближе к низкому уровню и функциональнее
В си больше простых типов данных..
Объявлять переменные можно в любом месте, там же и инициализовывать..
В си есть модификаторы.

Единственное что в Паскале мне больше нравица это что там . заменяет . -> ::

А вопще мне асм больше всего нравица!!!



Это сообщение отредактировал(а) Den64 - 16.11.2007, 02:19

 В с++ тоже.

 В С++ есть.

Не будешь же ты писать прикладнуху на С?

В паскале нет шаблонов(может в Delphi добавили?), там возможно только процедурное программирование и объектно ориентированное(с ограничениями), на си++ можно писать к примеру в функциональном стиле (если есть желание), возможно обобщенное программирование и т.д.
Если в паскале нет к примеру сборки мусора, то с этим ничего не поделаешь, в программе на с++ можно при желании использовать сборку мусора, можно использовать подсчет ссылок на объекты, и тд, ограничений никаких нет.

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


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


Вобщем вы сказанули противоречивую сентенцию. Противоречия как и тавтологии смысла не несут

Добавлено через 1 минуту и 12 секунд
Возможности одинаковы в обоих языках. Иба оба языка эквивалентны машине тьюринга. Это исчерпывающий ответ на ваш вопрос.

Добавлено через 6 минут и 14 секунд

чушь.


Колбасов после С++ вернулся к паскалю. Творожников вернулся. А вы говорите не один.

согласен

не аргумент

не аргумент

субъективно
этот критерий не может дать оюъективный ответ, какой язык лучше/хуже
в разных ситуациях по-разному

детский сад

функциональнее да
не понял только причем здесь низкий уровень

char, short, int, long, float, double
в Pascal?

согласен
только копилятор обычно все равно выделяет место под стековый фрейм для хранения всех локальных переменных (с целью оптимизации)

Но в С++ компилятор вызовет конструктор именно там, где объявлена локальная переменная, а не при входе в функцию. Благодаря этому в программах на с++ можно использовать идиому raii.

Однобайтовые
char, 
byte, 
Shortint
Boolean  

Двубайтовые
word, 
SmallInt
Integer (зависит от процессора)

четырех байтовые
Longword
Longint
Pointer (Зависит от процессора)

8 ми байтовые
Int64

С плавающей точкой
Single - 4 байта
Real   - 6-8 байт
Double - 8 байт
Comp   - 8 байт (целое длинное считается сопроцессором )
Currency - 8 байт (4 фиксированных знака после запятой)
Extended  - 10 байт

Файлы

множества
set of <> 1-32 байта

Перечисляемый тип

Строка

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



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

Из серьезных плюсов. 
Гибкая работа с указателями.
Макросы (в С это действительно нужная штука)
Гибкая работа с CRT
Прозрачный механизм работы переменными объявленные как static
Прозрачный механизм ввода/вывода в стандартные потоки

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

Приемущества паскаля
  В pascal е этому противопоставляется ясная и последовательная схема приоритета видимости переменных при возникновении конфликтов имен и доступа к переменным с меньшим приоритетом. 
  Строковые операторы работающие над типами строк (строка ведь встроенный тип как Integer).
  В конце, концов объекты. Стандарт Pascal был в последних версиях определен как Pascal with Objects. (не путать с Object Pascal). Простейшие объекты были уже тогда. Пусть у них не было механизма виртуальных методов, но уже были секции public/Private т.е. инкапсуляция + механизм наследования. Некоторые успели поработать даже с объектной Turbo Vision. 

  

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

если уж говорить об удобстве, то объективно, принцип определения переменных в любом месте кода, удобнее
кроме того, в С никто не запрещает определять переменные до начала, собственно, кода
в Pascal - жесткое ограничение
так что по всем параметрам, Pascal тут в минусе

Добавлено через 10 минут и 28 секунд

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

Это сообщение отредактировал(а) MAKCim - 16.11.2007, 12:45

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

в смысле весь код? 
компилятор проходит по каждой единице трансляции отдельно.

чем усложняет?

Это сообщение отредактировал(а) zkv - 16.11.2007, 13:11

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



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


После небольшой практики хочеться добавить регистрозависимость имен в плюс. Но не потому что возможно объявления типа
HWND hwnd; 
Я считаю создание переменных отличающихся регистром неправильным. Важно, то что это заставляет строже относиться к именам и не писать их как угодно. Например в паскале можно написать Hwnd1 или hWnd1, а это путает.

Добавлено через 8 минут и 25 секунд

  
у pas модулей реализация просто ниже и отделена в специальную секцию, так что это совсем не мешает просматривать описания 



Че делает компилятор мне не интересно, это уже особенность реализации, важно что он рассматривает все модули как единое пространство.


Необходимостью каждый раз писать префикс. использование using namespace я не рассматриваю так как это сводит на нет все его приемущества в данном модуле.

а как еще рассматривать?
как тогда компоновать объектные файлы?

  Ну например, ставить в соответствие каждому заголовочному файлу свой модуль реализации. Компилировать его так, чтобы он был самодостаточным и лишь линкер подставлял адреса функций/переменных из внешних модулей. А то ведь описать класс можно в одном заголовочном файле, а реализовать в cpp шнике с другим именем или вообще в нескольких. Т.е. модульность лишь призрачная. Меня по началу удивляло, чего это он не хочет компилить *.h файл  , а он просто по стандарту не знает где найдет реализацию.

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

Добавлено через 1 минуту и 46 секунд

кто мешает (так же как и переменные в С) реализовать методы в нужном *.cpp файле?   

в паскале быстрее ставить точку, нежели эту несуразицу ->

Добавлено через 1 минуту и 4 секунды

бред, ибо код в паскале более читабелен!

Добавлено через 2 минуты и 1 секунду

ага, особенно для баз данных  

Добавлено через 8 минут и 35 секунд

ну вот с одной стороны с++ позволяет объявлять переменные где и как попало (ну может я утрирую), а с другой стороны обязывает нас чётко писать имена переменных!!!!!!!! это минус