а еще оказалась говном система сборки-линковки.

Можно аргументы ?)

в 2017 лучше писать на Embedded подмножестве плюсов, нежели на сях. Потому что плюсы проще оптимизировать и на плюсах получается меньше кода.

Даже на embedded

а еще оказалась говном система сборки-линковки.

В каком месте говно то ? Стандарт общемировой

Который держится десятилетия

тормозит нещадно

Си тормозит ? Ты щас серьезно ?

Бенчмарки глянь

бля, ну в С++ система сборки на много круче, да. А поцаны и не знали идиот тот, кто переходит на личности, не так ли?

в 2017 лучше писать на Embedded подмножестве плюсов, нежели на сях. Потому что плюсы проще оптимизировать и на плюсах получается меньше кода.

Я в ембдд работал не один год, си стандарт. Плюсы никто не берёт по овердохера причин

Я в ембдд работал не один год, си стандарт. Плюсы никто не берёт по овердохера причин

каким?

//git на C написан

//git на C написан

да почти весь полезный софт на си написан

да почти весь полезный софт на си написан

^

В большом проекте не разобрать чё где откуда и где косяки. Есть реальные примеры переписывания больших проектов с плюсов на си

В большом проекте не разобрать чё где откуда и где косяки. Есть реальные примеры переписывания больших проектов с плюсов на си

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

то есть пока это довод уровня "люди не умеют писать код на плюсах, поэтому выбрали Си"

да почти весь полезный софт на си написан

У C++ читаемость кода ущербная

@podmokov еще есть чо? Кстати есть примеры и обратные - переписывания с Сей на плюсы

то есть пока это довод уровня "люди не умеют писать код на плюсах, поэтому выбрали Си"

Ну хорошо, где ты видел крутые проекты на плюсах в эмбедд?

У C++ читаемость кода ущербная

в С++ - почти всё что сверх си ущербное

Техаские инструменты пишут на сях

Почему может получиться двойной указатель? делаю func(dao *ModelDAO) findByParam(rs app.RequestScope, param string) (*model.Type) { var model model.Type if model, err := func1(&model); err == nil { if model, err = func2(&model); err == nil { return nil } } return &model } func1(dao *ModelDAO) (*ModelType) {} func2(dao *ModelDAO) (*ModelType) {}

Osal c-like

там где func2 получается ошибка, что метод принимает *ModelType, а я передаю **ModelType

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

что с моим синтаксисом не так?

тихо тут пацаны срутся

Коллеги, а тут много кто пишет микросервисы. А куда вы с десятков/сотен микросервисов собираете логи / сообщения о всяких ошибках? Самопальный апи? ELK? Еще что-то хитрое?

@tehfvpr та вижу. хватит им уже)))

Ну хорошо, где ты видел крутые проекты на плюсах в эмбедд?

Честно я и на Сях не видел крутых с точки зрения кодов проектов. Не в Embedded впрочем все немного лучше с плюсами, а с Сями одно говно, как и в embedded

бля, ну в С++ система сборки на много круче, да. А поцаны и не знали идиот тот, кто переходит на личности, не так ли?

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

@anatolijs graylog

Честно я и на Сях не видел крутых с точки зрения кодов проектов. Не в Embedded впрочем все немного лучше с плюсами, а с Сями одно говно, как и в embedded

TI OSAL неплохо написан как бы

Я писал софт для BLE и мне было ок

Си тормозит ? Ты щас серьезно ?

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

Я писал дрова на лин для embedded и мне было ок на сях

Я писал дрова на лин для embedded и мне было ок на сях

люди, упаси госпади, на перле пишут и им ок

не для ембеддед слава богу (хотя кто знает?)

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

а есть смысл C с другими языками сравнивать?

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

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

я как web-developer чувствую себя в вашей группе не в своей тарелке)))

@podmokov ты тоже троллишь же, да?

а есть смысл C с другими языками сравнивать?

Я не вижу. Он уникален и занимает свою нишу

люди, упаси госпади, на перле пишут и им ок

Дрова к ядру на перле. Серьезно ?

Я не вижу. Он уникален и занимает свою нишу

вот и я о том же. обя языка C и c++ в одной нише. других там нет

package main import ( "fmt" ) type t struct { id int cnt int } func foo(v* interface {} ) { *v = t{10, 20} } func main() { var v interface{} = t{} foo(&v) fmt.Printf("%v", v) }

спасибо! а с конкретным типом нельзя, получается?

ладн. позже зайду, как успокоетесь

Дрова к ядру на перле. Серьезно ?

Ок, тоже троль

спасибо! а с конкретным типом нельзя, получается?

почему? можно package main import ( "fmt" ) type t struct { id int cnt int } func foo(v* t ) { *v = t{10, 20} } func main() { v := t{} foo(&v) fmt.Printf("%v", v) }

Ок, тоже троль

все плохие. иди мамке пожалуйся

Чё тут происходит вообще, я тоже в ридонли

Ладно на го люди пытались проект поднимать дрова переписку с сей, я ещё понял..

все плохие. иди мамке пожалуйся

С тобой то не о чем говорить, сразу понятно стало с первого аргумента

Почему может получиться двойной указатель? делаю func(dao *ModelDAO) findByParam(rs app.RequestScope, param string) (*model.Type) { var model model.Type if model, err := func1(&model); err == nil { if model, err = func2(&model); err == nil { return nil } } return &model } func1(dao *ModelDAO) (*model.Type) {} func2(dao *ModelDAO) (*model.Type) {} там где func2 получается ошибка, что метод принимает *model.Type, а я передаю **model.Type Почему указатель двоит???

почему? можно package main import ( "fmt" ) type t struct { id int cnt int } func foo(v* t ) { *v = t{10, 20} } func main() { v := t{} foo(&v) fmt.Printf("%v", v) }

https://play.golang.org/p/KidfpgV99J вот так не работает

Почему может получиться двойной указатель? делаю func(dao *ModelDAO) findByParam(rs app.RequestScope, param string) (*model.Type) { var model model.Type if model, err := func1(&model); err == nil { if model, err = func2(&model); err == nil { return nil } } return &model } func1(dao *ModelDAO) (*model.Type) {} func2(dao *ModelDAO) (*model.Type) {} там где func2 получается ошибка, что метод принимает *model.Type, а я передаю **model.Type Почему указатель двоит???

ModelType это интерфейс?

@tehfvpr структура

я там переименовывал Везде model.type

кажись везде поправил

переопределил model же ты, не?

Почему может получиться двойной указатель? делаю func(dao *ModelDAO) findByParam(rs app.RequestScope, param string) (*model.Type) { var model model.Type if model, err := func1(&model); err == nil { if model, err = func2(&model); err == nil { return nil } } return &model } func1(dao *ModelDAO) (*model.Type) {} func2(dao *ModelDAO) (*model.Type) {} там где func2 получается ошибка, что метод принимает *model.Type, а я передаю **model.Type Почему указатель двоит???

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

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

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

func2(&model)

берешь

if model, err := func1(&model); здесь ты создал новую переменную model в которой лижет *model

@di3young спасибо. Я думал указатель сбрасывается

https://play.golang.org/p/KidfpgV99J вот так не работает

в этом случае, надо будет через var интерфейс явно, как я показал выше

в этом случае, надо будет через var интерфейс явно, как я показал выше

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

что-то я не могу подружиться с go - OOP после php Несколько другое поведение объектов, переданных в методы

что-то я не могу подружиться с go - OOP после php Несколько другое поведение объектов, переданных в методы

ты имеешь ввиду по значению и по указателю?

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

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

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

я готов выслушать советы, как удачно сделать дизайн взаимодействия вот с таким апи: http://download.automation.odin.com/oa/7.0/oapremium/portal/en/billing_api_reference/75178.htm

вот и я о том же. обя языка C и c++ в одной нише. других там нет

rust же

@anatolijs Да. Меня указатели вообще с толку сбивают. И не совсем понимаю как работать с интерфейсами вне пакетов, где они были объявлены

@anatolijs Да. Меня указатели вообще с толку сбивают. И не совсем понимаю как работать с интерфейсами вне пакетов, где они были объявлены

К указателям относись так: если необходимо косвенно изменить объект, используй указатель. В противном случае, используй значение. Ну и если поймешь, что львиная доля потери производительности уходит на копирование по значению, переходи на указатели. Только в этом случае, случайное изменение состояние внутри метода будет оттранслировано в сам объект, который вызвал метод. Про интерфейсы не понял вопроса.

@anatolijs в Go есть пустые интерфейсы, которые не имеют объявленных методов У меня в авторизации есть пакет apis с пустым интерфейсом. // Identity represents an authenticated user. If a user is successfully authenticated by // an auth handler (Basic, Bearer, or Query), an Identity object will be made available for injection. type Identity interface{} Когда я нахожу в db пользователя по запрашиваемому Bearer token - то в авторизации происходит следующее func(c *routing.Context, token string) (apis.Identity, error) { if len(token) > 0 { userDAO := daos.NewUserDAO() service := services.NewUserService(userDAO) user, err := service.GetByAuthKey(c, token) if err == nil { return apis.Identity(user), nil } Не понимаю для чего здесь нужен пустой интерфейс и как это потом использовать

@anatolijs в Go есть пустые интерфейсы, которые не имеют объявленных методов У меня в авторизации есть пакет apis с пустым интерфейсом. // Identity represents an authenticated user. If a user is successfully authenticated by // an auth handler (Basic, Bearer, or Query), an Identity object will be made available for injection. type Identity interface{} Когда я нахожу в db пользователя по запрашиваемому Bearer token - то в авторизации происходит следующее func(c *routing.Context, token string) (apis.Identity, error) { if len(token) > 0 { userDAO := daos.NewUserDAO() service := services.NewUserService(userDAO) user, err := service.GetByAuthKey(c, token) if err == nil { return apis.Identity(user), nil } Не понимаю для чего здесь нужен пустой интерфейс и как это потом использовать

interface{} тракруется как "все что угодно"

> interface{} тракруется как "все что угодно" привет из php|javascript

@anatolijs Я недавно начал изучать go, поэтому еще не привык к работе с ним Спасибо за помощь

@anatolijs Я недавно начал изучать go, поэтому еще не привык к работе с ним Спасибо за помощь

я тоже, поэтому спасибо за вопросы

@anatolijs Я недавно начал изучать go, поэтому еще не привык к работе с ним Спасибо за помощь

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

а то я здесь только пока холивары наблюдаю

@ngalayko т.е. я не имплементирую интерфейс, чтоб он "вынуждал" меня написать методы, а наоборот - пишу методы, чтоб структура подошла под нужный интерфейс?

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

Интерфейс определяет контракт и используется для конкретизации того, что можно ожидать от объекта. А "утиная" типизация просто упрощает описание типа и не требует указывать какой интерфейс этот тип исповедует.

под interface {} подойдет все, поскольку этот интерфейс не накладывает никаких ограничений

спасибо за разъяснения Буду разбираться

вот и я о том же. обя языка C и c++ в одной нише. других там нет

Rust

https://habrahabr.ru/post/318896/ что скажете?

Rust

да. ну он маргинальный в данный момент и мне не нравится.

https://habrahabr.ru/post/318896/ что скажете?

о, прикольно. а есть кстати живая перезагрузка конфига в viper ещё вроде

о, прикольно. а есть кстати живая перезагрузка конфига в viper ещё вроде

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

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

Да, я это и имел ввиду, что значения конфига переписываются (насколько мне известно), но сама программа не перекомпиливается

@antelman какая-то маленькая слабенькая статейка)

@antelman какая-то маленькая слабенькая статейка)

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

Есть у фейсбука в паблике модуль для грейсфула

с передачей listner-а

Это рабочий подход котоырй много где используется