Тоже считаю важной эту функцию. Могли бы сделать на кнопку Win, как в KDE, если с альтом есть проблемы, так как его используют програмы. А win — это системная кнопка. К тому же и называется подходяще — «windows», то есть для работы с «окнами»
На windows 10 я нашел только стороннюю програму AltDrag, которая имеет кучу проблем: изначальлно проблемы с масштабированием интерфейса — неверно определяет границы окон. Нужно в настройках совместимости включить совместимость с масштабированием интерфейса. И есть большая проблема, что появляются некрасивые белые полосы по границам окна, если изменять размер
В целом согласен про постоянные «танцы с бубном». В линуксах они постоянны, и сейчас, кто бы не убеждал, что это хорошая ос для домашнего использования — это абсолютно не так. Мне нравится эта система как система от программистов для программистов
Про Proton спасибо, оставлю ссылку на ваш комментарий в статье, если вдруг кому это сильно пригодится, чтобы он знал в какую сторону гуглить
Ну не сказать что прям переизбрали шаблоны. Допустим вам нужно в функции принять вектор из разных, заранее известных типов и как-то обработать его. Как это сделать с шаблонами? Ну с шаблонами даже такой вектор создать не получится, а если передавать через variadic template, то будет больше заморочек с рекурсией, перегрузкой шаблонов, и передача большого числа аргументов замороченей простого вектора
Я имел ввиду что в моей функции реализации можно не просто выполнить по действию для разного аргумента, а можно сделать поведение относительно типов других аргументов.
Можно сказать что у меня это обычная variadic функция, которая дополнительно неявно получает количество своих аргументов и массив типов. У вас же можно сказать реализация функции уже записана в макросе, а в нем невозможно делать какие-то сложные операции
Повторюсь, у вас хороший макрос, сделанный проще и пограмотнее моего. Но все же это не одно и то же
Но это конечно не тоже самое. В вашем решение вызываются для кажого аргумента отдельная функция, и нет собственно функции, которая принимает все аргументы. Хотя для большинства решения а тем более для print это может даже лучше
Еще заметил у вас do while(0), это как понимаю чтобы можно было использовать макрос в однострочных циклах и условиях. Учту это, а то у меня нигде это не использовалось
Видел и не раз. Может это были технические статьи и я не разобрался
Конечно грубоватые тут некоторые люди в сообществое, которые так отвечают человеку, который только что присоединился. Я же это отдельным комментарием спросил, а не в самой статье, это даже не оффтоп
Спасибо большое за пояснение. Можете еще уточнить, это касается только указателей на аргументы, или любая запись вроде
int a = 5;
int* b = &a;
Будет ub? Ведь часто именно такие примеры есть при объяснении работы с указателями
И по каким запросам можно что-нибудь нашкглить про проблему указателей на стек? Бегло я ничего не смог найти
За что минус, тут нет никакой солидарности к людям, которые только зарегистрировались? Нормальный вопрос, так как в редакторе нигде нельзя выбрать оглавление. Поставил перед заголовками якори и они огде не отображаются
Гуглить пытался, в справке по форматированию не нашел. Что сразу минусить? Нормальный вопрос
Нужно сначала посчитать количество аргументов, и написать макросы для всех количеств аргументов. И только потом узнавать тип аргумента, с подстановкой нужной функции.
В моем решение если рассматривать макросы снизу вверх, то так и происходит
На нулевое количество аргументов тоже есть место для макроса, есно на склейке с нулём.
Проблема не в том, что cool_print_0 не определен. Проблема в том, что при подстановки ничего появляется ненужная запятая и синтаксическая ошибка
cool_print_(, 63, 62, 62, ...)
Наглядность — дело субьективное. Для меня каст в воид и обратно кажется очень понятным
Мне больше интересно есть ли тут ошибка при взятии указателя на стек, или это просто какое-то предубеждение, что их нельзя брать ради того, чтобы нечаянно не передать в другую функцию?
Да, берется. Если это опасно, то могу исправить :) Я так сделал для наглядности, чтобы была отдельная переменная x
В Си я не эксперт, так что вам виднее. Это есть такое правило, что не в коем случае не стоит брать указатель на стек? Почему? Потому что если мы будем его использовать в другом блоке, то все поломается, или тут что-то большее? Просто в данном случае он используется более как локальный синоним. Логично, что потом я на этот указатель больше не ссылаюсь
Это мне напоминает другую ошибку, про которую я не написал, когда я в строку
cool_print_##n(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11,_12)
Первым аргументом поместил разделитель " ". Он каким-то образом «поднялся» вверх в самый верхний вложенный макрос
Я правда не знаю, это стандартизированная фишка макросов, или ошибка VS
На windows 10 я нашел только стороннюю програму AltDrag, которая имеет кучу проблем: изначальлно проблемы с масштабированием интерфейса — неверно определяет границы окон. Нужно в настройках совместимости включить совместимость с масштабированием интерфейса. И есть большая проблема, что появляются некрасивые белые полосы по границам окна, если изменять размер
Про Proton спасибо, оставлю ссылку на ваш комментарий в статье, если вдруг кому это сильно пригодится, чтобы он знал в какую сторону гуглить
Ну не сказать что прям переизбрали шаблоны. Допустим вам нужно в функции принять вектор из разных, заранее известных типов и как-то обработать его. Как это сделать с шаблонами? Ну с шаблонами даже такой вектор создать не получится, а если передавать через variadic template, то будет больше заморочек с рекурсией, перегрузкой шаблонов, и передача большого числа аргументов замороченей простого вектора
Я имел ввиду что в моей функции реализации можно не просто выполнить по действию для разного аргумента, а можно сделать поведение относительно типов других аргументов.
Можно сказать что у меня это обычная variadic функция, которая дополнительно неявно получает количество своих аргументов и массив типов. У вас же можно сказать реализация функции уже записана в макросе, а в нем невозможно делать какие-то сложные операции
Повторюсь, у вас хороший макрос, сделанный проще и пограмотнее моего. Но все же это не одно и то же
Хорошее альтернативное решение.
Но это конечно не тоже самое. В вашем решение вызываются для кажого аргумента отдельная функция, и нет собственно функции, которая принимает все аргументы. Хотя для большинства решения а тем более для print это может даже лучше
Еще заметил у вас do while(0), это как понимаю чтобы можно было использовать макрос в однострочных циклах и условиях. Учту это, а то у меня нигде это не использовалось
Видел и не раз. Может это были технические статьи и я не разобрался
Конечно грубоватые тут некоторые люди в сообществое, которые так отвечают человеку, который только что присоединился. Я же это отдельным комментарием спросил, а не в самой статье, это даже не оффтоп
Спасибо большое за пояснение. Можете еще уточнить, это касается только указателей на аргументы, или любая запись вроде
int a = 5;
int* b = &a;
Будет ub? Ведь часто именно такие примеры есть при объяснении работы с указателями
И по каким запросам можно что-нибудь нашкглить про проблему указателей на стек? Бегло я ничего не смог найти
За что минус, тут нет никакой солидарности к людям, которые только зарегистрировались? Нормальный вопрос, так как в редакторе нигде нельзя выбрать оглавление. Поставил перед заголовками якори и они огде не отображаются
Гуглить пытался, в справке по форматированию не нашел. Что сразу минусить? Нормальный вопрос
В этой статье произощес сильный сбой форматирования после одобрения модерацией:
https://m.habr.com/ru/post/553636/
Под спойлером после блока "задумка" в начале статьи я более-менее подробно описал произошедшее
В моем решение если рассматривать макросы снизу вверх, то так и происходит
Проблема не в том, что cool_print_0 не определен. Проблема в том, что при подстановки ничего появляется ненужная запятая и синтаксическая ошибка
cool_print_(, 63, 62, 62, ...)
Мне больше интересно есть ли тут ошибка при взятии указателя на стек, или это просто какое-то предубеждение, что их нельзя брать ради того, чтобы нечаянно не передать в другую функцию?
В Си я не эксперт, так что вам виднее. Это есть такое правило, что не в коем случае не стоит брать указатель на стек? Почему? Потому что если мы будем его использовать в другом блоке, то все поломается, или тут что-то большее? Просто в данном случае он используется более как локальный синоним. Логично, что потом я на этот указатель больше не ссылаюсь
Вот так переопределил
Вот такая ошибка:
Это мне напоминает другую ошибку, про которую я не написал, когда я в строку
cool_print_##n(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11,_12)
Первым аргументом поместил разделитель " ". Он каким-то образом «поднялся» вверх в самый верхний вложенный макрос
Я правда не знаю, это стандартизированная фишка макросов, или ошибка VS
Пока что прикреплю в начале статью png версию всего текста
Про dummy не понял вас. Что это за тип, и зачем функция печати для него
Могу, но там очень много. И не факт что этот баг не повторится после модерации. Я надеюсь модераторы смогут починить