Кто-нибудь может посоветовать хорошую библиотеку регулярных выражений для C++. Требования (желательно, но, в принципе, не обязательно):
Погуглил - нашел кучу самых разных библиотечек. Выбирать наугад не хочется, так что прошу совета у C++’ников.
… статья под названием “За что я не люблю С++“. Лично мне как человеку знающему язык C++ достаточно хорошо статья очень понравилась и я практически во всем согласен с её автором. C++ действительно очень сложный язык, который к тому же является очень негибким на этапе выполнения (да, да, скорость работы, я понимаю…), и имеющий просто потрясающе огромное количество мелких ловушек, при встрече с которыми можно стать в ступор на долгое время.
PS. Линк на статью нашел у Bolk’а.
PPS. А есть ли аналоги C++, кроме D? Я имею ввиду, которые бы компилировались в нативный код и были такими же эффективными (или хотя бы похожими по эффективности).
Вообще крышу срывает эта учеба…
Делал лабу по C++. Имеем классы:
enum AttributeType {BOOL, INT, DOUBLE, STRING};
class Attribute;
class BoolAttribute;
class IntAttribute;
class DoubleAttribute;
class StringAttribute;Зачем - не спрашивайте. Кривовато (из-за AttributeType), но на С++ по другому не получалось.
Неделю назад час ебался мучался вопросом, какого хера почему это у меня каст из BoolAttribute* в Attribute* делал хер знает непонятно что, но только не то, что нужно… В итоге забил… Сейчас сел доделывать лабу… На 2-й минуте меня осенило - забыл прописать наследование… Пипееец. Нужно было так:
enum AttributeType {BOOL, INT, DOUBLE, STRING};
class Attribute;
class BoolAttribute : public Attribute;
class IntAttribute : public Attribute;
class DoubleAttribute : public Attribute;
class StringAttribute : public Attribute;Я с себя потихоньку шизею…
Что-то я затянул немного выполнение лабораторных работ некоторых по универу, нужно исправляться. Сегодня решил вернуться ко второй лабе по ООП. Задание таково:
“Разработать объектно-ориентированную библиотеку для работы со структурами данных по одной из нижеперечисленных тем в соответствии с нижеуказанными требованиями. Свойства и методы для классов разработать в соответствии с известными определениями соответствующих структур данных. Составить тесты для проверки работоспособности библиотеки. Составить программу, демонстрирующую возможности разработанной библиотеки.”
Требования - хрен с ними, а вот тема мне попалась интересная: “Сетевые базы данных (ввод/вывод, навигация)”. Когда я это задание читал в первый раз - я впал в ступор. Потом оклемался, но когда видишь такое задание как-то не по себе становится…
Сетевая бд - это бд, в которой для связи записей используются графы (граф, по курсу структур данных, - это сеть). Т.е. здесь, в отличии от иерархических бд, связи получаются “много к многим” (а там - “один ко многим”).
Поговорил немного с преподами о задании, итог получился такой - “нам не нужна универсальная бд, сделай несколько таблиц статических и связывай их”. Говорил действительно немного - минуты полторы, так что кроме фразы выше я ничего особо не услышал. Сегодня решил хоть чего-нибудь напроектировать, чтобы в пятницу показать преподам и убедится, правильно ли я делаю, или нет. Мысля сейчас такая: есть отдельные таблицы (неважно, как представленные) и есть какой-нибудь класс Relation, который их связывает. Собственно, это очень напоминает обычную иерархическую бд (таблица - связующая таблица - таблица), но как это оформлять по другому я пока что не представляю.
Сел за комп, закодил… Получилось такая фигня:
class Masseur : public Record {
public:
Masseur();
virtual ~Masseur();
private:
char* _name;
char* _surname;
char* _fathername;
char* _qualification;
Date _birthday;
};
class Service : public Record {
public:
Service();
virtual ~Service();
private:
char* _name;
char* _part;
int _duration;
double _price;
};
class MasseurServiceRelation : public Relation {
public:
MasseurServiceRelation();
virtual ~MasseurServiceRelation();
private:
void add(Masseur*, Service*);
void remove(Masseur*, Service*);
void remove(Service* service);
void remove(Masseur* masseur);
};Сейчас сижу и думаю, правильным ли путем я иду…
PS. А первые две таблицы очень напоминают паттерн ActiveRecord, на правда ли? :)
В свое время выбирал IDE для работы с C++, посоветовали попробовать Code::Blocks. Попробовал, понравилось. Симпатичная IDE, хороший автокомплит, неплохая настраиваемость, поддержка gcc - а мне другого и не нужно было. После того, как я заинтересовался Qt, я стал искать плагины для поддержки этой библиотеки к Code::Blocks. Нашел QtWorkbench. Вот только плагин к линукс-версии можно подключить, только заново скомпилировав саму программу. Чем я раньше и занимался - ведь вот есть хорошая инструкция. Вчера заметил странную директорию debian, которая находится в Code::Blocks’овом trunk’е. Там есть файлик rules, после его просмотра стало ясно, что здесь все уже сделано для построения пакетов для Debian-based дистрибутивов линукса. И вот решил я ночью пакет сделать, со встроенным QtWorkbench’ем.
Для конфигурирования и сборки пакетов:
sudo apt-get install libtool autoconf automake dh-makeЕсли у вас не Ubuntu/Gutsy - следуем этим инструкциям и добавляем в apt нужный репозиторий. Устанавливаем wxwidgets и g++:
sudo apt-get install g++ wx-common libwxgtk2.8-devТакже мне в Kubuntu пришлось установить libgtk:
sudo apt-get install libgtk2.0-devДалее - следуем начальным инструкциям отсюда:
svn checkout svn://svn.berlios.de/codeblocks/trunk codeblocks
cd codeblocks/
wget http://qtworkbench.googlecode.com/files/QtWorkbench-src-0.5.1.tar.gz
tar zxf QtWorkbench-src-0.5.1.tar.gz
patch --unified --strip=0 --forward --input=qtworkbench.patch
./bootstrapКонфигурируем для установки всех плагинов и указываем, что ставить нужно в /usr:
./configure --prefix=/usr --with-contrib-plugins=allТеперь нужно указать, что мы хотим включить в пакеты и QtWorkbench (если этого не сделать - dh-make выдаст после линкования и компиляции всех файлов, что у вас есть лишние файлы и откажется создавать пакет):
sudo nano debian/codeblocks-contrib.installИ добавляем в конец файла эти строчки:
usr/share/codeblocks/QtWorkbench.zip*
usr/share/codeblocks/plugins/libQtWorkbench.*Сохраняем файл и начинаем делать пакеты (у меня компилировалось и линковалось долго, больше получаса, так что будьте терпеливы):
sudo ./debian/rules binary-archНа выходе получаем 7 пакетов и ставим Code::Blocks:
cd ..
sudo dpkg -i libcodeblocks0_1.0svn4561_i386.deb libwxsmithlib0_1.0svn4561_i386.deb codeblocks_1.0svn4561_i386.deb codeblocks-contrib_1.0svn4561_i386.debЯ использовал svn4561-ревизию, так что у вас номер в deb-файлах скорее всего будет другой. Учитывайте это.
Собранные мной пакеты лежат здесь (ubuntu 7.10) и здесь (debian unstable).
Начнем издалека… Есть в C++ встроенный тип size_t, который является “целым типом без знака, используемым реализацией для индексирования массивов” © Страуструп. То есть, если вы работаете с индексами в массивах и их длинами, то в общем-то “правильнее” использовать не int, что в большинстве случаев и делается, а именно size_t (для длин можно еще использовать ptrdiff_t - тип, который возвращает операция вычитания двух указателей). Вчера эта “правильность” для меня вышла боком…
size_t length;
...
for(size_t i = 0; i < length; ++i) {
double x = 2 * (i - length / 2) / length;
...
}Вот такой был изначальный код. Через несколько минут после написания я вспомнил, что неплохо бы сделать так:
size_t length;
...
for(size_t i = 0; i < length; ++i) {
double x = 2 * static_cast<double>(i - length / 2) / length;
...
}потому что при делении двух целых чисел у нас тоже целое будет, а мне нужно было как раз вещественное.
Но это еще ладно. После этого я отдал свой кусок лабораторной (мы ее пишем парами) своей девушке (а я как раз с ней пишу). Когда она добралась до этого кода и стала тестить его - у нее стали получаться какие-то странные, неправильные числа. Долгое время я копался в коде и не мог понять, в чем проблема, а потом до меня наконец-то дошло - разность двух беззнаковых чисел также будет беззнаковая (т.е. число -1 будет на самом деле 0xFFFFFFFF), после чего код превратился в такой:
size_t length;
...
for(size_t i = 0; i < length; ++i) {
double x = 2 * static_cast<double>(static_cast<int>(i) - static_cast<int>(length) / 2) / length;
...
}После чего я на всякий случай еще полчаса проверял небольшую программу на вот такие ошибки - на всякий случай. К счастью, таких больше не нашлось, но неприятный осадок остался.
Выводы: или пишите не особо заморачиваясь на правильности употребления типов (везде используйте int и double, например), или пишите семантически правильно, но не делайте таких ошибок, как я… Может, конечно, это только я такой, но мне лично сложно было именно по коду определить, что результат будет получаться не такой как я хочу.
PS. Я теперь немного понимаю, почему в Java нет unsigned типов. :)
Не могу не отметить статью из октябрьского номера MSDN Magazine про “Оптимизацию управляемого кода для многоядерных компьютеров”. В статье рассказывается о библиотеке TPL, которая позволяет использовать все преимущества многоядерности практически без изменений исходных кодов (по сравнению с переписыванием кода с использованием Thread’ов - здесь изменения в коде потребуются лишь чисто косметические).
На мой взгляд, готовится бомба, так как использование фич многоядерных процессоров становится до неприличия простым. Статья очень интересна как в теоретическом, так и в практическом плане. Так что советую ее почитать всем программистам, даже тем, кто с C# не знаком - ведь возможно, в ближайшем будущем именно такой подход и будет использоваться.
PS. В “более далеком” будущем, как мне кажется, эта библиотека перекочует в компилятор, который сам будет решать - нужно ли распараллеливать текущий код или нет.
PPS. Интересно, уйдут ли Thread’ы в небытие? :)
Достаточно интересный факт - MS открывает исходники многих библиотек .NET фреймворка, в частности .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). В дальнейшем планируется открытие и остальных библиотек.
В чем основные плюсы этого решения для .NET-программистов:
Теперь о подводных камнях - код открыт по лицензии Microsoft Reference License (MS-RL), которая подразумевает возможность только просмотра кода, перекомпиляция или изменение этих кодов по лицензии строго-настрого запрещены. То есть на развитие того же Mono Project это решение фирмы MS никак не повлияет, а жаль - очень бы хотелось, чтобы Mono был реальным аналогом того .NET’а, которым нас балует MS.
И вдогонку - на днях наткнулся на очень хорошую статью по нововведениям в C# 3.0, которая меня очень порадовала - в отличии от Java, C# не стоит на месте, а развивается. В Java в основном меняется библиотека стандартная, в случае же C# + .NET Framework меняются обе составляющие: язык становится более удобным (как по мне - гораздо более удобным, мне Linq ну просто очень понравился), а .NET Framework обрастает новыми функциями.
khim
Ruby, Python, PHP - хороши для прототипирования (где главное преимущество, отсутствуюшее в C++ - это возможность запустить новую версию без перекомпиляции), а если нужно делать что-то реально большое - то тут их достоинства резко превращаются в недостатки (если количество исходников в системе меряется миллионами строк, то отлавливание проблем на этапе компиляции куда полезнее возможности гибко манипулировать строением программы “в полёте”).FX Poster
По порядку:
- ООП в PHP нормальный - прям как в Java. Для динамического языка он, ИМХО, не сильно подходит.
- В Python/Ruby нормально юзаются private/public. Проблем с “гарантиями” не замечено.
- Да, конечно. На Rails/Django/Zope пишут только проекты для себя. :)
- Если вы пишите на C++/Java, то почему так защищаете PHP. Поверьте, его есть кому защищать - на нем ишут намного больше людей, чем на Python + Ruby.
- Ruby, Python, и в том числе PHP - хороши для тех ситуаций, когда ОГРОМНАЯ производительность не нужна и вполне достаточна производительность в 5-10 (может больше) меньшая, чем в C++.
- Большая часть проблем обнаруживается как раз на этапе выполнения.
PS. А что делать в C++ с ошибками в template’ах? ;)
meniam
По поводу PS, а шаблоны разве обязательно компилить ? ;)FX Poster
Похоже, что такое C++ Templates вы не знаете.meniam
Если честно - нет, не сталкивался.
Но грызет меня сомнение, что все-таки MVC в какой то степени присутствует. Парсинг файла (по аналогии как Smarty в php) - задача все таки выполнимая.
Может я чего-то и не понимаю, но как может программист пытаться меня подкалывать, даже не погуглив относительно темы разговора?!?!?!
Видать высказывание о том, что на PHP пишут все, даже домохозяйки - правда. Они почитали какие-то статейки по PHP, повыучивали модные аббревиатуры типа MVC и вперед, спорить с другими, нифига не шарящими “программистами”!
PS. Может я переборщил, но меня этот разговор взбесил…
Какие языки сейчас используются в веб-программировании? Навскидку я могу составить такой список: C#, Java EE, Python, Ruby, PHP, Perl. JavaScript брать в расчет не буду - сейчас я хочу поговорить именно о server-side языках.
C# - первая версия этого языка появилась в 2000 году, для веба стал использоваться с приходом ASP.NET, который вышел в 2002м году.
Java EE - первая версия, которая называлась J2EE и имела версию 1.2, вышла в далеком1991м году. Следующая версия 1.3 была выпущена аж через 11 лет. Сейчас новые версии выпускаются гораздо чаще. Используется в основном для разработки веб-сервисов. По крайней мере я не встречал мелкие или небольшие компании, которые писали бы “просто сайты” на Java EE.
Python - на самом деле достаточно древний язык. Первая версия языка была выпущена в 1990м году. Когда его начали достаточно сильно использовать в веб-приложениях сказать трудно. Можно считать, что в интернет он вошел с появлением таких легких и быстрых фреймворков, как Django/Turbogears и т.д. В таком случае получается что в инете он с 2004-2005-го года. На самом деле все было несколько раньше, но приход в интернет в то время был не совсем очевиден. Фреймворк Zope, который был изначально нацелен на интернет, был выпущен в 1995-1997 годах. Точнее на данный момент сказать не могу. Но еще раз повторюсь - это не было массовым явлением.
Ruby - разработан в 1995м году. В интернете стал использоваться с появлением, ясное дело, Ruby On Rails, который вышел в 2004-м году.
PHP - эдакий старичок программирования сайтов. Первая версия, которая называлась PHP/FI вышла в 1994м. А тот PHP, который мы знаем появился в 1997м году с выходом PHP3 и именно с этого момента он начал набирать популярность как язык для веб-разработки.
Perl - вышел в 1987м году, а вот когда появился в вебе - для меня остается тайной. Я этот язык особо никогда не любил и уж тем более никогда не использовал. Пользуются ли им еще в вебе - пользуются, но, как мне кажется, популярность этого языка неуклонно падает.
Теперь, собственно, к чему я вел это все. Выводы по Perl’у я делать не могу, а вот по всем остальным языкам получается интересная картина. C#/Python/Ruby - заявили массово о себе совсем недавно, причем их массовое распространение связанно с написанными для них фреймворками (ASP.NET/Django и компания/ROR). Java - в вебе используется только Java EE, и, хоть и появилась она давно, сейчас явно не собирается скидывать обороты. PHP - язычок, который пришел в веб сам, для которого до недавнего времени и фреймворков то не было, а те что были - их не использовали.
Я веду к тому, что все современные языки в вебе используют фреймворки, причем используют чуть ли не в обязательном порядке (да, вы можете на руби писать веб приложение, не используя рельсы, но никто этого при здравом уме делать не будет). А вот писать приложение на PHP не используя никаких уже созданных компонент - вполне обычное дело. И народ наоборот не хочет использовать фреймворки аргументируя это тем, что они “слишком сложные”, “тормозные” и т.д. И очень большая часть сайтов делается потом непонятно как… посмотришь код - убиться хочется. такое впечатление, что фраза “PHP портит нормальных программистов” - это не бред, а самая настоящая реальность.
В итоге (все ИМХО):
Из PHP Framework’ов я бы посоветовал выбрать Zend Framework, как наиболее конфигурируемый и обьектно-ориентированный. Для себя я выбрал именно его. Но в нем есть одно “но” - если вы в качестве wrapper’а для DB собираетесь использовать зендовские классы - вам возможно прийдется сменить хостера, так как нужна будет поддержка PDO/PDO_MySQL/PDO_PgSQL, которая, как мне кажется, не у всех хостеров есть.
PS. Лично мне сейчас нравится:
PPS. Пару часов назад гуглил украинских хостеров. Завтра буду узнавать - есть ли у них поддержка PHP >= 5.1.3 и PDO_MySQL (требования к Zend Framework’у). Посмотрим, какие результаты это даст. Кто знает хороших укр. хостеров - отписывайтесь, составлю табличку - кто и что поддерживает.
None
php|architect’s Guide to PHP Security by Ilia Alshanetsky
Последние комментарии