Пролог прикольная вещь, ты чо.

А есть какие-то разумные программы, написанные на нём?

Пролог прикольная вещь, ты чо.

это не отменяет его бессмысленности :)

А есть какие-то разумные программы, написанные на нём?

Есть, но малораспространены. Узкая специализация.

А мне довелось увидеть на прологе систему управления подъемниками и турникетами на лыжном курорте в ленобласти. На вопрос "нах..я" был выбран именно пролог так толком никто не ответил.

это не отменяет его бессмысленности :)

Если применяется, пустьи крайне узко, значит уже не бессмысленный.

О смысленности пролога, думаю, можно побеседовать вот тут: https://t.me/joinchat/AkxcTEMQENX1pfPjR0UhPA

А мне довелось увидеть на прологе систему управления подъемниками и турникетами на лыжном курорте в ленобласти. На вопрос "нах..я" был выбран именно пролог так толком никто не ответил.

Я знаю одну компанию, где на прологе была написана система для управления складами и логистикой. В итоге её переписали на Java

Специальный чатег по общим вопросам погроммирования.

Специальный чатег по общим вопросам погроммирования.

Не флудильня, конечно, просто общее.

его начнут использовать только лет через 5 минимум

Все компиляторы, не считая студийный, очень хорошо поддерживают С++17. Подожди полгода - год и студийный тоже подтянется :) Другое дело - если в фирме есть какие-то ограничения

Сейчас пруф скину, сек

http://en.cppreference.com/w/cpp/compiler_support clang и gcc все основные фишки поддерживают, а вот у msvc куча недочетов

а, сори тогда что ворвался в тред, виноват

а кто-нибудь реализовывал нормальную рефлексию, не сильно зависимую от компилятора? Видел попытки на CPPCON, но там была рефлексия с огромным кол-вом допущений и ограничений

Ваше очень важно для нас (нет).

Через 18 лет

http://en.cppreference.com/w/cpp/compiler_support clang и gcc все основные фишки поддерживают, а вот у msvc куча недочетов

да, компиляторы успевают, а вот люди не любят следить за новшествами и работают по странному техпроцессу. знаю тех, кто до сих пор юзает 98 стандарт

Прикинь, да

Разработчик, который там работал, говорил, что они всё переписали.

Да по факту многие фишечки того же С++11 спокойно реализуются средствами С++98. Да, конечно, далеко не все, но все же Если кодобаза большая - то её придется долго под другой стандарт переписывать (да и нужно ли?) :) Другое дело - когда кода не очень много, ну или работаешь один

А зачем нужна рефлексия и почему все с ней так носятся?

+++ Ну, правда, всякие там for(Type a : blah) не напишешь. Да и смысл auto был немного в другом можно заменить разве что на какой-то макрос, ну или заюзать компиляторозависимую штуку

а, и лямбд нету. Они бывают довольно удобны, но и без них жить можно

ага

А зачем нужна рефлексия и почему все с ней так носятся?

Можно получить информацию о методах и полях (название, количество аргументов, возвращаемый тип и т.п.), а так же информацию о базовых классах Как минимум можно реализовать сериализацию ЛЮБОГО класса ровно одной строкой. Да и прикреплять всякие СЯП куда проще

А зачем нужна рефлексия и почему все с ней так носятся?

Потому что это уберполезно.

отголоски этого есть, аля typeid - но все же это все не то

Потому что это уберполезно.

Угу. Все надеялись что в С++17 добавят, но в комитете все разругались (было несколько вариантов реализации статической рефлексии, не смогли выбрать самый удачный)

Только для этого кажись

Только для этого кажись

Только это не ограничивается "записать экземпляры в файлик"

Вот другой пример:

Только это не ограничивается "записать экземпляры в файлик"

А я не ограничивал

Именно статическую рефлексию хотят сделать?

Не вижу профита

редактор карт. Ты можешь увидеть свойства у объектов и их менять так, как душе удобно. И для этого тебе не надо руками регистрировать переменные

Именно статическую рефлексию хотят сделать?

Хотели добавить в С++17, а как сейчас - не знаю. Ждем С++20

Добавил поле но забыл что оно учитывается в компораторе

для этого нужно делать кастомные атрибуты, которые определяли бы, нужно ли сериализовать поле

Добавил поле но забыл что оно учитывается в компораторе

Александр намекает на то, что с рефлексией такой проблемы банально не будет. Ты сможешь одной командой получить список полей и обработать их корректно. Добавилось новое поле - не страшно, код менять не надо

для этого нужно делать кастомные атрибуты, которые определяли бы, нужно ли сериализовать поле

Да го сразу новые модификаторы чо уж там

для этого нужно делать кастомные атрибуты, которые определяли бы, нужно ли сериализовать поле

Потихоньку превращаемся в шарп, хе-хе.. :D

Да го сразу новые модификаторы чо уж там

фактически, атрибуты + рефлексия - замена модификаторам

Зачем тогда си++

Зачем тогда си++

Работа с памятью

Я имею

Если статически, то действительно круто выходит. Динамически - уже какая-то джава. В rust есть derive, у него в чём-то схожая функциональность. Можно автоматически генерировать классу функции.

#holywar ?

Кстати есть где-то перечисление всех вариантов рефлексии которые рассматривали?

Если статически, то действительно круто выходит. Динамически - уже какая-то джава. В rust есть derive, у него в чём-то схожая функциональность. Можно автоматически генерировать классу функции.

По факту динамическая и не нужна

Потомучто имена там на самом деле данные

@arseny ну сначала в любом случае статика будет. Если динамику добавят - то они её как-то хитро обыграют (например, компилятор будет автоматически пытаться использовать статическую рефлексию, если это возможно)

но так-то да, статики более чем достаточно

@arseny ну сначала в любом случае статика будет. Если динамику добавят - то они её как-то хитро обыграют (например, компилятор будет автоматически пытаться использовать статическую рефлексию, если это возможно)

Я хочу явно видеть компильтайм всегда

И так от констекспр плевался

@arseny ну сначала в любом случае статика будет. Если динамику добавят - то они её как-то хитро обыграют (например, компилятор будет автоматически пытаться использовать статическую рефлексию, если это возможно)

И специальный ключик, который будет ее отключать. Как typeid и исключения.

Я хочу явно видеть компильтайм всегда

А что делать, если ты работаешь с dll, причем либа часто перекомпилируется, меняются методы и поля (и тебе надо за изменениями следить)?

т.е. интерфейс остается тем же

А что делать, если ты работаешь с dll, причем либа часто перекомпилируется, меняются методы и поля (и тебе надо за изменениями следить)?

Инклудить интерфейс не?

а вот реализация...

т.е. интерфейс остается тем же

Ну ты через него же работаешь

Тебе больше ничего не нужно

Или ты думаешь тебе позволят доставать то что не объявлено?

Выглядит как дрисьня

а как ты через интерфейс получишь список полей, м? В нем-то всего лишь чисто виртуальные методы

Или ты думаешь тебе позволят доставать то что не объявлено?

позволят, ещё как

Или ты думаешь тебе позволят доставать то что не объявлено?

Выглядит как дрисьня

не хочу лезть в субъективщину

позволят, ещё как

Нельзя так делать

Это нарушение инкапсуляции кажется

Ну вот смотри, друг

Не буду

Это дичь

Все

Тогда к чему все это? Монолог?

Допустим мы разрабатываем игрушку. Есть интерфейс сущности IEntity. Все новые виды сущностей (монстры, окружение и т.п.) наследуются от IEntity и переопределяют виртуальные методы Вот мы дошли до редактора карт, в котором мы расставляем эти сущности (объекты). Как изменять свойства объекта, как их читать? Интерфейс - просто перечисление чисто виртуальных методов. Перекомпилировать редактор карт каждый раз? =))

Редактор карт знает лишь о каком-то IEntity, не более

Редактор карт знает лишь о каком-то IEntity, не более

Ну выбери чем будет IEntity. Кажется ты хочешь контейнер свойств. Только непонятно зачем тебе релексия если это явно контейнер

Динамическая рефлексия всегда сводится к контейнеру

Потомучто имена там на самом деле данные

Потомучто