LINUX.ORG.RU
Ответ на: комментарий от Gvidon

А так не считается. Я могу и в Си предварительно malloc-нуть побольше. Тут мы сравниваем то, насколько плюсы проигрывают оттого, что приходится вместо realloc делать malloc и копировать, а потом еще free

SZT ★★★★★
()
Ответ на: комментарий от SZT

приходится вместо realloc делать malloc и копировать, а потом еще free

И делают так в плюсах по вполне понятным и логичным причинам. Меня устраивает.

Gvidon ★★★★
()
Ответ на: комментарий от Gvidon

И делают так в плюсах по вполне понятным и логичным причинам.

И что же это за причины такие, от которых должна страдать производительность в векторе?

SZT ★★★★★
()
Ответ на: комментарий от SZT

Копирование элементов на новый this.

енивей. вектор довольно редко пользуется для такого пушинга как в примере. Чаще всего известно хотябы порядок количества элементов, ожидаемое в контейнере, поэтому делается reserve. если кто-то сильно дофига делает push, то что-то в консерватории не так.

anonymous
()
Ответ на: комментарий от SZT

Конструкторы копирования и деструкторы. Да, теоритически можно было бы написать специализацию вектора для чисел и указателей, но это просто никому не нужно, потому что реальной проблемы я всё равно не вижу. В подавляющем большинстве приложений никто не делает миллионы push_back'ов, а если и делает, то только после предварительного вызова reserve. Ну и накатать велосипед вроде твоего сишного тоже никто не запрещает, но это только после очень внимательного профилирования.

Gvidon ★★★★
()
Ответ на: комментарий от SZT

Когда надо - делаешь reserve, когда тебе пофик и ты даже миллисекунды для пользователя не выиграешь, то спор бессмысленный

vertexua ★★★★★
()
Ответ на: комментарий от SZT

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

тут дело не в самих плюсах, а в STL.

Где-то я даже читал, что само по себе программирование в ООП стиле дает в итоге ХУДШУЮ производительность, чем если все делать процедурно-императивно. Ну а если в плюсах писать как в Си и отключить все ненужности, связанные с обработками исключений, RTTI и прочее, скорость должна быть такая же

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от SZT

ну, я лично не фанат ООП. но для моих задач оно и не нужно, в 99% случаев. у меня всегда стоит главная задача - оптимизация по скорости. так что развесистую клюкву без особой необходимости я не использую. а вот студенты, только выпустившиеся из ВУЗов, страдают ООП головного мозга. видимо, им там очень долго втирают идею о ценности ООП.
я как-то переписывала код, в котором нанятый на работу программист-неофит для реализации обычного массива фиксированной длины для хранения структур создал иерархию аж из четырёх классов, с наследованием, наворотил какие-то итераторы, классы-абстракции и поверх этого всего какую-то аццкую нелинейную логику. и там ещё и ошибся в паре мест, в этом своём густом лесу. в итоге, я это всё выпилила и сделала простой malloc на нужный размер и по смещениям обращения. работать всё стало в сто раз быстрее :) обычно после двух-трёх лет работы с реальными проектами фанатичное пристрастие к ООП проходит. пожалуй, остаётся оно только в Qt-образных проектах, во всякой графической гуйне, и то пока графика не серьёзная. где серьёзная - там OpenGL во все поля и особо густой фигни не понаделаешь.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Кстати, упоминая OpenGL, то нынче геометрия подготавливается в буферы видеопамяти и оттуда обрабатывается шейдерами. Язык и рантайм на CPU перестают занимать хоть какое-то время исполнения. Мы успешно писали OpenGL приложения на Java и процессор был почти незанят, да и основная память тоже

vertexua ★★★★★
()
Ответ на: комментарий от Iron_Bug

видимо, им там очень долго втирают идею о ценности ООП.

И не только студентам. Вот цитата из учебника по с# (Фроловых):

Однако объектно-ориентированный подход, предлагаемый языком C++, значительно облегчает создание программ, в результате чего обоснованность использования классического языка С при создании новых программ представляется нам весьма сомнительной. Более того, начиная изучение программирования с процедурного, а не объектно-ориентированного языка, можно приобрести вредные привычки процедурного программирования. Эти привычки в дальнейшем затруднят изучение современных объектно-ориентированных и компонентно-ориентированных технологий.

По-идее, при обучении нужно объяснять студенту, что ооп это просто надстройка. При желании ооп можно присобачить к любому стандартному процедурному языку. Я никогда ничего не писал на ооп (потому что бейсик и потому что скрипты), но вполне себе представляю как это сделать (как присобачить ооп к не ооп).

rechnick ★★★
()
Ответ на: комментарий от rechnick

начиная изучение программирования с процедурного, а не объектно-ориентированного языка, можно приобрести вредные привычки процедурного программирования

Тут Фролов погнал.

rupert ★★★★★
()
Ответ на: комментарий от rechnick

ну, присобачить ООП к С можно, но выглядит это не слишком красиво. хотя, безусловно, работает. ведь компилятор никаких чудес не творит, он генерит код. а то, что можно сгенерить, можно написать и вручную. просто затрат больше будет.
для студента проще изучать структурированные языки типа Java или C# (кстати, последний я считаю аналогом жабы, а не C, ибо с С он не имеет абсолютно ничего общего). С# сейчас активно навяливается в ВУЗах. мне программисты-студенты, которые у нас работают, даже рассказали, что они на этом шарпе там «контроллеры программируют». я, честно говоря, хз, какой такой контроллер можно программировать на таком языке, но фиг его знает. в общем, мелкософт отчаянно впаривает свою поделку в учебных заведениях, это их стратегический план. хотя с точки зрения студентов лучше и выгоднее изучать ту же жабу. она более распространена и по-настоящему кроссплатформенна.
я не считаю процедурное программирование или ООП злом. но переусложнение паттернов в ООП иногда налицо. а студенты без опыта ещё и пытаются навернуть побольше всяких теоретических изысков в практику. в итоге выходят монстрообразные программы, которые приходится оптимизировать методом полного переписывания.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Примеры вузов можете привести? Вообще, это странно. У нас в вузе именно жабку предлагали изучать, а шарп рекомендовали для коннекта к мелкомягкой бд (использовал принципиально Qt). Хотя признаюсь, что пропаганда мс у нас жуткая.

kachsheev ★★★
()
Ответ на: комментарий от kachsheev

ну, в данном случае это бывший УрГУ, матмех (сейчас его присоединили к идиотскому УрФУ и он называется как-то вроде «института математики» УрФУ). вроде преподаватели там остались ещё нормальные, со старых времён. однако, мелкософт и С# там пропихивается коммерческими спонсорами факультета, как я понимаю. они проплачивают, чтобы студентов обучали тому, что им нужно.

Iron_Bug ★★★★★
()
Ответ на: комментарий от kachsheev

Вообще, это странно. У нас в вузе именно жабку предлагали изучать

А учитывая что с выходом C++11 все книги и курсы устарели к чертям, хрен тебе, а не C++ в вузе.

Самое прикольное не в этом. M$ в настоящий момент активно пилит Windows Runtime (сиречь WinRT, не путать с WindowsRT), который в сущности является старым-добрым COM (со своим старым-добрым ABI) в красивой обёртке, и *не* использует технологии CLR.

Я постоянно борюсь с желанием достать из закромов диски с MSDN конца 90-х годов. Там хоть можно найти незамутнённое описание COM и COM ABI.

Так что чую, вскорости unemployment lane пополнится свеженькими C# недоучками, прямиком из вузов.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Не всё. Базовые классы/функции остались теми же, как и работа с ними. Ну да, добавились новые, есть такое.

Кстати, нам начали давать плюсы как раз в районе 2011-2012 года с рекомендацией использовать 2010 студию. Никто и не обмолвился тогда о новом стандарте.

kachsheev ★★★
()
Ответ на: комментарий от kachsheev

сейчас я вроде даже слышала, что С больше не будут преподавать на моём бывшем матмехе. возможно, и плюсы тоже не будут. насчёт плюсов я думаю, что это, скорее, из-за сложности въехать в плюсы для нубов. за год - вряд ли, а два года на один курс там не дадут по часам. так что получится неэффективно. однако, всё, что не преподаётся, даже больше привлекает внимание студентов. так что негативного влияния на изучение плюсов вряд ли следует ожидать. плюсы заметно поднялись за последние года два в рейтинге и интерес к ним не ослабевает. а от сишечки всё равно никуда не деться, она была, есть и будет, тут можно не беспокоиться. если в сях будет меньше нубов - это только к лучшему.

Iron_Bug ★★★★★
()
Ответ на: комментарий от kachsheev

Не всё.

Все. Серьёзно была переработана семантика языка. Фактически C++98 с поправками 2003 года и C++11 — два разных языка.

Macil ★★★★★
()
Ответ на: комментарий от Iron_Bug

плюсы заметно поднялись за последние года два в рейтинге и интерес к ним не ослабевает

Поднялись они исключительно за счёт C++11, C++14 и ожиданий C++17. В этом-то и проблема. Их и так раньше объясняли через пень-колоду, а теперь... Даже понятия не имею что теперь.

Macil ★★★★★
()
Ответ на: комментарий от Iron_Bug

C# (кстати, последний я считаю аналогом жабы

лучше и выгоднее изучать ту же жабу. она более распространена и по-настоящему кроссплатформенна

да, но почему-то на java практически нет гейм девелопмента. А на C# имеется, притом немало. Может, всё дело в перформансе?

З.Ы. Ни с тем ни с другим языками не работал, просто изучал тему игровых движков в своё время

reprimand ★★★★★
()
Ответ на: комментарий от vertexua

хм. Существует такой движок как Unity, его поддержка имеется в linux. Ни XNA ни DirectX под онтопиком нет. Но разработка все равно под C#

а если говорить о привязках, то, судя по гуглёжу, OpenGL для Java имеется. Неужели никто ничего не сделал? Кто-нибудь знает, http://jmonkeyengine.org/ популярен хоть как-то?

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

OpenGL не популярен в приципе, только среди опенсорц-пердунов, где как известно игр нету.

Другое дело конечно PS4, но фиг знает что там за API, но вроде C++ обязателен.

Получается вот ниши для Java нету, хотя я сам много раз писал очень высокопроизводительную графику на Java. CPU там отдыхал, лениво дергая API для вызова отрисовки разных буферов в видеокарте, которые потом красились шейдерами. Можно было с таким успехом на Python переписать

vertexua ★★★★★
()
Ответ на: комментарий от Macil

Если надо объяснять через пень колоду — то лучше не объяснять, а посоветовать пиноколаду и жениться, чтоб не волноватсья о Гондурасе

В этом-то и проблема... Даже понятия не имею что теперь.

В любой непонятной ситуации жди ответного звонка. Нет никакой проблемы: человеков нельзя чему-то научить (извне), это знали еще др. римляни с греками и это нормально — это должно прийти изнутри, «само». А нет — так нет.

slackwarrior ★★★★★
()
Ответ на: комментарий от reprimand

Ну давай посмотрим категории где используется OpenGL

1) Опенсорц - игр особо нету, в DE всяких

2) PS4 - там что-то проприетарное и С++

3) Android - там подобие Java, но уже далеко только на уровне сорцов.

4) Кросс-API движки например для Steam. Вот тут может где-то приютится твой C#, но все-равно большинство на С++

Где используется DirectX/XNA

1) XBox

2) Windows

vertexua ★★★★★
()
Ответ на: комментарий от reprimand

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от vertexua

Ну давай посмотрим категории где используется OpenGL

начнём с того, что OpenGL - это промышленный стандарт. интерфейс для работы с векторной графикой. его реализации можно использовать где угодно, если железо его поддерживает (в современных GPU чаще всего так оно и есть). он не привязан к платформе. и большинство современных программ его используют, даже если и косвенно. потому что сам по себе он не то, чтобы сложен, но неосиляторам и формошлёпам не даётся. они даже не подозревают, что многие графические библиотеки на нём базируются. клепают гуйню и не задумываются, что внизу под их софтом реально работает куча библиотек.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Преимущества OpenGL и барану понятны. Дело в реальности и у нас есть конкретная тема разговора, а именно «Java не используется в играх, наверное потому что она тормозит». Это 4.2, и я обьясняю причины, такие как отсутствие ниши, доминирование консолей на игровом рынке, у которых фиксированый C++ (PS4) или C++/C# (Xbox) API. А чисто технических проблем с VM нету, там даже специальный gc есть для игр в том числе. Плюс я сам писал приложение на Java/OpenGL, где масса частичек звезды через n-body simulation на OpenCL падала в черную дыру, и это над поверхностью астероида. Noise post-processing, bloom, 3д очки.

CPU посредством Java там курило бамбук, двигало камеру и меняло парочку параметров шейдеров на каждом кадре, а потом несколько раз вызывало команду OpenGL «ну-ка, нарисуй вот это все у тебя в видеопамяти»

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

CPU посредством Java там курило бамбук, двигало камеру и меняло парочку параметров шейдеров на каждом кадре, а потом несколько раз вызывало команду OpenGL «ну-ка, нарисуй вот это все у тебя в видеопамяти»

оно верно, только не надо тут подменять сущности: не «посредством жабы», а посредством OpenGL. если через саму жабу графику рисовать, CPU просто умрёт от инфаркта.
пока жаба дёргает сишные функции библиотек нижего уровня или функции системы - она более-менее шустро крутится. но сама по себе она не предназначена для быстрой работы.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

пока жаба дёргает сишные функции библиотек нижего уровня или функции системы - она более-менее шустро крутится. но сама по себе она не предназначена для быстрой работы.

Непробиваемая логика. Что такое «сама по себе»?

Midael ★★★★★
()
Ответ на: комментарий от Iron_Bug

А либы в жабе нижнего уровня с каких пор не на С++? Ой, а жаба случайно сама по себе не либа нижнего уровня на С++?

vertexua ★★★★★
()
Ответ на: комментарий от Midael

когда какой-то код выполняется в JVM. проще из JVM дёрнуть код на Си. будет работать быстрее.

Iron_Bug ★★★★★
()
Ответ на: комментарий от vertexua

ну да, так оно. виртуалка. просто не нужно приписывать этой виртуалке какие-то особые достоинства. кроме быстрой и дешёвой разработки их нет. платой за эту дешевизну являются быстродействие и оптимизация в памяти.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Так говорят все люди, которые не особо разбирались как «виртуалка» работает. Например

1) new X() работает за амортизированые O(1), которые амортизируется сборкой мусора, возможно в другом потоке.

2) Виртуальные методы в большой части кода заменяются на невирутальные везде где это возможно. Причем не путем анализа дерева кода, а профилированием в runtime. Например если где-то есть интерфейс A, но в реале туда всегда приходит B extends A, то применят оптимизацию.

3) Вот такой код

String getXText() {
  if (this.x != null) {
     return this.x.getText();
  } else {
     throw new Exception("xxx");
  }
}

если окажется что x никогда не null в рантайме, то будет заменен на вызов без проверки с trap процессора, который выстрелит если это таки окажется иногда null и JVM достанет из закрома байткоды и перекомпилирует с проверкой.

4) Не говоря уже о всяких LongAdder, ConcurrentHashMap, которые еще надо поискать в плюсах, что повышает порог принятия решения о использовании сторонней библиотеки для плюсов. А речь как раз о написании высокопроизводительного кода. Я не раз видел когда С++ разработчики по причине гемора с библиотеками лепили std::unordered_map+std::mutex в реально неподходящем для этого месте.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

не особо разбирались как «виртуалка» работает

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

спроси любого админа и он скажет, что жаба тормозит и жрёт память. и всё, не надо никаких теоретических дебатов про O от хрен знает чего.

Вот это уровень владения вопросом

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

это уровень владения информацией. а уж нырять вглубь в эти ваши канализации - это вы как-нить сами, без меня.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Тоесть вопросом ты не владеешь. На будущее, я работал в проектах почти всех основных сфер IT, а если речь о языках то я полноценно и долго работал на C#, Java, C++, Python, JS, Scala. Не говно ковырять, а проекты запускать. Сейчас работаю на С++, но легко пройдусь по кругу еще, были бы проекты хорошие. То что ты говоришь, это вызывающее не владение вопросом и нежелание им овладеть, познания уровня двача. Очень желаю тебе в будущем разобраться.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

я полноценно и долго работал на C#, Java, C++, Python, JS, Scala.

значит, ни на чём полноценно и долго не работал. ну, разве что если тебе сейчас лет так под 90.
полноценно и долго - это от 10 лет постоянного программирования на языке. вот я полноценно и долго работаю в области С/C++ и у меня были настоящие большие проекты. но это опыт профессионального программирования более 20 лет, пардон.
жабистов я видела достаточно много. среди них даже пара хороших специалистов попадались. но сама жаба, увы, не торт. и ресурсы она жрёт как потерпевшая, даже у тех, кто владеет всеми тонкостями. потому что такова жаба.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

Очень странно что 20 лет, потому что сам подход к вопросу «не читала но осуждаю, жабистов видела в корридоре» не выдает опытного инженера

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

я жабистов не в коридоре видела, а чуть поближе. они могут быть неплохими людьми и даже сильными теоретическими программистами. они не виноваты, что жаба такая. но это не отменяет факта наблюдений за работой жабы на серверах и соответствующих выводов.

Iron_Bug ★★★★★
()
Ответ на: комментарий от vertexua

То что ты говоришь, это вызывающее не владение вопросом и нежелание им овладеть, познания уровня двача.

Это скорее профдеформация.

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.