Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
UppHub
Status & Roadmap
FAQ
Authors & License
Forums
Funding U++
Search on this site











SourceForge.net Logo

SourceForge.net Logo

GitHub Logo

Discord Logo

U++ usage and development cycle guide


Table of contents

 

1. Forum

2. Reporting bugs

3. GIT

4. Issue tracking

5. Something about coding standards

 


1. Forum

After you have installed U++ and tried some examples, you might have came to conclusion that you are going to give it a try. Now first thing that you should do at this moment is to register in the Forum, where you will be able to post question, propose changes, report bugs etc. We strongly recommend to use the forum for all the communication, please do not try to post emails about U++ features directly to authors. The main reason for this is that if you ask about your problem in the forum, the discussion will get recorded for future searches. Also note that that there is "Newbie corner".

Important note: If you feel like you are going to be involved in U++ development, please provide an information about your real name (so that you can be later added to contributors lists without further asking etc...).


2. Reporting bugs

If you do think that you have found a problem with U++ library, you should report it in the forum. In order to make dealing with the issue as efficient as possible please, following steps would be highly appreciated:

Specify the version of U++ (also, you might want to try svn trunk or latest nightly build to find out whether the issue was already fixed)

Specify your host platform (OS and its version, compiler and possibly also something about HW).

Post a testcase that can be easily compiled. Testcase should be the minimal source code required to reproduce the problem. Usually, it takes a form of package, compressed as .zip and posted as attachment in the forum. Ideally, the name of package should start with your name, followed by '_' and something that makes its name unique, like 'mirek_bug25'. The reason for this naming convention is so that it does not name-clash with other testcases.

Describe a way how to reproduce a problem

After posting a bug report, please let us time to process it. Serious bugs are usually fixed in days, but sometimes less serious issue can take weeks. If problem cannot be fixed immediately, it is usually moved to redmine issue tracking system. You can check the what issues are currently open here.


3. GIT

U++ currently uses git as their main version control tool. Main git repository are located under https://github.com/ultimatepp/ultimatepp. You could learn more about U++ framework development with git from following documentation site.

The GIT contains following sub-directories (U++ nests):

 

uppsrc

This contains "canonical" U++ library packages, albeit not all packages of this nest are exported to U++ releases at this time (sort of flaw).

reference

Reference examples. These examples are meant as sort of "documentation by example". This gets exported into U++ releases.

examples

Demonstration examples. This gets exported into U++ releases.

tutorial

Companion examples for tutorials. This gets exported into U++ releases.

upptst

Manual tests.

autotest

Automated tests.

benchmarks

Benchmarking code.

autotst

Special packages to test the autotest system.

rainbow

Testing area for developing new GUI backends.

 


4. Issue tracking

All longer term U++ issues should be tracked. We are using Redmine issue tracking system for this, which is here.


5. Something about coding standards

General, I believe that there will be a little problems with coding standard, as the reason that made you use U++ was probably its way of doing things in the first place. However, to recapitulate:

Using delete is a big no-no (of course there might be exception).

You can generally avoid new in U++, so think twice before using it

Generally, classes should have default constructor - that is required to make in-place construction possible

Please do not propose adding/using shared (reference counted) smart pointers. We have worked hard to make possible to avoid them :)

Use tabs to provide block indents, tabsize is 4 characters

Use spaces for non-block indents, e.g. to indent second line of long if condition

There are no recommendation about C++ formatting, put spaces and place { as you please

All C++14 core language features are allowed and it is minimal standard to compile U++

For now, U++ library code is C++20 compatible, but C++20 is not required. Parts intended to support C++20 features should be conditionally included using #ifdef CPP_20

Prefer U++ features over equivalents in the standard library for example use Upp::Index instead of std::set

 

Do you want to contribute?