[AGENT++] why is std::list, std::array, or std::queue not used?

[Isaac Nickaein]

> Yes, may be, but IMHO its time now to throw away the support for former OS and compilers!

While I can see the appeal to switch to latest compilers with recent
language and library features, and I personally advocate it, I believe
this is not feasible for Agent++ for two reasons:

1. As Frank stated, the library is mature and probably has been used
in many projects since its introduction. Those projects might have
some limitations and will not be able to simply switch to new
compilers.

2. While the mainstream compilers are catching up with the recent C++
language standards pretty fast, there are probably several obscure
compilers/hardware that are stuck with C++98/03. An upgrade means they
cannot be supported anymore.

> But the code is not exception save, not easy to read and so not easy to port to new embedded systems!
> (The logging is a nightmare, by the way)

I have disabled the logging altogether during building the library. It
might be useful to help the developer understand what is actually
happening under the hood, but a cleaner API and documentation could
cover that. I don't think the library have any duty to provide the
logging facility.

> C++17 supports threads, mutex, timer, clock, async, atomics, and  in future threadpool, filesystem, …asio and boost supports all current os and compilers and all the future features of C++20, the next std!
> It time to start …

These are great addition to standard library language. For a library,
however, this could be harmful. A library should enforce minimum
requirements so it be easier to adopt (e.g. a having C++11 requirement
is broader than C++17). Most recent C++ libraries are stick with C++11
or C++14. For instance: http://fmtlib.net

> I would like to help.

A proposal like POCO library that you mentioned in other email would
be a great start.  Some of the points that should be considered are:

1. A "standard" license should be agreed for a new Snmp++/Agent++.

2. The parts of previous code that cannot be transferred to new
license should be marked and rewritten if needed during the process.

3. API Compatibility should be decided. If the goal is to have minimal
breaking change, the task of transferring will be straightforward.
However, using language features (e.g. template [meta]programming,
concepts, etc) there could be a more elegant design which simplify the
implementation and usage of library. I am personally leaning toward
keeping API as it is, but someone with more experience with those
language feature might come up with a better design proposal.


Cheers,
Isaac