QT is developed by an alien civilization that hate humans. They can’t make std::shared_ptr
work in QML since 2014:

QT is developed by an alien civilization that hate humans. They can’t make std::shared_ptr
work in QML since 2014:
It converts only from non-virtual base class subobject:
struct B
{
virtual ~B() {};
};
struct D : public virtual B { };
int main()
{
D d;
B& br1 = d;
// cannot convert a 'B*' to a 'D*'; conversion from a virtual base class is implied
// static_cast<D&>(br1);
dynamic_cast<D&>(br1);
return 0;
}
In the vernacular they say stack and heap, but the standard call this automatic and dynamic:
In my previous post I compared the performance of a single QT connection with the performance of a notification mechanism based on virtual functions.
In this post I’ll demonstrate how the performance of QT signals degrade when the number of the connections grow. Briefly saying a QT signal becomes 57 times slower than a virtual function.
Below I described my experimentations and provided the full source code.
(more…)I defined a QT Object that contains an integer value and uses QT signal along with awl::Observable
based on virtual functions to notify the subscribers when the value changes:
#include "Awl/Observable.h"
#include <QObject>
namespace test
{
class NotifyValueChanged
{
public:
virtual void onValueChanged() = 0;
};
class ValueObject :
public QObject,
public awl::Observable<NotifyValueChanged>
{
Q_OBJECT
public:
Q_PROPERTY(int value READ value WRITE setValue NOTIFY valueChanged)
void notifyValueChanged()
{
Notify(&NotifyValueChanged::onValueChanged);
}
signals:
void valueChanged();
The parameter or print
function is a forwarding reference because the range can change while being iterated, but the current value is l-value reference:
#include <string>
#include <vector>
#include <ranges>
#include <iostream>
template <class R, class Value>
concept range_over = std::ranges::range<R> &&
std::same_as<std::ranges::range_value_t<R>, Value>;
template <range_over<std::string> Range>
void print(Range&& range)
{
for (const std::string& val : range)
{
std::cout << val << std::endl;
}
}
The code below prints l-value
:
#include <iostream>
namespace
{
void foo(const int&)
{
std::cout << "const l-value" << std::endl;
}
void foo(int&)
{
std::cout << "l-value" << std::endl;
}
void foo(int&&)
{
std::cout << "r-value" << std::endl;
}
}
Starting from C++14:
#include <string>
#include <memory>
int main()
{
std::unique_ptr<std::string> p = std::make_unique<std::string>("abc");
auto func = [p = std::move(p)]()
{
};
func();
return 0;
}
Static asserts in the code below do not fail with MSVC 19.32.31332 for x86:
#include <string>
int main()
{
std::string v = "abc";
auto func = [v]()
{
auto& l_ref = v;
static_assert(std::is_same_v<decltype(l_ref), std::string&>);
auto&& r_ref = std::move(v);
static_assert(std::is_same_v<decltype(r_ref), std::string&&>);
};
func();
return 0;
}
that is MSVC compiler bug. With GCC both l_ref
and r_ref
are const references.
Thanks to stackoverflow.com.
(more…)Some WordPress plugins stopped working with PHP 7.0 on my Ubuntu 16.04 server and I switched to PHP 7.4 with the following commands:
sudo add-apt-repository ppa:jczaplicki/xenial-php74-temp
sudo apt-get update
sudo apt-get install php7.4 php7.4-fpm php7.4-cli php7.4-mysql php7.4-dom php7.4-mbstring -y
service php7.4-fpm status
cd /etc/php/7.4/fpm/pool.d
sudo mv www.conf www.conf.dist
sudo mv ../../../7.0/fpm/pool.d/devnote.conf .
sudo service php7.0-fpm reload
sudo service php7.4-fpm reload