Qt как расширение C++

>самая ужасная у STL

У Джосьютиса прекрасная книжка по STL - чем не документация, а?

>Моё мнение - без Qt кодить на C++ не то чтобы не реально, это как сейчас сидеть под никсами юзая только links и vi.

Зато программировать на С++ без Qt можно и очень даже

в мемориз!

resize = realloc.

неа, realloc + T() для push_back достаточно сделать realloc + new (адрес нового последнего элемента) T(x)

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

могу предложить почитать исходники libstdc++ - она не требует наличия T() для std::vector::push_back.

не совсем понял.
я имел ввиду QVector<T>::realloc
не совсем в курсе, может в libstdc++ пользуется ::malloc/::realloc при выделении памяти под новый объект, но кутя гоняет через new (который не даст вызвать конструктор который не объявлен).

я когда-то, изобретая велосипеды, делал template<class T, bool UseMalloc = true) class List { .. }
где UseMalloc разрешал создавать и копировать объекты с пом. malloc/memmove/memcpy, иначе - конструктор по-умолчанию + копирования и operator=. Насколько это криво, как считаешь?

В Qt это вопрос решает QTypeInfo<T>::isComplex - по-моему дикий костыль.

почитать исходники libstdc++

не так уж это и просто :)

> Круто, конечно, юзать буст, но вот напишешь строк 200 кода и он тебе выдаст дысячи 2 печатных строк ошибок и всё... Думай сам что делать. Мне приходилось комментить куски кода по 10-50 строк кода и вылавливать ошибки.

Товарищ, может все таки в слесари ....

не знаю что там в бубунте, а в debian разделен.

где UseMalloc разрешал создавать и копировать объекты с пом. malloc/memmove/memcpy, иначе - конструктор по-умолчанию + копирования и operator=. Насколько это криво, как считаешь?

Это сильно криво, следует использовать placement new для копирования и malloc+realloc для выделения памяти и никаких UseMalloc не надо.

STL это базовая вещь и программист на С++ обязан знать STL «без словаря». А для обучения сойдет книжка Степанова.

ага. про placement new я не знал (видать равно как и разработчики QVector).
теперь понятно как оно работает.
век живи - век учись.

>никаких UseMalloc не надо.

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

>> Вот зачем QVector хочет чтобы у его элементов был конструктор по умолчанию?

для resize()

resize не вызывается. std::vector::resize(size_t) тоже требует конструктор по умолчанию, но ты не обязан платить за то, что не используешь.

типа того

я тебя люблю

> std::vector::resize(size_t) тоже требует конструктор по умолчанию, но ты не обязан платить за то, что не используешь

хех

это конечно в стиле плюсовых шаблонов, но я бы не сказал что это хорошо

можно довести этот пример до крайности:

some_container<some_class> x; // компилятор соглашается

и дальше *ничего* не возможно сделать с этим х, даже добавить элементы, т.к. у some_class не хватает чего-то там (методов, конструкторов, ...)

Ну, никто не заставлял тебя делать some_class без ничего.

#include <vector>

class foo
{
  foo();
};

int main()
{
  std::vector<foo> a;
}

этот пример компилируется. И вот такой тоже:

#include <vector>

struct foo
{
  virtual void bar() = 0;
};

int main()
{
  std::vector<foo> a;
}

Ну, никто не заставлял тебя делать some_class без ничего.

Это может быть ошибкой. И язык ничего не предоставляет для её обнаружения. Вообще говоря Boost.Concepts не просто так придумали, но её возможности ограничены.

>Это может быть ошибкой

Почему? Если функцию, которую никто не использует не реализовали - это не ошибка.

для string перевод string <-> number, нужен костыль

чавой-та костыль? мелкая функция, на 2 строчки :)

	template <typename Ty> 
	bool from_string(
		Ty& t_out, const std::string& string_in,
		std::ios_base& (*base_to)(std::ios_base&) = std::dec
		) {
			std::istringstream iss(string_in);
			return !( iss >> base_to >> t_out).fail();
	}

и используем

int some_int;
std::string some_string;

bool op_ok = from_string<int>(some_int, conv_string );

Кстати, вопрос почти в тему: существуют ли реально консольные приложения на Qt? Посмотрел бы ради любопытства

та наверное существуют, только сейчас не вспомню :)

а что конкретно интересует?

>главное правило: не тащить лишних зависимостей без необходимости

вообще можно типа как пользоваться только qtcore

если можно обойтись без qtcore, то зачем его тащить? :)

Моё мнение - без Qt кодить на C++ не то чтобы не реально

ещё как реально, никаких проблем (моё мнение)

это как сейчас сидеть под никсами юзая только links и vi

во-первых - нет, не так, а во-вторых многие так и сидят :)

Круто, конечно, юзать буст, но вот напишешь строк 200 кода и он тебе выдаст дысячи 2 печатных строк ошибок и всё...

есть такое, но это дело привычки и да, кто Вас заставляет писать 200 строк кода без тестирования? это ж мазохизм, даже и без темплейтов

можно довести этот пример до крайности:

some_container<some_class> x; // компилятор соглашается

и дальше *ничего* не возможно сделать с этим

ССЗБ

>есть такое, но это дело привычки и да, кто Вас заставляет писать 200 строк кода без тестирования? это ж мазохизм, даже и без темплейтов

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

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

А разве процесс перехода на новый компилятор не предусматривает тестирования всего кода с ним?

>А разве процесс перехода на новый компилятор не предусматривает тестирования всего кода с ним?

Что подразумевается под тестированием? Выше этим назвали проверку «скопилируется-не скомпилируется».

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

//ipc

> я бы не сказал что это хорошо

А чем это плохо? При попытке заюзать не поддерживаемый функционал, ты получишь ошибку времени компиляции. Кроме того, stl-ные библиотеки общего назначения. Навязывать для них жесткий интерфейс и заставлять программиста реализовывать не нужный ему функционал - как раз не хорошо.

P. S. Выше этим назвали проверку «скопилируется-не скомпилируется» по ходу написания кода, когда за раз не возникает несколько экранов ошибок.

>есть такое, но это дело привычки и да, кто Вас заставляет писать 200 строк кода без тестирования? это ж мазохизм, даже и без темплейтов

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

1) и без шаблонов будет те же самые тысячи строк, в которых будет не сильно проще разобраться; из опыта даже на довольно известных компиляторах вылизанных со всех сторон, какими являются, к примеру, visual c/c++ и gcc возникает куча ньюансов даже на сравнительно небольших и простых проектах

2) use unit-testing Luke

>1) и без шаблонов будет те же самые тысячи строк, в которых будет не сильно проще разобраться
Как когда. По крайней мере, без темплейтов текст ошибок гораздо читабельнее.

2) use unit-testing Luke

Так ведь использую. А это к чему было?

>1) и без шаблонов будет те же самые тысячи строк, в которых будет не сильно проще разобраться

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

да, есть такое... тем не менее, при некоторой сноровке, разбор аццких конструкций, выдаваемых гремучей смесью c++ & templates ставит в тупик не больше чем стандартные выкрутасы компилятора :) правда сначала надо съесть очень много кактусов

алсо, Александреску описал способ качественного трейса ошибок в коде с шаблонами (сам не юзал)

>2) use unit-testing Luke

Так ведь использую. А это к чему было?

а в чём тогда проблема? делаете отдельный бранч в VCS, с поддержкой unit-testing потихоньку восстанавливаете работоспособность кода, потом смотрите diff со старым кодом и обвешиваете #ifdef'ами или рефакторите

да, не всегда тривиально, но то же С++ а не Дельфи там какой, ылита :)

> А чем это плохо?

В общем-то это и не плохо, но когда надо сделать type erasure по типу явы, то начинаются трудности (мягко говоря).

Например такой тип Х, определяемый как «существует какой-то Т, такой, что Х равен std::vector<T>» требует определиться, есть ли у Х resize().

Не уловил.

существует какой-то Т, такой, что Х равен std::vector<T>

Значит, шаблоны. (Без шаблонов у нас есть отличный type erasure to «void *». xDD)

В каких ситуациях шаблон для Х будет требовать _не используемой_ функции в типе Т?