Что такое Exception in thread "main" java.lang.NoSuchFieldError: data at HelloApp.main(HelloApp.java:12)?

Спасибо, короче, пока буду в терминале всё делать, спасибо.

Как упростить выражение с факториалами?

Не понимаю(.

После раскрытия скобок:
S = n!/n! + 1!/n! + 2!/n! + ... + (n-1)!/n!
S = 1 + 1!/n! + 2!/n! + ... + (n-1)!/n!

Либо нужно вывести формулу следующего члена, либо всего ряда... Не понимаю.
S1 = 1
Sn+1 = S

Как вообще это нужно понимать? Как формула члена последовательности? Или как формулу ряда? Не понимаю.

Как упростить выражение с факториалами?

Akina, если я правильно понял вопрос, то проблема будет в том, что первое слагаемое будет 1/n!, что опять же требует вычисление факториала n. При n = 300 будет переполнение. Иначе можно было бы легко найти факториал, а потом пошагово делить его и найти сумму в делимом.

(Вопрос без однозначного ответа) Почему в window socket 2 используется так много различных дефайнов и псевдонимов?

Спасибо за подробный ответ!

Почему выражение (-1ll) в ассемблерном коде MSVC равно ff ff ff ff?

Круто! Спасибо! А я уже напрягся, что не понимаю суффиксы.

Правильно ли я понимаю правила arithmetic conversions?

Огромное спасибо!

Почему утверждается, что int32_t имеет ширину точно 32 бита, если он является всего лишь псевдонимом int, который может быть больше 32 бит??

Wataru, спасибо!!

Почему утверждается, что int32_t имеет ширину точно 32 бита, если он является всего лишь псевдонимом int, который может быть больше 32 бит??

Спасибо большое!

Почему утверждается, что int32_t имеет ширину точно 32 бита, если он является всего лишь псевдонимом int, который может быть больше 32 бит??

Спасибо!

Где вы взяли, что int32_t - это псевдоним int?

1) msvc 17.3.5: typedef int int32_t;
2) g++ -E: typedef int int32_t;
3) Extended integer types (since C++11) The extended integer types are implementation-defined. Note that fixed width integer types are typically aliases of the standard integer types.

При компиляции на другую архитектуру внезапно может оказаться, что int32_t - нифига не псевдоним к int.

Кажется, стало понятно.

int, long int, long long int, то есть стандартные типы, подчиняются стандарту, где говорится, что "размер должен быть НЕ меньше, чем", но может быть и больше.

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

Если представить такую архитектуру (и компилятор), где char равен 32 битам, то там будет typedef char int32_t;

Правильно понимаю?

Спасибо большое!

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

Ну, или https://c-faq.com/malloc/malloc1.html

#include <string.h>
for (char buffer [ 100 ] = { 0 }; fgets ( buffer, 100, file ) != NULL; ) {
    char* p;
    if ((p = strchr ( buffer, '\n' )) != '\0') {
        *p = NULL;
    }
}

А с другой стороны, можно и так

for (char buffer [ 100 ] = { 0 }; EOF != (fscanf_s(file, "%[^\n]%*c", buffer, 100)); ) {

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

jcmvbkbc, ну да, конечно, пробовал такой вариант,

for (char buffer [ 100 ] = { 0 }; EOF != fscanf_s ( file, "%[^\n]\n", buffer, 100 ); ) { // [^\n] читать всё и остановиться на \n ; \n пропустить \n

.
но он показался колхозом, потому и задал вопрос.

Проблема в том, что в msvc такой вариант не универсален - он нормально читает файлы, но плохо читает консоль. Функция читает все символы, встречает \n, останавливается, пропускает \n и зависает - потому терминал не возвращает управление. Тогда нужно ввести хоть один символ и нажать ввод. Естественно, что это будет прочитано на следующей итерации. Это можно исправить это с помощью "%[^\n]" и fgetc(), но тогда тогда получается чушь при чтении файла, да и вообще не красиво.

И получается, что самый универсальный способ это:

int custom_read ( FILE* file, char* buffer, int size ) {
    int i = 0;
    for (int c; (EOF != (c = fgetc ( file ))) && (i < size-1) && c != '\n'; ++i) {
        buffer [ i ] = c;
    }
    if (i) {
        buffer [ i ] = '\0';
    }
    return i;
}

Просто прочитать .txt,
Hello 123
World 456
отбросить '\n' и сохранить каждую строку, при необходимости сделать тоже самое через терминал.

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

Dmitrii, getline нет в msvc.

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

Если вам не нужно "зависать" на символе, то используйте другой формат, например %c, %s (симолы/строки)

Мне нужно считывать из файла строки с пробелами, оканчивающиеся символом переноса. Получается, что самый удобный и стабильный вариант - это самодельная функция на основе fgetc() вместо того, чтобы использовать, казалось бы, универсальную для всего scanf(). Или я не прав?

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

Спасибо за ответ! Конечно, я читал этот ман. Но в том и вопрос, что я не понял, как из вышенаписанного текста нужно было понять, что процесс матчинга останавливается на символе, который включен в сет, который начинается с ^.

Почему fopen устанавливает ошибку Invalid argument в errno при fopen в режиме r+ после w и fopen в режиме w+ после r?

res2001, кстати,

Вообще читать errno надо, только если fopen вернул NULL. При нормальном завершении errno не меняется.

наверное, можно дополнить, что есть fopen_s, которая принимает адрес указателя FILE * и возвращает errno_t. Эта функция так же меняет errno в состояние Invalid argument, но сама возвращает 0.

fopen_s ( &file, "file.txt", "r+" );
errno: 0x16 (Invalid argument)

errno = fopen_s ( &file, "file.txt", "r+" );
errno: 0x00

Почему поведение fscanf ( stdin, "%c", &c ) различается при чтении EOF в msvc и gcc?

Как всё это сложно.
Получается так:
1. Лучше вообще не использовать Ctrl+Z ни в каком виде.
2. При чтении stdin из терминала или (при перенаправлении) из файла лучше читать до '\n', например.
3. Не использовать feof при работе с stdin, когда он указывает на терминал (ну, или использовать, но использовать clearerr).

Почему fopen устанавливает ошибку Invalid argument в errno при fopen в режиме r+ после w и fopen в режиме w+ после r?

res2001, да, именно так, и при w+ тоже. Ещё раз спасибо.

Почему fopen устанавливает ошибку Invalid argument в errno при fopen в режиме r+ после w и fopen в режиме w+ после r?

res2001,
1.
Нужно было максимально упростить тело задачи. Было сложно увидеть и заметить, что создаются пустые файлы.
2.

#include <stdio.h>
#include <errno.h>

void test1 () {
    FILE* pFile;
    int er;

    pFile = fopen ( "file1.txt", "w+" );
    er = errno;
    perror ( "?" ); // ? : invalid argument
    fclose ( pFile );
}

void test2 () {
    FILE* pFile;
    int er;

    pFile = fopen ( "file2.txt", "r+" );
    er = errno;
    perror ( "?" ); // ? : Invalid argument
    fclose ( pFile );
}

int main ( void ) {
    test1 ();
    test2 ();
    return 0;
}

3.
Если файлы пустые:
?: Invalid argument
?: Invalid argument
Если есть хотя бы байт:
ошибок нет
4.
Самый главный вывод - это всё вообще неважно, важно не смотреть errno просто так.

Почему fopen устанавливает ошибку Invalid argument в errno при fopen в режиме r+ после w и fopen в режиме w+ после r?

Rsa97, спасибо, главное понятно, что

Вообще читать errno надо, только если fopen вернул NULL.

Почему fopen устанавливает ошибку Invalid argument в errno при fopen в режиме r+ после w и fopen в режиме w+ после r?

res2001,

Когда pFile уже закрыт, то вызывать для него clearerr - вообще смысла нет - он вернет ошибку. И clearerr сбрасывает флаги ошибок файла, а не errno.

конечно, туплю.

r+ выдаёт ошибку (меняет errno) при открытии пустого файла.