The naming conventions of Python's library are a bit of a mess, so we'll never get this completely consistent
http://legacy.python.org/dev/peps/pep-0008/
Python ist SCHROTT ;)
12.09.2014
Python Naming Conventions
Comments Off on Python Naming Conventions
I can feel segfaults
int main() {
const char *a = "I can feel segfaults";
printf("%c\n", (char*) * (char*) * (a+strlen(a)));
return 0;
}
Comments Off on I can feel segfaults
04.09.2014
virtual inheritance and sizeof()
Folgender Code:
#include < iostream >
#include < stdint.h >
using namespace std;
class Base {
public:
int32_t a;
};
class Derived : public Base {
public:
int32_t b;
};
class VirtualDerived : virtual public Base {
public:
int32_t c;
};
int main() {
cout << "sizeof Base " << sizeof(Base) << "\n";
cout << "sizeof Derived " << sizeof(Derived) << "\n";
cout << "sizeof VirtualDerived " << sizeof(VirtualDerived) << "\n";
return 0;
}
ergibt auf einer 32Bit Maschine folgende Ausgabe
sizeof Base 4 sizeof Derived 8 sizeof VirtualDerived 12
Die Größe der VirtualDerived Klasse ist also nicht einfach die Summer zweier 4Byte Variablen, sondern auch noch zusätzlich ein 4Byte Pointer auf die Base Klasse.
Auf einer 64Bit Maschine sind es entsprechend 16Byte
sizeof Base 4 sizeof Derived 8 sizeof VirtualDerived 16
Comments Off on virtual inheritance and sizeof()
03.09.2014
Fortran is DEAD!!
Leute, ist sag es schon die ganze Zeit: Fortran ist eine tote Sprache.
Und damit meine ich nicht nur diese verbuggten Compiler. Oder dass es ewig braucht bis man ein neues Feature vom Compiler unterstützt wird. Im Fortran 2003 Standard sind zwar schön viele OO Ansatze festgelegt, aber ich kenne kein Compiler der den Standard nach 10 Jahre komplett unterstützt. Andere Sprachen sind schon 2 Schritte weiter.
Nein, diesmal habe ich viel bessere Argumente auf Lager. In dem Paper [1] wurden 800000 Software Projekte und 13000 Programmierer ausgewertet. Ich möchte nur zu einem Bild aus diesem Paper meine Meinung loswerden. Dieses da:
Also, man sieht hier die Wahrscheinlichkeit, mit der man die Programmiersprache wechselt, wenn ein neues Projekt angefangen wird. Weis bis blau sind niedrige Wahrscheinlichkeiten und rot bis schwarz hohe.
Die Punkte auf der Diagonalen zeigen, dass man die Sprache NICHT wechselt.
Was haben wir denn da alles:
Rote Punkte sehe ich bei allesn *Basic Sprachen. Auch bei der C-Familie mit Java, Perl, PHP, Python bleiben die Programmierer bei ihrer Sprache.
Welche Sprachen bekommen Zuwachs? Das sieht man schön an den vertikalen Balken. Also Java, C/C++ und meinetwegen noch PHP. Das sind also die view Großen wohin die Programmierer wechseln, nachdem sie erkannten, dass ihre vorherige Wahl Schrott war. Tja, wagt es nicht das Wort gegen C++ zu erheben ;) Die Sprache ist sowas von geil und wird den ganzen anderen Schrott längerfristig schon tot trampeln ;)
Wohin rennen denn die Fortran Leute? JAVA. Ach ich lach mich kaputt. Das sind doch total verschiedene Welten.
Ich wette die Auftraggeber wollten parallelisierte hoch performante Software. Haben aber keine Programmierer gefunden der was aufn Kasten hat, und der Rest kam mit der Sprache nicht klar. Also wurde es wieder Java. Das ist ja bekannt und jeder kann es. Und jetzt ärgern die sich mit ihrere total aufgeblasenen, lahmen Software rum, HäHä.
Die *Basic sprachen sind auch alle hinfällig. Zwar wechseln die Leute hier nicht, aber es kommen auch keine neuen hinzu. Die Sprache stirbt also aus, wenn auch alle *Basic Programmierer ausgestorben sind. Sehr einfach Das ;)
[1] Empirical Analysis of Programming Language Adoption; Leo A. Meyerovich; Ariel S. Rabkin
Comments Off on Fortran is DEAD!!
01.09.2014
Fortran progressmeter nice code
! use modulo to determine when to print progress
! not independet of called algorithm speed
! possible output:
! 0.0 % done
! 0.01 % done
! 0,02 % done
! 0,03 % done
! or only one output
! 80.0 % done
! We can do better!
subroutine variant1(n)
implicit none
integer, intent(in) :: n
integer :: i
do i=1, n
if(mod(i, 1000) == 0) write(*,*) 100.0*i/n, "% done"
! call some algorithm
! ...
end do
end subroutine
! check in every iteration if progress is 10%, 20% u.s.w.
! pro: independet of called algorithm speed
! contra: more code
! possible output:
! 10 % done
! 20 % done
! 30 % done
! 80 % done
! 90 % done
! We can do better!
subroutine variant2(n)
implicit none
integer, intent(in) :: n
integer :: i
real :: percent, thr
thr = 1.0 / n * 100.0
do i=1, n
percent = 100.0*i/n
if(percent > 10.0 .and. percent < 10.0+thr) write(*,*) "10 % done"
if(percent > 20.0 .and. percent < 20.0+thr) write(*,*) "20 % done"
if(percent > 30.0 .and. percent < 30.0+thr) write(*,*) "30 % done"
if(percent > 40.0 .and. percent < 40.0+thr) write(*,*) "40 % done"
if(percent > 50.0 .and. percent < 50.0+thr) write(*,*) "50 % done"
if(percent > 60.0 .and. percent < 60.0+thr) write(*,*) "60 % done"
if(percent > 70.0 .and. percent < 70.0+thr) write(*,*) "70 % done"
if(percent > 80.0 .and. percent < 80.0+thr) write(*,*) "80 % done"
if(percent > 90.0 .and. percent < 90.0+thr) write(*,*) "90 % done"
! call some algorithm
! ...
end do
end subroutine
! recalc threshold in every iteration
! possible output:
! 10 % done
! 20 % done
! 30 % done
! ...
! 90 % done
! almost done!
! we have to avoid duplicate code; copy&paste erros
subroutine variant3(n)
implicit none
integer, intent(in) :: n
integer :: i
real :: percent
integer :: thr
thr = 10
do i=1, n
percent = 100.0*i/n
if(percent > thr) then
write(*,*) thr, "% done"
thr = thr + 10
endif
! call some algorithm
! ...
end do
end subroutine
! to avoid duplicate code and copy&paste errors, we move the code into a class and provide a progress function as interface
module ProgressMeterClass
implicit none
private
public :: createProgressMeter
type, public :: ProgressMeter
integer, private :: n
integer, private :: thr
contains
procedure :: progress
end type
interface createProgressMeter
module procedure newProgressMeter
end interface
contains
function newProgressMeter(n) result(this)
implicit none
type(ProgressMeter) :: this
integer, intent(in) :: n
this%n = n
this%thr = 10
end function
subroutine progress(this, i)
implicit none
class(ProgressMeter), intent(inout) :: this
integer, intent(in) :: i
if(100.0*i/this%n > this%thr) then
write(*,*) this%thr, "% done"
this%thr = this%thr + 10
endif
end subroutine
end module
!> we use OO techniques. The progressmeter code is now in the ProgressMeterClass module.
!> We simply create an object of this type and call progress() on it in every iteration
subroutine variant4(n)
use ProgressMeterClass
implicit none
integer, intent(in) :: n
integer :: i
type(ProgressMeter) :: pm
! we can pass a step and filehandle variable too
pm = createProgressMeter(n)
do i=1, n
call pm%progress(i)
! call some algorithm
! ...
end do
end subroutine
program Progressmeter
implicit none
integer :: n
n = 10000000
! call variant1(n)
! call variant2(n)
! call variant3(n)
call variant4(n)
end program
Comments Off on Fortran progressmeter nice code