Запрещение кастинга виртуального базового класса

#cpp

Почему запрещён кастинг в следующем коде?

class Base
{
};

class Derived : virtual public Base
{
};

int main()
{
    Base *p = new Derived;
    static_cast(p);
    return 0;
}

    

Ответы

Ответ 1

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

Если существуют только типы Base и Derived, то при касте Base* в Derived* надо добавить
смещение в 0 байт, т.к. адреса Derived и Base совпадают.
Однако компилятор допускает, что может существовать другие типы, например

struct Derived2 : virtual Base { char x[1024]; };
struct MostDerived : virtual Derived2, Derived {};


И Base* p может указывать на объект этого типа. Тогда MostDerived выглядит в памяти так:

смещение  | что находится
0         | MostDerived
0         | Base
0         | Derived2 
0         | char Derived2::x[1024]
1024      | Derived 


Виртуальный базовый класс Base, находится в Derived2, самом первом базовом классе
MostDerived. Т.к. Base - это пустой базовый класс, он не занимает никакого места в
памяти. После Derived2 будет располагаться Derived, уже без Base. По этому в этом случае
при касте Base* в Derived* надо добавить смещение в 1024 байт.

Т.к. компилятор не знает какое именно смещение надо использовать, он не может сделать
такой static_cast.

По этому для виртуальных базовых типов поддерживается только dynamic_cast, и то,
только для типов в которых есть виртуальные функции.

Тип timestamp отображается как DATETIME

#mysql #sql

Установил в таблице тестовой тип поля timestamp, и при добавлении туда значения в
виде 1421312123 оно отображается как 0000-00-00 00:00:00

Почему так происходит?

Перепроверяю, тип действительно timestamp.
    

Ответы

Ответ 1

тип timestamp хранит дату и время (отметку времени):


  The TIMESTAMP data type is used for values that contain both date and time parts.
TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.




вы же пытаетесь вставить в столбец число (в математическом смысле этого слова).

это число весьма похоже на количество секунд, прошедших с 1970-01-01 00:00:01 по
2015-01-15 11:55:23 (в московском часовом поясе), т.е., на unix-время (unix timestamp).

если так, то нужно преобразовать это число в дату и время с помощью функции from_unixtime.
примерно так:

insert into t values (from_unixtime(1421312123));


тогда в столбец с типом timestamp попадёт корректное значение, и эта отметка времени
будет корректно отображаться:

select * from t;
+---------------------+
| d                   |
+---------------------+
| 2015-01-15 11:55:23 |
+---------------------+

Rails + Devise + Angular2: аутентификация

#ruby_on_rails #безопасность #devise #csrf #angular2

У меня просто огромное количество вопросов... Но перед этим нужно описать, что собственно
происходит.

Преамбула

Я пытаюсь научить Angular2 авторизироваться в Rails 5 beta 3 приложении. При этом
Rails работает в режиме API. Как я понимаю, для того, чтобы Devise работал в режиме
API, нужен gem devise_token_auth. Гем я установил и настроил, но вот после этого начались
проблемы:

Unpermitted parameters: user, session

Первое, что я попробовал сделать после настройки, послать простой POST запрос и посмотреть,
что произойдёт. А произошло следующее: 

Processing by DeviseTokenAuth::SessionsController#create as *json*
  Parameters: {"user"=>{"username"=>"demo", "password"=>"[FILTERED]"}, "session"=>{"user"=>{"username"=>"demo",
"password"=>"[FILTERED]"}}}
Unpermitted parameters: user, session
  Rendered devise_token_auth/sessions/create.json (0.2ms)
Completed 401 Unauthorized in 18ms (Views: 3.2ms | ActiveRecord: 0.0ms)


И вот с этого момента я немного не понимаю, с каких это пор я должен прописывать
permit для параметров, которые ActionController::ParamsWrapper создаёт динамически
в качестве обёртки? Более того:

devise_parameter_sanitizer.permit(:sign_in) do |user_params|
  user_params.permit(:user, :session)
end


ничего не меняет. Кто-нибудь сталкивался с подобным ранее?

Authentication header

Покопавшись в документации в поисках решения проблемы я нашёл другую:


  The authentication information should be included by the client in the headers
of each request. The headers follow the RFC 6750 Bearer Token format


Т.е. в заголовке запроса должны быть следующие данные:

"access-token": "wwwww",
"token-type":   "Bearer",
"client":       "xxxxx",
"expiry":       "yyyyy",
"uid":          "zzzzz"


В AngularJS они генерировались модулем ng-token-auth, но как мне сгенерировать их
посредством Angular2, у которого данного модуля нет?



Подводя промежуточный итог (потому что чувствую я, после этих проблем я наткнусь
на их ещё большее количество), вот список моих вопросов:


Как исправить unpermitted parameters: user, session в devise_token_auth?
Как сгенерировать access-token?
Как высчитать expiry и есть ли "rails-way" для времени жизни токена?
Что следует писать в client? Раз уж этот идентификатор позволяет пользователю одновременно
авторизироваться с нескольких устройств, то как он должен выглядить? Что туда следует
записать?





Какие данные следует возвращать клиенту после авторизации (помимо 200)?
Какие ещё подводные камни могут меня ждать при попытке авторизироваться через Rails API?




UPD

Вот запрос, который я шлю:

private _user_session_url = 'auth/sign_in';

login (username: string, password: string) : Observable {
    let body = JSON.stringify({ username: username, password: password });
    // TODO: generate header data.
    let headers = new Headers({
        'Content-Type': 'application/json',
        'accept': 'json'
    });
    let options = new RequestOptions({ headers: headers});

    return this.http.post(this._user_session_url, body, options)
        .map((data: any) => data.json())
        .catch(this.handleError)
}


Как видите, session в теле запроса нет. Его создаёт ActionController::ParamsWrapper

В подтверждение привожу Request Payload:

{"username":"demo","password":"123"}    

    

Ответы

Ответ 1

Согласно краткой документации к devise_token_auth (DTA) POST /sign_in принимает только
параметры email и password прямо в корне. То есть, параметры должны выглядеть так:

{
  "email": "foo@example.com",
  "password": "bar"
}


Никакой вложенности. Не надо дополнительно настраивать санитайзер и придумывать ненужные
ключи.



А теперь ответ разом на все оставшиеся вопросы:

Token-Type, Access-Token, Client и Expiry.


  В AngularJS они генерировались модулем ng-token-auth


Нет, они генерируются сервером, клиент ничем умным не занимается. Хранятся они в
БД (в частично искажённом, но проверяемом виде, как пароли), а обмен ими происходит
с помощью заголовков. /sign_in возвращает все интересующие заголовки. Все эти значения
вы просто будете передавать туда-сюда (и обновлять, ведь по умолчанию после каждого
отдельного запроса токен меняется).

Кроме, разве что, Expiry, значением которого можно следить, "когда токен отвалится
и потребует обновления", что можно использовать для выкидывания на форму входа.

Пользоваться DTA без ng-token-auth можно, но прежде чем за это браться, стоит прочесть
документацию к используемым методам.



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

SOLID - обсуждение Open Closed Principle

#php #solid

  Бертран Мейер в основном известен как основоположник термина Принцип открытости/закрытости,
который появился в 1988 году в его книге Object-Oriented Software Construction. Идея
была в том, что однажды разработанная реализация класса в дальнейшем требует только
исправления ошибок, а новые или изменённые функции требуют создания нового класса.
Этот новый класс может переиспользовать код исходного класса через механизм наследования.
Производный подкласс может реализовывать или не реализовывать интерфейс исходного класса.


То есть получается если мы создаем например класс Человек, который имеет методы скажем
поесть, поспать, попить. Потом скажем через время нам нужно создать класс Работник
с методами - работать, получать зарплату и скажем ему нужен еще метод общаться, то
что получается мы не можем человеку добавить этот метод общаться, так как это нарушит
принципы SOLID? А только можем добавить его в класс Работник или любой другой который
наследуется Человека?...

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

Этот принцип же породит множество ненужных классов, наследующих базовый.

Из википедии:


  Solid - принципы, когда применяются вместе, предназначены для повышения вероятности
того, что программист создаст систему, которую будет легко поддерживать и расширять
в течение долгого времени[3]. Принципы SOLID - это руководства, которые могут применяться
во время работы над программным обеспечением для удаления запахов кода предписывая
программисту выполнять рефакторинг исходного кода, пока тот не станет разборчиво написанным
и расширяемым. Это часть общей стратегии гибкой и адаптивной разработки


Но данный принцип противоречит концепции (разборчиво написанного кода и расширяемости).
Т.е если у нас уже есть множество созданных объектов 'Человек', и в проекте мы хотим
чтобы они теперь могли общаться, после добавления данного метода в другой класс, мы
должны все наши объекты создать на базе другого класса. 

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

Ответы

Ответ 1

SOLID - это не догмы, а рекомендации. Обычно, если им следовать, то код получается
легче дорабатывать и тестировать. Но это может приводить к тому, что кода может быть
больше. Чем больше программируешь, тем больше понимаешь как лучше найти баланс.

Кроме наследования есть другие инструменты - например, инкапсуляция, интерфейсы.
Я бы сделал ОбщительныйИнтерфейс пока из одного метода общаться. И нужные наследники
Человека реализовывали бы этот интерфейс. Также, если многие потомки Человека общаются
схожим образом, то, чтобы не дублировать код, вынес бы логику общения в отдельный класс
и инкапсулировал его в нужных Человеков.

Не приходят сообщения на почту

#php #jquery #ajax

Не приходят сообщения на почту. На локалке все работает адекватно. Выгружаю все на
хостинг и сообщения не приходят. В чем может быть причина?

Сама форма:


    
close
    
Заказать бесплатный звонок
    

        
        
        
        
    
    
    




JS:  

$('#phone-call').submit(function(event) {
    event.preventDefault();
    $.ajax({
        url: 'feedback_lib.php',
        beforeSend: function() {
            $('#load').fadeIn(400);
        },
        type: 'post',
        data: $('#phone-call').serialize(),
        success: function(answer) {
            $('#answer').html(answer);
        }
    }).done(function() {
        $('#load').fadeOut(400),
        $('.subm').html('Спасибо за заявку!');
    });
});


PHP:  

if (preg_match('~[^а-яёА-ЯЁ ]~u', $name)) $result = 1;
else {
if (preg_match('/^\d+$/', $phone)) {
    $subject = "Письмо с Вашего сайта http://" . $_SERVER["HTTP_HOST"] . "/";
    $header = "From <" . $email . ">\r\nContent-type: text/plain; charset=utf-8\r\n";
    mail($subject, $message, $header, $recepient);
    mail($subject, $message1, $header, $copy);
    $result = 5;
} else $result = 4;
}
echo getAnswer($result);

    

Ответы

Ответ 1

Установи sendmail на хостинг, если нету прав напиши админам, чтобы они установили.


Ответ 2

Во первых - посмотри ошибку после вызова mail 

   print_r(error_get_last())


Во вторых - можно использовать эту библиотеку

PHPMailer

И с ее помощью отправлять письма со своей почты.

Java. Вопросы по многопоточности

#java #многопоточность #java_ee #jvm

К примеру у меня есть какой-то объект типа Object многопоточное чтение которого происходит
гораздо чаще, чем модификация и есть два варианта реализации:

a)  обычная переменная Object obj и ReadWriteLock соответственно на методы чтения
и модификации

б) volatile Object obj, на метод модификации - простой Lock, создание нового объекта
и замены ссылки obj. Метод чтения без синхронизации(не считая записи-чтения volatile
переменной)

Какой из вариантов предпочтительнее и будет работать быстрее и почему?
Если я решил делать вариант 1.б и точно знаю, что мое приложение будет запускаться
на сервере с несколькими процессорами архитектуры x86-64, то мог ли я вообще убрать
volatile и нарушив тем самым JMM, но полагаясь на протоколы когерентности кешей процессоров?
прочитает ли ядро 2-го процессора измененные данные в ядре первого и даст ли это хоть
какой-то прирост производительности? 

    

Ответы

Ответ 1

Интересный вопрос.  Попробую ответить, хотя не претендую на правильность. Буду рад
замечанием в комментариях.

1) Какой вариант будет быстрее? Сказать трудно, потому что все сильно зависит от
usecas'а который вы используете. А именно, от количества писателей и читателей, частоты
записи и чтения, потребность в "честной" синхронизации или ее критичности и пр.  В
общем, нужно замерять и писать тесты. Написал для этого вот такой код :

Для варианта с Lock: 

    private Object object = new Object();
    private final ReentrantLock lock = new ReentrantLock();             

    Supplier