Войти
ПрограммированиеФорумОбщее

Как правильно написать operator < в C++ (комментарии) (7 стр)

Страницы: 13 4 5 6 7 8 Следующая »
#90
19:35, 22 дек. 2011

laMer007
> Только один из конструкторов. Все остальные глотают.
  Ну так и продемонстрировал бы, а то что-то опять суёшь какой-то суррогат. Заодно посмотрим где больше лишнего кода.

> Этот код в том виде, в котором вы его написали, не безопасен с точки зрения
> переполнения буферов, если использовать его на реальных задачах с IO.
  Ну так сначала надо иметь перед собой реальную задачу, а потом говорить. Не забываем, что пример учебный. Тот, кто тебя собеседует, увидев такое, может подумать, что в более сложных примерах ты начнёшь городить такой же огород, как в первом варианте, и не заметишь, как трудоёмкость незаметно увеличится как минимум в log(N) или N раз, если ни ещё больше. Или ты просто боишься связываться с очень низким уровнем, пытаясь обойтись верхами, что тоже не всегда хорошо.
  А так если я уверен, что мне десяти тысяч символов в строке по любому хватит, то зачем я буду выделять память в куче, считая длину строки, если можно почти за бесплатно выделить массив на стеке, проделать нужные операции за один проход и, если надо, скопировать из него результат? Функция не рекурсивная, ничего страшного нет, а десять тысяч байт это всего 1% от обычного объёма стека, но уже слишком много для обычной строки, зато какой профит.

> Функция должна быть самодостаточная для своего функционирования, надежная,
> защищенная, проверяющая действия её пользователя как минимум в дебаге.
  Именно поэтому она должна выводить в stdout десять символов \a когда встречает ноль в строке. У тебя я что-то этого не заметил :)

> В 99% случаев char*-строки не нужны.
  Уж как минимум в 90% случаев можно обойтись только char*-строками. Остальные случаи я с ходу просто тяжело себе представляю, или это уже не строки, но всё равно оставил им 10%, а ты поступил по тролльи, пытаясь доказать обратное.


#91
19:56, 22 дек. 2011

char* по определению null terminated, длиннъ отдельно -> упаковка в struct -> другой тип.
_s в ANSI функциях работъ со строками - ето скорее против buffer overflow.

>Ага. Мне с памятью возиться, а ещё с длиной? Не, я не люблю многобукв, как и вы.
См. ANSI функции для работъ со строками, там именно так.

>Ну у вас я видел только char*-вариант пока.
Ну не могу я написать под любой вкус и цвет.
На абстрактном интервью, без никаких доп. требований написал бъ именно мой вариант.

>так что мой вариант почти ни чем не уступает вашему.
Он может алоцироватся на стеке?

#92
20:00, 22 дек. 2011

Я считаю, что надо все функции писать над std::string.
Потому что с чистым char* работать невозможно, а из готовых строк самая распространённая - это std::string.
В паскалоидных проще - там выбора либо нету, либо готовые массивы уже достаточно удобны в обращении.

И ещё меня порадовало, что никто не написал квадратное говно такого типа:

for each s in S {
  if (*s==' ' && s[-1]==' ') S.delete(s); 
};
#93
20:24, 22 дек. 2011

Zefick
> Ну так и продемонстрировал бы, а то что-то опять суёшь какой-то суррогат.
Да пожалуйста. Не работает для удобства использования лишь один конструктор, как я и говорил. Остальные конструкторы проверять лень, но так и есть.

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

> как в первом варианте, и не заметишь, как трудоёмкость незаметно увеличится как минимум в log(N) или N раз, если ни ещё больше.
Вообще то у меня в первом примере трудоёмкость О(n), как и у всех остальных.

>и не заметишь, как трудоёмкость увеличится в log(N) или N раз
На это способны только вы.

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

>считая длину строки
Вот это обычно и бывает, когда кривые ручки используют char* и потом каждый раз считают длину строки за О(n), взамен О(1) у меня.

> Именно поэтому она должна выводить в stdout десять символов \a когда встречает ноль в строке
Что-за ерунда?

> Уж как минимум в 90% случаев можно обойтись только char*-строками.
Как минимум есть 100% случаев, когда можно обойтись только char*-строками, но зачем использовать утюг для забивания гвоздей, если есть молоток?

Z
> Он может алоцироватся на стеке?
Да, достаточно использовать аллокатор со стека. Он даже из пулов памяти или других кастомных аллокаторов может тем же самым способом. Правда к функции придётся дописать шаблонный параметр.

#94
21:09, 22 дек. 2011

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

> А ведь это общая функция, которая будет использоваться во многих местах
> программы в самых разных случаях.
  Скорее всего это функция, которая будет использоваться только в одном месте. И выдумывать тут больше ничего не надо.

> Вообще то у меня в первом примере трудоёмкость О(n), как и у всех остальных.
  Ну так-то оно так, но вот ты уже при конструировании увеличиваешь коэффициент своего метода, которому и так суждено быть в несколько раз больше, чем у простого варианта. Чтобы вычислить end(char*) надо пробежать всю строку. Потом ещё это всё хозяйство копировать. Короче, работы лишней куча.

#95
21:16, 22 дек. 2011

Zefick
> Чтобы вычислить end(char*) надо пробежать всю строку.

Для std::string не надо

#96
21:26, 22 дек. 2011

Соломон Страуструбер
> Для std::string не надо
  А ты вообще в курсе, о чём это было сказано? Если нет, то полюбуйся.

  upd: Хотя что-то я туплю: для массива, с известной на этапе компиляции длиной тоже не надо :)

#97
21:38, 22 дек. 2011

Zefick
Почему вы защищаете Си-стиль написания программ для плюсов? Как то это странно, тк вы профи высокоуровневой Java. Или это не удовлетворенные Java'ой потребности в кулхацкерстве? Если пишете на плюсах, то и пишите большую часть программы в плюсовом стиле. А если есть желание покулхакерить, то Си там ==>.

#98
21:47, 22 дек. 2011

laMer007
> А если есть желание покулхакерить
> покулхакерить

Звучит почти как "покукарекать".

#99
21:51, 22 дек. 2011

Соломон Страуструбер
> Звучит почти как "покукарекать".
:p
Не ну си полезный для написания программ для встроенных устройств или программ системного уровня, но для среднестатистической GUI-программки он не нужен.

#100
21:54, 22 дек. 2011

laMer007
> Почему вы защищаете Си-стиль написания программ для плюсов?
  А кто сказал, что это надо писать обязательно на плюсах? При желании такое же можно забабахать и на Java. Мой вариант вообще не использует указатели, если что (только в месте обяъявления аргумента, но дальше он использутеся как массив), но тем не менее это чистый Си. Это вы зачем-то налетели со своими string-ами, толком так и не объяснив причины, по которым именно они должны быть использованы. Про лишний код мы разобрали, что его нет, а по быстродействию очевидно, что код в стиле Си будет в несколько (минимум в два) раза быстрее.

#101
21:58, 22 дек. 2011

ТарасЪ

> Потому что с чистым char* работать невозможно, а из готовых строк самая распространённая - это std::string.
Тяжелые строчки не всегда нужны. Некоторые говорят, что совсем не нужны. А char* - прекрасен и лаконичен. Только не надо разводить очередную жижу про то, что это не С++ стайл.

Z

> Незнаю, может ето я один такой противник многабукв и больших сорсов...
Когда, например, у тебя 8кБ на стек, данные и память (512 байт из которых съедает окружение), мгновенно осознаешь, зачем тебе нужны string, iostreams и stl вообще. Потом начинаешь понимать, что и на десктопе C-style хаки довольно эффективны. Посмотреть на тот-же pugixml.

#102
22:00, 22 дек. 2011

laMer007

> но для среднестатистической GUI-программки он не нужен.
glib/GTK, как-бе.

#103
22:08, 22 дек. 2011

Ghost2
> Когда, например, у тебя 8кБ на стек, данные и память (512 байт из которых
> съедает окружение), мгновенно осознаешь, зачем тебе нужны string, iostreams и
> stl вообще.
А разве не наоборот? Когда работаешь с девайсом, в котором мало памяти, то STL не нужен.

> glib/GTK, как-бе.
Я не спорю, что на Си можно или нельзя писать GUI приложения. Очевидно, что это возможно. Но это же не так удобно. Банально уже готовых в стандартной библиотеке возможностей и синтаксического сахара меньше, меньше контроль за безопасностью (вспомним те же массивы си с их не проверяемым индексным доступом). Больше времени затратить придется на разработку, что не выгодно.

#104
22:24, 22 дек. 2011

Ghost2
> Тяжелые строчки не всегда нужны. Некоторые говорят, что совсем не нужны. А
> char* - прекрасен и лаконичен.

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

Ghost2
> Когда, например, у тебя 8кБ на стек, данные и память (512 байт из которых
> съедает окружение), мгновенно осознаешь, зачем тебе нужны string, iostreams и
> stl вообще.

А как же "не платим за то, что не используем"? Чё, крестокомпилятор не может убрать все переголовы из СТЛ классов? Как же ваше "за счёт шаблонов С++ позволяет писать ещё более оптимально, чем Си"?

Страницы: 13 4 5 6 7 8 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.