- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
string Daumants::getReverse()
{
string message = this->data();
char *reverseMessage = new char[this->length()];
for (int i = this->length() - 1, j = 0; i >= 0; i--, j++)
{
reverseMessage[j] = message[i];
}
for (int i = 0; i < this->length(); i++)
{
message[i] = reverseMessage[i];
}
return message;
}
Follow us!
toxicDick
fixed
:D
=D
что ты все смеешься?
ты вообще проверял свой код, велосипедофаг? он точно переворачивает строчку?
тебе же намекнули уже
http://ideone.com/8S78f
когда "ой ой у тебя же волчанка шаблонный класс, а ты из него хочешь метод вызвать, паника, я щя обосрусь, или напиши this->, или задай мне ключик -fpermissive, чтобы я не обсирался"
но тут причин не вижу, да
мол зависимое имя
как известно, код с шаблонами парсится минимум дважды - в первый раз выявляются независящие от шаблонных параметров вещи, во второй шаблон непосредственно инстанциируется
стандарт в общем то требует чтобы всё, что не зависит от шаблонных параметров, должно быть объявлено/известно на момент первого парсинга кода
гцц облегчает себе жизнь и типа делает в точности, что требуется - вызов метода f() для него выглядит, как независящий от шаблона, поэтому он хочет иметь доступную декларацию уже на момент первого парсинга, и его не интересует, что f() может например быть объявлен в непосредственном предке
собственно такое поведение гцц может приводить к оооочень нетривиальным последствиям - ошибка компиляции с требованием "this->" лишь маленькая неприятность по сравнению с:
http://ideone.com/VaMKR
компилятор вижуал студии имеет другое мнение на этот счет (на счет поиска имен в конкретной точке) и не доставляет таких проблем, он вообще толерантнее гцц к программисту во многих отношениях
Неужели до сих пор не придумали опцию компилятора, которая пиздит за new (и за любое выделение ресурса) вне конструктора класса?
достаточно, чтобы выделяемый ресурс знал когда ему умирать
тут компилятор не в силах исправить генетику
Оператор = тоже считается.
А, блин, изменение длины для динмассива. Тут я даже не знаю, встроенный реаллок какой-то нужен.
метод reset позволяет установить новый указатель
и т.д. аналогично
выделение ресурсов всегда и только в конструкторах чревато баттхёртом с исключениями
в принципа можно отследить ту память, указатели на которую хранятся только в локальных переменных, но:
1) можно придумать кучу способов, каждый из которых все испоганит.
2) нафига это вообще делать? если проблемно разработчику следить за локальными, что ж он будет делать с полями класса например?
3) а что, если логика программы по работе с памятью нетривиальна? С++ позволяет реализовать это профессионалу - для этого он и создан.
Если один ресурс выделяется в нескольких местах - то можно один класс на все эти места.
Крестовики любят стебать дальфистов за то, что они руками выделяют ресурсы. Так почему же они считают нормальным писать не исключениебезопасные
a = new A;
delete a;
или безопасные, но муторные
try{
a=new A;
delete a;
} catch (...) {
delete a;
};
?
Это же потенциальная дыра - один раз ошибся и привет. Лучше заткнуть дыру до её возникновения.
И не нужно, потому что есть автодеструкторы.
Кулхацкеры, конечно же, негодуют, потому что руки и них из жопы.
Когда-то такое же негодование вызывал запрет тупо преобразовывать int* в float*.
+ не нужно городить классы
+ фича не строга, поэтому более универсальна
кажись, так и пришли к идее "сборки мусора"
Нифига, писать finally вручную - это убого, особенно если объектов много.
> а плодить синтаксическую единицу на каждый чих
Одна единица на каждый тип ресурса. Один раз написал автоудалялку для HGDIOBJECT и пользуйся ей всю жизнь, например. Я ж не заставляю писать по классу на каждый случай использования, лол.
если у тебя было bad_alloc на указателе a, то delete по нему будет пыщьпыщь
> все выделения ресурсов надо заворачивать в классы
используй уже умные указатели, они теперь банановые и в стандарте
привет бустоненавистникам
сродни "надо заставить людей выполнять работу в срок" и "надо заставить людей разрабатывать проекты, которые не падают и не текут"
если работник не может, он ищет другое место работы
если у работника по идеологическим причинам есть неприязнь к умным указателям и внимательной работе с ресурсами, то либо работник идиот, либо его начальник мудак, принимающий стратегические решения "мы не будем использовать стл и буст, потому что они тормозят и ниасилили, и вообще С++ говно, но мы будем писать на нём"
Потому что то, что ты говоришь - из серии "неприязнь в правильной передаче параметров в функцию" - если бы компилятор за этим не следил, это что же было бы?
хочется реже включать голову, иметь ниже порог вхождения и быстрее писать красиво выглядящие программы - есть другие языки и компиляторы, и интерпретаторы, и сборщики мусора, и формошлёпки, разве кто то кого то заставляет, я не пойму
любой свободно висящий new должен вызывать вопросы прежде всего у программиста, а не компилятора с++ - если программист знает что делает, компилятор лишь должен ему помочь это сделать максимально эффективно
если программист не знает - он зря выбрал опасную бритву
Компилятор должен изо всех сил помогать писать безопасный код. А скорость... Это в последнюю очередь оптимизируется, надёжность важнее.
Кстати, какой-то пидор опять поставил мне по минусу, а моим оппонентам - по плюсу. Я передаю ему привет и говорю ему, что он пидор.
Шарль Ожье де Бац де Кастельмор, граф д’Артаньян.
и так старается как умеет
разные долбоёбы не используют смарт пойнтеры потому что "медленные", поэтому выделяют голую память и отдают другому потоку её обрабатывать в надежде, что он её всё таки потрет
компилятор никогда не сможет выловить когда эта память в 99.99% случаев удалится, как задумано, а когда тупо утечет по разным причинам, в т.ч. race condition, поэтому предупреждения он не выдаст - попробуй проанализируй всё это - программист ССЗБ, сэкономил на счетчике ссылок, выбрал неверный инструмент, ему бы розовый дилдо, которым в ногу посложнее выстрелить
поискать утечки памяти в С++ поможет не компилятор, а средства отладки
но если делать сразу хорошо (а С++ этому не препятствует, в отличие от того же С), то валгринд не пригодится никогда
Нет, он не заставляет не использовать выделения памяти вне конструктора. Он не защищён от долбоёбов типа отписавшегося ниже. Не надо говорить, что сам виноват - всегда надо искать пути снизить человеческий фактор. То, что ты типа против - можно так же применить к чему угодно, например вообще к автовызову деструктора, и сказать, что раз сам не вызывает деструктор - значит сам себе виноват и нефиг неявные вызовы чего-либо делать. И я уверен, что в начале 80х подобные тебе именно так и говорили про автодеструкторы.
иди в чисто функциональные языки, это там как раз актуально
представь что ты пишешь обычный сервер на С++, ты дождался очередного клиента на сокете и готов от него принимать информацию
большинство протоколов подразумевает чтение из сокета несколько раз, например тот же http - тебе сначала необходимо прочитать сколько-нибудь, пока не станет понятно, сколько конкретно тебе еще требуется прочитать из сокета (например content-length: )
т.е. в общем случае твой класс connection, который пользуется сокетом, должен определенным образом увеличивать память под буфер принятых данных
и конечно он это будет делать не в своем конструкторе и не в конструкторе своего члена buffer
если бы он делал это только в конструторах, ты бы получил pure functional C++, надо дочитать 100 байт к имеющимся 10к - похер, создаем новый объект с длиной 10к+100, копируем старое значение, старый умирает, мы пользуемся новым
я могу привести еще миллион примеров, когда нам надо не в конструкторе выделять память, потому что на этапе конструктора может быть не все известно, и не в каждом экземпляре класса может требоваться выделение памяти
ты путаешь идеологии, С++ никогда не будет что либо запрещать с оператором new, более того, если ты его сам можешь перегрузить любым образом, хочешь свой менеджер кучи пиши со сборщиком мусора
Я смягчаю своё предложение - разрешить инициализацию вне конструктора, но только если писать длинное слово, чтобы программист как бы подписывался кровью под договором.
Как я писал ниже, по аналогии с запретом на прямое преобразование типов - там тоже заставляют длинное слово писать.
1) пользоваться тем, что большинство этих хендлов суть void *, поэтому отлично работает
единственное неудобство - в shared_ptr нет operator T * (), приходится использовать .get()
2) написать свой универсальный микровелосипед, типа template <class Handle> class scoped_handle;, который бы принимал в конструкторе значение хендла и описание деструктора хендла, в своем деструкторе делал что положено, имел operator Handle () и пару утилитарных методов (типа reset(new_handle), swap и т.д.) - вот сейчас написал такой микровелосипед, получилось всего то 70 строк на него
в хорошем смысле этого слова зачем же доходить до маразма типа "запретить malloc"
кто как хочет так и программирует мне вот даром не нужны умные указатели
меня тошнит от них да и упраление памятью намного сложнее чем просто выделил
в одном блоке и в нем же освободил вы еще скажите это разработчикам драйверов
и прочего низкоуровневогог кода что они теперь обязаны использовать смартпоинтеры
вот смеху то будет ситуации бывают разные и malloc использую и goto нет если
конечно загонятся по идеологии то тогда все объяснимо почему вы до такого
маразма дошли наверное перечитали умных книжек без фильтрации всего что в них
написано а читать их надо с иронией иначе беда
P.S вообще я очень толерантен к любому мнению но тут увидел ну просто бред
иначе это никак не назовеш
они всегда покажут все утечки памяти вместе с каллстеком до самого места выделения
и также прекрасно покажут утечки всех gdi user kernel бъектов а если юзер не
тестит чем нить вроде этого свои проги то он сам себе ССЗБ и никакие умные
указатели тут не помогут
вот качаем уже с ключиком и наслаждаемся автоматической и очень удобной багоискалкой
если вы выделяете память в одном методе класса, и ожидаете что она освободится другим методом или в деструкторе, ничего проще scoped_ptr быть не может, оверхеда в нем никакого, а удобство - существенно, т.к. в деструктор вообще ничего писать не приходится
scoped техника также удобна для любого захвата ресурса, необходимого для освобождения
нет ничего проще, чем написать ровно один раз
mutex::scoped_lock lock(mutex);
и знать, что при любом выходе из области видимости (по не одному return или по исключению) он сам освободится
если вы выделяете память и отдаёте попользоваться ею десятку другим параллельным асинхронным операциям, каждая из которых друг о друге ничего знать не хочет, а сами владеть выделенной памятью тоже не собираетесь - она вам не нужна, вам нужна новая область памяти, которую надо отдать другим операциям, shared_ptr решает эту проблему очень и очень просто, объект/память живёт ровно столько, сколько он обязан жить
как бы вас ни тошнило от умных указателей, как бы не был бесполезен многопоточный безопасный код низкоуровневым драйверописателям, как бы не изголялись с передачей в 10 этажные коллбеки сотни хендлов и кусков памяти в расчете, что они останутся живы и тогда, когда коллбек сработает, умные указатели действительно полезны
Тебе не нужны, а тем, кто пишет приложения, для которых важна надёжность - нужны. Тесты - это хорошо, но их что - ещё и на описатели окон и файлов и всего такого вешать? Ресурсы бывают разные.
> кто как хочет так и программирует мне вот даром не нужны умные указатели
Судя по стилю изложения - это 18-летний кулхацкер, недавно познавший прелести "прямого обращения к памяти", негодует.
вывод: если ты не знаеш то не пиздаболь попусту а то что ты такой
фанат умных указателей говорит только об одном что ты "упопротый"
ну не верю я что человек с опытом будет нести такую
ересь про malloc и что без умных указатей жизни нет
ПИЗДЕЕЕЦ
Я думал, тебе 18, в таком возрасте такие мысли и такая орфография - это, можно сказать, нормально.
ЯВАХУЭ
последние 10 лет а твое такое мировоззрение на возраст сродни "тупой малолетке"
тебя не красит нет если ты конечно хочеш и дальше ей оставатся то продолжай
будь малолеткой
У тех пидорков, что пишут гадости на http://huita.org/649 , ничего подобного за душой нету, они неспособны творить, вот и кукарекают.
Я сделал игру, которую несколько человек вовсю пиарят без моего ведома, кстати. Казалось бы, что плохого? Это же хорошо, это же достижение? Но ничтожные пидорки обсирают именно меня.
Скоро кровь потечёт!
Жду очередной порции детских какашек на лурке, в стиле "Тарас хуй и чмо я его ненавижу".
Это хуёво. Ибо отрываются они именно здесь, флудят =(
Убого же.
Лучше так:
Это намного короче, но содержит тотже самый код.
Правда, оно тоже содержит new, надо как-то правило нормально формализовать.
Ну и для упоротых можно оставить длинное слово. Типа a=new uncontrolled_resource<A>
По аналогии, как запретили делать преобразование int* к float*, но для упоротых оставили reinterpret_cast, короче, длинное слово, чтобы программист как бы подписывался: "да, я точно знаю, что я имею в виду и беру ответственность на себя".
Что в этом плохого? Можно так:
В данном случае как раз ничего.
Вот я и думаю, как бы запретить new так, чтобы в данном случае всё было по закону.
> auto a=std::make_shared<A>();
Ну или оставить только такую инициализацию.
> длинное слово, чтобы программист как бы подписывался
new в нынешнем С++ и есть это слово
прости, что оно недостаточно длинное для тебя
Знаешь, когда-то давны-давно все тоже считали, что писать (float*)(&i) достаточно длинно. Но прогресс поставил всё на место.