Kormos Anett írása Andy Vajna halálának online fogadtatásáról

Idézet:

Egy barátom azt tanácsolta, ne írjak erről a témáról, mert túlságosan vékony jég. Nekem pedig az jutott eszembe magamba fojtott riposztként, hogy ha vékony jég azzal kapcsolatban véleményt nyilvánítani: hogyan kéne reagálnunk arra, ha valaki meghal, akkor üsse bassza, szakadjon be alattam, mert ez a jég számomra nem megfelelő élőhely.

Ma reggel meghalt Andy Vajna.

Az internetet pedig rögtön elárasztották a haláláról, és a felesége anyagi fellendüléséről szóló mémek, amelyek belőlem valahogy nem tudták előcsalni az önfeledt kacagás ingerét.

Nem Andy Vajna vagy az özvegye miatt, nem a gyász vagy a mélységes együttérzés miatt.

Hanem azért, mert a derű helyett riadalom költözött belém. Riaszt, hogy mennyire elfogadottá, sőt lájkolandóvá vált az, hogy sokan egy jó poén kedvéért könnyedén levetik magukról emberarcukat …márha egyáltalán szokták még hordani.

Ti is tudjátok, messze vagyok a tapintatoskodástól, nem jellemző, hogy eltartott kisujjal fogom meg a poént. Azt vallom, bármiből lehet viccet csinálni: buzikból, zsidókból, cigányokból, nőkből, férfiakból, anyósokból, apósokból, gyerekekből és… igen, akár a halálból is. Feltéve, hogy képesek vagyunk olyan szellemesen kiforgatni azt a sarkából, hogy felülírjuk magának a HALÁL tényének a drámáját. Ha ezt a lécet nem sikerül megugrani, kár is neki futni, biztos bukás a vége.

Ugyanakkor azt is gondolom, hogy nyitott koporsó felett szotyihéjat köpködve az elhúnyton élcelődni, minimum nem elegáns, de inkább állati nagy parasztság. A szellemeskedésre meg kell várni a megfelelő időt, alkalmat, formát, helyet és közönséget. Ez most nem sikerült.

Itt azonban még kerestem a mentségeket: hogy a virtuális világ már teljesen leradírozta a valóság kontúrját, a mémgyárosok pedig nyilván röpke poéngyártási kényszerük hatása alá kerülve felejtették el, hogy meghalt valaki. De hát tudjuk: a virtuális világ vérszomjas csecsemő, a bölcsőjét pedig mi magunk ringatjuk.

Ezzel a keserű summázattal túl is libbentem volna a témán, amikor kiderült, hogy nagyobb a baj. Andy Vajna halálának napján rengetegen érezték úgy, hogy itt az idő, hogy indulataik és gyűlöletük rövidláncon tartott vérebeit végre ráuszítsák Vajna Tímeára.

És ez sokkolt igazán.

Mert ennek a virtuális vandalizmusnak én nem akarom kutatni az okait, és nem akarom felmenteni az elkövetőit.

Mert ettől valóban belém költözött a szomorúság és a részvét.

A gyász.

Csak az én gyászom nem Andy Vajnának szól, hanem azoknak, akikből az emberség úgy halt ki, hogy nekik talán fel sem tűnt.

Hogy miért osztom meg más posztját, mint másolatot?

Magyar Hang: A gyűlölködés ellen szólalt fel Kormos Anett, a Facebook törölte a posztját

undefined reference to `vtable for C'

This post intends to be a quick help for anyone who struggles with this error. This error came to me when I tried to compile a larger source code which was already compiling on Windows. It took me more than an hour to figure it out. Here is what I've found, from solution to details.

Possible reasons

• C.cpp was not compiled.
• C.o was not added to inputs.
• There is a virtual method in the C class that is not defined (body of method not present).

Minimalistic reproduction

vtrep.cpp

class C
{
public:
  virtual ~C()
  { }
public:
  virtual int id();
};

int main()
{
  C c;
  return 0;
}

Compilation

$ g++ -c vtrep.cpp -o vtrep.o
$ g++ -o vtrep vtrep.o
vtrep.o: In function `C::~C()':
vtrep.cpp:(.text._ZN1CD2Ev[_ZN1CD5Ev]+0x13): undefined reference to `vtable for C'
vtrep.o: In function `C::C()':
vtrep.cpp:(.text._ZN1CC2Ev[_ZN1CC5Ev]+0xf): undefined reference to `vtable for C'
collect2: error: ld returned 1 exit status

Note that the error messages tell nothing about the id() method.

Java ArrayList resize

Once I had an array:

    static final Apple[] apples = new Apple[4];

Then circumstances changed so, Apple became generic, so my code changed to

    static final Apple<T>[] apples = new Apple<T>[4];

which produced compile errors as Cannot create a generic array of Apple<T>, so I was forced to switch to ArrayList like:

    static final ArrayList<Apple<T>> apples = new ArrayList<>(4);
    // 4 means capacity here not size.

I have some code in a static initializer block that fills apples using calculated indexes, so it is not a sequence of add(e) calls and it is not desirable for me to rearrange it that way.

I would like to resize the array to have 4 elements, all of them null. A manual way to achieve it is this:

    static {
      for(int i=0; i<4; ++i)
        apples.add(null);
      // ORIGINAL index-magic based code here.
    }

Which is super effective but not so elegant.

Unfortunately all my search efforts on the Internet were derailed because of posts that suggest ensuring capacity and then adding elements with add(e). None of them addressed the original question of resizing an ArrayList using a filler element. The OPs of those questions were satisfied with those answers, but I really would like to have the answer to the original question.

Until then this will go:

  /**
   * Resizes and returns an {@code ArrayList}.
   * Capacity is not freed upon shrinking. At most one allocation happens.
   * 
   * @param list
   *          Input to be altered, return value.
   * @param size
   *          Desired size
   * @param filler
   *          Additional elements - if any - will be set to this.
   * @return Altered list.
   */
  public static <T> ArrayList<T> resize( ArrayList<T> list, int size, T filler ) {
    for( int i = list.size(); i > size; --i )
      list.remove( i - 1 );
    list.ensureCapacity( size );
    for( int i = list.size(); i < size; ++i )
      list.add( filler );
    return list;
  }

  /**
   * Resizes and returns an {@code ArrayList}.
   * Capacity is not freed upon shrinking. At most one allocation happens.
   * Additional elements - if any - will be set to null.
   * 
   * @param list
   *          Input to be altered, return value.
   * @param size
   *          Desired size
   * @return Altered list.
   */
  public static <T> ArrayList<T> resize( ArrayList<T> list, int size ) {
    return resize( list, size, null );
  }

It is slower than the original for based ad-hoc solution, but it is quicker to read at the place of usage, and resizing of arrays do not (should not) happen that often, as I would seriously doubt the general quality of a code where an array resizing takes place at a hot-spot.

Senior developer / Tapasztalt fejlesztő

Senior Developer explaining how to use his library

A tapasztalt fejlesztő elmeséli, hogy hogyan kell a programját használni

↠ @ DevOps reactions

Prizma napló #2

A két szemem fókuszpontjainak távolsága kb ötöde szemüvegben, mint szemüveg nélkül. A mérési nehézségekhez képest egész jóra sikerültek a lencsék.

A kilincset egyszer-egyszer még mindig eltévesztem, de már csak pár centivel.

Az autók mozgásával kapcsolatban nincsen a korábban tapasztalt bizonytalanság (amit rögtön nem is írtam le).

A szivárvány effektet már csak nagyon ritka fényviszonyok mellett látom. Cserébe minden egy picit olyan, mintha finoman meg lenne rajzolva a kontúrja.

Eddig még egyszer sem sikerült elfelejtenem, hogy rajtam van, azaz még nem szoktam meg.

Prizma napló #1

Minden kontúr szivárványos. A szemész hölgy ezen nem lepődött meg. Azt mondta, hogy meg fogom tanulni a szivárvány nem látását.

Vélt vagy valós térélmény javulás

Emlékezetből pontosan fogom a kilincset, látás alapján 10 centit tévedtem elsőre.

Bizonytalan voltam elsőre egy-két tárgy darabszámát illetően.

A szemüveg felvétele és levétele után nem tapasztalom a megjósolt lehetséges tüneteket (több perces átszokási idő, kettős látás, bizonytalan távolság érzékelés)

Szemüveg nélkül a bal szemem a domináns, szemüvegben a jobb.

Prizma napló #0

Körülbelül egy hónapja volt a melóhelyemen egy szemészeti szűrés, amelyen kiderült (csodák csodája), hogy szemtengely ferdülésem van. Nem volt meg a helyszínen minden műszerük ami a paraméterek pontos kiméréséhez szükségesek lettek volna, ezért elhívtak a székesfehérvári bázisukra további vizsgálatokra, amelyre el is mentem.

A színpad úgy néz ki, hogy egy szemésztáblára felfestenek egy szálkeresztet úgy, hogy a függőleges és a vízszintes szár más-más polarizációval látszott, nekem pedig egy olyan szemüveget (szemészeti lencseállványt) adtak amely elé polár-szűrőket helyeztek. Így a bal szememmel csak a függőleges szárat láttam a jobb szememmel csak a vízszinteset.

Ilyenkor jött a belépő mutatvány. Képes vagyok-e az agyammal mindkét szem képét egyszerre látni. Némi játék után a mutatvány sikerült. A körülbelül 5 méterre lévő falon egymástól fél méter távolságra megláttam az ábra két komponensét. Függőleges irányban is volt némi elcsúszás, az eltérés nagyja vízszintesen volt.

Ekkor következett a prizma típusú lencsék cserélgetése, amelyek a szemeimből kiinduló nézést megpróbálták párhuzamosra téríteni (értjük). A függőleges irányú igazítás tökéletessé vált, a vízszintes nem nagyon akart összejönni. Az agyam elutasította azt az ötletet, hogy a bal és a jobb szemem által látott tárgy megegyezik. Amikor a két komponensnek elvileg egymáson kellett volna lennie, akkor a vízszintes komponens el kezdett gyors tempóban ugrálni a függőleges komponens két oldala között.

Az így kimért közelítő értékeket elfogadtuk és felvéstük az adatlapra. Ez alapján elkészíthették számomra azt a szemüveget, amihez ha jól hozzászokom, akkor újabb mérések következhetnek. Ha az agyam tényleg megtanulja a normál emberek látását és sikerül pontosan kimérni a szemtengely ferdülést, akkor az egy műtéttel drasztikusan csökkenthető. Szerencsés esetben meg is szűnhet.

A szemüveget ma vettem át és el is kezdtem hordani. A viccesebb vizuális élményeimet pedig meg is fogom osztani itt a blogon. Meg amúgy is, diagnosztikai szempontból esetleg hasznos lehet, ha naplózva vannak.

Easy but not too slow integer to string conversion

In my previous post I compared the speed of different methods of converting integer to string. The problem was that these solutions both relied on the environment somehow and cannot be used on an adhoc manner like messages[i] = std::string("Error found at line #") + IntToString(lineNumbers[i]) + ".";. These both need some circumstancial preparation like creating a buffer (char buffer[...]) or a std::stringstream outside the loop and resetting it after usage. So I started on a journey to create a kitchen-ready preparation-less yet not too slow implementation for my imaginary IntToString() function.

#include <iostream>
#include <limits>
#include <sstream>
#define __STDC_FORMAT_MACROS
#include <inttypes.h>

// Utility functions and structs

template<typename Unsigned>
char * DigitsToString(Unsigned i, char * endPtr)
{
    char *&cursor(endPtr);
    *cursor = 0;
    if(!i)
    {
        *--cursor = '0';
        return cursor;
    }
    for(;i;i/=10)
    {
        *--cursor = char(i%10+'0');
    }
    return cursor;
}

template<typename Unsigned>
std::string UnsignedToString(Unsigned i)
{
    const size_t bufsize = std::numeric_limits<Unsigned>::digits10 + 1;
    char buffer[bufsize];
    return DigitsToString(i,buffer+bufsize-1);
}

template<typename Signed>
std::string SignedToString(Signed i)
{
    if(i>=0)
    {
        return UnsignedToString(i);
    }
    const size_t bufsize = std::numeric_limits<Signed>::digits10 + 2;
    char buffer[bufsize];
    char *cursor = DigitsToString(-i,buffer+bufsize-1);
    *--cursor = '-';
    return cursor;
}

template<bool is_signed,typename Integral>
struct ToStringConverter { };

template<typename Integral>
struct ToStringConverter<false,Integral>
{
    static std::string Do(Integral i){ return UnsignedToString(i); }
};

template<typename Integral>
struct ToStringConverter<true,Integral>
{
    static std::string Do(Integral i){ return SignedToString(i); }
};

// The IntToString()

template<typename Integral>
std::string IntToString(Integral i)
{
    return ToStringConverter<std::numeric_limits<Integral>::is_signed,Integral>::Do(i);
}

// Testing my IntToString()

template<typename Integral, Integral count>
void testFun()
{
    for(Integral i=0; i<count; ++i)
    {
        IntToString(i);
    }
}

// An std::stringstream based integer to string conversion

template<typename T>
std::string StreamedToString(const T& i)
{
    std::stringstream ss;
    ss << i;
    return ss.str();
}

// Testing of the std::stringstream based integer to string conversion

template<typename Integral, Integral count>
void testStream()
{
    for(Integral i=0; i<count; ++i)
    {
        StreamedToString(i);
    }
}

#ifndef TEST_CASE
#define TEST_CASE 1
#endif

int main()
{
#if TEST_CASE == 1
    testFun<uint64_t,100*1000*1000>();
#endif
#if TEST_CASE == 2
    testStream<uint64_t,100*1000*1000>();
#endif
    return 0;
}

This is far from being a market-ready product, but it might be useful. Speed test:

$ g++ -W -Wall -Wextra -pedantic -O2 int_to_str_speed2.cpp -DTEST_CASE=1 -o int_to_str_speed2
$ time ./int_to_str_speed2

real    0m12.404s
user    0m12.397s
sys     0m0.008s
$ g++ -W -Wall -Wextra -pedantic -O2 int_to_str_speed2.cpp -DTEST_CASE=2 -o int_to_str_speed2
$ time ./int_to_str_speed2

real    1m36.204s
user    1m36.174s
sys     0m0.008s

Speedy integer to string conversion in C++

Test

This is a log entry about playing around the question. There are robust ways of converting integers to string already implemented out there, for example FastFormat. Good for them. Let's see how I played on my playground.

I measured the speed of sprintf(), snprintf() and my own implementation. I tried to make most of the decisions compile-time. I didn't care to write time measurement into my program, instead I'm using GNU's time utility with three different versions of my program separated using macros.

#include <iostream>
#include <cstdio>
#include <limits>
#define __STDC_FORMAT_MACROS
#include <inttypes.h>

#ifndef TEST_CASE
#define TEST_CASE 1
#endif
#ifndef TESTCOUNT
#define TESTCOUNT 100*1000*1000
#endif
#ifndef INTTYPE
#define INTTYPE uint64_t
#define INTFMT PRIu64
#endif

template<typename Integral>
char *myUIntToStr(Integral i, char *endPtr)
{
    char *&cursor(endPtr);
    if(!i)
    {
        *--cursor='0';
        return cursor;
    }
    for(;i;i/=10)
    {
        *--cursor = char(i%10+'0');
    }
    return cursor;
}

int main()
{
    const size_t BUFSIZE = std::numeric_limits<INTTYPE>::digits10 + 2;
    char buffer[BUFSIZE];
    buffer[BUFSIZE-1] = 0;
#if TEST_CASE == 1
    for(INTTYPE i = 0; i<TESTCOUNT; ++i)
    {
        sprintf(buffer,"%" PRIu64,i);
    }
#endif
#if TEST_CASE == 2
    for(INTTYPE i = 0; i<TESTCOUNT; ++i)
    {
        snprintf(buffer,BUFSIZE,"%" PRIu64,i);
    }
#endif
#if TEST_CASE == 3
    char * const endPtr = buffer + BUFSIZE - 1;
    char * output;
    for(INTTYPE i = 0; i<TESTCOUNT; ++i)
    {
        output = myUIntToStr(i,endPtr);
    }
#endif
#if TEST_CASE == 4
    std::stringstream ss;
    for(INTTYPE i = 0; i<TESTCOUNT; ++i)
    {
        ss << i;
        ss.str(""); // clearing
    }
#endif
    return 0;
}

In many cases the arithmetic correctness of a program or interoperability of a binary format can be achieved by using fixed size integers like uint64_t instead of the fluffy definition of short, int, long, etc.. These fixed size integers are defined in the inttypes.h header file of the C99 standard. I don't know any standard options for this purpose under C++03, so I chose to use this second best solution. I'm using this decision for a while and the time is finally on my side: The C++11 standard includes this header. The defining of __STDC_FORMAT_MACROS before including this header results in the creation of printf() formatters for those types (without the % sign).

In theory this is a portable source code in practice (sic), in practice I haven't tried. This thing is only a proof of a concept.

The original idea for the conversion implementation came from abelenky at a stackoverflow.com question which was about the alternatives to itoa(). I added that the buffer is allocated outside the function on stack (something like for free) and a pointer to its end passed into the function.

Environment

• OS: Debian (6.0.4 Squeezee) GNU/Linux (2.6.32-5-amd64)
• G++ 4.4.5
• CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz

Results

$ g++ -W -Wall -pedantic -Wextra -O2 -DTEST_CASE=1 sprintf_speed.cpp -o sprintf_speed
$ time ./sprintf_speed

real    0m16.776s
user    0m16.757s
sys     0m0.012s
$ g++ -W -Wall -pedantic -Wextra -O2 -DTEST_CASE=2 sprintf_speed.cpp -o sprintf_speed
$ time ./sprintf_speed

real    0m16.951s
user    0m16.953s
sys     0m0.000s
$ g++ -W -Wall -pedantic -Wextra -O2 -DTEST_CASE=3 sprintf_speed.cpp -o sprintf_speed
$ time ./sprintf_speed

real    0m4.295s
user    0m4.296s
sys     0m0.000s
$ g++ -W -Wall -pedantic -Wextra -O2 -DTEST_CASE=4 sprintf_speed.cpp -o sprintf_speed
$ time ./sprintf_speed

real    0m15.443s
user    0m15.429s
sys     0m0.012s

The difference between the sprintf() and snprintf() version was around 2 to 4 percent consistently in favor of sprintf(). It's unfair to compare these guys to my solution because they also have to parse their given formatter parameter. I believe that my solution is somewhat optimal. The fourth case with std::stringstream is there for reference, that is the clean C++ style portable way for doing the conversion. Surprisingly fast.