Выпуск Bluetuith v0.1.8

Там сырой указатель

Архитектура процессоров x86 и x64 предоставляет возможности аппаратной защиты областей памяти.
Разработчики компиляторов не используют эту возможность, так как тогда код будет некорректно работать на других типах процессоров (точнее не надёжно работать).

Архитектура процессоров x86 и x64

Ложная дихотомия. x64 — это частный случай архитектуры x86.

Перечитайте еще раз

Перечитайте еще раз

А… ты не понимаешь как зависимости в go резолвятся. Почитай доки.

Чем CLI.

Где?

vec : std::vector<int>
vec.end() : std::vector<int>::iterator

Обожаю плюсы за то что *a может означать вообще что угодно в зависимости от контекста.

p1 = p + 42;

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

По ссылке в 8 строчке

Там всё что угодно может означать вообще что угодно.

Солнышко мое, почитай стандарт пожалуйста.

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

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

Это не винегрет, это арифметика указателей.

	int *p, *p1, *p2;

	p = calloc(10, sizeof(*p));

	p1 = p + 1;
	p2 = &p[1];

	assert(p1 == p2);

	return 0;

Это не винегрет, это арифметика указателей.

Можно называть это как угодно, суть от этого меняется.

Можно называть это как угодно, суть от этого меняется.

Ауф.

Можно называть это как угодно, суть от этого меняется.

У этой штуки четко определенные границы применимости, если что.

По ссылке в 8 строчке

Там

std::cout << *vec.end() << std::endl;

Кто из них, по-твоему, сырой указатель?

std::cout  : std::ostream
vec::end() : std::vector<int>::iterator
std::endl  : std::basic_ostream<char>& (*)(std::basic_ostream<char>&)

Арифметика указателей именно то, ради чего выбирают Си или Си++ вместо какого-либо другого языка.

Как без этого «винегрета» удобно работать с указателями на элементы массивов?

Вот этот метод

vec.end()

возвращает указатель, который ты пытаешься разыменовать в сишном стиле.

Зачем дурочку корчишь, не пойму?

С каких пор std::vector::iterator является сырым указателем? А std::unique_ptr в твоей вселенной тоже сырой указатель?

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

Ты плюсы на картинках видел?

Тут тоже указатель?

#include <iostream>
#include <optional>

int
main(void)
{
	auto var = std::optional{true};
	bool val = *var;
	std::cout << val << std::endl;
}

С каких пор std::vector::iterator является сырым указателем?

Я не говорил такого. Я сказал, что он возвращает указатель.

vec.end() является функцией, которая возвращает std::vector::iterator.

std::vector::iterator является классом, а не функцией. Ни один из методов этого класса указатель не возвращает.

Кто «он», который возвращает указатель?

Это не указатель. Это итератор.

Не от контекста, а от оператора. Любой оператор может быть переопределен. В данном случае у класса std::vector::iterator есть метод operator*()

Ну так это вообще STL. А он ужасен. Никто же не мешает писать классы нормально.

Не от контекста, а от оператора. Любой оператор может быть переопределен. В данном случае у класса std::vector::iterator есть метод operator*()

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

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

А на данный момент STL часть стандарта Си++. Поэтому если нет жёстких требований по скорости, то уж лучше Go.

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

А на каком-то другом языке vec.end().operator_star() более понятно? Или в чём суть претензии?

В том что язык наследует легкость RCE от C, а понятность кода стала только хуже :(

а понятность кода стала только хуже

Чем хуже?

То, что было в Си

plus(my_class_data(a), mult(my_class_data(b), my_class_data(c)))

стало

a.data() + b.data() * c.data()

Неужели стало менее понятно?

STL кусок говна. Зачем вообще в стандарте языка STL – для меня загадка до сих пор.

До STL в любой более-менее крупной библиотеке была частичная кривая реализация std::string и std::vector. А при использовании нескольких библиотек постоянно приходилось перекладывать байтики из одного типа в другой.

Так и сейчас приходится. Кому-то std::string, кому-то boost::container::string, кому-то QString, а кому-то const char* подавай.

кому-то const char* подавай

Это сишкой покоцанные)

Сейчас есть std::string и всё нормальные работают с ним. Ибо стандарт.

Да нет. Вот например MySQL++. Они будут все контейнеры в мире поддерживать? Нет. const char* и привет.

std::string почти бесполезный класс. У него нет методов. Нафиг нужна строка, в конструктор которой нельзя передать число, и из которой нельзя геттером получить число?

Число чего хочешь передавать при работе с UTF-8?

Прочто создать строку с числом. Просто в конструкторе. Без std::to_string

Мое любимое вот это:

#include <iostream>

static
void foo(int &v)
{
	v = 10;
}

int
main(void)
{
	int v = 5;
	foo(v);
	std::cout << v << std::endl;
	return 0;
}

Читая main() невозможно понять что foo() модифицирует v :D

видимо тем что в bluetoothctl тебе нужно руками водить mac-адрес нужного девайса, а тут для этого типа есть меню

Вот например MySQL++. Они будут все контейнеры в мире поддерживать?

У них там мешанина из const char* и std::string. Плюс, как я понял из чтения по диагонали, у них ещё и свой String есть.

Да, это представление SQL строки. Она может быть NULL.

Ну и замечательно, чем больше вариантов - тем лучше. Суть моего позапрошлого коммента была в том, что не нужно без веских причин использовать небезопасные C-like типы.

А в каком виде? У %f в C не просто так столько квалификаторов.

В Си аналогично, если v строка, массив или структура.

Это верный путь к 2+2-2=20 как в js.