char buffer[l+1];, т.к. выделяется он на стеке, состояние которого и оставшийся размер ты не знаешь._malloca()[?]. Это - аналог alloca()[?] из GNU. Но к работе с _malloca() тебе нужно подойти ответственно, Майки снова начудили с ее интерфейсом, а все той же alloca() пользоваться решительно не рекомендуют через ругань транслятора. char buffer[argc+1]; - это VLA, который является стандартным только для C99.constexpr int bl = argc+1;constexpr существует и работает только во время трансляции кода. Откуда транслятору знать здесь и сейчас, с какими параметрами результирующий код будет выполняться на потенциальных миллиардах целевых устройств? к сожалению красивого фреймворка именно для c++ нет, отсюда разработка даже простейшего приложения (особенно если нужен доступ к перифирии и графическому ускорителю) очень сложны
соответственно и разрабатывать лучше/легче на java
точнее под виртуальную машину dalvik virtual machine
это машина исполнения скомпилированного кода java
$(SolutionDir). Никаких абсолютных путей. Никаких путей относительно проекта. Никаких висящих в воздухе путей. Все должно быть строго от корня солюшена.какой у меня риск потерять время в пустую
я очень боюсь что не осилю обучения на немецком
this никогда не может быть nullptr, иначе это UB. int никогда не переполняется, иначе это UB. Понятие UB позволяет очень жестко оптимизировать код. Еще к таким асимптотическим правкам относится удаление неиспользуемых объектов, участков недостижимого кода, развертка циклов или свертка планарных конструкций. Эти оптимизации не отключаются, т.к. они заложены в сам язык, в процесс трансляции. Еще к таким оптимизациям относится перестановка блоков бинарного кода для случаев, когда результат не меняется, а вот бранчинг кода резко снижается.
А никак. :)
Если бы я хотел решение на этот вопрос, я бы сразу написал его как ответ. Но я этого не сделал по объективным причинам.
Если ты разобрался и решил свой вопрос, у тебя есть возможность написать ответ самостоятельно и отметить его решением.