Лучшая структура папок для C++ межплатформенная библиотека и привязка

Question

Лучшая структура папок для C++ межплатформенная библиотека и привязка

Я провел некоторое тестирование, и я думаю, что даже используя subscribe() в качестве огня и забыть, дождусь завершения запроса, прежде чем вернуть ответ веб-браузеру или REST-клиенту (по крайней мере, в моих простых тестах это выглядит так) , Итак, вы должны сделать то же самое из @Async, создать другой поток:

@PostMapping("/create")
public Mono<Resource> create(@Valid @RequestBody Resource r) {
    return processor.run(r)
    .subscribeOn(Schedulers.elastic()) // put eveything above this line on another thread
    .doOnNext(string -> repository.save(r)); // persist "r", not changing it, though

}

И класс Processor:

Mono<String> run(Resource r) { 
    WebClient webClient = WebClient.create("http://localhost:8080");
    return webClient.get()
           .retrieve()
           .bodyToMono(String.class);
}

54

c++ cross-platform

задан Kevin P. 13 April 2009 в 17:00

3 ответа

Другие вопросы по тегам:

c++ cross-platform

Похожие вопросы:

score 11 · Answer 1

Структура выглядит хорошей мне, но существует несколько точек:

нормально разделить C++ заголовочные и исходные файлы в различные каталоги, или возможно существует структура в каталоге модулей, который Вы не показываете?
Вы, вероятно, хотите, чтобы каталоги поместили промежуточные файлы как *.obj в
Вы будете нуждаться в различных каталогах для отладки и выпускать выходные файлы
каталог для установщиков как InnoSetup и их файлы установки может быть полезным - необходимо принять philosphical решение относительно ли к управлению версиями они

Что касается инструментов для создания структуры несколько минут потратили запись, что сценарий удара - все, в чем Вы нуждаетесь - стоит иметь те же инструменты (как удар) доступный на всех платформах.

score 8 · Answer 2

Почему Вам нужны различные папки платформы для двоичных файлов? Вы собирающийся создавать этот исходный код под различными platoforms, но с той же файловой системой?

Если да, я думаю, что Вам нужен компилятор определенные папки также.

Почему Вы не используете различные папки для отладочной сборки и сборки конечных версий, возможно, unicode и non-unicode, однопоточности или сборок многопоточности?

Взгляд bjam или Scons делают заменители. Возможно, Вам не нужны различные папки в каталоге сборки.

Я думаю, что будет лучше, если все модули из каталога "модулей" будут содержать "тестовый" каталог для теста сам.

И в последний раз - видят библиотеку повышения, этот platofrm independed библиотека, которые имеют хорошую структуру.

Также попытайтесь получить идеи от antother платформы independed проекты.

Структура папок повышения:

boost - root dir
- boost - library header lib ( for users )
- libs - library source dir ( one dir per lib )
    - build - library build files ( if they are needed )
    - doc - documentation files
    - example - sample programs
    - src - library source files
    - test - programs and srcipts for testing module
- bin - created by bjam build system
    - libs
        - <lib-name>
            for all compiled folders from libs [example|test|build]
                - <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]>
                    contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system

- doc
- tools

При выборе bjam - Вы не будете заинтересованы на сборке и структуре папок мусорного ведра.

Также Ваш libs/src/dir мог содержать собственный для всех файлов платформы и связать директоров для платформы spcific файлы.

Я не вижу серьезных проблем в Вашей структуре папок, возможно, Вы будете видеть их, когда запустят прототип проекта записи.

score 2 · Answer 3

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

Вы собираетесь обслужить Win64? Это будет все больше важной целью.

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

Вместо этого если Ваш компилятор позволяет его, отложите промежуточные каталоги одной стороне.

Иначе удостоверьтесь, что Вы добавляете все промежуточные каталоги к своим svn свойствам исключения. Некоторый GUI делает это легче, чем другие (Черепаха в Windows, Краеугольном камне или Версиях на OS/X).