Ja w swojej nieskończonej naiwności sądziłem, że aby rozwiązać jakikolwiek [ten też] problem wystarczy tylko trochę pomyśleć, a reszta to tylko narzędzia do zakodowania i sprawdzenia pomysłu, i niektóre z nich dodatkowo tylko bardziej ułatwiają i przyśpieszają kodowanie i debugowanie, więc czemu ich nie używać? Ale żeby mieć z nich korzyść to właśnie trzeba używać je jak najczęściej i nawet do najprostszych i najłatwiejszych przypadków. Pisałem kiedyś, że używanie STL może niekiedy utrudnić rozwiązanie jakiegoś problemu, ale myślałem o osobach nie znających go, ale jak mają się tego nauczyć nie próbując go używać? Też widziałem te kody o których piszesz, ale [dalej w swojej naiwności] sądziłem, że tutaj w większości piszą i zamieszczają te kody osoby mające problemy nie tylko z samym STL ale ogóle z programowaniem/kodowaniem/debugowaniem. Osoby, którym STL nie przeszkadza, a wręcz pomaga raczej tu tego nie piszą więc nie wiedziałem, że można z tego wyciągnąć wniosek, że w większości wypadków STL przeszkadza. Widocznie można i widocznie masz rację. Jeszcze w jednym przyznaję ci rację. Rzeczywiście w STL to [i nie tylko] zadanie jest banalnie proste, trywialne i nieciekawe:
[bbone=cpp,1465]#include
exclude
int main(){
std.thinking(off); // for ever
STL.LoadBalancer.Read();
STL.LoadBalancer.Print();
return std.BigSuccess! // AC
} [/bbone]
Podejrzewam, że większość zgłaszających, tak jak i ja użyła tego powyższego programu, bo akurat w tym zadaniu większość zgłoszeń jest w c++ [tylko jedno c], chociaż z drugiej strony to że jest akurat c++ to jeszcze o niczym nie świadczy, a pierwszą instrukcję można z powodzeniem i sukcesem używać we wszystkich językach programowania. 
