Всем привет. Кто может подсказать откуда берутся дебажные секции в shared либе, если она компилируется без всяких -g ? Но при этом, если убрать -pthread, то эти секции пропадают.
приходят из libpthread?
Berkus
Vitaliy
Там нет дебажных символов
Vitaliy
Я через readelf смотрю
Vitaliy
Я оговорился
Vitaliy
Я имел ввиду дебажные секции
Berkus
забыл атомики и заборчики
Berkus
что дает квалификатор volatile для переменной? начнем с этого
Arseny
Все проще. По стандарту такой код UB
Aidar
по идее stop может быть в невалидном состоянии
Aidar
для bool не гарантируется аномарность
Aidar
для atomic<bool> не гарантируется lockfree
Berkus
очередность инструкций у тебя будет разная пушо два треда, компилятор и volatile не спасут
Anonymous
Ребята подскажите литературу для написания парсера текста
Berkus
нет, он отрубает сохранение однажды полученного результата в регистре, при каждом обращении к переменной будет выполнено новое чтение из памяти. никаких гарантий ордеринга или атомарности там нет
Anonymous
Ребята подскажите литературу для написания парсера текста
Yacc/bison + lex/flex. Есть как книги, так и хорошая дока. Если совсем базовое понимание нужно, то dragon book
Oleg
Опасная рекомендация. После dragon book возникает желание самому написать, а не лезть во всякие бизоны.
Anonymous
Anonymous
Ну если нет, например, понимания НБНФ, то в бизон тоже смысла лезть особо нет
Anonymous
Еще можно на antlr посмотреть. Доки тоже вагон и тележка. Но это для адептов LL грамматик :)
Berkus
для человеческого текста надо другие парсеры )
Oleg
Еще можно на antlr посмотреть. Доки тоже вагон и тележка. Но это для адептов LL грамматик :)
Что странно, при этом к у них LL(*) и это даже часто работает.
Oleg
для человеческого текста надо другие парсеры )
Да, рекуррентные нейронные сети вроде бы эта лабуда называется.
Anonymous
Для человеческого текста нужны токенайзеры, леммеры, word2vec и уже потом что-нить типа lstm или другие rnn
Anonymous
Но перед всем этим нужно ответить на простой вопрос - чтобы что? Сетки для какой-то цели прикручиваются с каким-то ожидаемым результатом, а не как сферический конь в вакууме
Anonymous
коллеги, добрый вечер, вопрос у меня, довольно простой
дано:
boost::posix_time::ptime
найти:
способ вывода в строку в формате
""2018-01-15T18:15:30.12345Z"
ключевой момент - как заставить выводить мили/микросекунды даже если они по нулям.
std::string to_iso_extended_string(ptime)
умеет почти все, кроме милисекунд, точнее она их показывает, когда они есть. Может есть возможность указать явный формат?
И да, если я правильно понимаю, то индейская национальная изба мне, а не микросекунды.
kitsu
коллеги, добрый вечер, вопрос у меня, довольно простой
дано:
boost::posix_time::ptime
найти:
способ вывода в строку в формате
""2018-01-15T18:15:30.12345Z"
ключевой момент - как заставить выводить мили/микросекунды даже если они по нулям.
std::string to_iso_extended_string(ptime)
умеет почти все, кроме милисекунд, точнее она их показывает, когда они есть. Может есть возможность указать явный формат?
И да, если я правильно понимаю, то индейская национальная изба мне, а не микросекунды.
http://www.boost.org/doc/libs/1_63_0/doc/html/date_time/date_time_io.html
гугл выдал это
Anonymous
Joy
Парни, вопрос будет очень тупой, и если для этого чата его уровень низкий - перенаправьте в более "новичковый" что-ли.
Итак, есть структура проекта - основной каталог с исходниками src, в нем общий /headers и несколько папок под заголовочные файлы упорядоченные по классам: /monsters /items /states
Основной вопрос - как правильно это добро друг в друга инклудить?
У меня постоянно получалось какое-то "перекрестное опыление", когда классу Game нужно знать класс Battlefield, наоборот тоже, получается каша и ошибки, а работающую конфигурацию получаю методом тыка ((
На данный момент вопрос решается так, что я предварительно объявляю нужные классы в заголовочном файле, а инклуд уже в cpp - но IDE это говно подчеркивает (потому что IDE тоже говно ахах)
К примеру вот так выглядит класс Game
https://s9.postimg.org/hlefwoqn3/2018-02-17_06-46-47.png
Joy
Я его и использую, но возможно надо порыть в сторону того почему gnome builder его подчеркивает как ошибку
Anatoly
Я его и использую, но возможно надо порыть в сторону того почему gnome builder его подчеркивает как ошибку
с точки зрения языка С++ ваш код не содержит проблем, разбирайтесь с IDE. а так де факто стандартная структура проекта:
build - сборочные скрипты, cmake описание проекта и т.п.
doc - документация
include - заголовочные файлы
src - исходные файлы
test - тесты
Joy
include выносятся из src?
Joy
А как прописывать инклюды? Настроить переменную окружения? Или "../include/xzxz.h"
Joy
Я интересую как правильней, сделать можно и так и так
Surreal
cmake
Alexander
Я интересую как правильней, сделать можно и так и так
Сделай cmake проект и пропиши include_directory
Anatoly
А как прописывать инклюды? Настроить переменную окружения? Или "../include/xzxz.h"
обычно делают
include/<имя библиотеки или приложения>/*.h
и включают после
#include "myproject/myheader.h"
предварительно описав в CMakeLists.txt через target_include_directories:
target_include_directories(${PROJECT_NAME} PUBLIC include)
Anatoly
в итоге, твои заголовки не пересекуться с thirdparty заголовками и сразу отличишь свои от thirparty в коде.
Anatoly
ну и раз пошла такая пьянка включай заголовочные файлы в следующем порядке:
1. стандартные заголовки
2. thirdparty заголовочные файлы
3. свои заголовочные файлы
например
#include <vector> // standard library
#include "boost/optional.h" // thirdparty library
#include "myproject/game.h" // my header
...
Anatoly
Вакансии публикуются не здесь через согласование с @AlexFails , читайте правила.
Александр
Anonymous
Anatoly
а почему именно такой порядок?
для новичков должны быть какие-то правила, пусть будут такие.
Anatoly
и не поспоришь..
ну, на самам деле это вольный перевод boost guideline: https://github.com/boostorg/geometry/wiki/Guidelines-for-Developers
Anatoly
вообщем, к чему это все. лучше плохой стиль, чем отсутствие стиля. как-то так.
Berkus
А как прописывать инклюды? Настроить переменную окружения? Или "../include/xzxz.h"
если хедер лежит в include/sub/dir/head.h
то в cpp файлах пишется #include "sub/dir/head.h"
Berkus
а путь к include прописывается в билдсистеме
Egor
ну и раз пошла такая пьянка включай заголовочные файлы в следующем порядке:
1. стандартные заголовки
2. thirdparty заголовочные файлы
3. свои заголовочные файлы
например
#include <vector> // standard library
#include "boost/optional.h" // thirdparty library
#include "myproject/game.h" // my header
...
всё как раз наоборот - 1. текущий хедер, 2. хедеры проекта, 3. хедеры библиотек, 4. стд - https://llvm.org/docs/CodingStandards.html#include-style
Anatoly
всё как раз наоборот - 1. текущий хедер, 2. хедеры проекта, 3. хедеры библиотек, 4. стд - https://llvm.org/docs/CodingStandards.html#include-style
наличие разных стилей предполагает разные правила. какого-то единственно верного стиля едва ли найдется. вот еще один стиль https://google.github.io/styleguide/cppguide.html вообщем, пусть будет хоть какой-то стиль, чем не будет совсем.
Egor
способ обсуловлен объективными причинами, а не желанием сделать так или так
Anatoly
способ обсуловлен объективными причинами, а не желанием сделать так или так
llvm пишет: We prefer these #includes to be listed in this order:
Anatoly
prefer - предпочитаем
Egor
и всё же это не спонтанное решение
Anatoly
если заголовочные файлы не связаны с хаками - порядок включения не имеет значения и относится к вопросам стиля.
Anatoly
а если один заголовочный файл полагается на наличие в цепочке включение уже включенного ранее файла - это расстрел
Egor
если хедер использует <вектор> - надо включать вектор везде в .цпп или один раз в .х ?
Anatoly
если заголовочный файл определяет сущность требующую полное определение vector там и включаешь. на самом деле, не понял к чему ты ведешь.
Igor
всё как раз наоборот - 1. текущий хедер, 2. хедеры проекта, 3. хедеры библиотек, 4. стд - https://llvm.org/docs/CodingStandards.html#include-style
то ли о Мейерса, то ли у Саттеры как раз про это читал. Такой порядок должен быть. На текущий хедер должно "влиять" как можно меньше включений
Эдвард
если хедер использует <вектор> - надо включать вектор везде в .цпп или один раз в .х ?
А в чем Принципиальная разница во включении вектора?
Berkus
если хедер использует <вектор> - надо включать вектор везде в .цпп или один раз в .х ?
iwyu же, где используешь - там и включай
Berkus
если заголовочные файлы не связаны с хаками - порядок включения не имеет значения и относится к вопросам стиля.
вот это верное замечание, в основном какой-то порядок включения диктуется хаками или просто желанием какого-то однотипного стиля
Крылатый
Инклуды лучше в спп
Vsevolod
редко??
Berkus
а у Лакоса ее не найти случайно?
Berkus
у него добрых пол-книги посвящено правильному порядку инклюдов и их взаимосвязи с классами и компонентами
Санжар
у него добрых пол-книги посвящено правильному порядку инклюдов и их взаимосвязи с классами и компонентами
Можно полное название если имеется?
Andrey
Large Scale C++?
Anatoly
#book #design #cpp #eng
Anonymous
Если найдёшь- кинь мне пожалуйста.
Berkus
я точно ее кидал или сюда или в супапро
Berkus
в супапро вот было
Berkus
John Lakos
Berkus
#books