Неправильный вывод в textEdit

} Почему в textEdit все 20 раз выводится ‘)’ ?

а скока надо?

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

код неполон небось

При вводе в поле textEdit

if ( new_Label[d] == ‘(’);

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

int b=20; int d=0; QString new_Label;

Не пиши так, пожалуйста. Вот так делай:

    int b = 20;
    int d = 0;
    QString newLabel;

Ну что, пацаны, наверное баг в компиляторе. Стопудова.

Спасибо, глазам полегчало.

как вообще в только что созданном стринге может что-то лежать? почему там ТС ищет левую скобку? чтоб что-то там найти надо туда это сначала положить.

ps… ну вот там и скобочки оказались :)

Потому что у тебя после if точка с запятой стоит. То есть оператор закончен и все, хотя странно что нет синтаксических ошибок.

То есть оператор закончен и все, хотя странно что нет синтаксических ошибок.

а это не ошибка, это просто пустое тело if. никто не запрещает.

Но меня вот больше удивляет, что код обернутый в избыточные {} срабатывает без каких-либо синтаксических ошибок. Забавно

как вообще в только что созданном стринге может что-то лежать?

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

Но меня вот больше удивляет, что код обернутый в избыточные {} срабатывает без каких-либо синтаксических ошибок. Забавно

Так ЕМНИП в плюсах можно код так в «блоки» выделять.

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

#include <stdio.h>
int main() {
    {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    printf("Hi\n");
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
}

Работает-таки. ;)

В сях, видимо, тоже (см.выше).

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

Ну насколько я помню С и плюсы, то когда ты только создал переменную и выделил под нее память, лежать в ней может все, что угодно.

это обьект класса, при инициализации длина строки будет нулем, а залезть за длину интексом ему не дадут проверкой…ну если они там в куте проверку таки делают. но раз у него работало.. проверку они не делают - что нехорошо. тут все короче зависит от конструктора класса и как реализован оператор []

оказывается можно включить предупреждение
-Wempty-body

оказывается можно включить предупреждение -Wempty-body

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

#include <stdio.h>
int main() {
    int a = 8;
    {
        int b = 9;
        printf("%d\n", a);
    }
    printf("%d\n", b);
}

test.c: In function ‘main’:
test.c:14:20: error: ‘b’ undeclared (first use in this function)
   14 |     printf("%d\n", b);
      |                    ^
test.c:14:20: note: each undeclared identifier is reported only once for each function it appears in

О, действительно работает как внутренняя область видимости. Хотя мне сложно представить возможности применения подобной конструкции, в т.ч. и для RAII.

В некоторых языках программирования, прежде всего в C++, деструктор переменной немедленно вызывается при выходе из её области видимости, в том числе в ситуациях, когда возникло исключение, и таким образом, ресурс необходимо освободить, что делает RAII ключевой концепцией для написания кода, безопасного при исключениях (в языках, семантика которых предполагает обязательное наличие сборщика мусора, объект продолжает существовать, пока на него существуют ссылки).

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

Так чтобы сработал конструктор класса, объект еще нужно создать. А он его только объявил.

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

{
  T x__; //тут сработает конструктор

....
....
  // <--А тут деструктор
}

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

А, да, неплохо.

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

Отлично! Теперь целесообразность применения точно ясна, arigatou gozaimasu.

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

Да, вы правы, так и есть.

Так ведь, пожалуйста, будьте любезны. Материалов полно.

Никто не запрещает. Ты внутри блока можешь локальные переменные объявить, а потом освободить стек, например.

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

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

Впрочем, нужно в опции компилятора и линкера нужно глянуть ...

Впрочем, нужно в опции компилятора и линкера глянуть …

При объявлении переменных произвожу всегда их инициализацию.
Если не инициализировать скажем адресные поля структур, то

ОТГРЕБЕТЕ ...

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

потому что у тебя переменная пустая, там же ничего не было перед циклом.

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

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

Но я бы ещё добавил:

1. Если ты обрабатываешь строку, выводить её после каждой итерации цикла — плохая идея. Лучше после цикла выведи результат.

2. Если я правильно понял твой замысел, весь этот цикл элементарно заменяется одним QString::replace().

3. Объявлять счётчик и границы цикла (если они больше нигде не нужны) обычно лучше всего внутри самого for. Да, из этого правила бывают исключения, но тут явно не тот случай.

P.S. И кстати, чем у тебя с QuaZip дело закончилось? Ты из каждой темы исчезаешь, ни решённой не помечаешь, ни наоборот.

Я в эту переменную ввожу через виджет QlineEdit { QPushButton button=(QPushButton)sender(); QString All_numbers; All_numbers=(textEdit->text()+button->text()); QString new_Label; new_Label=All_numbers; textEdit->setText(new_Label); }

не осилил все это дело с Quazip

Разве код сохранения из поля ввода не должен быть после какого-то сигнала типа textChanged? А не просто так вот.
И вообще у тебя где все таки объявлена переменная? Код та у тебя тут с объявлением, а ты говоришь, что в другом месте уже значение присвоил.

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

Печально. Я пользовался, успешно (правда, более старой версией).

Если ты итерируешься по строке, то вместо b используй new_Label.size(). Или ты любишь, когда ноги простреляны?

Проблема решена, нужно было переменную QString new_Label объявить в mainwindow.h