Почему у функции scanf_s в Visual Studio 2013 при использовании "%s" прекращается работа в языке Си .
char name[40];
scanf_s("%s", name);
Тут, когда в консоли ввёл данные, нажимаю энтер, и вижу сообщение "Прекращение работы".
Потому что scanf_s требует указания размера всех передаваемых ей буферов.
scanf_s("%s", name, 40);
у меня старенький компилятор (C++98). функция to_string() присутствует в библиотеке но во время компиляции выдает ошибку.
Фкнкция std::to_string была включена в стандарт C++ 2011. В связи с этим, например, в MS VS 2010 она перегружена не для всех целочисленных типов, для которых она должна быть перегружена в соответствии со стандартом, потому что компилятор MS VC++ 2010 вышел до окончательного принятия стандарта. Об этом недостатке MS VC++ 2010 можете почитать в моем сообщении по этой ссылке
Как компилировать Pascal и в чем лучше писать на Ubuntu? Желательно что-нибудь минималистичное
например, так:
устанавливаем компилятор freepascal
$ sudo apt-get install fp-compiler
создаём файл hw.pas следующего содержимого:
program hello;
begin
writeln ('hello, world.')
end.
компилируем:
$ fpc hw.pas
...
запускаем получившийся бинарник hw
$ ./hw
hello, world.
На вход программе подаётся набор английских букв. Имеется словарь из слов.
Как сгенерировать такие предложения из слов, чтобы каждое из предложений состояло только из тех букв, что были поданы на вход, учитывая количество повторений.
Пример
Входящий набор символов: hellomyfriend
Вывод программы:
Feed Hilly Morn
Feed Hilly Norm
Feed Horny Mill
Freehold Nil My
Refilled Hon My
Defiler Hymn Lo
и т.д.
Выбрать слова которые удовлетворяют входному набору символов у меня получилось. А вот быстро составлять из них предложения не получается.
Я делал методом перебора всех слов. Для фразы myfavoritegame скрипт отрабатывал около 5 минут. На сайте предложения отдаются мгновенно.
Можете что-нибудь посоветовать?
Предположим, вам нужно просто найти все возможные комбинации слов из данного словаря, удовлетворяющие условию. Не отвлекаясь на особенности именно языка.
Важно для поиска:
наличие букв в слове. Исключаем содержащие буквы вне заданных. Исключаем, по мере составления фразы, уже использованные.
считаем буквы. В любой момент составления фразы известно, слова какой длины подходят, или точно не подходят.
повторы букв.
Не важно
порядок букв в словарном слове.
смысл слова.
Для скорости нужно сделать поиск по важным признакам максимально быстрым, при необходимости убрав неважные аспекты.
Для быстрого нахождения слов с подходящим набором букв, но без учёта повторов, можно сделать битный индекс, как предложил @Mirdin: 26 букв английского алфавита = 26 бит. Пронумеровать слова в словаре (или просто индексом считать номер строки) и составить отдельный индекс в две колонки: id слова - битовая маска имеющихся букв. Для словаря меньше 65 тыс. слов, такой индекс будет "весить" 6 байт на слово, менее 400k. Можно держать в оперативной памяти для почти-мгновенного поиска. Так можно быстро найти например, первое слово фразы – просто, чтобы точно были выключены биты "лишних" букв.
Стоит сделать копию словаря, где буквы слова отсортированы по алфавиту, и слова отсортированы по алфавиту. Т.е. опять отдельный индекс: сортированные_буквы - id_слова. Этот индекс будет тяжелее самого словаря на (число слов * 2 или 3 байта). В этом индексе можно быстро находить подходящие слова и отбрасывать точно-неподходящие.
Алгоритм примерно такой. Ищем первое слово. Хочется найти первое же слово наибольшей возможной длины. Перебор по длине, от большего к меньшему. Ест допустимый набор букв и длина. Нашли первое слово, обновили допустимый набор букв и длины слов – ищем следующее слово.
Вывожу в окне содержание папки
dirs = Directory.GetFiles(mw.paths[1]);
foreach (string dir in dirs)
{
//код
}
Список файлов выводится, но он автоматически сортируется по алфавиту, и если изменить имя файла или удалить его, то в окне ничего не поменяется, пока я не закрою окно и не открою снова
Подскажите, как лучше сделать отображение файлов в папке?
Мне не пришлось использовать FileSystemWatcher Я создал новый класс, который отвечал за удаление и изменение имени файла, и в момент изменения файла вызывал метод класса
Столкнулся с проблемой выполнения функции в функции и все это классе библиотеки (использую готовую библиотеку для работы потоков PHPThreads).Я передаю ей в качестве аргумента глобальный массив с данными.Необходимо чтобы функция выполнялась в функции класса корректно.
Сам код:
$mas = array(
'id1',
'id2',
'id3',
'id4',
);
function Eacher($m){
foreach ($m as $value) {
echo $value;
}
}
$Thread->Create(function() {
Eacher($mas);
});
$Thread->Run();
?>
В вашем коде есть две проблемы:
Вы не инициализировали сессию. Похоже, что этот момент является критическим для работы используемой вами библиотеки.
Как уже сказал @Visman, вы неправильно передаете массив в новый тред. Вообще, в PHP для передачи значения в анонимные функции, нужно использовать замыкания. Однако, в вашем случае этот подход не годится, ведь выполнение задачи будет проходить в другом процессе. По этой же причине, вариант с глобальными переменными тоже вряд ли сработает. К счастью, используемая вами библиотека предоставляет специальные средства для передачи аргументов функции. Пример есть в readme
Таким образом, ваш код должен иметь вид:
session_start();
include 'lib/Threads.php';
$mas = array(
'id1',
'id2',
'id3',
'id4',
);
function Eacher($m){
foreach ($m as $value) {
echo $value;
}
}
$Thread->Create(function($vars) {
extract($vars);
Eacher($mas);
}, array(
'mas' => $mas,
));
$Thread->Run();
Взялся я за реализацию IoC для сервиса данных. Сделал вот так:
interface IDataService
{
}
и его реализация (возьмем для примера RpcJson):
class JsonRpcDataService : IDataService
{
}
Далее регистрируем их в IoC-контейнере. Тут все пока понятно.
Далее переходим к собственно к реализации. Я определил следующую структуру сервиса данных:
Модели - тут все понятно
Коллекторы - это вспомогательные классы для получения данных
Обработчики - вспомогательные классы для обработки данных (сохранения, например)
Опишем интерфейс модели:
interface IBook
{
string Autor { get; set; }
...
}
Коллектор:
interface IBooksCollector
{
IEnumerable
И обработчик:
interface IBooksHandler
{
void Save(IBook book);
...
}
Ну и, соответственно, для реализуем каждый из них для JsonRpc. Далее дополняем интерфейс IDataService
interface IDataService
{
IBook CreateBook();
IBooksCollector CreateBooksCollector();
IBooksHandler CreateBooksHandler();
}
И реализуем эти методы в JsonRpcDataService. Их я сделал для того, чтобы я на уровне ViewModel должен был бы связывать только IDataService с RpcJsonDataService, а не все интерфейсы с их реализациями. Чтобы в итоге я мог делать как-то так:
var dataService = IoC.Resolve
Вместо
IBook book = IoC.Resolve
и где-то до этого связывание
IBook book = IoC.Register
где Book - реализация IBook для RpcJson. Так как моделей может быть очень много, то вместо кучи строк вида:
IoC.Register
Все сводится к одной:
IoC.Register
По ходу у меня появились вопросы, на которые я и прошу Вас ответить:
Правилен ли такой подход с созданием инстансов? Или может сделать фабрики вида CreateModel
В первую очередь - неверно ваше желание обойтись минимальным количеством регистраций компонентов. Если у вас 40 компонентов нет ничего зазорного в том чтобы регистрировать все 40 компонентов в контейнере. Это не будет ошибкой. Более того, хотя многие контейнеры и поддерживают в том или ином виде автоматическую регистрацию компонентов, Castle Windsor например, насколько мне известно, обязывает вас явно регистрировать каждый компонент, и такой подход с явной регистрацией имеет определенный смысл. Но здесь вы вправе выбрать то что вам ближе - автоматическая регистрация или явная регистрация каждого компонента, оба подхода имеют свои преимущества и недостатки.
Второе - вы ошибочно ассоциируете регистрацию компонента и последующее получение его из контейнера. Если вы написали IoC.Register
Ответы на ваши вопросы:
Использование фабрик для создания моделей - нормальный подход. Создавать фабричный метод вида CreateModel
По формулировке вашего вопроса видно что вы довольно плохо ориентируетесь в теме и двигаетесь в неверном направлении. Вам стоит потратить немного времени на ее изучение, прежде чем проектировать приложение. В частности паттерны внедрения зависимостей, упомянутые выше (внедрение конструктора и внедрение свойства), существенно важнее для понимания DI, чем любые вопросы, связанные с регистрацией компонентов в IoC-контейнере. Вообще внедрение зависимостей это как раз про эти паттерны, а IoC-контейнер это просто инструмент, облегчающий построение приложения с использованием DI, и DI можно применять вообще без IoC-контейнера.
В комменатриях @cybrex посоветовал прочитать книгу Симан М. - Внедрение зависимостей в .NET. Я присоденияюсь к этому совету, почитайте - не пожалеете.
