+++ /dev/null
-/**
-@defgroup s4u_api S4U: Next generation SimGrid API
-@brief Future core API, mixing the full power of SimGrid to the power of C++.
-
-@b TLDR: The best documentation is the @ref s4u_examples
-
-Currently (v3.21), S4U is definitely the way to go for long-term
-projects. It is feature complete, but may still evolve slightly in the
-future releases. It can already be used to do everything that can be
-done in SimGrid, but you may have to adapt your code in future
-releases. When this happens, compiling your code will produce
-deprecation warnings for 4 releases (one year) before the removal of
-the old symbols.
-If you want an API that will never ever evolve in the future, proceed
-to the deprecated @ref MSG_API instead.
-
-The S4U interface matches the concepts presented in @ref
-starting_components "the introduction". You should read this page
-first, to not get lost in the amount of classes provided here.
-
-@section s4u_raii Memory Management of S4U objects
-
-For sake of simplicity, we use
-[RAII](https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization)
-everywhere in S4U. This is an idiom where resources are automatically
-managed through the context. Provided that you never manipulate
-objects of type Foo directly but always FooPtr references (which are
-[boost::intrusive_ptr](http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html)<Foo>),
-you will never have to explicitely release the resource that you use
-nor to free the memory of unused objects.
-
-Here is a little example:
-
-@code{cpp}
-void myFunc()
-{
- simgrid::s4u::MutexPtr mutex = simgrid::s4u::Mutex::create(); // Too bad we cannot use `new` here
-
- mutex->lock(); // use the mutex as a simple reference
- // bla bla
- mutex->unlock();
-
-} // The mutex will get automatically freed because the only existing reference gets out of scope
-@endcode
-*/
abstract algorithms in the domains of Cloud, P2P, HPC, IoT, and similar
settings.
+Currently (v3.21), S4U is definitely the way to go for long-term
+projects. It is feature complete, but may still evolve slightly in the
+future releases. It can already be used to do everything that can be
+done in SimGrid, but you may have to adapt your code in future
+releases. When this happens, compiling your code will produce
+deprecation warnings for 4 releases (one year) before the removal of
+the old symbols.
+If you want an API that will never ever evolve in the future, you
+should use the deprecated MSG API instead.
+
-------------
Main Concepts
-------------
Sometimes, you want to change the setting of an activity before it even starts.
-.. todo:: fill this section
+.. todo:: write this section
+
+-----------------
+Memory Management
+-----------------
+
+For sake of simplicity, we use `RAII
+<https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization>`_
+everywhere in S4U. This is an idiom where resources are automatically
+managed through the context. Provided that you never manipulate
+objects of type Foo directly but always FooPtr references (which are
+defined as `boost::intrusive_ptr
+<http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html>`_
+<Foo>), you will never have to explicitely release the resource that
+you use nor to free the memory of unused objects.
+
+Here is a little example:
+
+.. code-block:: cpp
+ void myFunc()
+ {
+ simgrid::s4u::MutexPtr mutex = simgrid::s4u::Mutex::create(); // Too bad we cannot use `new`
+ mutex->lock(); // use the mutex as a simple reference
+ // bla bla
+ mutex->unlock();
+
+ } // The mutex gets automatically freed because the only existing reference gets out of scope
