а я бы остановился на похапе7)

Павел, а если предложить им микросервисную архитектуру? Туда Ди проще будет вписать

Я прекрасно знаю что такое микросервисная архитектура, и поверь, это далеко не панацея, а зачастую превращается в лютый ад.

а не мог бы рассказать про минусы?

Просто из того что я смотрел там все же плюсов в разы больше.

а не мог бы рассказать про минусы?

https://habrahabr.ru/post/276539/

https://medium.com/@dolphin278/%D0%B2%D0%B0%D0%BC-%D0%BD%D0%B5-%D0%BD%D1%83%D0%B6%D0%BD%D1%8B-%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B-1d6ac1747515

https://medium.com/@dolphin278/%D0%B2%D0%B0%D0%BC-%D0%BD%D0%B5-%D0%BD%D1%83%D0%B6%D0%BD%D1%8B-%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B-1d6ac1747515

Все зависит от того, на что ориентирован проект и на какие нагрузки

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

И только добавляют страданий.

В частности вот и в моем проекте тоже куча боли. Взяли распилили 1 проект на проект + 3 микросервиса. И мы всегда делаем в 3 раза больше инфраструктурной работы.

а какого рода работы стало больше?

Вместо деплоя одного приложения надо задеплоить 4. Вместо правки одной строчки кода в проекте надо править эту строчку в 4х проектах и делать 4 коммита. Вместо единой базы моделейЮ работающих с БД, получаем 4 версии одного и того же класса в проектах, либо общий репозиторий с зоопарком версий.

+ это все обросло кучей менеджеров и контроллеров для распаковки/запаковки запроса в HTTP

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

И это было на PHP написано??

Там еще это все вросло в AWS инфраструктуру

Но у меня и на прошлой работе был опыт с сервисами, часть на nodejs, команда была грамотнее но все равно не намного лучше получилось.

И это было на PHP написано??

Да, но от языка не зависит на самом деле. В той статье что я дал, там есть заметка о том что это все уже было в начале 2000х, написано на джаве, C++ и всех других возможных языках. И все провалилось.

Ребят, я до книжки добрался. Привидите мне пример когда auto полезен. Желательно простой и наглядный.

да в принципе, auto полезен в любом месте, где, например, возвращаемое из функции значение присваивается объявляемой переменной

если его просто пихать везде то читабельность падает

ИМХО

во всяком случае @Lord_Evil бил по рукам меня за это

жизнь — это цепь компромиссов)

@Lord_Evil не терпит компромиссов)

это уже личные проблемы @Lord_Evil )

size_t на 64 битах равен 64 битам?

да

я так понимаю, в D size_t для amd64 — это алиас на ulong

если написать "равен размеру машинного слова" это же не правильно будет? машинное слово же вроде что-то другое

«равен размеру указателя» будет ближе к истине, наверное)

Несколько слов нужно сказать о типе size_t. Данный тип был введен в Си-подобные языки с появлением 64-битных процессоров. Если во времена 32-битных процессоров тип int совпадал по размеру с размером указателя и был равен 32 битам, то с появлением 64-битных процессоров возникли определенные сложности с портированием программного обеспечения, т.к. размер указателя на 64-битных системах стал равен 64-битам. В итоге был введен новый беззнаковый тип size_t, который привязан к битности процессора. На 32 битной системе он равен 32 битам, на 64 битной — 64. Иными словами size_t - это максимальный целочисленный тип для данной платформы. Если компилятор будет запущен на 128 битном процессоре, size_t будет равен 128 битам. так норм?

как-то сомнительно)

чтоб не писать шаблоны с их аргументами

чтоб не писать шаблоны с их аргументами

м... да точно, хороший пример

Несколько слов нужно сказать о типе size_t. Данный тип был введен в Си-подобные языки с появлением 64-битных процессоров. Если во времена 32-битных процессоров тип int совпадал по размеру с размером указателя и был равен 32 битам, то с появлением 64-битных процессоров возникли определенные сложности с портированием программного обеспечения, т.к. размер указателя на 64-битных системах стал равен 64-битам. В итоге был введен новый беззнаковый тип size_t, который привязан к битности процессора. На 32 битной системе он равен 32 битам, на 64 битной — 64. Иными словами size_t - это максимальный целочисленный тип для данной платформы. Если компилятор будет запущен на 128 битном процессоре, size_t будет равен 128 битам. так норм?

size_t это не указатель

size_t в D — это вообще alias, прописанный в object.d, а не отдельный тип)

size_t в D — это вообще alias, прописанный в object.d, а не отдельный тип)

а в чистом Си так же?

но его размер зависит от размера указателя платформы

я имею ввиду, что это не указатель по смыслу

в чистом си это, скорее всего #define

это типа размера

это типа размера

Как тогда лучше написать: ``

Данный тип был введен в Си-подобные языки с появлением 64-битных процессоров. Если во времена 32-битных процессоров тип int совпадал по размеру с размером указателя и был равен 32 битам

но с чистым Си в этом плане вообще проблемы, ибо стандартом размеры short, int и long определяются в зависимости от платформы

а size_t, по сути, это максимальный индекс массива на платформе, который зависит от размера указателя

Как тогда лучше написать: ``

есть тип ptrdiff_t, он больше подходит к термину "указатель"

такое вот перепетии судьбы)

так как беззнаковый

тфу

знаковый

а для чего писать эту историческую справку, раз столько толкований? (: мб просто написать, как устроено в D?

у указателя знак может быть?

а size_t беззнаковый, и алгебру указателей на нём не очень делать

у самого указателя нет, а у разницы да

если ты вычисляешь смещение относительно чего-то то можешь получить минус

есть тип ptrdiff_t, он больше подходит к термину "указатель"

А как указатель может быть знаковым?

короче, суть size_t — максимальный размер индекса, ptrdiff_t — разница между индексами, я так понимаю)

Да

+

Так как предложение то переписать: Данный тип был введен в Си-подобные языки с появлением 64-битных процессоров. Если во времена 32-битных процессоров тип int совпадал по размеру с размером указателя и был равен 32 битам

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

а для чего писать эту историческую справку, раз столько толкований? (: мб просто написать, как устроено в D?

согласен

Я читал что ptrdiff_t для адресной арифметики, когда один указатель можно вычесть из другого. А если просто нужен указатель как адрес ячейки памяти, то size_t подойдет.

согласен

учебник для кого? не для историков же)

Я читал что ptrdiff_t для адресной арифметики, когда один указатель можно вычесть из другого. А если просто нужен указатель как адрес ячейки памяти, то size_t подойдет.

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

если его просто пихать везде то читабельность падает

Я согласен, читабельность иногда падает. Его можно использовать когда создаешь объект класса через auto foo = new SomeObject!Some() так как и так справа видно какой тип будет у переменной.

ERROR: S client not available

но это всё словоблудие и на практике я редко где встречал адресную арифметику

Блин, может тупо напистать что size_t это максимальный целочисленный тип для данной платформы?

не правильно будет

потому что 64-битные данные можно ворочить и на 32х битах

только это 4 операции будет вместо одной (если не ошибаюсь)

всмысле не для тебя 4, а для процессора

а вот что писали в далеком 2003 году на форуме D

In most compilers, 'size_t' is a type definition (typedef) specifying the kind of integer variable returned by the 'sizeof' operator. It is used because the exact type returned by 'sizeof' can vary from implementation to implementation. For portability, it's a good idea to use 'size_t' when you want a variable that represents the size of something.

ты заметишь падение производительности, если делаешь это в buttle-neck

ну это понятно, но вроде бы фраза верна? можно добавить "реальный\истинный размер"

http://forum.dlang.org/post/2m7vjvglnc4r9l6q3g1nuvd9gt1brbrdqu@4ax.com

короче, в D size_t соответствует максимально доступному размеру массива, и все)

не массива, скорее всего

целочисленной переменной

для x86 — это 32 бита, для amd64 — это 64 бита

а памяти, занимаемой массивом

терминология блин

короче пиши меньше слов)))

ну вообще, наверное, да)

никак в толк не возьму почему про массив то речь если это вроде для целочисленных?

ох

короче, достоверно известно, что size_t будет равен размеру указателя на уровне машинных кодов)

для конкретной архитектуры

вот мне кажется эта формулировка немного может сбить с толку

размер size_t, а не сам size_t

можно написать, что дальше археологи еще не раскопали)

можно написать, что дальше археологи еще не раскопали)

идеально!

пора уже вводить новую дисциплину: компьютерная археология)

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

в этой дисциплине можно изучать кобол и режимы работы процессоров intel)

я тут прочитал что в С++ размер указателя зависит не от архитектуры, а от компилятора %)

https://www.viva64.com/ru/k/0044/