for %%g in (*.*) do call :s_subroutine "%%~nxg" "%%g"
goto :eof
:s_subroutine
set _sss=%1
set _ddd=%_sss:!=_%
ren %2 %_ddd%
exit /b 0
как правильно обеспечить надежность и безотказность ее работы?
доступен 24 часа 7 дней в неделю.
бекап
в случае проблем с доступностью, перезапускать/запускать саму СУБД.
какие операции, запросы или их комбинации нежелательны для БД и могут привести к проблемам.
как это "длина числа в битах", что нужно делать чтобы ее определить.
велосипед не нужно изобретать
Когда писал свой вопрос, думал об аналоге scripting.dictionary с возможностью обращения из другой программы: в процессах висит словарь, одна программа в него пишет, другая - читает. И казалось, что доработка API к существующему словарю - плевое дело.Excel книга в роли "словаря" (или InMemoryDB) с доступом по OLE - самый простой в освоении вариант
Так как cout присутствует в стандартной библиотеке С++, для которой gcc требуется явное связывание с -lstdc++; g++ по умолчанию связывает стандартную библиотеку.
gcc vector.cpp -lstdc++ -o vector.o
char *s = new char[strlen(source) + 1]; ... strcpy_s(s, strlen(s), source);
strlen(s) -- вообще за гранью добра и зла и возвращает случайное число, по большому счёту. Потому что s -- только что выделенный неинициализированный массив.strcpy_s совершенно бессмысленный и неправильный. Бессмысленный, потому что ты только что выделил столько памяти, сколько данных в строке. strcpy_s имеет смысл, если буфер в который ты копируешь -- это массив фиксированной длины. Неправильный, потому что даже если ты имел в виду strlen(source), а не strlen(s), то должен был передать strlen(source) + 1, чтобы было куда 0-терминатор скопировать. Кроме всего прочего, strcpy_s ещё и возвращает код ошибки, который имеет смысл проверить.memcpy(s, source, strlen(source) + 1); или вообще выкинуть s = new char [...]; strcpy_s ... delete [] s; и заменить на s = strdup(source); ... free(s);strcpy_s(s, strlen(source) + 1, source);
Для чего просиживаете на тостере по 5-6 часов в день?