Eternal_Shield Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1 Цитата: с какого перепугу публичная функция вдруг стала "в рамках одной сущности" ? В данном конкретном примере, сущность - это record. В рамках этой сущности для метода видны все поля и пофиг на видимость.   Цитата: ...а я ее видел. Скажем так: инлайн может вызвать побочные эффекты у ем-рошного компиля, которые не позволят скомпилироваться. Ошибка а-ля URW**** или С*****. Это проблема ровности компиля, а не инлайнинга. Методы, которые невозможно заинлайнить никогда будут являться стоперами компилации.   Цитата: И вместо TestSetType = set of 0..255; поставь для соотвествия TestSetType = set of UInt8; Тут вопрос ридабилити. Сталкивался с тем, что некоторые человеки-ппцшники считают, это 1 байтовое множество, а не множество с 256ю элементами, размер которого 32 байта   Всего записей: 767 | Зарегистр. 18-05-2009 | Отправлено: 19:40 30-08-2013 | Исправлено: Eternal_Shield, 19:41 30-08-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: для метода видны все поля   Интересно как с этим в C++   В рамках той же логики функция должна читать глобальные переменные в секции Implementation,- видит же их! - а вот хрен вам...   Цитата: Методы, которые невозможно заинлайнить никогда будут являться стоперами компилации. Не-а, это была именно остановка компиляции, а не внутренняя ошибка.   {$inline on} обязывает заинлайнить все функции, и если этого не получится - то соотв. ошибка. А что до "is hint"... ну в справке Дельфи много чуши. До XE3 например (пока я не пристал к Крису с вопросами) там писали что string в новой Delphi **опционально** юникодный.   Цитата: Тут вопрос ридабилити. Для багтеста не первый вопрос   Цитата: некоторые человеки-ппцшники   Ну если у людей в школе не было комбинаторики - то их трудно лечить. Но даже тут можно было бы type xxx = 0..255; var yyy: set of xxx; var I: xxx;   Добавлено: Цитата:  что инлайнится компилятором уже бинарный код, и нужды хранить что-то промежуточное нет. и как же он "инлайнится" в место вызова ? де-компиляцией ? тогда бы и ассемблерные функции можно было инлайнить.   Цитата: инлайн не означает, что все вызовы обязательно заинлайнятся Справка и компилятор - разные вещи. Справкописатели не тестируют то, что написали и иногда справка и компилятор друг другу противорчат...   Например я не заметил там запрета на инлайнинг вложенных функций.   Хотя конечно режима "попробуй заинлайнить, а не сможешь - и хрен с тобой" не хватает... В смысле не auto, когда инлайнится всё подряд, а именно когда я помечаю функции - но допустимо их проигнорить (но не заинлайнить непомеченные).   Цитата: так что приведи пруф Тяжело. Кажется всплывало на StackOVerflow при обсуждении какого-то бага на пересечении как раз инлайнов с дженериками. И там была инсайдерская (т.е. неофициальная) инфа, что дженерики сделаны на базе инлайн-механизма.   Собственно, если они уже скомпилированны окончательно, то почему из них нельзя получить доступ в implementation-only переменным, например ?   Цитата: т.к до включения в бинарник, просто не известно что конкретно нужно компилить И тут встает интересный вопрос...   Package1(dcp, bpl) - объявляет TBase<T>; Package2(dcp, bpl) - объявляет TypeX = TBase<integer>; Package3(dcp, bpl) - объявляет TypeY = TBase<integer>; EXE - использует оба package2 и package3 (BPL)   Получается, что у нас в программе две реализации одного и того же класса...   Добавлено: Цитата:  в полученных dcu, код в инлайн функциях был честно собран Кстати, учитывая процитированную необязательность инлайна - вполне возможно что инлайн функции двуличны - хранятся и в окончательном виде, и в виде AST, а по месту уже решают вызывать или инлайнить.   Или ещё как угодно, внутренности dcc32 нам не ведомы...   Добавлено: Цитата: во-вторых и приватные методы могут вызываться снаружи   что вы имели в виду, кстати ? "дружественность" всего модуля ? ну... с точки зрения Дельфи тот же модуль - это не "снаружи", да и можно на strict private заменить без потери общности Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 22:48 30-08-2013 | Исправлено: Arioch1, 23:31 30-08-2013

X11 Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору интересно, а в XE4 функция UpperCase все ещё не юникодная? В XE3 все ёще нет ---------- /не мы такие, жизнь такая/ Всего записей: 3253 | Зарегистр. 24-11-2005 | Отправлено: 19:04 02-09-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору X11 Backward-compatibility.   У неё кажется ещё со времен Turbo Pascal заявлена работа исключительно с латиницеЙ, и нкоторые проги на это завязаны   Добавлено: Цитата: А означает это то, что вся эта чехарда с переключением раскладок лежит не на Delphi, а на самой Винде   В вашем с AlexXL тезисе о "гениальной" VCL "не нуждающейся в книжках" это не имеет значения. Это просто одна из тех вещей, которые Delphi должна была икапсулировать скрыть от программиста, как и другие геморрои Windows   Цитата: просто нет другого способ правильно определить локаль соответствующую языку текста. Cистеме нет, а программе - есть. Если Delphi решила, на примере WideString, с какой именно кодировкой она собирается трактовать AnsiString, значит и с clipboard она должна себя вести так же. Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 10:59 03-09-2013

X11 Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: она юникодная.. но работает только с a..z ) с учетом локали - UpperCase([chr], loUserLocale), она же AnsiUpperCase     в том-то и дело, что работает с "но" и с "учетом" )))   Добавлено: Цитата: Цитата: интересно, а в XE4 функция UpperCase все ещё не юникодная?     Для работы с юникодом применяет новый rtl, а старое для совместимости.   т.е. есть что-то новое вместо UpperCase? ---------- /не мы такие, жизнь такая/ Всего записей: 3253 | Зарегистр. 24-11-2005 | Отправлено: 13:41 03-09-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: вместо UpperCase?   Был AnsiUpperCase - ещё в Delphi 5 1999-года насколько помню.   Цитата: Delphi, может сама решить под какой кодовой таблицей трактовать набор байтов?   А как она УЖЕ РЕШАЕТ это со всеми AnsiString - и переменными и свойствами всех этих компонентов ? Вот и ПРОДОЛЖАТЬ решать так же в случае копирования в буфер.   Цитата: т.к. это будет неправильно.   Почему ? Вот я - блондинка. Села за дельфи, бросила на форму TEdit.   Код: procedure TForm1.FormShow(const Sender: TObject); begin    Edit1.Text := 'Мама Мыла Раму';    Edit1.SelectAll;    Edit1.CopyToClipboard; end;   Ивот вы уверяете, что если Delphi/VCL скопирует текст как полагается, без разрушений, с признаком руского языка - то это по вашему неправильно. А вот если Delphi/VCL все разрушит и скопирует кракозябры - то это правильно и хорошо.   Альтернативненько, чо... Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 14:06 03-09-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Выше писал, это поломает текст в случае нескольких языковых раскладок.   1) У текста нет раскладок, это не клавиатура.   2) Откуда в неюникодной VCL разные "раскладки" ? Если в AnsiString свойстве TEdit.Text несколько разных "раскладок", то он уже испорчен.   ----   Цитата: системная локаль по умолчанию.   как же можно? ведь это же     Цитата: поломает текст в случае нескольких языковых раскладок. ???   ----   Цитата: Delphi поступает так, как задизайнено и задокументировано в Винде   То есть вы так и не погуглили ни про ReCreateWnd, ни про OwnerDraw, ни про другие случаи, когда Delphi кладет большой и толстый на то, Цитата: как задизайнено и задокументировано в Винде ? Попробуйте, вдруг интереcное что узнаете.   Кроме того,  что там делает и как делает винда - не важно. Это всё в принципе не оправдание для VCL.   Те кто хочет писать "как в винде" - пишут нa MFC или OWL или сразу на API.   VCL - для тех кто хочет писать "как удобно", в не "как можно вместить WinWord в 2 мегабайта памяти на 16-битном процессоре"   ---------------   Цитата: Код: procedure TForm1.FormShow(const Sender: TObject);   begin      Edit1.Text := 'Мама Мыла Раму';      Edit1.SelectAll;      Edit1.CopyToClipboard;   end; Этот простой код должен просто работать. Цитата: феерический бред   Да да, вы уже говорили, работоспособность - феерический бред, а вылавливание и обхождение багов - норма. Интересно, кто кроме вас ещё в это верит?.. Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 11:13 04-09-2013 | Исправлено: Arioch1, 11:17 04-09-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ego666 Arioch1   Так и не понял - чего вы зацепились то! Выскажу имхо.   VCL - довольно удобная, функциональная обертка над WinAPI. Голое WinAPI безусловно не так удобно в п ользовании, и для своего времени VCL стало хорошим компромисом между абстракцией фреймворка и платформой. Более того, часть функций платформы поддержано языком и фреймворком: сообщения, OLE, OLE-типы, ...     Но как и у любой сложной вещи, у VCL были свои недостатки и косяки в поддержке платформы - глупо отрицать что все идеально. Ничего идеального не бывает, VCL не исключение. Но да, VCL удобна и функциональна, и функциональнее многих! Как и Delphi RTL. Не будем спорить, круче ли .NET, но их хотя бы можно сопоставлять.   К слову,  FMX менее удачная абстракция имхо, именно за счет меньшей опоры на поддерживаемые платформы.   Можно ли развивать VCL? Думаю, безусловно да. И зря ЭМРО сделало ставку на FMX, забросив развитие VCL. Но это мое имхо, и чистая теория - в жизни мы имеем то, что имеем: развитие FMX и более медленное развитие VCL. Также считаю зря, что VCL не рефакторят, избавляясь от косяков реализации или архитектуры (часть вы упомянули). Да, сломать старый код - плохо. Но можно было бы придумать варианты! Типа, замена юнитов на "новые версии" или еще какой механизм.. Миграционные ассистенты, в конце концов! Появился бы смысл тянуть код на новые версии среды Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 12:18 04-09-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору > чего вы зацепились то!   А это просто.   AlexXL сказал, что если для бибдиотеки пишут книгу - это плохая библиотека. Для хорошей библиотеки - книги не нужны.   Я возразил ему, что по его логике, тогда и VCL - плохая библиотека, потому что дял ее исползования (за пределами Hello World) нужна документация.   Он, кажется, замолчал. Зато вдруг проснулся ego666, влез в чужой спор на стороне Алекса, и до сих пор доказывает, что VCL не нуждается в докусментации, просто нужно досконально знать MSDN. В обещм, забавная позиция, с ним весело.       Добавлено: Цитата: Да, сломать старый код - плохо. Но можно было бы придумать варианты!   Да даже не придумывать, а подсмотреть в LCL, все равно они уже испачкались, делая XE2 на основе Лазаря Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 12:28 04-09-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1   Ну что вы как скучающие в поисках троллинга)) Понятно же, что любые категоричные позиции при внимательном рассмотрении - неадекватны! В жизни вообще редко есть чего-то черно-белое. Спорить можно обо всем, но практического смысла занимать крайние позиции нету, имхо   Про книги - это ж понятно, что погорячились с категоричностью! Но если переформулировать - то врядли кто то будет спорить: если для пользования библиотекой без книги никак, то это не очень годная библиотека. Лучше пользовать более понятную библиотеку (если она есть - для некоторых ситуаций без вариантов, типа SDK). Но вреда от книги не усматриваю  никакого, и книги пишут не только для библиотек, которые никак нельзя освоить иначе. И вообще - книг писано по любому поводу куча! И по стоящему поводу, и по не очень стоящему!)     Ну и VCL! Да, можно и без книг чего-то писать. но что-то без книг писать сложно (например, интеллектуально емкие штуки, но не из-за VCL, а по своей природе). Да, иногда нужно в MSDN лезть. Да, не всегда что-то очевидно, но часто все довольно прозрачно. Хз. По разному бывает на практике! )) Жизнь - штука сложная и многогранная!     Добавлено: Frodo_Torbins   Цитата: Они считают, что вся платформа Win32 мертва   В целом, доля PC среди компьютерных устройств снижается, да. Текущая big thing - это mobile. В векторе маркетинга ЭМРО правы.     Но в тактике действий?! Я считаю, они допускают ошибку. Если у них было удачное решение для одной платформы, нафига они поддержку других платформ сделали вообще с другой идеологией, архитектурой?! И опять наступают на грабли отсутствия рефакторинга для доведения фреймворка.     Если FMX была нужна для других платформ, нафига нужно FMX решение для Win? Там уже есть VCL. Что касается OSX и iOS - почему бы не сделать так, как сделано в iCL? А лучше - с совместимость с VCL (хотя бы идеологической). Надо векторные контролы со стилями - сделайте их "в уголке" для нуждающихся!     Тесты же показывают, что iCL работает куда ни шло прилично, а FMX вообще отвратно. Ну и интересно, как оно на android будет. Волнуюсь за диспетчер памяти, который будет прибивать NDK-приложения "на раз". Все-таки для Android - NDK это экзотика! Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 12:35 04-09-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Про книги - это ж понятно, что погорячились с категоричностью!   Это вам понятно. А вот некто бросился эту позицию защищать с пеной у рта.   Другой вариант - "чукча - не читатель": некто бросился рвать на груди рубаху, даже не прочитав о чём идёт спор и против чего он возражает (а значит и за что вписывается). Но мы же не будем НАСТОЛЬКО плохо думать о программисте, правда? :-D     Цитата:  если для пользования библиотекой без книги никак   Этот тезис "за всё хорошее против всего плохого".   Для Hello World книги не неужны (за исключением безнадёжных случаев). Для развитой, не тривиальной программы - необходимы.   А вот где именно на этой шкале вы поместите "пользование" - это вкусовщина и случайность, тут просто не о чем говорить.   Добавлено: Цитата: нафига нужно FMX решение для Win?   Скорее всего купились на обещания Майкрософта и лезли в Метро, чтобы один exe и на десктопе и на планшете.   Добавлено: Цитата: Волнуюсь за диспетчер памяти   ДУмаете, с ним что-то плохое случится ? :-D Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 12:46 04-09-2013 | Исправлено: Arioch1, 12:48 04-09-2013

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE4

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование