А есть ли способ заставить конечный класс в иерархии классов

реализовать все, всё ещё не реализованные абстрактные методы?
самый простой пример:
program Project1;
{$mode delphi}
type
TMyClass = class abstract
procedure test; virtual; abstract;
end;
TMyClass2 = class(TMyClass);

var
O: TMyClass2;
begin
end.

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

на такое ругаться нельзя, в O может быть в итоге наследник TMyClass. вот на TMyClass.Create должна быть ругань

ругань есть на создании. на объявлении класса как Борис сказал ругаться не очень, вдруг наследники таки метод реализуют? [dcc32 Warning] Unit11.pas(38): W1020 Constructing instance of 'TMyClass2' containing abstract method 'TMyClass.test'

program Project1; {$mode delphi} type TMyClass = class abstract procedure test; virtual; abstract; end; TMyClass2 = class sealed(TMyClass); var O: TMyClass2; begin O:=TMyClass2.Create; end. Ок ) уточним пример - вот тут хочу чтобы компилятор сказал мне плохие слова 😄

sealed - наследников уже не будет

Ууу, кстати... Delphi ещё как матюкается... а FPC молчит надо бы зарепортить! Ну всё, вопрос снят - это возможно, но пока-что в FPC проглядели

такой типа интерфейс, но без интерфейса... в интерфейсе мне не подходит что его хрен заинлайнишь

Renat Suleymanov
Как раз создаст еще нереализованные абстрактные ме...

нее, это человеческий фактор, надо исключать такое, если возможно

Нет, Lazarus тоже репортит. Но только в случае, если в коде где-то есть вызов абстрактного метода

Репортит, возможно, но он компилирует успешно программу Мне нужно чтобы он останавливал компиляцию по ошибке

Это сообщение уровня хинта. Зачем прерывать компиляцию, не понятно

потому-что программа не функциональна без реализации всех методов UB по паскалевски )

Тогда может интерфейс заюзать, там точно не получится скомпилировать без реализации. Раз уж так строго нужно

если метод не вызывать то справится :) но лучше так не делать

интерфейс - если сам интерфейс не юзать - это лишние куски кода, причём там где я принимаю этот класс - я использую именно класс, а не интерфейс, поэтому как мне проверить во время компиляции, что все нужные методы класса реализованы?

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

Ну, хинт то будет. Нужно приучаться обращать внимание и убирать все предупреждения компилятора

признайся просто, что ты у себя в программе где-то заложился на такое поведение FPC 😁 и теперь меня отговариваешь от репортинга 😁

А что в Дельфи реально это не компилится? Может я что-то не понимаю. Мне кажется это как-то жестко )

warning в делфе

ну вот: https://t.me/Delphi_Lazarus/333871 реально а мне кажется - разумное поведение

блин, ну вот же ЕГГОГ, даже два

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

ага с sealed

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

Нужно научится просто работать с хинтами в Лазарус и никаких проблем не будет

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

Стикер

Стикер

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

Стикер

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

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

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

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

Нет, никаких тонн варнингов. У меня в проектах все чисто. Читать мое первое сообщение. Точка. Повторятся не хочется

https://gitlab.com/freepascal.org/fpc/source/-/issues/40808

надеюсь когда-то разработчики лазаруса возьмут твой метод на вооружение, чтобы пустой лкл проект не "сыпал" ворнингами при сборке, как и сам лазарус

Лучше не надо Надо ввести метрику: кол-во хинтов, кол-во варнингов на каждую сборку, и после каждой сборки выводить только вновь возникшие

Peter
ну вот щас пустой лкл проект "выбрасывает" такое -...

Я не спорю, но имхо лучше не скрывать это совсем, а как-то более умно фильтровать Ну к примеру по-пакетно, по-модульно, по пути ФС, по признаку того новое ли это сообщение по отношение у прошлой компиляции Допустим! В первый раз компилятор выдал кучу Будем считать, что юзер ознакомился На второй раз, если там те же самые сообщения, то их мьютить и не выводить, ибо ничего не изменилось, а если есть новые - то выводить только их Ну и плюс кнопка - сбросить все признаки - после этого последующая компиляция снова выдаст на один раз всю кучу, а потом снова включится интеллектуальный фильтр

Например просто починить ворнинги, и удалить из дефолтной выдачи те, что сломаны

Peter
ну вот щас пустой лкл проект "выбрасывает" такое -...

Никогда варнинги адекватными не будут в fpc по одной простой причине. Разрабы компилятора сами ими не пользуются. В проекте компилятора все варнинги/хинты отключены.

Это точно?

Только надо иметь ввиду, это для для lpi компилятора. Думаю для компилятора это сделано осознанно. Во всех других проектах lpi в исходниках Lazarus и хинты ворнинги конечно же включены

Да, так и есть, я не помню где-то читал, в каком-то мануале на компилятор - и там писалось, что эти *.lpi - только лишь для каких-то вроде как тестовых вещей Может сами разрабы их и используют, но наверное у них варнинги включены

Jack128

Мне там больше нижняя настройка нравится "Stop after number of errors: 50" - выглядит надежно 😂

По крайней мере это говорит о том что парсер/резолвер/итд умеют восстанавливаться после ошибки и дальше работать, что не плохо

Я тебя опечалю :)

Ну если я в исходнике два unresolved идентификатора напишу, про оба ошибку выдаст, а не помрет от первой ошибки

Там есть более хитрые ошибки, то что ты написал - это штатное. А вот хитрые умашаешся еще искать как правильно патчить чтобы остальное не сломалось.

Это понятно, что есть сложные случаи, когда все «взрывается»

взрывается это еще мягко сказано, иногда он может потерять тот модуль который парсил и продолжить с совершенно другого (в транке это уже пофикшено)

+ там в проекте не видно режимов компиляции. Только default, в котором даже символы не стрипятся

а других build mode'ов в проекте и нет, это единственный. Честно говоря не разбирался, как там релиз компилятора собирается.

Так я о том и говорю. Впечатление, как будто они какие-то "дежурные": нет ни отладочного mode ни релизного. И как выше сказал @O_o_0_0_o_O это объясняется тем, что они для каких-то тестовых вещей. Так что то, что именно в этом проекте отключены хинты ничего не говорит. Повторюсь во всех других проектах в исходниках - все включено