языки программирования

[nightmare2]

Порог вхождения = сложный язык. Если вошел, то "запутанный" синтаксис не должен быть проблемой.

Для запутаного синтаксиса нужно тратить больше тактов мозга на чтение чужого кода?

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

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

[nightmare2]

Реальная проблема C++ в том, что он слишком низкоуровневый с запутанным синтаксисом.

А по мне так главная проблема - последствия низкоуровневости, когда базовые вещи (управление памятью например) можно сделать 1024 разными способами.
Это создаёт сложности в интеграции.
Например - решили использовать DOM в проекте.
В Java: Погуглил "Java DOM Implementation", пошарил в JavaDoc, выбрал что удобнее (Dom4j, JDom, etc.) включил jar - поехали.
В C++: погуглил, вроде что-то нашёл, да принципы управления памятью несовместимы с остальным проектом. Пишем адаптер. Потом отлаживаем его, особенно в многопоточной среде. Потом оказывается что этот доморощенный адаптер не работает в определённых условиях... А так хотелось просто использовать DOM, а не рефлексировать...
При этом в Java есть куча стандартизированных de jure или de facto интерфейсов, в которых реализации можно подменять не затрагивая кода.

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

[Palych]

Порог вхождения = сложный язык. Если вошел, то "запутанный" синтаксис не должен быть проблемой.

Для запутаного синтаксиса нужно тратить больше тактов мозга на чтение чужого кода?

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

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

Кроме читаемости важно ещё насколько терпима система к говнокоду на этапе исполнения.

[oshibka_residenta]

Амазон и ибей как раз начинались на другихплатформах, perl, c++, asp а потом уже переползли на джаву.

Ну замечательно. Когда им надо было развивать, писали значит на Perl и C++. А когда рынок завоевали, и умные люди ушли, стали тупых на Жабу сажать.

Да нет, не когда завоевали рынок. Просто раньше, когда на C++ все было написано, eBay сервера приходилось перегружать примерно раз в день. Я понимаю, что C++ прекрасен, это просто программисты не умеют код без утечек памяти писать. Но бизнесу других найти не получается. Все умные-то сидят на Привете.

[Medium-rare]

Да нет, не когда завоевали рынок. Просто раньше, когда на C++ все было написано, eBay сервера приходилось перегружать примерно раз в день. Я понимаю, что C++ прекрасен, это просто программисты не умеют код без утечек памяти писать. Но бизнесу других найти не получается. Все умные-то сидят на Привете.

Проблема в открытых new и delete сейчас для тех, кто не хочет ничего знать о развитии языка. Теперь не только в Boost, а стандартизовано: http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 С unique_ptr и подкола нет никакого, и его можно использовать в 95%. Только с shared_ptr / weak_ptr, там, да. Процедура код-ревью на то.

[oshibka_residenta]

Да нет, не когда завоевали рынок. Просто раньше, когда на C++ все было написано, eBay сервера приходилось перегружать примерно раз в день. Я понимаю, что C++ прекрасен, это просто программисты не умеют код без утечек памяти писать. Но бизнесу других найти не получается. Все умные-то сидят на Привете.

Проблема в открытых new и delete сейчас для тех, кто не хочет ничего знать о развитии языка. Теперь не только в Boost, а стандартизовано: http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 С unique_ptr и подкола нет никакого, и его можно использовать в 95%. Только с shared_ptr / weak_ptr, там, да. Процедура код-ревью на то.

Видимо eBay почему-то не мог 10 лет ждать этой красоты. Кстати, как насчет компиляторов. Уже все поддержано? Похоже, что нет. Ну ничего, лет через 10 это будет по-настоящему прекрасный язык.

[crypto5]

Да нет, не когда завоевали рынок. Просто раньше, когда на C++ все было написано, eBay сервера приходилось перегружать примерно раз в день. Я понимаю, что C++ прекрасен, это просто программисты не умеют код без утечек памяти писать. Но бизнесу других найти не получается. Все умные-то сидят на Привете.

Проблема в открытых new и delete сейчас для тех, кто не хочет ничего знать о развитии языка. Теперь не только в Boost, а стандартизовано: http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 С unique_ptr и подкола нет никакого, и его можно использовать в 95%. Только с shared_ptr / weak_ptr, там, да. Процедура код-ревью на то.

А как unique ptr может покрывать 95% кейсов если вроде как он позволяет иметь только одну ссылку на участок памяти?

[crypto5]

Амазон и ибей как раз начинались на другихплатформах, perl, c++, asp а потом уже переползли на джаву.

Ну замечательно. Когда им надо было развивать, писали значит на Perl и C++. А когда рынок завоевали, и умные люди ушли, стали тупых на Жабу сажать.

Да нет, не когда завоевали рынок. Просто раньше, когда на C++ все было написано, eBay сервера приходилось перегружать примерно раз в день. Я понимаю, что C++ прекрасен, это просто программисты не умеют код без утечек памяти писать. Но бизнесу других найти не получается. Все умные-то сидят на Привете.

Я уже написал выше чего не хватает с++ фреймворкам для того что бы догнать джава фреймворки которые тоже усиленно развиваются: http://forum.privet.com/viewtopic.php?f ... 5#p5296872 Без этого с++ джаве для ebay-e подобных сервисов не конкурент.

[Medium-rare]

А как unique ptr может покрывать 95% кейсов если вроде как он позволяет иметь только одну ссылку на участок памяти?

std::vector< std::unique_ptr<MyType> > myVector; // правда тут надо слегка вникнуть в move semantics и как это работает с unique_ptr

[Medium-rare]

Видимо eBay почему-то не мог 10 лет ждать этой красоты. Кстати, как насчет компиляторов. Уже все поддержано? Похоже, что нет. Ну ничего, лет через 10 это будет по-настоящему прекрасный язык.

И в GCC и MS VC++ смартпойнтеры по стандарту 11 поддерживают. По остальным фичам GCC уже почти всё покрыли, MS VC++ только что выпустил новый релиз компайлера, где тоже почти всё, с совсем небольшим отставанием от GCC, но с лучшей имплементацией смарт-пойнтеров, как говорят.

[crypto5]

А как unique ptr может покрывать 95% кейсов если вроде как он позволяет иметь только одну ссылку на участок памяти?

std::vector< std::unique_ptr<MyType> > myVector; // правда тут надо слегка вникнуть в move semantics и как это работает с unique_ptr

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

[crypto5]

Видимо eBay почему-то не мог 10 лет ждать этой красоты. Кстати, как насчет компиляторов. Уже все поддержано? Похоже, что нет. Ну ничего, лет через 10 это будет по-настоящему прекрасный язык.

И в GCC и MS VC++ смартпойнтеры по стандарту 11 поддерживают.

Где то видел бенчмарк, так там auto & smart pointers сливают сильно по производительности даже ocaml инкрементальному GC(в джава думаю GC значительно быстрее), смысл тогда юзать с++ если операции с памятью превращаются в тормоза?

[Medium-rare]

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

Нам надо перемещать контент, не так ли? Для того move semantics, новый тип конструктора, и немножко модифицировать MyType из std::vector< std::unique_ptr<MyType> >. А для std::list, по идее, можно даже не заморачиваться. Просто классики теперь настойчиво рекомендуют vector для большей performance.

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

[crypto5]

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

Нам надо перемещать контент, не так ли? Для того move semantics, новый тип конструктора, и немножко модифицировать MyType из std::vector< std::unique_ptr<MyType> >. А для std::list, по идее, можно даже не заморачиваться. Просто классики теперь настойчиво рекомендуют vector для большей performance.

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

Да, код обычно проясняет все абстрактные ворпосы.

[Medium-rare]

Где то видел бенчмарк, так там auto & smart pointers сливают сильно по производительности даже ocaml инкрементальному GC(в джава думаю GC значительно быстрее), смысл тогда юзать с++ если операции с памятью превращаются в тормоза?

Вы правы, особенно reference count, shared_ptr, который по идее, надо юзать лишь в интерфейсной части между библиотеками. Хорошо спроектированная библиотека не должна содержать по возможности shared_ptr у себя внутри. Это чей-то guideline, так скажем.

А про unique_ptr, там по ссылке из журнала Dobbs. Выложили ассемблер, и сколько добавилось за счёт unique_ptr, о том речь.

P.S. Вот это, что для тех, что для других смарт-пойнтеров, несколько лучше у студийного компайлера и сделали, только что

[Medium-rare]

Да, код обычно проясняет все абстрактные ворпосы.

С пару месяцев назад пробовал, всё что мог, в новом C++ 11. Это header для некоего подобия cron. Action есть назначается ScheduleItem, который хранится по значению в векторе, но при копировании ScheduleItem, Action перемещается. A bit complicated, но вот хотелось подменять Action "на лету". В приниципе можно было организовать вместо std::vector<ScheduleItem> m_vctSchedule; какой-то std::vector< unique_ptr<ScheduleItem> > m_vctSchedule; Ну или take care of Action while copying ScheduleItem, который имеет unique_ptr<Action>.

Code: Select all

#include <string>
#include <atomic>
#include <mutex>
#include <vector>
#include <ctime>
#include <chrono>
#include <memory>
#include <future>
#include <functional>
#include <condition_variable>


namespace cpp11_fubar
{

class SchedulerControlInterface
{
public:
	virtual void stop() = 0;
	// virtual void notify_complete() = 0;
};

struct Result
{
	typedef enum
	{
		WaitingOnStart,
		Started,
		FinishedOk,
		Terminated,
		FailedToStart
	}
	completionCode;

	Result(completionCode code = WaitingOnStart) : m_completionCode(code) {}
	const completionCode getCompletion() {return m_completionCode;}
	const std::string getInfo() {return m_info;}
	completionCode m_completionCode;
	std::string m_info;
};

typedef SchedulerControlInterface* SI;

class Action
{
public:
	Action(const std::string& info, std::function<void (SI)> function) :
		m_info(info), m_function(function) {}

	std::function<void (SI)> m_function;
	const Result& getResult() {return m_result;}

	void setResultCode(Result::completionCode code) {m_result.m_completionCode = code;}
	void setResultInfo(const std::string& info) {m_result.m_info = info;}

	std::string getResultInfo() {return m_info;};
protected:
	Result m_result;
	std::string m_info;
};

class ScheduleItem
{
public:
	ScheduleItem(std::chrono::time_point<std::chrono::system_clock> pt, Action* action) :
		m_point_in_time(pt), m_action(action) {}

	std::chrono::time_point<std::chrono::system_clock> m_point_in_time;
    std::unique_ptr<Action> m_action;

	// move constructor
	ScheduleItem(ScheduleItem&& item) {operator=(item);}

	// copy constructor does 'move' too
	ScheduleItem(const ScheduleItem& item) {operator=(const_cast<ScheduleItem&>(item));}

	// copy operator (acts as move for unique_ptr)
	ScheduleItem& operator=(ScheduleItem& item)
	{
		// dealing with move for unique_ptr
		m_action = std::move(item.m_action);
		m_point_in_time = item.m_point_in_time;
		return *this;
	}
};

class Scheduler : public SchedulerControlInterface
{
public:
    Scheduler();
    virtual ~Scheduler();

    std::future<Result> start();
    void stop();

	void consumeSchedule(std::vector<ScheduleItem>&);
    void consumeSchedule(const std::string& xmlStr);

    void tick();

private:
    std::atomic<bool> m_bContinue;
    std::mutex  m_mtx;
    std::condition_variable m_FinishCondVar;

    std::vector<ScheduleItem> m_vctSchedule;

    Result loopThruTimes();
};

}

[M. Ridcully]

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

С этим я скорее соглашусь.

Всё замечательно, гогда все в команде придерживаются одного стиля и пишут на хорошем C++. Но редко какая программа живёт в вакууме, и вот при взаимодействии со всякими 3rd-parties цирк и начинается. Чувствуешь себя полным идиотом, когда приходится в XXI веке писать, к примеру, код по конвертации строк из одного дебильного формата в другой (разумеется, кадый из разработчиков этих библиотек считал, что его строки самые строчные строки в мире).

По поводу умных указателей - на одной работе, помнится, моей первой задачей было утечку найти. Оказалось, что кто-то чуток не так использовал CComBSTR (это smart pointer для строк в COMе, кто не в курсе). Так что smart pointers тоже не панацея, если не уметь ими пользоваться.

Справедливости ради, у нас сейчас веб-погромисты по полной огребают проблемы с памятью с garbage collected JavaScript & ActionScript. Причём на такие танцы с бубном им приходится идти, от которых у непосвящённых (вроде меня) волосы дыбом встают и сложности речного управления памятью с malloc/free кажутся игрой в кубики для трёхлеток. Так что думать всегда надо.

Кстати, не понял, как это smart pointers могут быть настолько медленными, что их с GC сравниваете тут? Даже самому захотелось померять...

[Интеррапт]

Кстати, не понял, как это smart pointers могут быть настолько медленными, что их с GC сравниваете тут? Даже самому захотелось померять...

По массе причин. Например, reference counting - это довольно дорогостоящая операция (особенно с синхронизацией). GC может удалить сразу много обьектов, а это как правило более эффективно, чем когда много мелких обьектов удаляются один за другим по ходу выполнения кода (как в случае со смарт поинтерами). И еще всякие аспекты.

[Мальчик-Одуванчик]

Кстати, не понял, как это smart pointers могут быть настолько медленными, что их с GC сравниваете тут? Даже самому захотелось померять...

Управление памятью штатными средствами С++ достаточно нееффективно.
Собственно умные указатели с семантикой переноса а так же R-value reference и есть один из способов оптимизации в этом направлении.

[Medium-rare]

std::shared_ptr, с его подсчётом ссылок, как и его шестёрочный тип std::weak_ptr вовсе не должны быть часто используемы. Только для интерфейсного кода. Вот std::unique_ptr и есть star of the show, оборачивайте в него всё, что динамически выделяется. И будет вам щастье и быстрый безопасный код.