ProgrammeringsBaren! Småprat, om det du elsker!

[Lycantrophe]

... det kan du?

 

http://en.cppreference.com/w/cpp/io/basic_ifstream/basic_ifstream #3

[Lycantrophe]

Men ikke faktisk skriv slik kode er du snill.

[Emancipate]

Da får jeg feilmelding:

error: no matching function for call to ‘std::basic_ifstream<char>::basic_ifstream(std::string&)’

[Lycantrophe]

C++11?

 

Nøyaktig hvorfor det er sånn er nok en oversight i C++98-standardiseringen, men men.

 

Om du er låst til 98 kan du bruke str.c_str(), som strengt tatt er det std::string&-argumentet gjør.

Endret 23. januar 2016 av Lycantrophe

[Emancipate]

Ok, jeg måtte bruke --std=c++11. Rart at det ikke var godkjent fra begynnelsen.

 

Og hvorfor fungerer while (ifile.get(ch)) når operator bool er markert "explicit" på streamen?

[Lycantrophe]

while() er en bool context, så det er jo helt riktig.

[Emancipate]

Det er i og for seg det samme problemet med istream::getline, den tar kun char*, ikke string&. Er det noen logikk bak det?

[Lycantrophe]

Tipper det stammer fra veldig veldig tidlig i standardiseringen, før man var komfortabel med å krever std::string& som argument til noe som helst.

[Emancipate]

http://www.impredicative.com/ur/

• There is the old bulwark of first-class functions with lexical closures, which most languages in this space already support, though there are some laggards.

• Ur/Web provides much better run-time performance than any competing system. Server-side components are native code and don't use garbage collection.

Hvordan klarer de det første punktet uten garbage collection?

[torbjørn marø]

 

Hvordan klarer de det første punktet uten garbage collection?

 

http://programmers.stackexchange.com/questions/189856/is-garbage-collection-needed-for-implementing-safe-closures

[endrebjo]

Den årlige kåringen er her igjen: http://spectrum.ieee.org/computing/software/the-2016-top-programming-languages ( interaktiv greie).

I år har det også blitt synset litt ekstra rundt stor data: http://spectrum.ieee.org/computing/software/top-programming-languages-trends-the-rise-of-big-data

[siDDis]

Det er bare å vente på at big data bølgen slår hardt inn i dette landet også. Da blir det massevis med Python og R stillinger. Muligens Julia slår til etterhvert, det er jo fremdeles i modningsfasen.

[Occi]

Vil nå tro biblioteker og (Apache-)prosjekter styrer vel så mye som språkpreferanser innen stordataverden.

 

Mye, spesielt under Apache-paraplyen, er fortsatt Java (og i enkelte tilfeller Scala). Noen tilbyr API i flere språk, eller bindings, men arbeidshesten i bakkant er fortsatt ofte uansett JVM.

 

På egne ben er både Python og R også interessante, men av det jeg har sett er det ofte på en litt annen skala (lite distribusjon å snakke om), eller mer fokus på analyse/data science/ml/bi, .. (velg fra kurven av buzzwords).

Endret 26. juli 2016 av Occi

[siDDis]

Jada, Java er fremdeles veldig relevant. Som du sier så er det distribuerte systemer som gjelder for Java stacken. Spørsmålet er om det er verdt det, da det ofte kan lønne seg å aggregere/filtrere data før du bruker det til in-memory analyse med f.eks Python som vil være mye raskere.

 

Får en ikke plass i minnet, så er fremdeles SQL servere suverene til data-analyse og fremdeles mye raskere enn Spark. Den eneste grunnen til at en vil se på Hadoop/Spark stacken er når IO er utfordringen, f.eks du skal scanne 100GB/s. Men PCIe v4 åpner for opptil 30GB/s på en 16x slot, og 4 av disse åpner for 120GB/s via NVMe. Selv om NVMe SSD'ene ikke er helt der idag så nærmer de seg i stort tempo. En skal heller ikke se bort i fra at RDMA også blir en populær teknologi for å kjapp tilgang til større datamengder med lavest mulig forsinkelse. Alt dette vil jo hjelpe på for en enkel SQL server :-)

[Occi]

Hva som er raskest, eller kanskje like viktig mest tilgjengelig og enkelt å arbeide med, avhenger såpass av behov, bruk, datamodell m.mer at sammenligninger på generelt grunnlag blir fort litt knapt.

 

"SQL-servere" er unektelig diffust, og Spark har såpass med APIer og opsjoner for clustering at det kan også bety så mangt. Samme kan sies om utfordringen med IO.

 

Uten at det bør være nødvendig å gå spesifikt mer i dybden på dette eksempelet, så må man i det minste ta for seg datamodell, hvordan dataene skal jobbes med, søk/batch/iterativ osv. hvis det først skal være noe poeng å diskutere denne type påstander.

Endret 26. juli 2016 av Occi

[Locrin]

Noen som er flinke på python, sql og flask som vil kikke på. https://github.com/okristian1/bord og se om det er noe åpenbart idiotisk i koden der?

 

Koden er live her: http://bordfinneren.no/

 

Alt av tilbakemeldinger mottas med et stort smil.

[endrebjo]

Det virker veldig lite skalerbart og vedlikeholdsvennlig å hardkode hver eneste restaurant. Hvis du skal utvide til 20, 30 eller 100 blir det fryktelig mye dum copy-pasting. Og hvis du etter å ha implementert 100 restauranter finner ut at du vil restrukturere litt, så har du plutselig en kjempejobb.

Første steg på veien er å ta en kikk på Dictionaries i Python. Det er en helt sentral og uunngåelig datastruktur i Python. Da ser du plutselig at alle Description_blabla-variablene kan puttes i en Description-dictionary.

[Matsemann]

    for restaurant in restaurant_list:
        for thing in restaurant:
            for reservation in thing:
                for i in reservation:
                    for g in reservation.get('TableNrs'):
                         while counter < len(reservation.get('TableNrs')):

å splitte ut dette i mindre funksjoner, evt. restrukturere slik at ikke dette er nødvendig, kunne vært lurt

[Locrin]

Takk for gode råd. Skal ta en titt på dictionaries og fikse den for loop høystakken. Skammer meg litt over den.

 

Selvlært og fortsatt veldig nybegynner

[Locrin]

Det virker veldig lite skalerbart og vedlikeholdsvennlig å hardkode hver eneste restaurant. Hvis du skal utvide til 20, 30 eller 100 blir det fryktelig mye dum copy-pasting. Og hvis du etter å ha implementert 100 restauranter finner ut at du vil restrukturere litt, så har du plutselig en kjempejobb.

Første steg på veien er å ta en kikk på Dictionaries i Python. Det er en helt sentral og uunngåelig datastruktur i Python. Da ser du plutselig at alle Description_blabla-variablene kan puttes i en Description-dictionary.

 

Beklager, forstår ikke hva du mener. Kan du gi et annet eksempel?

 

Trodde det var dictionary jeg hadde brukt her.

 

if free_tables_frati >= int(guests)/4:

restaurants.append({

'id': "1",

'name': "Frati",

'logo': "static/media/img/logo_Frati",

'link': "https://frati.2book.se/",

'number': "735 25 733",