−120
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 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
- 40
- 41
- 42
Option Explicit
Dim HTMLCode As String 'переменная для хранения кода страницы
Private Sub Command1_Click()
Winsock1.RemotePort = 80 'устанавливаем порт сервера 80
Winsock1.RemoteHost = "ippages.com" 'Хост
Winsock1.Connect 'Подключаемся
Label4.Caption = Winsock2.LocalIP
End Sub
Function CutIP(HTML As String) As String
Dim p1 As Integer
p1 = InStr(HTML, "Content-Type: text/html")
CutIP = Trim(Mid(HTML, p1 + 27, Len(HTML) - p1 - 23))
End Function
Private Sub Label1_Click()
End Sub
Private Sub Winsock1_Close() 'Событие генерируется при закрытии Канала связи
Form1.Caption = "Не подключен" 'Просто сообщаем о том что не подключены
Winsock1.Close
End Sub
Private Sub Winsock1_Connect() 'Событие генерируется при подключении
Form1.Caption = "Подключение" 'Подключены
'Посылаем запрос на сервер выдающему наш IP
Winsock1.SendData "GET " + "/simple/" + " HTTP/1.0" + Chr(10) + Chr(10)
End Sub
'Событие генерируется когда нам приходят данные
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
Dim Temp As String
Winsock1.GetData HTMLCode
Label1.Caption = CutIP(HTMLCode)
End Sub
Получение ай-пи адреса посредством отправки на сайт запроса через компонент WinSock.
http://vbbook.ru/visual-basic/polychenie-svoego-ip/
Строго говоря, это не лажа кодера, просто используется (по незнанию?) очень глючный и непредсказуемый компонент.
Fixed by me:
Function GetCurrentIP() As String
Dim txt As String
Dim i, j As Integer
Dim mshttp As New XMLHTTP 'по умолчанию сервер всегда зареган.
mshttp.open "GET", "http://checkip.dyndns.org/", False ' синхронный get
mshttp.send
txt = mshttp.responseText
i = InStr(1, txt, ":")
If i > 0 Then
i = i + 1
Else
GetCurrentIP = "" ' удобно было бы, если по присваиванию, подобному этому, происходило покидание процедуры. Ан, нет.
Exit Function
End If
j = InStr(i, txt, "</")
If j < 1 Then
GetCurrentIP = ""
Exit Function
End If
GetCurrentIP = Trim(Mid(txt, i, j - i))
End Function
Запостил: 
Stertor,
15 Февраля 2014
Follow us!
???
Ага, а входить по enter'у
Что учесть?
Я (борманд) забрал себе этот акк, посредством юзер-скрипта.
Пруф (просто не с того логина написал).
>Но я борманд, как мне это учесть?
И вообще здесь уже давно никого нет. Просто я логинюсь под спизженными с помощью юзерскрипта учетками и пишу от их имени.
Сам с собой разговариваю, вайпаю, с других акков минусую этот вайп, срусь и делаю сайту страйко раскрутку за мелкий прайс.
Не примазывайся, лучше поставь юзер-скрипт.
P.S. Меню юзерскрипта не показывается, когда пользователь разлогинен. Все думают, что это я CSS-селектор не учёл, а на самом деле...
Кстати отличная штука, рекомендую:
https://github.com/bormand/govnokod-board
А вы знаете, что надо действовать от противного - говорить что юзер-скрипт ворует куки - как бы шутя, чтоб больше идиотов его ставили. Также как модерация была вроде шуткой.
Как и тонкий, вроде "случайный" слив инфы про Алтай. Зато никто не будет искать в других местах.
И при реальном деаноне у шерлоков не будет сходиться инфа с тем как я тут "проговорился".
Ты про 1000 пустых строк или про "да хуле"?
> учесть, что ты не борманд
Но я борманд, как мне это учесть?
*Зловещий смех за кадром*
Ну он был испорчен пока в этом треде не отписывались.
Ну и я же еще не настолько ебанулся, чтобы во все треды в цикле постить этот блок энтеров.
Просто Konardo еще не установил себе юзерскрипт.
тем, что надо писать лишние скобки, и любой человек, мало-мальски знакомый с C, увидит тут не возврат из подпрограммы, а выход из программы?
плохая идея
это же касается и сишной exit, но последней хоть пользуются раз в тысячелетие
всё, что меняет поток исполнения, не должно напоминать процедуру, которую написал вася пупкин,
оно именно что должно напоминать конструкцию языка - return, throw, if, switch/case, goto
switch (i+1); // очевидно, что это конструкция языка
не тупи
ты хоть читаешь, что я пишу?
поток исполнения должен меняться конструкциями языка, а не процедурами
В версии Турбо Паскаль 7.0 определены стандартные процедуры:
Break
Continue
я не ослышался??
где аргументы по делу?
вот ведь пригорело :3
минус не мой
Ну, это уж слишком.
Если честно, я еще нигде не видел такого годного ООП, как в делфях, а мой разум понимает только ООП. Не знаю, может, в сишке лучше.
Бейсик ползает, по-пластунски.
А в сишке ООП убог.
Ну можно в экзешник запаковать (ruby ocra), просто чтобы легче было распостранять, но скорость и занимаемый объем от этого лучше не станут.
ООП? В сишке?
разве что согласно парадигме "не можешь срать - не мучай жопу"
в сиплюсном билдере чтобы добавить строчку в поле ввода, нужно сделать следующее:
и тут же внезапно
Это ты можешь понять?
У тебя же выходит "я не врубаюсь в русский язык", при том что ты не знаешь его букв.
а то мы люди тёмные, непонятно, каких неизведанных высот достигло величие ООП в дельфи-то, какими процедурами оно ещё может удивить
можно в отдельном треде даже
А если вы про непосредственную языковую поддержку стандартного остопизденевшего поноса с наследованием и виртуальными методами, то этого в сишке нету.
Про крутое ООП в Дельфи я не знаю, но Стертор - крутой специалист.
я-то хотел похоливарить насчет множественных наследований, интерфейсов, миксинов, щяблонов, перегрузок, финализаций, делегатов и о прочих няшностях
или ты заранее соломку стелишь, признавая ущербность дельфей даже в такой тривиальщине как ООП?
Но уж если подняли тему, то скажу, что в делфи половина из перечисленного реализуется куда изящнее, чем в этих ваших крестаххх.
лучше подождём в треде профессионалов, которые могут приводить взвешенные аргументы
я сейчас имею в виду чисто синтаксис, а не "так лучше работает".
а то пока это всё голословные утверждения
Это на РСДН каждый второй тред про полиморфное дерьмо. А я в этом ноль.
Один блять хочет в рантайме узнать тип по указателю void*. На Base*, а именно void*, и спрашивает как узнать, инт там или дабл по этому указателю.
Другой блять хочет вернуть из функции выражение, тип которого зависит от входных данных функции (не шаблона, а функции).
Пиздец кто допустил динамических питушков до крестов?!
А мне-то что, надо только автодеструкторы чтоб были.
Ну и да, наследование со статической перегрузкой иногда полезно.
Для меня крестовое ООП удобнее.
В Аде тоже неплохо, но там есть свои плюсы и минусы.
вся надежда теперь на kipar...
Эмуляция, мать её. Всякие gnome на сишке написаны с эмуляцией ООП через структуры, указатели на функции и макроговно. И это вполне работает.
GObject
> Тарас вам скажет
Тарас сказал.
Мужик сказал, мужик сделал.
Обстановка не располагает конструктивно спорить. Я просто говорю факт - дельфину смотрящему на С++ ООП там кажется убогим, и пользователи крестов в целом не отрицают, что он больше на шаблоны ориентирован.
Виртуальных методов класса (например конструкторов) нет, свойств нет. Указателей на методы нет.
RTTI с доступом к свойствам по текстовому имени нет.
Классы не являются "первоклассными гражданами".
Возможности без гемороя отнаследоваться от вектора, стрима или других конструкций STL нет. Даже обратится к методу родителя без указания имени родителя нельзя.
Да, все это "нинужно" и можно запилить с определенными ограничениями и костылями, но для того кто изучает язык вывод однозначен.
Ну а с Ruby вообще сравнивать бесполезно, такое полноценное ООП как там разве что в smalltalk есть.
Всегда было интересно что эта абстракция означает по отношению ко всему (классам, функциям, объектам и тд).
поюзать в фабрике?
указателей на методы? есть же
кстати, хотелось бы развить тему "4-байтные делегаты в дельфях" в разрезе того, что объекту запрещено было бы умереть, пока у кого-то есть делегат этого объекта
ну или хотя бы методы предотвращения segfault при обращении к такому делегату? может, это уже из коробки работает? (кстати, ниже я высказал предположение, что все дельфиньи объекты хранятся в куче и возможно даже имеют счетчик ссылок, так и есть?)
> свойства?
свойств нет, и лично я считаю, что такой сахар мог быть полезен (и пусть у вендоров болит голова, как их экспортировать из dll)
RTTI нет (я тебе больше скажу - ABI нет)
вот такая вот расплата за то, что дельфи медленно работает только на x86, а С/С++ быстро работает на x86/ARM/SUN/IBM/и прочем миллионе архитектур с миллионом компиляторов.
кстати, а что с RTTI в GNU pascal и Free pascal? (смотри, всего-то есть три компилятора и уже неладно)
и что со стандартизацией ISO этих "возможностей"? Ну или хотя бы ANSI?
когда вендорозависимые "улучшения" языка будут зафиксированы на бумаге?
обратиться к методу родителя без указания имени родителя можно только в убогом языке, который не поддерживает множественное наследование, а С++, как все знают, не входит в эту группу
с динамическим скриптоязыком вообще сложно что-либо сравнить, слишком разные категории
теперь про дельфи, из того, что не было раскрыто выше
* множественного наследования нет
* пока стертор спрашивал зачем нужны . и ->, я погуглил и немного запутался
в дельфях объекты все через ссылку что-ли работают (присваивают два объекта, как будто ссылку перекинули)? располагаются в куче? в другом примере сделали указатель на объект, и обратились к методу этого объекта через ".", что происходит? умный указатель не сделать, но он и не нужен, т.к. есть счетчик ссылок за кулисами? если так, то когда вызывается деструктор? в дельфи вообще RAII есть?
если это всё так, до меня начинает доходить, почему Тарасу не нравится ООП "вообще" - дельфи, как типичный язык для обучения, не напрягает школьный мозг сложными вопросами, а когда эти вопросы всплывают, приходится реализовывать собственный ООП, с ручным закатом солнца
---
блин, я же говорил, что нужен отдельный тред, а сейчас будет куча колонок с одинаковым отступом
Те, которые объявлены через class - да. Передаются по ссылке и запиливаются через фабричный метод Create, который там называют конструктором. Ссылка эта в общем случае не умная, и удалять объект надо вручную. Исключение сделано только для интерфейсов (аля COM-интерфейсы).
в куче, но без счетчика ссылок
теперь понятны, откуда горячечный бред по поводу виртуальных конструкторов
массиву и стеку то теперь насрать какие объекты хранить - везде будут тормоза обращения в кучу
ну т.е. обращение к делегату приведет к падению приложения, если объекта уже не станет?
ну и RAII идёт лесом, т.к. за эти объекты ни компилятор ни среда ответственности не несут - они же не знают, сколько раз пользователь скопировал ссылку и что с ней сделал
и этот язык назвали более удобным? только разве что в рамках 40-минутной лабораторной работы "дети, проснитесь, давайте сегодня познакомимся с ООП, а на следующей неделе посортируем пузырьком"
ну т.е. обращение к делегату приведет к падению приложения, если объекта уже не станет?
В очень редких случаях - да. Во всех остальных приведет к порче памяти, со всеми последующими "трололо". Проги на делфи имеют встроенный перехват исключений.
Вообще, положа руку на сердце, серьезное мое программирование началось после того, как я поставил FastMM - менеджер памяти. Он проверяет память проги на целостность, ищет утечки памяти. Если что не так - моментально прихлопнет прогу и выдаст сообщение об ошибке.
скрещивать два равноправных предка - такое тоже бывает, тот же std::iostream - наследует от std::istream и std::ostream
только идиот будет отрицать полезность множественного наследования, только потому, что в его любимом языке его не осилили сделать
при наследовании ты добавляешь поля к себе, а не к предку
ромбовидное наследование означает сколько копий будет иметь тот самый класс-дед
и чем отличаются поля от методов - и там, и там легко создать конфликт имён, который потом надо каким-то образом разруливать
конфликт полей исчезает, рвать объекты не надо
> и там, и там легко создать конфликт имён, который потом надо каким-то образом разруливать
методы можно перегрузить, поля нет
A и B наследуют от base и перегружают метод say, который говорит "A" и "B" соответственно
и вот класс Foo наследуется от A и B, а метод say не перегружает - что он будет говорить?
Либо ошибку компиляции при попытке вызова Foo::say
тебе надо освежить раздел множественного наследования в С++ - возможно, там уже давно работает то, что ты только собираешься выдумать
Его неудержимо рвало на Родину...
о чем ты говоришь? какие части?
у тебя либо две полностью изолированные копии monkey (как в моем примере), либо если ты хочешь ромб и получить строго одну копию monkey - надо вспомнить о виртуальном наследовании
А теперь покажи свой пример, где база имеет поле A.
Покажи свой пример, где база имеет поле A, один из наследников имеет поле Б (отдельно пример для первого отдельно пример для второго), но чтобы класс не рвало.
Пример, где оба наследника имеют доп.поле, ну тут понятно, что не порвать не получится.
Вообще мне просто интересно, какие концепции можно получить, если ввести "наследование-без-новых-полей", может быть даже тут можно будет делать неявный каст не только наследника к базе, но и наоборот, и по сути получаем не наследника и базу, а два (а то и более) равноправных класса, которые можно неявно кастить друг к другу.
что куда чего "рвёт"
мне сложно декодировать этот термин
тебе не нравится, как компилятор будет расставлять части класса, унаследованного от A: virtual base и B: virtual base?
почему тебя это волнует? какую проблему ты испытываешь?
Это же переголова какая-то.
Ты ответь, обязательно ты разбрасывать мозги, если в базе есть поля, а из наследников никто не добавляет новых полей? Или если только один наследник добавляет новые поля?
хитрое размещение полей должно касаться только наследника в отношении тех полей, которые он добавил сам
потому что база не может предугадать когда вдруг от нее отнаследуются и как, поэтому должна вести себя как нормальный цельный объект и до наследования, и после, и занимать одинаковый конечный размер
глубже исследовать это дело мне сейчас уже лень)
Точнее так - во всех языках о которых он слышал, кроме одного убогого.
> тот же std::iostream - наследует от std::istream и std::ostream
В этом случае как я понял класс обертка. И наследование не нужно.
Почему нужно много интерфейсов - думаю и так понятно. А вот миксины нужны для реализации АОП. Очень удобно и улучшает код.
http://docwiki.embarcadero.com/RADStudio/XE5/en/Operator_Overloading_(Delphi)
прошло лет 20 на такую простую вещь
пройдет еще 20 и добавят автодеструкторы и RAII
а множественное наследование, пожалуй, вообще не осилят никогда - слишком сложная тема для дешевой формошлёпки, не тот уровень, да и процедуры для ключевых слов так скоро закончатся
ты пиздун, питон не отказался
алсо, слово "сознательно" к ЙАЖА не относится
жаль, что писать на нём некому, нечего, не в чем и не на что
Да пиздец ваще, как же сишное a[N]-то работает, а?
ты знаешь тип объекта, тебе в рантайме говорят N - целое число, и ты просто выделяешь сколько надо
а дельфишное должно работать вот так:
я хочу массив из наследников класса TFoo, но каждая ячейка становится хуй знает какого размера, т.к. _каждая_ ячейка в рантайме может быть _разного_ размера
что делать компилятору, когда ему говорят a[10]? откуда он поймет, то 9 элементов перед этим элементом - имеют, допустим, уже известный, но отличный друг от друга размер?
только и остается, как хранить указатели на объекты в куче
Любую проблему можно решить добавлением еще одного уровня абстракции
Никаких проблем, если заставить размер ячеек делать одинаковым (типа определять разом при объявлении массива, пусть даже от числа, известного лишь в рантайме)
ты не можешь предугадать, какого он будет размера
ты не можешь сделать их одинаковыми на 100 байт, потому что наследник может занимать и 150 байт
Я говорю не про то, что сейчас в Дельфи, потому что сейчас всё на куче и всё ясно.
Я говорю, как оно в теории могло бы быть.
Оно даже в рантайме неизвестно. Вот создал я массив. Затем загрузил плагин, в котором были новые потомки TFoo. И поместил запиленного этим плагином потомка в массив. Кровь-кишки-распидорасило.
Разве что запретить динамическую подгрузку модулей...
И получи Discriminant_Error
/facepalm
Не нравится такая-то рантаймовая фича - не пользуйся, лол, не будет тебе тормозить.
А если ту же фичу в кресты добавить, то при её использовании так же тормозить будет.
> если так, то когда вызывается деструктор?
Когда вызывается вручную.
> в дельфи вообще RAII есть?
Есть, но для этого надо делать некоторые движения языком
но оно указано в списке "преимуществ" ООП
> вручную
никакие несостоятельные претензии по поводу непонятного школьникам синтаксиса с фигурными скобками не перебьют козырь по поводу крайней степени идиотизма с ручным вызовом деструктора и такой внезапной ограниченностью использования объектов
если честно, дельфи меня уже второй день удивляет
стоит копнуть чуть глубже, и прямо нет предела удивлению
Сейчас еще больше удивлю - там есть ДВА вида классов. Одни объявляются ключевым словом object: их можно размещать на стеке, можно в куче, ссылки нужно юзать явно (наследие object pascal). Вторые - ключевым словом class.
Но зачем? Вот что хотелось бы - так это возможности запроксировать кучу методов в хранящийся в поле вектор, стрим и т.п. без тонны говнокода. А наследоваться от них - нахер надо.
Наследование в его исходном смысле - это все-таки отношение "является", а не "мне лениво выдумывать свой интерфейс и проксировать методы, поэтому я унаследовал свою херню от вектора".
берёшь и наследуешься, все методы получены
или он намекал на массив полиморфных векторов, часть из которых должна была быть пользовательским классом вектора с нетривиальным деструктором?
Тарас сказал "Сосну" - Тарас соснул.
уже все объяснили. Факт в том что виртуальных методов класса нет.
>указателей на методы? есть же.
Через std::function bind что-то там - костыль, а в яыке нет.
>вот такая вот расплата за то, что дельфи медленно работает только на x86
И? Мы же вроде об ООП, а не о скорости работы. А так да, только ассемблер и царская сишка нормальные языки, а платформы кроме х64 питушня.
>кстати, а что с RTTI в GNU pascal и Free pascal? (смотри, всего-то есть три компилятора и уже неладно)
в fpc есть, причем в отношении свойств работает почти также (там правда еще фич добавили, но не суть). GNU - мертв давно (да и вообще я не слышал чтоб кто-то всерьез им пользовался, это скорее proof of concept что другие паскали могут существовать).
>когда вендорозависимые "улучшения" языка будут зафиксированы на бумаге?
Не понял, при чем тут убогость ООП в крестах.
>обратиться к методу родителя без указания имени родителя можно только в убогом языке, который не поддерживает множественное наследование, а С++, как все знают, не входит в эту группу.
Он входит в группу, состоящую из него одного. Во всех нормальных языках множественного наследования нет, только в С++ выпендрились и из-за этого не могут даже обратиться к имени родительского класса.
>с динамическим скриптоязыком вообще сложно что-либо сравнить, слишком разные категории
Если говорить об ООП и прочих абстракциях - что сложного?
Все равно что сказать "в гимпе удобно рисовать чертежи, а с автокадом его нельзя сравнивать, слишком разные категории".
>пока стертор спрашивал зачем нужны . и ->, я погуглил и немного запутался
ну т.е. ты не знаешь дельфей и поэтому не можешь говорить изящно там сделано или нет. Подождем кого-то с более взвешенными комментариями.
>блин, я же говорил, что нужен отдельный тред, а сейчас будет куча колонок с одинаковым отступом
Ну, как видим отдельные упорыши могут любой тред испортить сажей.
Дык у вас негров же вешают.
Что-то мешает замутить один инстанс еще одного класса, в котором эти виртуальные методы есть?
По сути в языках, где есть статические виртуальные методы, именно так и сделано. Просто в них класс это first-class citizen, и является обычным классом, и поэтому все это работает изкоробки без лишних телодвижений ;)
Ну я и говорю - да, все это можно запилить с разной степенью костыльности\неудобств. Сделать чтоб каждому классу генерировался свой метакласс и чтоб они также унаследованные методы друг у друга вызывать. Но по сравнению с языком где это есть из коробки ООП в крестах убог.
тебе лень гуглить - ладно, мне не жалко
нет только виртуального конструктора (по очевидным причинам производительности и модели представления данных) да виртуального шаблонного метода (по понятным причинам времени инстанциирования такого метода)
в чем же факт?
> в языке нет
ну есть же! и всегда было
как мне в дельфи в делегат получить умный указатель на объект, который не даст объекту уничтожиться?
> об ООП
вызов метода у класса через сопоставление текстом - имеет мало общего с языком, претендующим на скорость исполнения, мы же ведём речь про то, что дельфи претендует на нишу С++?
> все остальное питушня
только виндовс x32! только однобайтовые кодировки! только один поток! только одна версия компилятора! ну не суть
отсутствие вызова метода через текстовое имя как раз напрямую связана с гетерогенностью языка. если бы языком занималась лишь одна лажовая конторка, то в крестах тоже получили бы 2% ниши и полную невостребованность
собственно, как ты сам видишь на примере Qt (а в нем работает в крестах то же самое, что ты привел в пример), эта проблема решается именно свистоперделкой, заточенной на конкретного вендора, и о ней бессмысленно рассуждать, пока она не станет стандартом
ну так что со стандартом у дельфи?
> к имени родительского класса
а ты пишешь наследника, не зная, от какого класса он унаследован?
если у тебя возникла такая необычайная необходимость, ты постоянно меняешь имя предка, а борланд с++ не умеет в умную замену (почти уверен в этом), то всегда есть typedef, чтобы конкретное имя предка запомнить только лишь в одном месте на весь класс
зато взамен приобрести множественное наследование - инструмент, одновременно заменяющий убогие interface и mixin, то самое, что дельфи так и не осилило до сих пор
меня радуют вообще дельфиньи визги, что перегрузка операторов не нужна, шаблоны не нужны, а в итоге с запозданием лет в 20 им это в недоделанном виде дают и теперь-то они заживут! дойдет дело и до "ненужного" множественного наследования
Долго рассказывать, но можно.
> вызов метода у класса через сопоставление текстом - имеет мало общего с языком, претендующим на скорость исполнения
С++ вообще говно, в нём есть ассоциативный массив, и если его использовать вместо обычного, то ты получишь тормоза по скорости, фуууу С++ тормозное говноооооо
Кстати, напомни, во сколько раз Дельфи тормознее С++ного студийного компилятора или гццшного компилятора?
если метод хоть где-нибудь вызывается с помощью текстового имени, то как минимум этот метод нельзя оптимизировать и инлайнить, выкинув из финального объектника
если в дельфи теперь _все_ методы такие, то это пиздец, теперь понятно, почему дельфиний TOAD работает медленнее .net студии (ещё и падает, сука, постоянно, но в этом уже кривые руки пидарасов виноваты, а не язык)
а далее уже идут более понятные и повсеместные причины, связанные с динамическим вызовом (поиск подходящего метода по массиву имён), от этого не уйдешь
того же в крестах, если хочешь, легко можешь добиться через GetProcAddress и dll и аналогов для конкретного компилятора - что тут нового
думаю, если каждый метод в новой дельфи так теперь работает (тарас, у тебя её нет, думаю), то получится минимум раза в два тормознее
притом что какая-нибудь жаба может на лету переоптимизировать такие вызовы, рано или поздно подставляя изученный уже адрес, у дельфи такой возможности нет - она же не виртуализирует поток исполнения
кстати, почему до сих пор никто не упомянул мультиметоды?
Схуяли?
> то получится минимум раза в два тормознее
В этом треде крестушиный кокот такой густой, что можно топор вешать.
25% в самом выгодном для крестов раскладе, с совсем шаманскими гццшными оптимизациями, из-за которых код нестабильно работает. Если же без них, то 10% в пользу крестов.
на коде Тараса, всячески избегающего ООП через индирект, обжегшись на молоке
т.е. это голая разница в числодробилке такая?
ты ведь понимаешь разницу в тысяче мелких объектов, размещенных на стеке или локально в массиве, чтобы попасть в кеш, и той же тысячей в сраной куче с десятком переголов? как истинный байтоёб ты не можешь это не понимать
kipar вообще предлагает все методы вызывать динамически, через текстовое имя
кстати, что там с типобезопасностью аргументов? а результата?
Да, конечно, это Дельфи сам по себе заскипидаривается, увидев меня!
> т.е. это голая разница в числодробилке такая?
Это разница в задаче, в которой есть немного места и на глобальные оптимизации. А если выставить параметры так, что голая числодробилка выходит на первое место, то разница в скорости между крестами и дельфями вообще исчезает.
> ты ведь понимаешь разницу в тысяче мелких объектов, размещенных на стеке или локально в массиве, чтобы попасть в кеш, и той же тысячей в сраной куче с десятком переголов?
Кто тебя заставляет-то?
> kipar предлагает все методы вызывать динамически, через текстовое имя
Пруф.
Ты расскажи мне про то, каким нахуй образом это мешает инлайну там, где вызов прямой. Блять, так это ж ёб вашу мать, если в крестах я хоть раз вызвал некий метод по указателю, то всё, пизда инлайну? Ох нихуя ж себе!
http://ideone.com/WhLF4K
Так значит, в крестах нет множественного наследования? Да кресты же говно полное, как можно на этом говнище писать!!!
блять, ну ты ослеп? не видишь typedef чтоли? :) и вообще не палица так this->Base::f(); бгг
>> всегда есть typedef
читай скрижали ещё раз
Блять чё так с полемическим учеником разговариваешь? :3
хоть и работы сегодня дохера :)
нет только виртуального конструктора (по очевидным причинам производительности и модели представления данных) да виртуального шаблонного метода (по понятным причинам времени инстанциирования такого метода)
Нет, нет любых виртуальных методов класса (в крестах их еще называют "статическими методами", из-за этого некоторые крестовики в принципе неспособны понять как они могут быть виртуальными, мол "они же статические"!). Но да, это из-за того что классы не являются первоклассными гражданами.
>ну есть же!
Разумеется я имею в виду указатель на метод конкретного экзмепляра, т.е. "делегат".
>как мне в дельфи в делегат получить умный указатель на объект, который не даст объекту уничтожиться?
В ООП нет указателей. RAII это тоже тема более-менее перпендикулярная ООП.
>вызов метода у класса через сопоставление текстом - имеет мало общего с языком, претендующим на скорость исполнения, мы же ведём речь про то, что дельфи претендует на нишу С++?
Я думал мы говорим где ООП убог, а не о том кто на что претендует.
>отсутствие вызова метода через текстовое имя как раз напрямую связана с гетерогенностью языка. если бы языком занималась лишь одна лажовая конторка, то в крестах тоже получили бы 2% ниши и полную невостребованность
Но кому интересно с чем это связано. Я знаю что все проблемы С++ можно обосновать отговорками типа "это нужно для обратной совместимости" и "зато мы в другом месте сэкономили пару тактов".
>ну так что со стандартом у дельфи?
Пока компилятора только два кому нужен стандарт?
>а ты пишешь наследника, не зная, от какого класса он унаследован?
Я не вижу смысла помнить об этом, если за меня это может сделать компилятор.
Да все вроде есть, и интерфейсы и миксины. А множественное наследование не нужно, во всех нормальных языках от него отказались, послушаем визги крестовиков когда и там от него откажутся.
>если метод хоть где-нибудь вызывается с помощью текстового имени, то как минимум этот метод нельзя оптимизировать и инлайнить, выкинув из финального объектника
А кто говорил про все методы? Какие надо, такие и объявляешь. Да и вообще я вроде про свойства говорил, насчет методов надо уточнять.
>В крестах не обязательно указывать класс предка, как и в дельфях
Ну да, но наверняка все пишут без этой обертки и указывают имя предка вручную, поэтому любой чужой класс придется в нее оборачивать.
Я вот это всё эмулировал через ручное заполнение специальной структуры, содержащей нужные значения и указатели на нужные методы.
> typedef BasePituxKokokokot Base;
А теперь унаследуй что-нибудь от D.
http://ideone.com/KiglAl
Problems, Bormand?
http://ideone.com/XC0BQl
Но я знаю что это решаемо, мне на другом форуме уже показывали реализацию.
Ого... В MS VC вроде такой проблемы нет. Видимо gcc 2 прохода делает.
В очередной раз вижулстудия попыталась выебнуться и соснула сомалийских хуйцов :)
От порядка описания членов в классе ничего зависеть не должно. Поэтому и виснет.
Давеча ж на крестофоруме обсуждали, когда порядок инициализации в конструкторе (который в том случае был _важен_) не совпадал с порядком объявления, и компилятор их конструировал именно в порядке объявления, и кишками распидорашивало.
емнип, гцц даже ворнингами срётъ об этом
Что решаемо? Что показывали?
сделали так:http://ideone.com/QxMoHo
что?
>Stertor 16.02.2014 16:05 #
>Ну, это уж слишком.
>Stertor
Типа кто-то увидит в коде break, continue, exit и не догадается, что это смена потока исполнения?
если серьезно
Break и Continue можно так же переопределить?
То что их можно переопределить - да, по-моему, недостаток, но я не вижу в этом ничего критического, #define true false примерно того же порядка явление.
self.Exit, чтобы компилятору было понятно, что это вызов метода класса.