На каком языке больше возможностей работы с  строчками? 

Это сообщение отредактировал(а) kurzon - 6.10.2007, 18:25

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

Больше всего на АСМе.

Голосую за русский язык.  

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

Голос прынят за С#

асм полюбэ!

не, brainfuck получше будет..

Здесь всё начиналось, а здесь бенчмарк по строкам.

Что же касается возможностей - вопрос бредовый... Единственный известный мне язык, нативно приспособленный к работе со строками, - это perl со своими pcre и т.д.
В паскале есть определённый набор возможностей работы со строками, который ты можешь расширить только своими ф-циями. В С++ делай производный класс от std::string или QString(или ещё чего-нибудь) и добавляй к уже имеющемуся набору возможностей что угодно.

В принципе не слушай ни кого! Пользуйся тем языком, который лучше знаешь. Ну а вообще посоветую лучше C++. Не потому что им чаще пользуются, а потому что там можно грамотно распряжаться памятью не резервирую место под символы, которых в строке вообще не будет, в отличии от Pascal.

Чё, правда что ль?  

  Ну если говорить о Turbo Pascale, то правда, но едва ли о нем идет речь...

    

Поддерживаю 

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

  Это кто там не знает что 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 секунд

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

А как тогда в паскале объявить переменную для блока(типа "где попало")?

  Паскаль процедурно ориентирован, значит во вложенной процедуре.

это - несомненный плюс.



бред только для малознакомого с С/C++. Иначе придется объявить бредом всю математическую нотацию, заменив словами "принадлежит", "существует" и т.д.

  Не все так красиво, в математике все однозначно, а тут нет. Тот же оператор деления. В паскале и бейсике операторы целочисленного деления и деления с плавающей точкой различаются, потому при делении 2х переменных/значений всегда тип результата очевиден, чего не скажешь про С/С++.

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

Недостатки есть в любом языке. Ну, кроме матерного  
Так что вопрос только в том, насколько перевешивают достоинства.
Лично мне в С++ больше всего нравятся три вещи:
1. Поддержка нескольких парадигм программирования. Причем хорошая поддержка, а в грядущем стандарте станет еще лучше. 
2. Возможность при необходимости сделать все что угодно (например, наличие reinterpret_cast), но поощрение делать красиво и правильно.
3. Выразительность. Возможность на языке не только писать код, но и проектировать программу - сильная вещь.

Pascal лишен некоторых недостатков С++, но не имеет упомянутых достоинств. имхо.

для детей младшего дошкольного возраста.


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

Зато "несуразица" предоставляет намного более широкий диапазон возможностей .


Субъективное мнение. Мне вот читабельней кажется плюсовый код.


Опять же на любителя. Что читабельней: findAll или findall? А ведь паскаль не запрещает написать второй вариант .

 ИМХО бессмысленно сравнивать процедурный язык, созданный для учебных целей  и промышленный ОО-язык. Стоит м.б. Delphi vs C++ тогда обсуждать.  (или Algol vs C++  )

Sartorius, я об этом уже говорил, тут даже не определено в какой из спецификаций "Pascal", "Pascal with Objects" или "Object Pascal".

не бред ибо согласно [c++2003: lex.key] и даже [c99: 7.9](но в си только при подключенном iso6446.h   ) можно писать and'ы.
ахх, ну и разумеется #define and && можно сделать и в более старых си.  Вот и будет читабельность.
а в паскале с препроцессорами вообще говоря тяжко. 

Мне вот всякие input.readable() and output.writeable() c and'ом тоже читаются легче чем с &&. 


йап-йап. в паскале нет аналогов шаблонов. только за это его дóлжно мучить пока он ими не обзаведётся{как уже было с перегрузкой операторав} или пока он не умрёт.
[Хотя если достать какой-нибудь макропроцессор{типа m4}, то в принципе можно кода нагенерировать, но это полумера]


а можно этот пункт подробнее?.

Можно. Язык программирования не может (да и не должен) быть полноценным языком проектирования, но язык может поддерживать напрямую некоторые принципы проектирования.
В отношении С++ это прежде всего поддерживаемые парадигмы. Про это я сказал в п.1, но относительно технических средств. То же верно и в отношении проектных средств: программист может обдумывать задачу с той точки зрения, которая в данный момент приемлема, используя синтаксис С++.

Вот вам простой пример разного подхода к одной задаче. Задача - вычисление определенных интегралов функций одного переменного.
Идея - имеем классы для определения подынтегральных функций и нечто собственно для вычисления интеграла.

ООП:


Обобщенное программирование:


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

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

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

И напоследок. С++ не поддерживает напрямую некоторые вещи. Но его легко научить это поддерживать. Посмотрите на boost - он почти целиком из таких расширений состоит. Особенно выразительные примеры - пример Dimension Analisys в MPL и библиотека parameters.
Т.е. для конкретной задачи мы можем создавать инструменты, используя которые приобретаем новые семантические средства, синтаксически оставаясь в языке.

Немного сумбурно получилось. Если што непонятно готов развить.   

baldina, непонятно только одно: какой из языков ты считаешь невыразительным - С++ или Паскаль? 

Я не говорил, что Pascal невыразителен (хотя чистый паскаль стоит сравнивать с С а не С++).
Я говорил за что мне нравится С++

Добавлено через 2 минуты и 12 секунд
Религиозные войны вообще дело такое... Тонкое, как и восток. Остроконечники и тупоконечники.

Спасибо, теперь понятно .
Полностью с тобой согласен - С++ очень выразительный язык.

FindAll

Может быть тебе ещё и For кажется читабельней, чем for? 0_o

Здесь говорили что система модулей в Delphi лучше чем cpp - h файлы, мне -же кажется что наоборот, в плюсах можно разделять реализацию и объявления.
Это может быть очень удобно, если умеешь пользоваться, можно спрятать реализацию класса, спрятать его члены, оставить только объявление базового класса и фабрику для создания производных классов. В паскале-же "все кишки наружу".

Нет, в паскале, в случае предоставления только dcu(если мы говорим про турбо паскаль, то это вообще tpu ) то реализации как-бы никто не увидит. Но система модулей там действительно гнилая. Нет возможности разделить реализацию одного класса на несколько исходных файлов. А если ещё и учесть, что, чтобы иметь доступ к private членам нужно находиться именно в том же файле, что и другой класс, то получается вообще очень длинная простыня.

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

К вопросу темы (про строчки).
Огромный плюс С и С++ - отсутствие стандартных операторов ввода-вывода, и реализация посредством стандартной библиотеки.
То же относится и к строкам. Родные строки в паскале конечно удобней С-строк. Но если расширять их функционал - в силу более простой семантики (массив символов - более общее понятие, чем "строка") различные преобразования в С++ проще и эффективнее.

  Знаем мы все эти расширения, тормозят они нипадецки. Встроенные вещи, на то они и встроенные, что оптимизированы и работают быстро, так что со строками в стиле C ничего не сравниться. Вся эта хваленная универсальность постоянно выходит боком сильными тормозами. Потому что универсальность делается в ущерб эффективности. Железки мощные нехай работают, а как выходишь на максимальную загрузку так сразу все видно.

std::string - тормоз? Хотел поспорить на пиво, передумал. Достаточно погуглить, что бы нарыть тестов тех самых расширений.

Гм. Гм. Ну чёрт с ними с «расширениями», но как можно назвать быстрым представление строк, в котором для определения длины строки требуется O(N) времени.

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

Так в std::string длина и сохранена. Точно так же, как в ваших ansi/widestring .

"расширение" std::string имеет метод size(), имеющий временную сложность О(1).
Под быстротой С-строк, понятно, понимается эффективность доступа к отдельному символу, при этом не т ребуется каких-либо преобразований. Скорость работы строк паскаль и std::string (а также С-строк, если их грамотно использовать) полагаю одинакова. А вот скорость работы специальных классов, обрабатывающих строки, в момент преобразования в стандартную строку, может быть разная. Для std::string, например, это происходит без каких-либо накладных расходов.

Добавлено через 5 минут и 3 секунды
Конкретно касаемо расширений для строк Pascal vc C++. Т.к. в паскале длина строки всегда хранится вместе со строкой, любые манипуляции, меняющие длину строки обязательно приводят к операциям, корректирующим значение длины. Нетрудно придумать практические примеры и написать для них класс С++ (или использовать строки С), где вычисление длины строки и её изменение будет происходить реже. Для миллиона таких операций разница в скорости будет видна на глаз.

  В делфях точно (не знаю как во всех паскалях), есть полная поддержка сишных строк. Во FreePascal думаю тож есть. Т.е. объявление, выделение, адресация инкремент указателей, даж некоторые стандартные функции. Это довольно удобно при работе с WinApi или если скажем урезать модуль System для получения ультрамаленьких приложений. 

Почему всегда когда речь заходит преимуществах Pascal - Delphi, то приводят в пример именно строки. Неужели больше нечего? std::string может в отличии от AnsiString использовать механизм copy on write, если приложение часто копирует строки, то это дает заметное преимущество в скорости. Причем у меня есть выбор какой реализацией string пользоваться, ненравится cow - не используй, вместо string можно использовать vector, если хочется можно сделать свой string совместимый с stl, а у вас особого выбора нет 

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

  Понял че сказал? С каких пор копирование по значению быстрее передачи по ссылке?


  Почему нет? Если говорить о Object Pascal, то никаких проблем создавать объекты.

правильно все сказал   

Да, понял. 
Кто мешает использовать указатели и ссылки на объекты-строки. При копировании по значению(глубокое копирование) AnsiString копируется полностью, а std::string (при использовании идиомы COW), копирует только ссылку на объект. Далее при попытке изменить одну из строк происходит реальное копирование. С ссылками на строки можно работать так-же как и в паскале.

А могут ли эти объекты выглядеть как встроенные типы данных - Integer, String и пр..

  Мешает то что их удобство и состоит в том, что они создаются в стеке, а значит во выходу из функции токая строка уничтожается.


  В точности описал механизм AnsiString  , только он встроенный. 


  Выглядеть понятие весьма растяжимое и специфичное. Сильно зависит от компилятора и его возможностей. 

cow к передаче параметров по ссылке/значению никакого отношения не имеет.

да че вы ссоритесь? ObjectPascal, FreePascal, Delphi... Понятно, что все востребованные языки развиваются, не только паскаль, но и С++.

Вот только... Есть стандарт С++. Мы собственно говоря про С++ остаемся в его рамках. Идите теперь почитайте про паскалевский стандарт.

А про "поддерживает то, поддерживает сё..." - если в языке есть оператор print или тип string я хочу ими пользоваться. ибо они есть стандартное свойство языка. Очень трудно понять и объяснить, что "вот этой фичей пользоваться не надо, она убогая, используйте вот это расширение языка для этой среды или вот эту библиотеку проприетарного производителя"

тоже самое можно сказать и про std::string, память под строку выделяется в куче, в стеке хранится только указатель на ее начало + специфичная для конкретной реализации информация. Даже если принять что std::string и AnsiString реализованы одинаково, то все равно, std::string - это stl контейнер, и для него есть туева хуча стандартных алгоритмов. Так-что можно сказать что он более функциональный.

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

  Это старый стандарт.

std::string более стандартный чем все паскали вместе взятые.

+1

Добавлено через 3 минуты и 27 секунд
кстати название темы: Pascal sv C++, что бы это могло значить ??

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

Блин, что за марафон с аватарками? Я теперь всех путаю .

верно, есть стандарт 1999 года, но что-то не очень его раздают, видимо секретный.   
в открытом доступе удалось онаружить только Draft 1993, есть там что-то про объекты даже

Добавлено через 3 минуты и 31 секунду
но кстати на http://www.iso.org/ из опубликованных значится только ISO 7185:1990 Information technology -- Programming languages -- Pascal 

у тебя они включены?


есть даже ревизия 2003го. Все официально продаются комитетом за небольшую плату. А драфт можно без проблем найти и по-современней, было бы желание...

ладно, стандарт есть. я рад за паскаль, правда. даже был удивлен сходу не обнаружив концов.
ну так в последнем стандарте read, write, string исключили? вряд ли. значит все рассуждения остаются в силе.

а ты присоединяйся