LINUX.ORG.RU

Чем чреват и плох подобный код на практике?

 ,


0

1
extern "C"
{
    QString boo()
    {
        return "9";
    }
}

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

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

Ответ на: комментарий от next_time

Ну как ты сам отметил, с теоретической т.з. тут полностью implementation-defined поведение.

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

Самые плохие выстрелы в ногу — те, которые не всегда стреляют.

Стоит осознавать, что C++ - это один сплошной выстрел в ногу. Для интереса предлагаю засечь, сколько времени вам понадобится, чтобы найти ошибку в коде:

#include <iostream>
#include <string>
#include <string_view>

int main() {
  std::string s = "Hellooooooooooooooo ";
  std::string_view sv = s + "World\n";
  std::cout << sv;
}
Я был шокирован тем, что кресты так работают. На таком языке впринципе невозможно эффективно и безопасно писать код, и единственное оправдание - что Си для того же проект подошел бы еще хуже. Собсна, в моем первом серьезном проекте на Си большую часть времени я провел за поиском ошибок работы с памятью.

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

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

0 секунд. Сплошной выстрел в ногу - это давать кресты человеку, не набившему на них руку.

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

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

byko3y ★★★★
()

Три причины:

  1. Там есть плюсы
  2. Там есть си
  3. Там есть кутэ

Если смешать три говна, конфеты не выйдет. Пропорции не имеют значения, а ингридиенты.

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

По мере прочтения и увидел. В крестах на автомате думаешь про время жизни объектов, особенно когда видишь указатели/ссылки/view.

clang-tidy ловит такое, кстати.

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

кроссплатформа

Ну давай расскажи мне как на твоей кроссплатформе бринг-ту-топнуть окно уже запущенного инстанца, при запуске второй копии. Давай. Жду.

Назовешь альтернативы?

Да легко. Дельфа, Лазарус и ещё штук сто. Сиплюсаторы из своего мирка вообще не выбираются? Мок жрать не задолбало ещё?

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

Даунбасс, чё это ты через 5 лет неактивности вылез? Кто разрешил?

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

По мере прочтения и увидел. В крестах на автомате думаешь про время жизни объектов, особенно когда видишь указатели/ссылки/view.

Хорошо, я верю, что опытный кодер на крестах способен каждую строку думать о том, как не выстрелить себе в ногу. Каждую строку, потому что указателей/ссылок/отображений в коде обычно много, если это код на крестах, а не код на C с расширением .cpp.
Однако же, я настаиваю на том, что пример выше - это простейший вариант ошибки на 8 строчек. Когда же счет идет на много-много тысяч строк кода, то ошибки неизбежны, и кресты в этом плане не дают никаких преимуществ на C, и опытные разрабы на крестах приходят к отказу от фич крестов в сторону упрощения кода. Например, в команде разрабов Unity3d запрещено использовать Boost.
http://aras-p.info/img/blog/2018/cpp_phases.jpg

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

Ну давай расскажи мне как на твоей кроссплатформе бринг-ту-топнуть окно уже запущенного инстанца, при запуске второй копии. Давай. Жду.

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

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

Да легко. Дельфа, Лазарус и ещё штук сто. Сиплюсаторы из своего мирка вообще не выбираются? Мок жрать не задолбало ещё?

На дельфе пишу очень много лет. Кроссплатформа там на Qt была так-то.

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

указателей/ссылок/отображений в коде обычно много, если это код на крестах, а не код на C с расширением .cpp

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

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

Кто-то приходит к отказу, кто-то наоборот задействует всё на полную. Целые классы ошибок крестами устраняются, новые классы появляются :D Тут уж кому какие ошибки больше нравится разгребать.

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

Дельфа

её нет под онтоп, незачёт

Лазарус

там кути, как раз, ЕМНИП

ещё штук сто

таких же, что предыдущие или что поинтереснее назовёте?

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

Куте такого не может, хотя задача жизненная. Так что называть её кросплатформой не совсем корректно. Это не гуй, а фигня какая-то.

В офтопе это можно сделать без окна, как и в линупсе.

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

Кроссплатформа там на Qt была так-то.

Когда был Куликс, о котором никто не помнит. И потом Куликс закрыли. Видать с тупым дерьмом навроде кутэ задолбались возиться. А когда от кути отказались — тема попёрла.

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

дельфийский код хавает на раз два.

таких же, что предыдущие или что поинтереснее назовёте?

Электрон может в сингл-инстанс с оповещением запущенной копии из коробки. В отличии от.

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

дельфийский код хавает на раз два.

без гуя

Электрон может в сингл-инстанс с оповещением запущенной копии из коробки

электрон - тормозное, жрущее память, убого выглядящее говно

ах, ну да, это ещё и одна из наиболее медленных платформ для разработки

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

Куте такого не может, хотя задача жизненная. Так что называть её кросплатформой не совсем корректно. Это не гуй, а фигня какая-то.

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

В 5.11.1 добавлен хак активации через подключение к очереди ввода при QWindowsNativeInterface::windowActivationBehavior == QWindowsWindowFunctions::AlwaysActivateWindow

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

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

Будешь все данные копировать, что ли? Если хочешь, чтобы программа работала быстрее питона, то приходится использовать память повторно.

Кто-то приходит к отказу, кто-то наоборот задействует всё на полную.

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

Целые классы ошибок крестами устраняются, новые классы появляются

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

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

Когда был Куликс, о котором никто не помнит. И потом Куликс закрыли. Видать с тупым дерьмом навроде кутэ задолбались возиться. А когда от кути отказались — тема попёрла.

Куда поперла? Ты можешь назвать что-то известное, написанное на FireMonkey? Я - нет. Даже более старое WPF, тоже векторный GPU гуй, имеет весьма скромный список боевых приложений: https://stackoverflow.com/questions/7837/what-real-world-wpf-applications-are...

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

Электрон может в сингл-инстанс с оповещением запущенной копии из коробки. В отличии от

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

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

Будешь все данные копировать, что ли?

Буду, например, shared_ptr гонять. Или ссылки. Да, они почти те же указатели, но они не бывают владеющими, и ошибиться с временем жизни сложнее.

«а может быть Boost был лишним?»

Может да, может нет. Не только ньюфаги его пишут и используют.

Ошибок, которые были в Cи - ты сразу уточняй. В паскале их не было

В паскале не бывает висячих указателей и разыменования nil?

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

ограниченный фиксированный функционал

Всякий линейный ограниченный функционал f, определённый на линейном многообразии Y линейного нормированного пространства X, можно продолжить на все пространство с сохранением нормы.

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

Буду, например, shared_ptr гонять. Или ссылки. Да, они почти те же указатели, но они не бывают владеющими, и ошибиться с временем жизни сложнее.

Ошибиться со временем жизни в крестах? Просто. Сложнее, чем в Си, но все равно просто. Лямбды новые - те вообще приглашают к ошибкам со временем жизни. Для устранения части этих проблем и применяют продвинутые анализаторы коды.
Также, проблема shared_ptr и прочих заключается в том, что они делают код нечитаемым - за деревьями не видно леса.

Ошибок, которые были в Cи - ты сразу уточняй. В паскале их не было

В паскале не бывает висячих указателей и разыменования nil?

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

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

Всякий линейный ограниченный функционал f, определённый на линейном многообразии Y линейного нормированного пространства X, можно продолжить на все пространство с сохранением нормы.

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

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

Будешь все данные копировать, что ли?

Про COW-on-write не слыхал?

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

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

Нет там ничего мутного. Фокус нужно передать ни какому-то окну, а ожидаемому пользователем. Задача тривиальная.

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

Расход памяти и процессорного времени в наше время никого не волнует. А лет через эн, разница между электроном и кутэ будет минимальной. Чего нельзя сказать о скорости разработки. Лишней возни в кутэ столько, что кажется, что её туда специально добавляли. Особенно радуют стили цсс от кутэ — тупое дерьмо.

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

Которого не имеет кутэ, да. И нет необходимости, более того вредно, выходить за эти рамки. Всё чётко.

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

Вы из криокамеры-то выйдите. Ага, не волнует. То-то воя по всему интернету «фаерфокс/хром опять сожрал всю память», «современные игры слишком много жрут» и т.д. и т.п. Это лет 5 назад, когда казалось, ОЗУ всё дешевеет и дешевеет, все думали - ну докуплю себе плашку, если что. Тем временем, с тех пор ноуты с 16ГБ так и остались до сих пор в верхних ценовых сегментах.

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

и процессорного времени

волнует не процессорное время, а тормоза - когда сраный текстовый редактор на электроне по полминуты висит

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

А зачем его жрать? Он просто работает

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

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

Ну вот, ни черта не знаешь, а плюешься во все стороны.

Называть говно говном теперь стало плохо, и так же плохо как не знать чего нету? Прости не знал.

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

То-то воя по всему интернету «фаерфокс/хром опять сожрал всю память», «современные игры слишком много жрут» и т.д. и т.п.

Да, и никто, никто, не берётся переписывать всё это на КуТэ и плюсы или си. Все просто докупают железо, а остальные делают свою юнити с питоном вперемежку. Ни о чём не говорит? Да очень просто — с этим набором инструментов новое железо выйдет быстрее и обновиться, у основной аудитории, чем ты на своих дрочённых плюсах сделаешь свою, уже устаревшую и никому не нужную поделку. И она вовсе не будет кроссплатформенной. Cest la vie, мэн. Твоя теория о плюсовом превосходстве не выживает в суровой реальности.

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

волнует не процессорное время, а тормоза - когда сраный текстовый редактор на электроне по полминуты висит

Это на твоих деревянных счётах? Странно, кто-то тут постоянно врёт, что на плюсах можно нормально заработать. Оказывается, что даже на комп ниже среднего не хватает. Ну так это ещё и инструменты для нищих плакс оторванных от реальности. Так выходит.

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

А тебе мешает?

Конечно же нет, я ведь его не трогаю. Не тронь, как говориться, и вонять не будет.

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

Нет там ничего мутного. Фокус нужно передать ни какому-то окну, а ожидаемому пользователем. Задача тривиальная.

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

И получается, что лучший вариант, как ни странно, - это тупо вызвать платформоспецифичную функцию.

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

Которого не имеет кутэ, да. И нет необходимости, более того вредно, выходить за эти рамки. Всё чётко.

Все кресты лежат у твоих ног - используй что хочешь. Кутя только гуй рисует (грубо говоря).

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

То-то воя по всему интернету «фаерфокс/хром опять сожрал всю память», «современные игры слишком много жрут» и т.д. и т.п. Это лет 5 назад, когда казалось, ОЗУ всё дешевеет и дешевеет, все думали - ну докуплю себе плашку, если что. Тем временем, с тех пор ноуты с 16ГБ так и остались до сих пор в верхних ценовых сегментах.

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

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

Qt не может полноценно инкапсулировать этот механизм

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

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

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

Суть кросплатформы как раз в том, чтобы полноценно всё это инкапсулировать в себя.

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