Ну мы и не претендовали на rocket science. Была решена конкретная проблема, по результатам написана статья. Возможность вывода данных в JSON, это просто приятное дополнение. Но, в любом случае, спасибо за мнение.
Понадобится XML — сделаем. Будет перспектива добавления множества форматов выдачи — напишем обобщенное решение. А тратить время на код который никогда не пригодится, слишком затратно. А что Вам в коде понравилось?
В численном выражении сказать не получится, тестов не ставили. Если хочется конкретных цифр, то у Вас теперь есть оба инструмента для сравнения, можете попробовать. Если же рассматривать чисто умозрительно, по сравнению с нашим подходом добавляются две операции, выделение памяти и копирование. Их можно избежать, что и было сделано.
GDAL, а конкретнее OGR, выполняет много ненужной в конкретной задаче работы. В частности он копирует данные из WKB в свои собственные объекты, что снижает производительность.
Читается легче, но где-то читал, может быть даже на этом сайте, что читаемость кода понижается если определения участвующих в выражении сущностей не доступны на этом же экране. Т. е. если для понимания что же такое, например, SizeOffset придется прокручивать экран или открывать другой файл, читаемость падает.
Для абстрактного кода и его рефакторинга, именованные константы безусловно предпочтительнее. Но в конкретном случае мы имеем дело со сложившимся и неизменным долгое время форматом, и по моему мнению, тут нет необходимости городить такой огород.
Так да! Но есть ли в этом объективный смысл? Улучшает ли это понимание кода, облегчает использование?
Тот кто использует этот класс все равно вызовет метод size() и не увидит что за этим скрывается.
А при чтении кода нужно будет отвлекаться и смотреть на определение SizeOffset.
В предыдущем Вашем примере уже становится не так красиво, количество Size'ов на строку кода великовато, да и смысл каждого Size'а различен.
Все «магические» числа, это смещения в байтах для заранее известной внешнеопределенной бинарной структуры. И поля структуры, совершенно спокойно, могут не иметь соответствий в типах определенных в языке. Так что, указания конкретного количества байт смещения, будет нагляднее и очевиднее чем что-либо другое. А в случае сферического рефакторинга, Вы правы.
Ну можно почти все магические числа заменить на sizeof(unsigned int) или sizeof(double) и не факт, что стало бы читабельнее, мне нужно было ехать, а не «шашечки». Да и все константы очевидны из описания формата.
Пример слова «фигня» (если не нравится, то «штука»).
Использовать следующим образом для набора необходимого количества значений, указать пальцем на предмет и сказать: «Эта фигня предназначена для ....».
В различном контексте принимает произвольные семантические значения.
Хм… мне бы и в голову не пришло. Но спасибо за развитие кругозора. И еще вопрос, Ваш пример написан на С++, я конечно понимаю что MFC это страшное наследие, и префикс 'C' в имени класса получается сам по себе, но пользуетесь ли Вы неймспейсами (namespace)?
С. Макконнелл «Совершенный код» тоже затрагивает поднимаемые здесь вопросы, ну и еще некоторые ;)
Пост хорош, но некоторые мысли, мне кажется, не доведены до логического завершения.
В пункте 6, к переменным с которыми предполагается сложная работа, возможно было бы полезнее сделать сеттеры и геттеры, а не описывать как правильно с ними работать.
С. Макконнелл «Совершенный код» тоже затрагивает поднимаемые здесь вопросы, ну и еще некоторые ;)
Пост хорош, но некоторые мысли, мне кажется, не доведены до логического завершения.
В пункте 6, к переменным с которыми предполагается сложная работа, возможно было бы полезнее сделать сеттеры и геттеры, а не описывать как правильно с ними работать.
С. Макконнелл «Совершенный код» тоже затрагивает поднимаемые здесь вопросы, ну и еще некоторые ;)
Пост хорош, но некоторые мысли, мне кажется, не доведены до логического завершения.
В пункте 6, к переменным с которыми предполагается сложная работа, возможно было бы полезнее сделать сеттеры и геттеры, а не описывать как правильно с ними работать.
А какой формат сохранения? Возможно ли версионирование? И возможно ли изменения без редактора, в текстовом представлении?
Нужной вещью, в моем случае, оказалась производительность, за нее и пришлось побороться в этом велосипеде принеся определенные жертвы.
Для абстрактного кода и его рефакторинга, именованные константы безусловно предпочтительнее. Но в конкретном случае мы имеем дело со сложившимся и неизменным долгое время форматом, и по моему мнению, тут нет необходимости городить такой огород.
Тот кто использует этот класс все равно вызовет метод size() и не увидит что за этим скрывается.
А при чтении кода нужно будет отвлекаться и смотреть на определение SizeOffset.
В предыдущем Вашем примере уже становится не так красиво, количество Size'ов на строку кода великовато, да и смысл каждого Size'а различен.
Первый вариант мне кажется более очевидным для чтения.
Второй не содержит «магических» чисел, но стал ли он более читаемым(очевидным для понимания)?
Использовать следующим образом для набора необходимого количества значений, указать пальцем на предмет и сказать: «Эта фигня предназначена для ....».
В различном контексте принимает произвольные семантические значения.
Готов поспорить что есть еще одно правило, которое Вы соблюдаете, но не упомянули ;)
Правило о количестве параметров передаваемых в функцию или метод.
Пост хорош, но некоторые мысли, мне кажется, не доведены до логического завершения.
В пункте 6, к переменным с которыми предполагается сложная работа, возможно было бы полезнее сделать сеттеры и геттеры, а не описывать как правильно с ними работать.
Пост хорош, но некоторые мысли, мне кажется, не доведены до логического завершения.
В пункте 6, к переменным с которыми предполагается сложная работа, возможно было бы полезнее сделать сеттеры и геттеры, а не описывать как правильно с ними работать.
Пост хорош, но некоторые мысли, мне кажется, не доведены до логического завершения.
В пункте 6, к переменным с которыми предполагается сложная работа, возможно было бы полезнее сделать сеттеры и геттеры, а не описывать как правильно с ними работать.