| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > Pascal sv C++ |
| Автор: kurzon 6.10.2007, 18:18 |
| На каком языке больше возможностей работы с строчками? |
| Автор: Daevaorn 6.10.2007, 19:34 |
| шаблонный характер std::string дает очень большой простор для различных маневров, чего нет у опонента |
| Автор: Alexeis 6.10.2007, 20:05 |
| Больше всего на АСМе. |
| Автор: Esperito 6.10.2007, 22:15 |
| Голосую за русский язык. |
| Автор: Sanchezzz 6.10.2007, 22:29 |
ЗА русский это да  . но если по теме то в обоих не мало того что есть так что сравнивать бессмысленно ставлю на с++ так что им больше пользуются |
| Автор: kurzon 6.10.2007, 22:32 | ||
Голос прынят за С# |
| Автор: Djinn 7.10.2007, 12:06 |
| асм полюбэ! |
| Автор: nerezus 7.10.2007, 14:57 |
| не, brainfuck получше будет.. |
| Автор: archimed7592 7.10.2007, 18:17 |
| http://forum.sources.ru/index.php?showtopic=179471&view=showall всё начиналось, а http://forum.sources.ru/index.php?showtopic=181364&view=showall бенчмарк по строкам. Что же касается возможностей - вопрос бредовый... Единственный известный мне язык, нативно приспособленный к работе со строками, - это perl со своими pcre и т.д. В паскале есть определённый набор возможностей работы со строками, который ты можешь расширить только своими ф-циями. В С++ делай производный класс от std::string или QString(или ещё чего-нибудь) и добавляй к уже имеющемуся набору возможностей что угодно. |
| Автор: NEW_M_A_N 7.10.2007, 20:56 |
| В принципе не слушай ни кого! Пользуйся тем языком, который лучше знаешь. Ну а вообще посоветую лучше C++. Не потому что им чаще пользуются, а потому что там можно грамотно распряжаться памятью не резервирую место под символы, которых в строке вообще не будет, в отличии от Pascal. |
| Автор: archimed7592 7.10.2007, 21:16 | ||
Чё, правда что ль?  |
| Автор: Alexeis 7.10.2007, 21:51 |
| Ну если говорить о Turbo Pascale, то правда, но едва ли о нем идет речь... |
| Автор: doomik 8.10.2007, 23:06 | ||||
 |
| Автор: GrayCardinal 14.10.2007, 12:39 | ||
Поддерживаю |
| Автор: MrCherry 15.10.2007, 09:41 |
| чем больше в универе долбят поганый паскаль - тем больше я его ненавижу. ни один человек, который разбирается в с++ никогда не вернётся к паскалю. |
| Автор: Alexeis 15.10.2007, 10:00 |
| Это кто там не знает что String без параметров в Turbo Pascal займет 256 байт, а с параметрами займет столько байт сколько установят? Причем строка не может занимать больше 255 символов. Если не согласны так хоть поясните с чем. Конечно можно извратиться и работать с указателями, но это неудобно. |
| Автор: Den64 16.11.2007, 02:16 | ||
Раньше я програмил тока на Паскале, я его неплохо знаю. Потом я изучил си. Мне он кажется намного логичнее и проще! В Паскале процедуры лишняя констроукция в си и без неё ниплохо. {} - быстрей писать. В си нинужно писать then. В Паскале строгая типизация - это минус для меня. В си нет тупова булевого типа! % круче чем div, | круче чем or, ! круче not, & круче. for в си намного ближе к низкому уровню и функциональнее В си больше простых типов данных.. Объявлять переменные можно в любом месте, там же и инициализовывать.. В си есть модификаторы. Единственное что в Паскале мне больше нравица это что там . заменяет . -> :: А вопще мне асм больше всего нравица!!! |
| Автор: nerezus 16.11.2007, 06:55 | ||||
Не будешь же ты писать прикладнуху на С? |
| Автор: Lazin 16.11.2007, 08:24 |
| В паскале нет шаблонов(может в Delphi добавили?), там возможно только процедурное программирование и объектно ориентированное(с ограничениями), на си++ можно писать к примеру в функциональном стиле (если есть желание), возможно обобщенное программирование и т.д. Если в паскале нет к примеру сборки мусора, то с этим ничего не поделаешь, в программе на с++ можно при желании использовать сборку мусора, можно использовать подсчет ссылок на объекты, и тд, ограничений никаких нет. |
| Автор: esperant0 16.11.2007, 08:34 | ||||
Прикольно, вы в начале призываете никого не слушать, а потом даете совет. Так вас ведь то же не надо слушать. Согласно вашему совету. А значит не надо слушать что не надо никого не слушать, А значит всех надо слушать. Тогда придется и вас послушать. А вы говорите никого не слушать. Вобщем вы сказанули противоречивую сентенцию. Противоречия как и тавтологии смысла не несут Добавлено через 1 минуту и 12 секунд Возможности одинаковы в обоих языках. Иба оба языка эквивалентны машине тьюринга. Это исчерпывающий ответ на ваш вопрос. Добавлено через 6 минут и 14 секунд
чушь. Колбасов после С++ вернулся к паскалю. Творожников вернулся. А вы говорите не один. |
| Автор: MAKCim 16.11.2007, 09:55 | ||||||||||||||||
согласен
не аргумент
не аргумент
субъективно этот критерий не может дать оюъективный ответ, какой язык лучше/хуже в разных ситуациях по-разному
детский сад
функциональнее да не понял только причем здесь низкий уровень
char, short, int, long, float, double в Pascal?
согласен только копилятор обычно все равно выделяет место под стековый фрейм для хранения всех локальных переменных (с целью оптимизации) |
| Автор: Lazin 16.11.2007, 10:18 | ||
Но в С++ компилятор вызовет конструктор именно там, где объявлена локальная переменная, а не при входе в функцию. Благодаря этому в программах на с++ можно использовать идиому raii. |
| Автор: Alexeis 16.11.2007, 10:50 | ||||
Однобайтовые 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. |
| Автор: MAKCim 16.11.2007, 12:45 | ||||||
пожалуйста, пусть вызывает  одно другому не мешает, да я и не говорил про конструкторы
если уж говорить об удобстве, то объективно, принцип определения переменных в любом месте кода, удобнее кроме того, в С никто не запрещает определять переменные до начала, собственно, кода в Pascal - жесткое ограничение так что по всем параметрам, Pascal тут в минусе Добавлено через 10 минут и 28 секунд
если говорить об ELF - формате, то там для каждого исполняемого файла или разделяемой библиотеки существует лишь один програмный сегмент кода, который отображается компоновщиком (ядра или пользовательского уровня) на адресное пространство процесса секций может быть много, но все они расположены в пределах одного програмного сегмента последовательно друг за другом (возможно, с выравниванием) я не вижу смысла во множестве програмных сегментов кода зачем для кода каждого из модулей создавать отдельный сегмент? какие проблемы это может решить? |
| Автор: zkv 16.11.2007, 13:10 | ||||||
по мне так гораздо удобней (хедеры отдельно) в большинстве случаев мне нафиг не надо заглядывать в реализацию
в смысле весь код? компилятор проходит по каждой единице трансляции отдельно.
чем усложняет? |
| Автор: Alexeis 16.11.2007, 13:44 | ||||||||||
Это уже детали реализации языка конкретным компилятором, к самому языку это не относиться. Я подразумевал именно логическое структурирование модулей. Расположение модулей в экзешнике не регламентируется стандартом.
Согласен, но отчасти. Сама возможность механизма приводит к необходимости проверки, но это не такой уж принципиальный вопрос. После небольшой практики хочеться добавить регистрозависимость имен в плюс. Но не потому что возможно объявления типа HWND hwnd; Я считаю создание переменных отличающихся регистром неправильным. Важно, то что это заставляет строже относиться к именам и не писать их как угодно. Например в паскале можно написать Hwnd1 или hWnd1, а это путает. Добавлено через 8 минут и 25 секунд
у pas модулей реализация просто ниже и отделена в специальную секцию, так что это совсем не мешает просматривать описания
Че делает компилятор мне не интересно, это уже особенность реализации, важно что он рассматривает все модули как единое пространство.
Необходимостью каждый раз писать префикс. использование using namespace я не рассматриваю так как это сводит на нет все его приемущества в данном модуле. |
| Автор: MAKCim 16.11.2007, 22:28 | ||
а как еще рассматривать? как тогда компоновать объектные файлы? |
| Автор: Alexeis 16.11.2007, 22:43 | ||
Ну например, ставить в соответствие каждому заголовочному файлу свой модуль реализации. Компилировать его так, чтобы он был самодостаточным и лишь линкер подставлял адреса функций/переменных из внешних модулей. А то ведь описать класс можно в одном заголовочном файле, а реализовать в cpp шнике с другим именем или вообще в нескольких. Т.е. модульность лишь призрачная. Меня по началу удивляло, чего это он не хочет компилить *.h файл , а он просто по стандарту не знает где найдет реализацию. |
| Автор: MAKCim 16.11.2007, 22:53 | ||||
объектный файл самодостаточен каждый объектный файл имеет таблицу релокаций, т. е таблицу, которая описывает сущности, значения которых до момента компоновки не известны компоновщик рассматривает объектные файлы как самодостаточные сущности, которые могут быть связаны только посредством релокаций т. е как раз получается описанная тобой схема Добавлено через 1 минуту и 46 секунд
кто мешает (так же как и переменные в С) реализовать методы в нужном *.cpp файле? |
| Автор: Akella 14.12.2007, 01:21 | ||||||||
в паскале быстрее ставить точку, нежели эту несуразицу -> Добавлено через 1 минуту и 4 секунды
бред, ибо код в паскале более читабелен! Добавлено через 2 минуты и 1 секунду
ага, особенно для баз данных Добавлено через 8 минут и 35 секунд
ну вот с одной стороны с++ позволяет объявлять переменные где и как попало (ну может я утрирую), а с другой стороны обязывает нас чётко писать имена переменных!!!!!!!! это минус |
| Автор: nerezus 14.12.2007, 08:34 | ||
А как тогда в паскале объявить переменную для блока(типа "где попало")? |
| Автор: Alexeis 14.12.2007, 08:59 | ||
Паскаль процедурно ориентирован, значит во вложенной процедуре. |
| Автор: baldina 14.12.2007, 10:40 | ||||
это - несомненный плюс.
бред только для малознакомого с С/C++. Иначе придется объявить бредом всю математическую нотацию, заменив словами "принадлежит", "существует" и т.д. |
| Автор: Alexeis 14.12.2007, 11:10 | ||
Не все так красиво, в математике все однозначно, а тут нет. Тот же оператор деления. В паскале и бейсике операторы целочисленного деления и деления с плавающей точкой различаются, потому при делении 2х переменных/значений всегда тип результата очевиден, чего не скажешь про С/С++. А вот на счет логических операторов соглашусь, побитовый and и and сравнения это разные операторы и тип результата разный, потому называться должны по разному. |
| Автор: baldina 14.12.2007, 11:24 |
| Недостатки есть в любом языке. Ну, кроме матерного Так что вопрос только в том, насколько перевешивают достоинства. Лично мне в С++ больше всего нравятся три вещи: 1. Поддержка нескольких парадигм программирования. Причем хорошая поддержка, а в грядущем стандарте станет еще лучше. 2. Возможность при необходимости сделать все что угодно (например, наличие reinterpret_cast), но поощрение делать красиво и правильно. 3. Выразительность. Возможность на языке не только писать код, но и проектировать программу - сильная вещь. Pascal лишен некоторых недостатков С++, но не имеет упомянутых достоинств. имхо. |
| Автор: Daevaorn 14.12.2007, 12:53 | ||||
для детей младшего дошкольного возраста.
Не где попало, а там где потребовалось. А от нечувствительности к регистру вся соль, от объявления переменных в одном месте, теряется. |
| Автор: archimed7592 14.12.2007, 18:33 | ||||||
Зато "несуразица" предоставляет намного более широкий диапазон возможностей .
Субъективное мнение. Мне вот читабельней кажется плюсовый код.
Опять же на любителя. Что читабельней: findAll или findall? А ведь паскаль не запрещает написать второй вариант . |
| Автор: Sartorius 14.12.2007, 18:48 |
| ИМХО бессмысленно сравнивать процедурный язык, созданный для учебных целей и промышленный ОО-язык. Стоит м.б. Delphi vs C++ тогда обсуждать. (или Algol vs C++ ) |
| Автор: Alexeis 14.12.2007, 19:03 |
| Sartorius, я об этом уже говорил, тут даже не определено в какой из спецификаций "Pascal", "Pascal with Objects" или "Object Pascal". |
| Автор: Mayk 16.12.2007, 15:00 | ||||||
не бред ибо согласно [c++2003: lex.key] и даже [c99: 7.9](но в си только при подключенном iso6446.h  ) можно писать and'ы.ахх, ну и разумеется #define and && можно сделать и в более старых си. Вот и будет читабельность. а в паскале с препроцессорами вообще говоря тяжко. Мне вот всякие input.readable() and output.writeable() c and'ом тоже читаются легче чем с &&.
йап-йап. в паскале нет аналогов шаблонов. только за это его дóлжно мучить пока он ими не обзаведётся{как уже было с перегрузкой операторав} или пока он не умрёт. [Хотя если достать какой-нибудь макропроцессор{типа http://www.gnu.org/software/m4/}, то в принципе можно кода нагенерировать, но это полумера]
а можно этот пункт подробнее?. |
| Автор: baldina 16.12.2007, 18:16 | ||||||||
Можно. Язык программирования не может (да и не должен) быть полноценным языком проектирования, но язык может поддерживать напрямую некоторые принципы проектирования. В отношении С++ это прежде всего поддерживаемые парадигмы. Про это я сказал в п.1, но относительно технических средств. То же верно и в отношении проектных средств: программист может обдумывать задачу с той точки зрения, которая в данный момент приемлема, используя синтаксис С++. Вот вам простой пример разного подхода к одной задаче. Задача - вычисление определенных интегралов функций одного переменного. Идея - имеем классы для определения подынтегральных функций и нечто собственно для вычисления интеграла. ООП:
Обобщенное программирование:
Я пока это писал видел только общий план. В принципе написанное будет работать (совсем немного доопределить, что б компилилось и линковалось). В подробности шаблонов ООП и Templates я не вникаю, я их просто использую, думая о задаче. Здесь много нерешенных проблем, например погрешность вычисления, эффективность и т.д. И я могу спокойно их обдумывать, выражая мысли на бумаге, которые уже являются правильным кодом, его мне не придется переписывать. Только изменять и дополнять. При этом код получается самодокументируемым. Вам ведь понятно что там к чему? И это достигнуто малыми средствами. Самим языком, а не комментариями и выкрутасами с макросами. Чисто технически - мне импонирует возможность написать интерфейс класса, не реализуя его, и опробовать его в программе. Она, конечно, не будет линковаться, но будет компилироваться. Т.е. я могу попробовать на зуб свой интерфейс еще до реализации. И изменять его не вдаваясь в подробности реализации. Я не утверждаю, что в других языках так нельзя. Но так выразительно, и что бы еще потом получилось эффективно - мало где. И напоследок. С++ не поддерживает напрямую некоторые вещи. Но его легко научить это поддерживать. Посмотрите на boost - он почти целиком из таких расширений состоит. Особенно выразительные примеры - пример Dimension Analisys в MPL и библиотека parameters. Т.е. для конкретной задачи мы можем создавать инструменты, используя которые приобретаем новые семантические средства, синтаксически оставаясь в языке. Немного сумбурно получилось. Если што непонятно готов развить. |
| Автор: archimed7592 16.12.2007, 18:25 |
| baldina, непонятно только одно: какой из языков ты считаешь невыразительным - С++ или Паскаль? |
| Автор: baldina 16.12.2007, 18:37 | ||
| Я не говорил, что Pascal невыразителен (хотя чистый паскаль стоит сравнивать с С а не С++). Я говорил за что мне нравится С++ Добавлено через 2 минуты и 12 секунд Религиозные войны вообще дело такое... Тонкое, как и восток. Остроконечники и тупоконечники.
|
| Автор: archimed7592 16.12.2007, 18:40 |
| Спасибо, теперь понятно . Полностью с тобой согласен - С++ очень выразительный язык. |
| Автор: Akella 17.12.2007, 04:34 | ||
FindAll |
| Автор: archimed7592 17.12.2007, 09:27 | ||
Может быть тебе ещё и For кажется читабельней, чем for? 0_o |
| Автор: Lazin 17.12.2007, 09:46 |
| Здесь говорили что система модулей в Delphi лучше чем cpp - h файлы, мне -же кажется что наоборот, в плюсах можно разделять реализацию и объявления. Это может быть очень удобно, если умеешь пользоваться, можно спрятать реализацию класса, спрятать его члены, оставить только объявление базового класса и фабрику для создания производных классов. В паскале-же "все кишки наружу". |
| Автор: archimed7592 17.12.2007, 09:50 |
| Нет, в паскале, в случае предоставления только dcu(если мы говорим про турбо паскаль, то это вообще tpu ) то реализации как-бы никто не увидит. Но система модулей там действительно гнилая. Нет возможности разделить реализацию одного класса на несколько исходных файлов. А если ещё и учесть, что, чтобы иметь доступ к private членам нужно находиться именно в том же файле, что и другой класс, то получается вообще очень длинная простыня. |
| Автор: Lazin 17.12.2007, 11:00 |
| Возник тут у меня вопрос, можно-ли на паскале реализовать смарт поинтер, или к примеру запретить создавать объекты в стеке, или наоборот в куче? Есть ли там возможность реализовать собственную стратегию управления памятью (на плюсах я могу переопределить new delete). Возможно, что это слишком субъективно, но все программы на паскале которые я видел, были какими то неказистыми и невыразительными, несмотря на синтаксис самого языка. Возможно это мне так кажется, так как на той же площади монитора помещается меньше строк кода на паскале, а это хуже для читаемости чем даже птичий язык С++? имхо паскаль имеет самый раздутый синтаксис... |
| Автор: baldina 17.12.2007, 11:07 |
| К вопросу темы (про строчки). Огромный плюс С и С++ - отсутствие стандартных операторов ввода-вывода, и реализация посредством стандартной библиотеки. То же относится и к строкам. Родные строки в паскале конечно удобней С-строк. Но если расширять их функционал - в силу более простой семантики (массив символов - более общее понятие, чем "строка") различные преобразования в С++ проще и эффективнее. |
| Автор: Alexeis 17.12.2007, 12:59 | ||
Знаем мы все эти расширения, тормозят они нипадецки. Встроенные вещи, на то они и встроенные, что оптимизированы и работают быстро, так что со строками в стиле C ничего не сравниться. Вся эта хваленная универсальность постоянно выходит боком сильными тормозами. Потому что универсальность делается в ущерб эффективности. Железки мощные нехай работают, а как выходишь на максимальную загрузку так сразу все видно. |
| Автор: baldina 17.12.2007, 13:24 | ||
std::string - тормоз? Хотел поспорить на пиво, передумал. Достаточно погуглить, что бы нарыть тестов тех самых расширений. |
| Автор: Void 17.12.2007, 13:39 | ||
Гм. Гм. Ну чёрт с ними с «расширениями», но как можно назвать быстрым представление строк, в котором для определения длины строки требуется O(N) времени. |
| Автор: Alexeis 17.12.2007, 14:07 | ||
Так в критических местах ее можно сохранить в локальной переменной, чтобы постоянно не вычислять, а если посмотреть на набор функций, то они ориентированы на выполнение всех операций без вычисления длинны. Т.е. делаем операцию пока не встретим нуль или отседова n символов. Зачастую можно обойтись без операции вычисления длинны или вызов производить пренебрежительно редко. |
| Автор: archimed7592 17.12.2007, 14:19 | ||
Так в std::string длина и сохранена. Точно так же, как в ваших ansi/widestring . |
| Автор: baldina 17.12.2007, 14:21 |
| "расширение" std::string имеет метод size(), имеющий временную сложность О(1). Под быстротой С-строк, понятно, понимается эффективность доступа к отдельному символу, при этом не т ребуется каких-либо преобразований. Скорость работы строк паскаль и std::string (а также С-строк, если их грамотно использовать) полагаю одинакова. А вот скорость работы специальных классов, обрабатывающих строки, в момент преобразования в стандартную строку, может быть разная. Для std::string, например, это происходит без каких-либо накладных расходов. Добавлено через 5 минут и 3 секунды Конкретно касаемо расширений для строк Pascal vc C++. Т.к. в паскале длина строки всегда хранится вместе со строкой, любые манипуляции, меняющие длину строки обязательно приводят к операциям, корректирующим значение длины. Нетрудно придумать практические примеры и написать для них класс С++ (или использовать строки С), где вычисление длины строки и её изменение будет происходить реже. Для миллиона таких операций разница в скорости будет видна на глаз. |
| Автор: Alexeis 17.12.2007, 15:22 | ||
В делфях точно (не знаю как во всех паскалях), есть полная поддержка сишных строк. Во FreePascal думаю тож есть. Т.е. объявление, выделение, адресация инкремент указателей, даж некоторые стандартные функции. Это довольно удобно при работе с WinApi или если скажем урезать модуль System для получения ультрамаленьких приложений. |
| Автор: Lazin 17.12.2007, 15:49 |
Почему всегда когда речь заходит преимуществах Pascal - Delphi, то приводят в пример именно строки. Неужели больше нечего? std::string может в отличии от AnsiString использовать механизм copy on write, если приложение часто копирует строки, то это дает заметное преимущество в скорости. Причем у меня есть выбор какой реализацией string пользоваться, ненравится cow - не используй, вместо string можно использовать vector, если хочется можно сделать свой string совместимый с stl, а у вас особого выбора нет  Добавлено через 1 минуту и 22 секунды с такой аватарой меня так и тянет паскаль защищать , в конце концов это мой первый язык программирования |
| Автор: Alexeis 17.12.2007, 16:04 | ||||
Понял че сказал? С каких пор копирование по значению быстрее передачи по ссылке?
Почему нет? Если говорить о Object Pascal, то никаких проблем создавать объекты. |
| Автор: zkv 17.12.2007, 16:13 | ||
правильно все сказал |
| Автор: Lazin 17.12.2007, 16:15 | ||||
Да, понял. Кто мешает использовать указатели и ссылки на объекты-строки. При копировании по значению(глубокое копирование) AnsiString копируется полностью, а std::string (при использовании идиомы COW), копирует только ссылку на объект. Далее при попытке изменить одну из строк происходит реальное копирование. С ссылками на строки можно работать так-же как и в паскале.
А могут ли эти объекты выглядеть как встроенные типы данных - Integer, String и пр.. |
| Автор: Alexeis 17.12.2007, 16:21 | ||||||
Мешает то что их удобство и состоит в том, что они создаются в стеке, а значит во выходу из функции токая строка уничтожается.
В точности описал механизм AnsiString , только он встроенный.
Выглядеть понятие весьма растяжимое и специфичное. Сильно зависит от компилятора и его возможностей. |
| Автор: baldina 17.12.2007, 16:22 |
| http://en.wikipedia.org/wiki/Copy-on-write к передаче параметров по ссылке/значению никакого отношения не имеет. да че вы ссоритесь? ObjectPascal, FreePascal, Delphi... Понятно, что все востребованные языки развиваются, не только паскаль, но и С++. Вот только... Есть стандарт С++. Мы собственно говоря про С++ остаемся в его рамках. Идите теперь почитайте про паскалевский http://www.moorecad.com/standardpascal/. А про "поддерживает то, поддерживает сё..." - если в языке есть оператор print или тип string я хочу ими пользоваться. ибо они есть стандартное свойство языка. Очень трудно понять и объяснить, что "вот этой фичей пользоваться не надо, она убогая, используйте вот это расширение языка для этой среды или вот эту библиотеку проприетарного производителя" |
| Автор: Lazin 17.12.2007, 16:33 | ||||
тоже самое можно сказать и про std::string, память под строку выделяется в куче, в стеке хранится только указатель на ее начало + специфичная для конкретной реализации информация. Даже если принять что std::string и AnsiString реализованы одинаково, то все равно, std::string - это stl контейнер, и для него есть туева хуча стандартных алгоритмов. Так-что можно сказать что он более функциональный.
Вот в этом и проблема, если он встроенный то его или невозможно изменить, или это сделать очень сложно. Такая реализация может в многопоточных приложениях вызывать утечку памяти при копировании(глубоком) между потоками(либо каждая строка должна содержать примитив синхронизации). Ты ничего не подозревая копируешь строку, думая что другой поток будет использовать копию, а он использует тот-же объект. |
| Автор: Alexeis 17.12.2007, 16:33 | ||
Это старый стандарт. |
| Автор: Daevaorn 17.12.2007, 16:38 | ||
std::string более стандартный чем все паскали вместе взятые. |
| Автор: Lazin 17.12.2007, 16:40 |
| +1 Добавлено через 3 минуты и 27 секунд кстати название темы: Pascal sv C++, что бы это могло значить ?? |
| Автор: archimed7592 17.12.2007, 16:46 |
| Alexeis, если автоматический объект, созданный на стеке, выходит из области видимости, то это вовсе не означает, что он освобождает какие-то ресурсы(маленькую область стека мы в расчёт не берём). Вот, к примеру, shared_ptr - он ничего не уничтожают, если есть другой shared_ptr, ссылающийся на тот же объект . Блин, что за марафон с аватарками? Я теперь всех путаю . |
| Автор: baldina 17.12.2007, 16:47 |
| верно, есть стандарт 1999 года, но что-то не очень его раздают, видимо секретный. в открытом доступе удалось онаружить только Draft 1993, есть там что-то про объекты даже Добавлено через 3 минуты и 31 секунду но кстати на http://www.iso.org/ из опубликованных значится только ISO 7185:1990 Information technology -- Programming languages -- Pascal |
| Автор: Daevaorn 17.12.2007, 16:52 | ||||
у тебя они включены?
есть даже ревизия 2003го. Все официально продаются комитетом за небольшую плату. А драфт можно без проблем найти и по-современней, было бы желание... |
| Автор: baldina 17.12.2007, 16:58 |
| ладно, стандарт есть. я рад за паскаль, правда. даже был удивлен сходу не обнаружив концов. ну так в последнем стандарте read, write, string исключили? вряд ли. значит все рассуждения остаются в силе. |
| Автор: Lazin 17.12.2007, 17:17 | ||
а ты присоединяйся |
| Автор: archimed7592 17.12.2007, 17:19 | ||
Сдать аватарку в аренду? Кстати, есть здесь добрые люди, которые смогут присобачить к моей аватарке новогоднюю шапку? |
| Автор: Alexeis 17.12.2007, 17:32 | ||
После такой тупости да еще поддерженной кучей народу считаю, что мне здесь обсуждать нечего... |
| Автор: Daevaorn 17.12.2007, 17:35 | ||
Мы люди не гордые. Критику любим. Обоснуй. |
| Автор: baldina 17.12.2007, 17:47 |
| ну вот, дельфиста обидели... Alexeis, тут изначально обсуждать то нечего было Развивай ЧЮ |
| Автор: Mayk 17.12.2007, 18:19 | ||
http://en.wikipedia.org/wiki/Buffer_overflow. такая неориентированность на длину строки приводит к некоторым серьезным проблемам с безопасностью. gcc к примеру любит орать warning'и если кто-то хочет использовать gets. |
| Автор: baldina 17.12.2007, 18:26 | ||
точно к таким же проблемам ведет неправильное значение длины строки |
| Автор: Mayk 17.12.2007, 19:09 | ||
А что, её так легко запороть? выйти за границы буффера гораздо легче. |
| Автор: Lazin 17.12.2007, 19:21 |
| archimed7592, ПРЕВЕД!!! Добавлено через 1 минуту и 8 секунд я как то странно себя чувствую  |
| Автор: baldina 17.12.2007, 20:48 | ||
как легче умереть, прыгая с крыши, или подставляя голову под падающие кирпичи? направление разное, результат один, рецепт общий - обходить и крыши и кирпичи. Если это С строка, имеется оконечный 0, достижение которого контролируется, то имхо разницы никакой. |
| Автор: Mayk 18.12.2007, 11:48 | ||
контролируется? То-то же strncpy не оканчивает строку нулем при нехватке места. Причем самое смешное, snprintf строку нулем заканчивает если места нет. Кстати. В ЖЖ упаминались http://hallvards.blogspot.com/2007/08/highlander2-beta-generics-in-delphi-for.html |
| Автор: archimed7592 18.12.2007, 12:21 |
| Mayk, пожалуйста, не нужно путать мощнейший метаязык в виде шаблонов С++ и какие-то дженерики, которые, что в java, что в .net'е, что в Delphi основаны на интерфейсах. В дотнете, по сути, никакой разницы между интерфейсом и дженириком нет. Да и вообще, ни одна runtime технология никогда не сравниться с compile-time шаблонами. |
| Автор: Mayk 18.12.2007, 14:25 | ||
Согласен, не сравняется [ровно как и с++ не сравнится с немрловскими макросами]. Однака положа руку на сердце, оно ей часто надо? При дженериках приведение типов в контейнерах более не требуется. Это хорошо. А то что дженерики обрабатываются в рантайм жалко конечно, но не более того. Задачи в которых требуется тьюринг полнота шаблонов на практике имхо достаточно редки. [Не могу вспомнить и одного примера, использующего мощь метаязыка, но думаю что они есть]. Задачи в которых шаблоны делают много чего нечитаемого в stderr'е достаточно часты. Это уже имхо авторов STLFilt'а. |
| Автор: archimed7592 18.12.2007, 15:27 | ||||
Не так давно я на С# делал фасад для работы с AutoCAD'ом через COM. Считывался XML файлик, в котором рисуемые сущности могли находится либо внутри block, либо внутри layer. Вся разница в том, что в первом случае нужно вызывать ф-цию myBlock.AddXXX, а в другом modelSpace.AddXXX. Мне досталась какая-то кривая версия автокада, в которой AcadBlock и AcadModelSpace не имели общего интерфейса. В итоге выхода было два: дублировать код полностью, либо написать обёртки над этими объектами. Ессно я выбрал второй вариант, ибо он кошернее и мне требовалось работать всего с 15-20 ф-циями(т.е. я просто делал минимальную обёртку). Но, если бы это был С++, то никаких обёрток не понадобилось бы т.к. С++ инстанцирует шаблон в compile-time и сразу может проверить наличие или отсутствие нужных методов. А в дотнете - сиди и делай copy-paste. Позже понадобилось добавить ещё около 20 ф-ции, благо я порылся в иерархии, поэкспериментировал и понял что можно явно приводить оба объекта к какому-то магическому IAcadBlock3(а зачем нужны первые 2? ).Ну а если посмотреть масштабнее - могло бы быть 150 ф-ций, причём, разных поддерживаемых сущностей могло бы быть не 2, а штук 15 и, по закону подлости, они не имели бы общего интерфейса. В таком случае я просто написал бы скриптик, генерирующий обёртки, но что же это за шаблоны, если их главную ф-цию приходится выполнять самому, пусть, порой и в полуавтоматическом режиме... Добавлено через 14 минут и 57 секунд
Ну а что касается этого - возьми, хотя бы, те же traits... Или, вот я сейчас достаточно плотно работаю с геометрической библиотекой CGAL. Она совершенно не привязана к типу, представляющему число. Это может быть и double и числовые типы из GMP и что угодно другое. Вот понадобилось мне использовать неточные сравнения(в моём случае это была точность до 1e-6). Написал я класс, в котором все операторы сравнения перегружены для неточных сравнений - и вуаля, теперь, сравнивая два вектора я могу быть уверен, что не получу отрицательный результат из-за неточности double. Можно сделать подобное на дельфёвых интерфейсах? Несомненно, но, представьте себе, какой получиться оверхед из-за, во-первых, вызовов ф-ции, да ещё и виртуальных вызовов(когда ни один линкер, не в силах ничего оптимизировать). Ещё пример: в этой библиотеке написана обёртка над mpz_t из GMP, которая немного кривовата. Я элементарно унаследовался от этой обёртки, не меняя, по сути ничего - просто сделал forward конструкторы. Потом, чтобы обёртка, над Gmpzf начала правильно считать sqrt, я унаследовался от соответствующих traits, где изменил всего один функтор Sqrt, заменив его вычислитель на нужный мне. И все эти унаследования и прочие извращения никак не сказались на производительности т.к., к примеру, forward-ctor - просто инлайнился(как, скорее всего и сам конструктор, на который происходил редирект). Анлогично и со всем остальным. Кстати, когда-то и где-то мы делали бенчмарк vector vs new. Угадай кто остался в пролёте ;). Шаблоны - это мощь. |
| Автор: baldina 18.12.2007, 15:46 | ||
хотелось бы узнать, как strncpy может определить нехватку места. этот пример скорее подтверждение моего поста насчет переменной, хранящей размер, а не опровержение. Добавлено через 1 минуту и 48 секунд archimed7592, +1 вобщем С++ рулит. чтд |
| Автор: archimed7592 18.12.2007, 15:54 | ||
На самом деле очень просто. "Решение этой задачи предлагаю решить читателю самостоятельно" .Добавлено через 1 минуту и 58 секунд Просто если задуматься, почему strncpy не пишет в конец 0, то можно достаточно быстро прийти к ответу на вопрос почему sprintf пишет, а strncpy нет . Решение этой задачи тоже остаётся на плечах читателей  . |
| Автор: baldina 18.12.2007, 16:21 | ||
| archimed7592, если б так все было просто... смотри сюда:
Добавлено через 2 минуты и 26 секунд да и вообще, имея void f (char *str, size_t size) { // делать здесь предположения о реальном размере памяти, на который указывает str дело неблагодарное } Добавлено через 3 минуты и 52 секунды а итог простой - все на плечах пользователя. и забытый 0, и неправильно определенный size есть проблемы одного рода |
| Автор: archimed7592 18.12.2007, 16:37 | ||
| baldina, нет, нет. Мы не берём в расчёт неправильный размер, указанный заведомо большим, чем реальный. Что же касается меньшего размера - ты можешь считать, что всё правильно, ибо, если идёт просьба записать не больше 6-ти байт в 10-байтный буффер, то значит оставшиеся 4 байта для чего-то нужны и для строки не предназначается. Ну а незаписываемый 0 в случае strncpy - подтолкну направление в котором нужно мыслить: что возвращает strncpy? А что возвращает snprintf? Добавлено через 53 секунды
Само собой. Просто иногда на плечи пользователя возлагается чуть больше, а иногда - чуть меньше . |
| Автор: Mayk 18.12.2007, 16:45 | ||||||
/archimed7592, ну ты и графоман блин, я столько не осилю /
c# и дот нет? А тот addXXX можно было вытащить и вызвать через рефлекшн?
В том числе и шаблоны c++[особенно пока variadic template arguments не появятся в компиляторах]. Правда в гораздо меньшей степени.
йап, в том то и дело что в строках аля паскаль никаких дополнительных переменных не надо. |
| Автор: archimed7592 18.12.2007, 16:50 | ||||||
Можно, но это, IMHO, ещё большее извращение.
Имея Boost.Preprocessor это не проблема.
Ты думаешь их нет? |
| Автор: baldina 18.12.2007, 17:23 | ||||||
я только это утверждал. так что, archimed7592, мы спорим об одном и том же разными словами. речь шла о возможном переполнении буфера. более я ни с чем не спорю. (хотя в скобках замечу, что семантика strncpy, чем является возвращаемое значение, к возможному переполнению никакого отношения не имеет. отношение имеет правильное или неправильное использование, корректная или некорректная программа) Добавлено @ 17:29
Я кстати недавно тестировал std::vector vs boost::array. gcc и VC++. Результат был одинаков и несколько меня обескуражил - если размер указывать заранее, то vector быстрее (правда совсем ненамного). Скурпулезное рассмотрение выявило причину. Получается немного разный ассемблерный код, вот за счет этого и разница. Но кто бы мог подумать! |
| Автор: Mayk 18.12.2007, 19:42 | ||||
Boost.Preporcessor сам по себе проблема трудочиаемости http://www.boost.org/libs/preprocessor/doc/index.html. йа пробовал на нём сделать
но испугался этих жутких макросов. Благо ~40 строк pythonа генерирует такой хедер без проблем. |
| Автор: MAKCim 19.12.2007, 01:20 |
| не знаю господа я вот капитально на Python подсел более мощного во всех отношениях языка я не видел + мощная интеграция с С чего еще надо?  |
| Автор: Mayk 19.12.2007, 13:38 | ||
| так и запишем что в борьбе с++ vs паскаль победу одерживает питон. кстати, чисто посмеятся, гугл находит http://www.pascal-central.com/top10.html.
 * пристыженно уходит учить Ерланг * |
| Автор: Void 19.12.2007, 13:59 |
| Наконец-то... Развели, понимаешь, войну Pascal vs C++ в канун 2008 года. Хорошо хоть не Алгол против Фортрана И да будет системный код наш на Си, сервера на Эрланге, а прикладная логика на Питоне. |
| Автор: Lazin 19.12.2007, 14:17 | ||
ибо не было и не будет универсального языка программирования имхо связка python(lua) скрипт + код на С\С++, всегда будет наиболее мощной и гибкой, Delphi курит в сторонке )) |
| Автор: archimed7592 19.12.2007, 15:45 | ||
Интеграции с С++ . |
| Автор: Void 19.12.2007, 15:54 | ||
Boost.Python, SWIG.  |
| Автор: MAKCim 19.12.2007, 17:27 | ||
а зачем? Python самодостаточен а для низкоуровневых вещей есть С вся проблема С++ (точнее компиляторов) - использование разных алгоритмов трансформации имен символов для генерации объектных файлов т. е код на С++ довольно тяжело интегрировать с Python |
| Автор: archimed7592 19.12.2007, 23:36 |
| Void, MAKCim, шуток не понимаете что ль? |
| Автор: MAKCim 20.12.2007, 00:06 | ||
честно говоря не понял, в чем заключалась шутка вполне себе серьезное высказывание, правда со смешным смайлом хотя может у тебя просто настроение было хорошее |
| Автор: Lazin 20.12.2007, 12:26 |
| пару месяцев назад читал статью, о тенденциях в программировании, в частности речь шла о том какие системы программирования как развиваются.. там говорилось о том, что количество проектов использующих Python, Lua, ruby и т.д. растет быстрее всего, чуть медленнее Java - .NET, С++ занимает свою нишу (что-то около 20%), ну а Паскаль скоро будут помнить только старожилы, так как он займет свое почетное место среди таких языков как Cobol, Fortran и пр... ps возможно он сохранится только в Российских ВУЗах |
| Автор: archimed7592 20.12.2007, 12:31 | ||||
Поскорей бы...
Не дай Б-г. |
| Автор: MAKCim 20.12.2007, 12:33 | ||
сейчас нарвешься на паскалистов |
| Автор: Mayk 20.12.2007, 13:11 | ||||
чисто циферки. Некоторая статистика по freshmeat [собираеццо не регулярно].
pascal на fm'е действительно не очень живой. |
| Автор: Fiyanov 18.3.2008, 08:25 |
| Delphi умирает уже не первую пятилетку господа. Смотрите правде в глаза. Он всегда отставал от VS. Но признаков смерти никода не было. Более того этот самый Delphi (сейчас это Developer Studio) вытащил Борланд из долговой ямы. То есть его покупают. Вот уже 2007й вышел. Правда не в полной редакции но всё же. Не думаю что делфи когда нибудь умрёт. Это глупость. Каждый день появляються новые тихнологии с новыми языками и находяться люди которые их осваивают и дают им жизнь. Делфи же уже старичёк, у него хватает фанатов. Всё зависит от мастерства! |
| Автор: Любитель 31.3.2008, 03:38 | ||
Ну-ну! Это совершенно разные вещи. Дженерик (в дотнет) - это особое понятие на уровне рантайма (ВМ), что кстати не отменяет шаблонов и прочих механизмов встроенной кодогенерации (всяких там макросов...) со стороны конкретного языка. Физический класс инстанцируется при первом использовании дженерика. Для reference-типов - один (ну там мож где тип тупо храниться - дотнетчики поправят ), для value-типов - по классу для каждого (всмысле заюзали дженерик с value-типом - сгенерился класс). Причём тут интерфейсы?Дженерики из гуд - для языков, имеющих возможность создания типа на лету (читай - имеющих ВМ/интерпретируемых/etc.). Что касается питона - вот тоже давно нравился и нравится, но вот юзать - совсем не юзаю (за исключением waf-а ). Почему? А фиг его почему... Прикладной уровень питона не знаю совсем |
| Автор: archimed7592 31.3.2008, 04:17 | ||||
При том, что при написании дженерика ты должен перечислить все интерфейсы, которые тебе необходимы(или получишь объект с которым ничего не сможешь сделать - даже необходимость делать new ты должен указать явно). Др. словами ничего не мешает написать не менее гибкий код просто напросто используя интерфейсы. А если метод не интерфейсный(ну не догадался разработчик в интерфейс засунуть), то от дженерика пользы столько же сколько от копипаста .Просто я на опыте сталкивался, когда несколько нужных мне классов не имели интерфейса и пришлось мне заниматься копипастом... Так что не надо "ля-ля" про инстанцирование. Если бы оно было, то ничего не мешало бы использовать рефлексию и сделать перечисление интерфейсов лишь как вспомогательный инструмент в случае дженерика. Та же ситуация, насколько я понимаю, и в Java. Добавлено через 3 минуты и 16 секунд
А, ну да, по сути я не утверждаю, что это одинаковые вещи. Я лишь хотел сказать, что никаких преимуществ при использовании дженериков(вместо интерфейсов) нет... Ну, разве что, синтаксис немного иной - на любителя . |
| Автор: Lazin 31.3.2008, 08:10 |
| duck typing рулит , никаких дженериков и шаблонов не нужно |
| Автор: Любитель 1.4.2008, 15:47 | ||||
Ну да - всегда можно обойтись боксингом/анбоксингом + интерфейсами + кастингами. Страдает производительность.
Протесть дженерик-коллекцию интов и обычную. Увидишь разницу.
А тут вроде наоброт - гораздо хуже. Дженерики - лишь мелкое удобство. |
| Автор: archimed7592 1.4.2008, 20:54 | ||||||
А где разница то? 1. В синтаксисе 2. В подсказках IDE(будет показывать, что аргумент ф-ции не object, а int). 3. В просто смешной защите от дурака(нельзя будет передать ничего, кроме int). Но здесь, если отвлечься от конкретно коллекций и перейти к чему-нибудь, что будет пользоваться не только operator=, к примеру, выставлять в требованиях некоторый интерфейс дабы с обобщёнными объектами можно было бы как-то взаимодействовать, то переписав код на интерфейсы ты получишь ту же самую "защиту от дурака", которая будет выражаться в ругани компилятора при попытке использовать объект, который не поддерживает требуемый интерфейс. Вывод: это лишь синтаксический сахар. Вполне возможно, что in a nutshell это нечто большее, но предоставляемый ф-ционал - лишь сахар, пудра, пыль. Примеру ради: как не используя рефлексии реализовать аналог следующего плюсового предиката?
Сразу приведу пример шарповых классов:
Этим кодом я хочу подчеркнуть, что оба типа(KeyValuePair1 и 2) НЕ имеют общего интерфейса предоставляющего доступ к value(и не могут иметь, если конечно value не превратить в банальный object - от чего убегали к тому и придём). |
| Автор: mr.DUDA 4.4.2008, 08:41 | ||
archimed7592, можно конечно и так:
В этом случае есть общий интерфейс. Код громоздкий, сам знаю З.Ы. в дженериках вывод типа хромает, но мелкомягкие вроде собираются что-то с этим делать (Рихтер упоминал про это). З.Ы(2) в холиварах на винграде - как на военных заводах времён перестройки: что ни попробуют собирать, но вместо кастрюль и сковородок выходит автомат Калашникова. Так и здесь - какой язык ни начни сравнивать с другим, хоть OCaml с Haskel - всё равно в итоге перемываем кости .NET/C#... Про паскаль и С++ забыли уже. |
| Автор: archimed7592 4.4.2008, 09:13 | ||||
Ну дык я то просил без общего интерфейса . Могу уточнить: классы KeyValuePair1/2 ты никак модифицировать нельзя(пусть они библиотечные, к примеру)...
|
| Автор: Любитель 4.4.2008, 12:54 | ||
| Ещё раз - дженерики это не механизм кодогенерации! Это возможность рантайма. Насчёт "потесть" - я про поизводительность. Непосредственная работа с интами или постоянный боксинг/анбоксинг. Добавлено через 1 минуту и 48 секунд
Йа хде?  |
| Автор: Akella 21.4.2008, 22:42 | ||
|
| Автор: Beltar 5.5.2008, 15:57 |
| Собственно выпустив C# и Java несостоятельность Си++ уже признали. Остается только подождать, пока в Паскале не уберут запрет на операции над указателями без приведения к целому, после этого Си++ можно выносить. Если еще и шаблоны ввести, то точно у Си++ никаких плюсов уже не будет. Конечно MS будет сопротивляться, но это ей не поможет. |
| Автор: Alexeis 5.5.2008, 16:13 | ||||
Операции над указателями типа PChar разрешены, так легче переносить код из C++.
Delphi активно обменивается фичами с C#, а не С++, потому шаблонов ждать не стоит. |
| Автор: Lazin 5.5.2008, 16:22 | ||||||||||
с каких это пор, у них совершенно разные области применения учи матчасть
Паскаль? А, это-то, что пылится на одной полке с Cobol-ом? Жуть, на нем кто-то еще пишет? Так что, там еще и указатели нужно к целому приводить , так вот почему Borland никак не выпустит Delphi под 64х битную архитектуру, просто у дельфистов сразу все программы поломаются
Вот именно "как", компилятор С++ на порядок(и вряд-ли на один ) сложнее паскалевского, "как" не получится, получится жалкая пародия
а они тут причем? вообще язык С++ - свободный, он никому не принадлежит, есть его стандартязык паскаль - практически умер , есть много несовместимых между собой реализаций (free pascal, delphi мож чего еще), даже набора стандартных библиотек нет но паскалистам этого не объяснишь, так как:
даже когда это что-то лучшее осталось в прошлом |
| Автор: Beltar 5.5.2008, 23:28 | ||||||||||
Я конечно понимаю, что очень хочется верить, что последний вменяемый язык на земле исчезнет, но он по-прежнему продолжает развиваться, а вот C#-Builder благополучно накрылся ибо нефиг, раз Delphi .NET есть.
Наличие или отсутствие стандартов, на Паскаль они вроде тоже были, глубоко и искренне пофигу, тем более, что язык для RAD избыточен для программирования контроллеров. Что включать в стандарт будем? Соответствуют-ли стандарту все плюсовые компиляторы еще вопрос. Сделает кто-то Ada Studio сравнимую с Delphi и VS будут Аду массово использовать, нет значит не будут. Решают не столько качества языка сколько его поддержка крупной фирмой. Еще Fortran каким бы отстойным он по сравнению с европейским Алгол-60 ни был, в Америке цвел и пах, только из-за стараний IBM. Модула-2 может и лучше Паскаля, но где она сейчас? Только потому, что Borland не выпустила ее на рынок. Совершенно стихийным было развитие Бейсика и современный VB это уже совсем др. язык. Куда более стихийным, чем у Паскаля, который ориентировался на Borland.
Даже если компилятор Паскаля будет работать в 10 раз медленнее, я бы не советовал гнуть пальцы по поводу короткого синтаксиса Си, т. к. первая же компиляция программки в 5000 строк просто сожрет все время, сэкономленное на наборе за все время создания программы. Так что каким местом сложность стала преимуществом мне непонятно.
Как и у сишников т. к. смещения по памяти типа адрес+4 могут стать некорректными. Причем скорее именно у сишников. Пасквилянт еще подумает перед тем, как извращаться. [quote]Жуть, на нем кто-то еще пишет?[quote] Ну если вы не в курсе, то что я могу поделать. У меня вот знакомых пишущих на Си меньше, чем на Delphi.
Ну просто такую мелочь как класс стека (мне хватает для этого массива и Top:Integer) или отсутствовавший в VCL до Delphi 10 пустяковый компонентик иконки в трее при желании можно махом написать самому или всегда найти. Проблема блин. Очередь или сортировку сделать. Если сишники этого не могут без STL, то кто тогда Windows написал. Не делайте мне смешно. Не поймите меня превратно. Я ничего не имею против STL и даже за нее, меня всегда удивляло почему подобная мелочевка не идет в VCL (или по крайней мере я про нее не знаю). Но подобную мелочь всегда можно найти. |
| Автор: baldina 5.5.2008, 23:38 | ||
Вы еще кипятите? |
| Автор: archimed7592 5.5.2008, 23:42 | ||||||||||
У сишников, в отличии от паскалистов, ptr + 4 - это сдвиг на sizeof(ptr) * 4, так что не надо "ля-ля". Есть конечно моменты, на которые нужно обратить внимание при портировании кода, но их ограниченное кол-во и сложность портирования не так уж и высока.
Ню-ню 
А как, вообще Delphi к паскалю относится? С тем же успехом можно под одну гребёнку и C++, и Java, и PHP и т.д., ибо у них синтаксис от Си происходит.
Есть выбор: писать самому, допустить ошибки, отладить, снова отладить и т.д. Потом выяснится, что алгоритм неэффективен, переписать, отладить, снова отладить и так до бесконечности. Или же можно взять готовый, обобщённый алгоритм(к контейнерам то же самое относится).
А ты поищи, поищи. Давно это в паскале(да, лан, пусть, даже, в Deplhi) шаблоны появились, чтобы эта мелочёвка вообще в природе появилась? |
| Автор: Lazin 6.5.2008, 08:04 | ||||||||||
я тебе про одно, а ты мне про другое, я о том, что при работе с указателем как с целым может возникнуть проблема с переносом на 64-х битную архитектуру, например представим что в С нету арифметики указателей (прям как в паскале )
код нормально отработает при компиляции под 32х а если скомпилировать под 64х то то-же будет работать, почти всегда
ну вот недавно собирал библиотеку - 30 000 строк (Си), секунды 3 или 4 , а ведь современные компиляторы умеют собирать разные единицы трансляции параллельно И вообще ты не о том, вот есть к примеру в Delphi шаблоны, а может ли он самостоятельно выводить типы шаблонных параметров, а есть ли в Delphi(Pascal) аналог шаблон-шаблонных параметров (это когда в шаблон передается не тип, а другой шаблон) и тд... Шаблоны в Delphi - это элементарная параметризация типов, а в С++ это тьюринг полный язык, на котором можно писать программы, которые будут выполняться во время компиляции и вычислять значения и типы.
наверное потому-что STL использует шаблоны, и без них очень кривой STL получится , неудобный (кстати насколько я знаю есть в Delphi и стеки и динамические массивы и все что душе угодно...)
Вот был сначала Visual Basic, дожил он до 6-й версии, а потом взял и исчез, прекратил развиваться, а все из-за того, что он зависел от одной известной компании. |
| Автор: jackfrost 19.6.2008, 13:42 |
 Люди, все эти языки фуфло, ну сколько уже лет математикам приходится писать один и тоже цикл для вычисления банальной суммы: for (double i=1; double tmp=0 ,i<N,i++) {tmp+=1/i; } неужели сложно сделать что-то типа: sum(i,1,N,1/i); или даже sum(i,1,N, sum(j,1,N,1/i+1/x(j) ) ) ну это же проще пареной репы!!! веть вообще это можно было-бы решить макросом, если бы в Си составной оператор мог бы быть выражением: result = ( for (double i=1; double tmp=0 ,i<N,i++) {tmp+=1/i;} , tmp ); идиотизм писать математику на языке заточенным по работу с железом. А все эти паскали явы и ады не далеко ушли... таже фигня.. ..а те замечательные изменения которые приняли в С99 - пошли коту под хвост. Никто не хочет поддерживать уже почти 10лет, по IT меркам почти вечность.... |
| Автор: Alexeis 19.6.2008, 13:45 |
| jackfrost, используй пакеты Математика, матлаб и проч. Там все предельно просто. |
| Автор: jackfrost 19.6.2008, 13:53 | ||
МАТЛАБ пользую для прототипирования алгоритмов, а писать потом все равно все на Си приходится. кстати действительно из смешного - в МАТЛАБе нат такой операции если под знаком суммы стоит функция строго одного аргумента, то нужно раскрывать все в цикл... |
| Автор: Lazin 19.6.2008, 14:42 | ||
а почему нельзя написать функцию sum? |
| Автор: Alexeis 19.6.2008, 14:49 | ||||
Потому что она без счетчика. Без счетчика такая функция есть, по крайней мере в модуле Math. Выбирайте на любой вкус .
|
| Автор: jackfrost 19.6.2008, 15:16 | ||
да не об этом речь,
вот о каком синтаксисе мечтают люди, а функции тут не причем - просто препроцессор долженбы развернуть этот в код: for (tm1=0,i=1,i<N,i++ ) { for (tmp2=0,j=1,j<M, j++) { tmp2+=1/i+1/x(j); } tmp1+=y(i)*tmp2; } res=tmp1; а через функции никак - ибо выражение 1/i+1/x(j), должно быть вычесленно до вызова функции... может в Яве или в Си-шарпе есть механизмы сделать нечто подобное? собственно для этого достаточно чтобы сложный оператор (цикла) имел значение и мог быть правым значением в присвоении: res={for (.... } для рекурентного вызова... ну и механизм макросов как в Сях или желательно помощнее.... всех делов... |
| Автор: Alexeis 19.6.2008, 15:46 |
| jackfrost, так вполне можно написать в Delphi. Смотри x(j), y(i) - это функции. Функции можно передавать в качестве параметра в другие функции. Точнее функцией будет 1/i+1/x(j) . Добавлено через 1 минуту и 55 секунд Хотя пожалуй вложенно не получиться. |
| Автор: Mayk 19.6.2008, 16:15 | ||||||
Кому сложно? Это делается элементарно. В одну строку. Но не на си и не на паскале. Ф-циональные языки и их особенности не запрещали.
Добавлено через 1 минуту и 54 секунды
Посмотри в сторону Nemerle. Там есть очень мощная система макросов. |
| Автор: Любитель 19.6.2008, 16:51 | ||
Короче, люди мечтают о лямбда-функциях. Препроцессор тут не при чём |
| Автор: lukas 19.6.2008, 19:28 |
| вообще написали бы еще в теме Глагол vs С++ ... жестокое сравнение было бы... |
| Автор: jackfrost 25.6.2008, 10:13 |
| нафих глаголъ и лямбду с питоном, вот нашел решение, работает только в GNU C и его портах: #define SUM(n,N0,N,eq) ({double tmp_##n=0; for (int n=(N0);n<(N);n++) {tmp_##n+=(double)(eq);} tmp_##n; }) Понятно, что такой код, далеко не безопасен и далек от оптимальности, но на этапе прикидки сложной математики просто супер!! Теперь можно писать запросто вот так: main() { double A[2][3]={{1,2,3},{4,5,6}}; double sumall=SUM(k,0,2, SUM(n,0,3, A[k][n]) ); printf("%f\n", sumall ); } такчто Си рулит и по сей день. |
| Автор: Lazin 25.6.2008, 10:41 |
| покойся с миром в профессиональном плане конечно)))) |
| Автор: Void 25.6.2008, 13:50 | ||
На этапе прикидки сложной математики, нужно и использовать соответствующие инструменты, от Матлаба до Хаскеля, Окамла, Схемы и Питона с соответствующими пакетами. Как только произнесены слова «можно не очень оптимально», Си отправляется в лес. Можно, конечно, одним топором всё рубить, только зачем. Впрочем, дело вкуса. |
| Автор: JackYF 25.6.2008, 15:25 |
| Господа паскалисты, а на каких платформах уже научился работать ваш компилятор? x86_64, arm, sparc, mips, powerpc? |
| Автор: Lazin 25.6.2008, 15:59 |
| JackYF, призывает древние силы иначе как древними паскалистов назвать сложно)))) |
| Автор: lukas 25.6.2008, 16:10 |
| JackYF, freepascal на всех известных...  |
| Автор: Lazin 25.6.2008, 16:14 |
| древние силы окончательно пробудились! |
| Автор: Mayk 25.6.2008, 17:06 | ||
На всех-всех? Даже на z80 с 48 кб памяти? |
| Автор: Alexeis 25.6.2008, 17:12 |
| Да не ребята, на железке паскаль не рулит, и С++ тоже. Трудно с малыми ресурсами писать высокоуровневый код. Получается либо С, либо сиподобный С++. |
| Автор: jackfrost 25.6.2008, 17:42 | ||||
уже писал, что даже МАТЛАБ не позволяет писать ТОТ пример нормальным математическим языком.. а вот на Си - оказывается можно.... да и потом 90% математики что сейчас пишется в мире идет для встраиваемых систем, там естественно ничего кроме Си и быть не может по определению. |
| Автор: nerezus 25.6.2008, 17:54 | ||
 У меня на мобильнике есть джава. На етокене - тоже джава. Больше подобных девайсов у меня нету. |
| Автор: Lazin 25.6.2008, 18:17 | ||
 |
| Автор: jackfrost 25.6.2008, 18:19 | ||||
а у меня на спектруме вообще был БЕСИК и что?? никто на яве не будет веть делать реализацию например WiFi протокола ? )))))) я про эту математику собсвенно говорил.. |
| Автор: Lazin 25.6.2008, 18:20 | ||||
Mathcad тебе поможет, Мatlab он не для этого синтаксис Си можно исковеркать как угодно, главное что-бы ваши коллеги не знали где вы живете Добавлено через 42 секунды
это не математика |
| Автор: Alexeis 25.6.2008, 19:43 | ||
По определению, может быть С++ с урезанными возможностями. В основном где могут стараются реализовать компилятор С++. |
| Автор: Void 25.6.2008, 19:56 | ||||
Ну хорошо, Матлаб пролетает, давно я его не трогал. Остаются языки с list comrehensions. Haskell, к примеру:
В точности как просили. И операторы в функциональных языках являются выражениями, ага. Функции высшего порядка, немного синтаксического сахара и вуаля. |
| Автор: lukas 25.6.2008, 21:18 |
| Какие то ограниченные вы люди... последнее время увлекаюсь скриптовыми языками... еще что-то пишу на делфи, например в последнем проекте на делфе использую скриптовой движок PHP ... практически 70-80% в проекте будет написано на PHP, а делфи лишь как оболочка, этого требует задумка проекта... P.S. После тестирования многих скриптовых движков (Lua, Python, PHP, Pascal Script, FastScript) я выбрал PHP... Pascal Script слишком медленный, Lua трудно итегрировать, FastScript платный, а питон отдельная история... Под устройства не пишу... и никогда не буду писать, это не мое... так что мне что есть реализация freepascal'ya на z80 с 48 кб, что ее нет, по - барабану... слишком узкая специализация... |
| Автор: Lazin 25.6.2008, 21:36 | ||||||||
и кто после этого ограниченный? |
| Автор: lukas 25.6.2008, 21:47 | ||||
| почему то еще все забыли про Lazaru и MSEide аналоги среды делфи под большое кол-во операционных систем... GNU Pascal ... который работает на следующих платформах ... (из вики)
Безосновательные комментарии игнорирую... |
| Автор: Lazin 25.6.2008, 22:37 | ||
PHP самый ограниченный из перечисленных тобой скриптовых языков)) |
| Автор: lukas 26.6.2008, 08:00 | ||
Lazin,
опять безосновательное утверждение... |
| Автор: Lazin 26.6.2008, 08:36 | ||||||
с каких это пор MSYS это платформа?
ну взять хотя-бы питон
питон - ЯП общего назначения, не только для веба (пхп в основном для него) в нем нет скобок но есть пространства имен и модули еще он быстро работает и имеет классный синтакс, only one thing to do this)) а еще классы и функции могут содержать документацию также, аргументы функций можно передавать как обычно а так-же по их именам ну и конечно множественное наследование.. и интроспекция конечно-же функционально программирование: лямбды, замыкания.. map reduce питон следует принципо everyting is an object так-же возможна перегрузка операторов можно использовать потоки есть много встроенных типов данных - списки, словари, кортежи (AFAIK в PHP только массивы, которые ближе к словарям можно использовать любой GUI фрэймверк.. Qt, tk, wxWidgets... интернационализация на высоте, так как используется юникод))) Добавлено @ 08:41 а для ПХП есть что то похожее на http://twistedmatrix.com/trac/? |
| Автор: nerezus 26.6.2008, 08:51 |
| Lazin, в пхп даже потоков нет) |
| Автор: MAKCim 26.6.2008, 09:18 | ||
при чем здесь язык к потокам? |
| Автор: nerezus 26.6.2008, 09:31 |
| MAKCim, а вот допустим я хочу управлять графикой, делать что-то в сети и что-то просчитывать? Нужно 3 потока. Иначе как в левых прогах будет подвисание интерфейса. |
| Автор: Alexeis 26.6.2008, 09:37 |
| nerezus, если скрипт php работает больше секунды это уже плохо . Какая фтопку графика, когда результат работы php это html? |
| Автор: MAKCim 26.6.2008, 10:15 |
| nerezus, ну а причем здесь аязык? или работу с потоками нужно синтаксически встроить в язык? я думаю, не сложно написать библиотеку для работы с потоками |
| Автор: Lazin 26.6.2008, 10:23 | ||
| MAKCim, речь шла о скриптовых языках (в частности о питоне), там возможность работы с потоками поддерживается интерпретатором... хотя для программиста поток является библиотечным объектом Добавлено через 42 секунды
на С или паскале не сложно, а на ПХП? |
| Автор: MAKCim 26.6.2008, 11:00 | ||
т. е виртуальной машиной, т. е используется API хостовой системы очевидно то же самое можно реализовать в ядре PHP и точно так же поток будет представим объектом |
| Автор: nerezus 26.6.2008, 11:04 | ||||||||
PDF, картинки и т.д. - все это нормально для пхп. К тому же ты забываешь про скриптинг, где скрипты работают часами/днями. Хотя это не сильная сторона пхп(сложность интеграции, отсутствие освобождения памяти(имхо это фатально), слабые возможности для скриптинга) Тут у питона и луа конкурентов имхо нету. Первый особо богат возможностями(я физику на нем через биндинг ODE считал), а второй интегрируемостью и скоростью.
Добавлено через 34 секунды
|
| Автор: MAKCim 26.6.2008, 11:06 | ||
если не реализовано, значит никому не надо |
| Автор: nerezus 26.6.2008, 11:15 |
| MAKCim, Поддержка кучи оборудования в линуксе тоже не реализована. Нет до сих пор свободных дров для WiFi девайсов. Я не поверю, что это никому не надо ;) А вот многопоточность нужна мне. Но ее нету, а у меня недостаточно ресурсов(знание, время, возможности), чтобы ее сделать. |
| Автор: Alexeis 26.6.2008, 11:23 | ||
Мне кажеться это насилие над языком. Если есть что-то тяжелое и длительное, то это должен эффективно решать движок, при помощи быстрых и оптимизированных функций. |
| Автор: lukas 26.6.2008, 13:29 |
| что-то вы тут спорите много... все что нет в PHP стандартном (в том числе и потоков) будет реализовано средствами delphi и добавлено в движок как библиотека... да и многопоточность мне особо не нужна.... |
| Автор: MAKCim 26.6.2008, 16:43 | ||||
здесь вопрос не только в том, надо кому-то или не надо, но еще и в отсутствии открытых спецификаций на устройства иди напиши драйвер без спецификации Добавлено через 2 минуты и 52 секунды
есть две проблемы первая озвучена выше вторая связана с ядром и порождается из-за нерешенной первой |
| Автор: nerezus 26.6.2008, 17:16 | ||
иди напиши модуль без соответствующих возможностей пхп ) |
| Автор: MAKCim 26.6.2008, 17:21 | ||
но тут все проще PHP же открыт? |
| Автор: lukas 26.6.2008, 18:08 |
| здесь не обсуждаются низко уровневые языки.... P.S. Fast Script еще оказался и очень медленным.... это очень не приемлемо... P.S.S. Python мож и хорош,... но нравится мне больше PHP... тем более я использую 5ую версию, где ООП более менее на высоком уровне... |
| Автор: Lazin 26.6.2008, 19:40 | ||||
а как-же Pascal и С++?
в PHP ООП развит слабее, нет duck typing, а так-же не все является объектом хотя я практически не знаю PHP могу и ошибаться |
| Автор: Void 26.6.2008, 19:44 | ||
Я тоже толком не знаю PHP, но по-моему типизация для объектов ам именно что утиная. |
| Автор: nerezus 26.6.2008, 19:49 | ||
Все равно не сможешь написать модуль, не изменяя пхп, а изменять нельзя. И даже если бы ты захотел сделать это для себя - то там немеренное количество работы. И еще: тебе придется править каждый используемый тобой экстеншн. Ибо непотокобезопасны. А это уже нереально. И как следствие, что если ты все-таки это сделаешь(перепишешь движок пхп, нужные тебе модули), то другой человек не сможет воспользоваться твоими достижениями: 1) Код надо будет поддерживать в актуальном состоянии, т.е. при каждой новой версии тебе придется переписывать часть своей. 2) Человеку могут понадобиться другие модули. И кстати да: многие модули не имеют открытых исходных кодов =) |
| Автор: lukas 27.6.2008, 07:49 | ||
| Lazin, ну прально... в PHP не все является объектом как например в Java, но я не считаю это недостатком... А в 5ом ПХП добавили публичные, приватные и т.п. методы, еще вроде свой-ва... могу ошибаться... P.S. Протестировал вчера Lua, вышло так что Lua - 5 сек а PHP - 8 сек, Lua выйграла..., хотя язык довольно скуден особенно в ООП, там его вообще нет... Python вообще трудно интегрировать с VCL ...
Это языки высокого уровня, видно как вы разбираетесь в языках... а тем более логичнее было бы написать Pascal vs C, а не (C++) |
| Автор: nerezus 27.6.2008, 08:02 | ||||
Объясни, каким боком тут VCL? о_О
|
| Автор: Lazin 27.6.2008, 08:20 | ||||||
С++ - язык программирования низкого уровня Добавлено через 2 минуты и 58 секунд
ООП там есть, луа не поддерживает классы, но зато поддерживает прототипную модель ООП... Добавлено через 4 минуты и 40 секунд
уверен что есть готовый питоновский биндинг для VCL |
| Автор: lukas 27.6.2008, 10:42 | ||||
Lazin, в Lua я вроде читал только какие то таблицы и шаблоны, которые и какбы заменяют объекты... но это даже не объектная модель java...
ссылочку... я что-то ничего не нашел... хотя б для c++ ... Добавлено через 1 минуту и 57 секунд
да нет... это классовая иерархия в Билдере и Делфи, на которой основан весь GUI программ... да и не только... |
| Автор: Lazin 27.6.2008, 11:33 | ||||||
ты путаешь понятия, объектная модель и модель ООП, так что мы говорим на разных языках
SWIG разве не сгенерит? Да и дергать ВЦЛ компоненты через скрипт...
думаю здесь все знают что это такое... |
| Автор: JackYF 27.6.2008, 12:23 | ||
Не поверишь, гуй можно создавать и без VCL. |
| Автор: Alexeis 27.6.2008, 12:32 | ||
Это фантастика |
| Автор: Daevaorn 27.6.2008, 15:26 | ||
А какие есть? |
| Автор: JackYF 27.6.2008, 18:32 | ||
Ну дык. А то человек вон какую фразу сказал "весь GUI"... |
| Автор: lukas 27.6.2008, 19:56 |
| JackYF, я сказал что-то не так... я говорю что в Делфи и в Билдере весь GUI строится на VCL, а VCL строится на WinApi... мне не хочится возвращатся к WinApi, обработке сообщений и т.д, я буду терять много времени на это, легче один раз интегрировать VCL в движок... и вообще забыть про реализацию GUI ... |
| Автор: nerezus 27.6.2008, 20:38 | ||||
P.S. Насчет определения разобраться бы. Я для себя юзаю такое: ЯП низкого уровня - язык, в ктором нет абстракции над железом/ОС и напрямую приходится работать с вещами, не связанными с алгоритмом программы. В C++ это делать приходится(указатели, контроль памяти), однако есть средства, которые в некоторых случаях позволяют этого избежать(ООП фреймворки вроде Qt), однако избежать удается не всего, да и некоторые средства просто убоги по сравнеию с аналогами в других языках(например те же ссылки, которые нельзя переназначмить даже и т.д.) Добавлено через 5 минут и 15 секунд
Так же это относится ко всем дровам, часть закрытых большая. |
| Автор: lukas 28.6.2008, 09:29 |
| для меня единственный язык низкого уровня это ASM и все его похожие реализации... компилируемые языки, которые переводят свою запись на язык ASM являются языком высокого уровня, другие же языки, которые исполняются, переводятся в байт код - скриптовые языки... ненужно тут причеслять что кто-то решил что работа с памятью делает язык низким по уровню... Если в языке превосходят конструкции высокой абстракции... то и считать этот язык нужно как высокого уровня... а то что в нем присутствуют средства, конструкции низкой абстракции... не делает его низкоуровневым языком. |
| Автор: nerezus 28.6.2008, 12:26 | ||
P.S. Слово абстракция тут лишнее для низкоуровневых ЯП. |
| Автор: Lazin 28.6.2008, 12:28 | ||||
Язык программирования Высокого уровня - это язык предназначенный для легкого понимания человеком, для того, что-бы программы можно было писать быстро. Разницу почувствовать достаточно легко, к примеру, написав программу на питоне или руби, а потом на Си В общем, ЯП высокого уровня, это язык, который позволяет ничего не знать о железе, работе с памятью и тд... а позволяет просто описывать то, как программа должна работать... правда работать она будет как правило не так быстро)) |
| Автор: Mayk 28.6.2008, 12:54 |
| АААААа! Холивар перерастает в "WTF из высокоуровневый язык программирования". >ПАНИКА< ЗЫ. Поставил теги PG-13 и NC-17 (это мол "кино детям не смотреть") запасся попкорном в ожидании феерии. |
| Автор: MAKCim 28.6.2008, 13:52 |
| господа, посмотрите в википедии насчет высокоуровневости, чтобы зря не холиварить |
| Автор: Lazin 28.6.2008, 14:04 | ||
половине форума вход заказан |
| Автор: MAKCim 28.6.2008, 14:10 | ||
в С понятия "указатель" и "память" абстрактны в том плане, что нет необходимости задумываться об ее (памяти) организации и о доступе (через указатели) к ней мы не задумываемся о селекторах, дескрипторах, сегментах, лимитах, не вычисляем эффективные адреса, не учитываем разрядность адресов... точно так же С и "железо" не связаны друг с другом ЯВУ - набор семантических и синтаксических правил описания действий, которые могут быть преобразованы в набор конструкций целевой системы в этом плане даже MSIL и байт-код Java (в случае, если он не выполняется напрямую) являются ЯВУ |
| Автор: lukas 28.6.2008, 15:25 | ||
http://ru.wikipedia.org/wiki/Высокоуровневый_язык_программирования
В теме не написано что мы обсуждаем именно С++, а не си... P.S. Философы хр-вы... Добавлено через 3 минуты и 56 секунд MAKCim, послушался вашего совета... спасибо... |
| Автор: Lazin 28.6.2008, 16:36 | ||
Свое мнение иногда полезно иметь ну и фиг с ней, с викой, все равно не понимаю, как можно сравнивать Smalltalk и Pascal =) |
| Автор: lukas 28.6.2008, 17:32 | ||
Блин, щас покапался в документации по ООП в PHP 5 ... и понял что интегрировать VCL туда будет проще простого, написав для этого несколько функций... и НАПисав несколько модулей для классов на ПХп... и все будет в ажуре... ХЫ.... щас даже умудрился сделать что-то на подобии несуществующих свойств у объектов, как в Java... круто смотрится...
|
| Автор: MAKCim 28.6.2008, 17:46 | ||
перечитай тему |
| Автор: lukas 28.6.2008, 18:43 |
| MAKCim, в заголовке... ??? |
| Автор: nerezus 29.6.2008, 17:41 | ||
|
| Автор: lukas 29.6.2008, 18:14 |
| nerezus, я уж забыл о чем спор был.... ... в самом начале... |
| Автор: MAKCim 29.6.2008, 18:31 | ||
так и есть покажи другие определения |
| Автор: Lazin 29.6.2008, 18:49 | ||
http://www.rugost.com/index.php?option=com_content&task=view&id=47&Itemid=50, пожалуйста...
Добавлено через 1 минуту и 35 секунд "удобны для восприятия человеком", у всех вызывает разные ассоциации |
| Автор: MAKCim 29.6.2008, 20:07 | ||
точно поэтому не может быть определением определение однозначно |
| Автор: nerezus 29.6.2008, 22:39 | ||
|
| Автор: MAKCim 30.6.2008, 00:03 | ||||
это? new связан с алгоритмом? тогда чем malloc() хуже? |
| Автор: nerezus 30.6.2008, 11:10 | ||
А в маллок приходится рассчитывать размер выделяемой памяти. Более того - с этой памятью нельзя удобно работать: переназначив объект по нему старый не уничтожается(если специально его не удалять), хоть и не используется в дальнейшем, и будет жрать память. Т.е. приходится выполнять работу, которые могла бы сделать VM/компилер. Где встречал определнеие? Вроде в сборнике статей Спольски и в одной *нормальной* книге по пхп(таких ОЧЕНЬ мало, многие авторы не знают предмет, например те же Михаил Фленов(этот вообще *удак, любой новичок за неделю изучения знал больше, чем он на момент написания книги. У меня ее друг кстати сжигал, там дезинформации 99.(9)%), Либо всяких Лаур Томпсонов и Люков Веллингов, которые работая в MySQL не знают, как работать с СУБД). |
| Автор: MAKCim 30.6.2008, 11:25 | ||||
sizeof() отменили?
а должен? это есть критерий высокоуровневости? |
| Автор: Lazin 30.6.2008, 12:08 | ||
тогда еще нужно будет вызывать функцию, которая инициализирует выделенную память, так как в Си нет конструкторов ;) |
| Автор: MAKCim 30.6.2008, 12:34 | ||
да причем здесь конструкторы вообще? мы говорим о высокоуровневости С, а не о С как замене С++ |
| Автор: Lazin 30.6.2008, 13:32 | ||
это к тому, что связан |
| Автор: lukas 30.6.2008, 17:49 |
| достаточно сравнить конструкции в ASM с Си, сразу станет ясно где высокоуровневый язык... а где низкоуровневый... |
| Автор: Lazin 30.6.2008, 18:33 |
| достаточно сравнить конструкции в Си с Haskel (Prolog, Erlang, Ruby, Smalltalk, Python, Tcl) что-бы перестать судить так категорично наверное имеет смысл говорить, что один язык более высокоуровневый, более абстрактный чем другой, то есть все относительно |
| Автор: nerezus 30.6.2008, 22:42 | ||
Как по мне - так асм гораздо ближе к C, чем C к питону. |
| Автор: lukas 1.7.2008, 10:29 |
| ну по логике я бы разделил языки на 3 типа.. - низкоуровневые - высокоуровневые - скриптовые (которые выполняются, python выполняется) Вообщем это филосовский вопрос, и нет никаких правил определения высокоуровневости языка... |
| Автор: Lazin 1.7.2008, 11:51 |
| вот интересная статья на тему: http://home.pacbell.net/ouster/scripting.html тут все ЯП делятся на "системные" и "скриптовые"... да и в целом статья интересная. |
| Автор: nerezus 2.7.2008, 13:22 |
| lukas, интересно-интересно, джава системный язык? ) |
| Автор: lukas 2.7.2008, 17:48 |
| nerezus, причем тут это??? практически для многих интерпритируемых языков существуют компиляторы в машинный код... компиляторы в байт код, в .NET и т.д.... |
| Автор: baldina 2.7.2008, 19:48 |
| С, Prolog, Smalltalk - это поддержка совершенно разных парадигм программирования. Какой смысл сравнивать яблоки с картофелем? Pascal vs C++ имхо бессмысленно. Pascal vs C - понимаю, Object Pascal (или тогда уж Modula-3) vs C++ тоже понимаю. а так и получили ... посты со сравнениями с асмом Добавлено через 1 минуту и 54 секунды а уж интерпретируется или компилируется это совсем другая классификация. можно интерпретировать С. Можно компилировать Васик. Это не свойства языка, а способ реализации и т.д. Добавлено через 3 минуты и 56 секунд Lazin, я с тобой категорически согласен Но мне кажется стоит говорить не об уровне языка как таковом, ибо он только средство, а о том, какие этот уровень приносит преимущества и недостатки при использовании языка. |
| Автор: lukas 2.7.2008, 20:13 |
| мне кажется тему надо закрыть... ибо спорить уже не о чем... |
| Автор: Lazin 2.7.2008, 20:31 |
| надо подумать о чем поспорить... |
| Автор: baldina 2.7.2008, 23:03 |
| надо поспорить о чем подумать о чем поспорить |
| Автор: Любитель 3.7.2008, 10:08 |
| Прежде чем об этом спорить - надо хорошо подумать! |
