C++: Kontakt søges til folk interesse herfor

Vi arbejder selv med en konvertering fra ansi C til C++ af et database system med omkring 400 sourcefiler i 1.5MB directory.

Med omkring 3 millioner C++ programmører er det jævnfør Bjarne Stroustrup det mest udbredte programmeringssprog.

Formål: Etablering af en programmeringsfabrik eller laboratorium, som kan lave hvad-som-helst og hurtigt kan lære nye programmører op.

Eksempel 1: udvide et programmeringssprog udnyttende C++ standard. 

Eksemple 2: Lave grafik direkte fra ioctl(), hvorved alle programmer kan holdes ekstremt hurtige, fleksible og fri for kollapser.

Skriv et indlæg og/eller send mig kontaktinfo for uddybende information. 

Hej...

Jeg er selv c++ programmør, og kender ikke det helt store til de andre sprog. Men de "erfarne" folk, jeg har snakket med siger enstemmigt, at hvert sprog har sine kerne kompetencer. Men hvis man skal skrive ekstrem hurtig kode, så er det kun c og c++ der fungerer.

Java er måske på vej ind på det embeddede marked, men alle de projekter jeg har lavet, har det stækt være at foretrække at kode dem i c++. Der er flere af de spog der bliver nævnt, der er lavet i c/c++, så det kunne være en grund til, det tadig bliver brugt. Der er kommet en række af nye sprog, der helt klart har deres fordele, men hvis man skal lave hurtuge kerner til avancerede programmer, så kan Java og C# ikke bruges.

Det hele bunder også i programmerings verdenen eksploderer for tiden, og det gør den i mange forskellige retnigner. Samtidig med det der skal laves, bliver der mere og mere af. Det betyder der fx at der skal laves mange windows programmer, hvor C# har rigitg mange fordele. På den måde bliver der opfundet sprog der er meget speciffike i mål, hvor de så er rigtig gode. Men i forhold til hastighed er der kun etsprog der slår C/C++, det er optimeret assembly. Det er der bare ikke så mange der gider at kode i mere.

Dette er skrevet udfra det jeg ved, men hvis det er nogen der er uenige, eller ved bedre, så sig endelig frem.

Jeg kunne godt være interreseret i at vide mere om kodefrabrikken, skriv endelig her, eller på kristoffer@klj-enterprise.dk.

Mvh

Kristoffer L Jakobsen

www.klj-enterprise.dk

Om C++.  Det var stort set alle de samme grunde som førte til min egen beslutning om konvertering til c++ efter en længere tids søgen efter alternativer til C. Men at der slet ikke er andre reelle alternativer til C og C++ vidste jeg faktisk ikke. 

Vi har i foreningen DKUUG.dk søgt  at finde frem til folk med interesse for C++ og vi har foreslået et foredrag her i efteråret af Bjarne Stroustrup i forbindelse med 25 året for internettets etablering i Danmark.

Min deltagelse i DKUUG er af forretningsmæssige grunde og jeg har siden 1988 opereret DBA 1Base Group.

Jeg har i længere tid arbejdet med forslag om en international konference om C++ med en  work-shop, som tænkes fortsat via et formaliseret samarbejde mellem deltagerne.

Vi: Det er Keld Simonson og jeg selv. Vort første organsiserede møde i DKUUG  blev en meget stor success med en tredje deltager - efter en anden gæst forlod mødet protesterende hvad han kaldte "rekrutteringsforsøg".

krisjakobsen:

kodefrabrikken

Jeg sender dig noget mere eller mindre relevant information. 

--------------------------------------------- 

Omkring programmering vedrørende et helt anderledes database system og SQL baserede systemer (RDBMS):

Efter min opfattelse er tabelbaserede database systemer alt for primitive og det reflekteres i. at det for store virksomheder og organisationer er MEGET dyrt at udbygge og vedligeholde  sådanne systemer.

Et typisk SQL baseret system anvender måske 10-30.000 tabeller. 

Jeg arbejder og har altid arbejdet med en  database organisering, hvor alle data lagres i hvad man kan kalde selvbeskrivende datafelter struktureret via den første bit i 16 bits blokke. Det har i praksis kørt fint lige siden implementering i 1982, hvor vi een gang for alle eliminerede data destruktion, garanterede læsbarhed af data og total (næsten) data fleksibilitet i datalagring, hvor nye applikationsprogrammer kunne skrives "at will" uden at påvirke kørende programmer. Jeg har selv lavet omkring 1400 applikationer og har en meget stor success historie bag mig. Vi var i stand til at servicere 2-300 on-line brugere i en computer fabrik via en 2 * 400 MHz server med ekstremt hurtige svartider. 

I det nye udvidede system planlægger vi at reservere 2  bit ud af 16 til kodificering af information. Det giver 14 bit til at repræsentere basal information ELLER beskrivende kodificering af de felter, som følger efter.

Vi i 1Base har lige siden 1982 løst  det fundamentale problem med genlæsning af data, som nu kommer op i XML-baserede løsninger som beskrevet i debatten om ODF men uden at der tages højde for eksisterende tabelbaserede database systemer.

Det grundlæggende fundamentale problem i SQL (tabel) baserede systemer er, at data felter skal beskrives i en tabel dictionary i modsætning til vores design. Desuden har tabelorganiserede systemer indbyggede svagheder og matcher ikke natur-love.

 MVH fra Ejler 

Frank Nielsen:

Har du nogen performance målinger

Fra den daglige log dengang med omkring 250 on-line brugere:

tc4s: 52018, exftc: 10196, #not101: 1361    +  n1r  Klb  991007 

tc4s: 18455, exftc: 7554, #not101: 1013     +  n1r  eo  991010 

Tal 1 er records kreeret, forandret and gent denne dag. Tal 2 er netto tilgang for dagen, idet mange records behandles over flere omgange, Tal 3 er nye records dannet denne dag.

En record kan repræsentere en faktura, ordre eller tilbud med alle hovedoplysninger, varelinieinformation og debitor/kreditor transaktion med fra 50-300 indekserede felter. Eller en stykliste eller indkøbstransaktioner eller time/sagsrecord eller ...

Hertil kommer databaselæsninger på omkring 5-10 millioner recordlæsninger eller mere per dag. Det typiske er omkring 100 gange antallet af skrivninger, idet der i databasen samtidig er ekstremt mange søgninger SAMTIDIG med opdateringer.

Frank Nielsen:

optimistisk eller pessimistisk låsning

Faktisk låses der slet ikke. Database opdateringer bliver sat i kø og afsluttes een ad gangen. 

Frank Nielsen:

skalere

Jeg forstår ikke hvad du mener. 

Men det er en slags main-frame system.

Det udvidede system vil kunne blive ubegrænset stort og residere på mange computere og data records vil fungere som uafhængige "agenter" eventuelt med mange kloner, som arbejder sammen. 

Dine eksisterende data og de nye vil kunne leve fredeligt sammen på HW i dette system uden tidsbegrænsning og går ind i det evige liv. Derfor kaldes dette koncept 1Base Valhalla. 

Frank Nielsen:

C++

I modsætning til ANSI C konverteringen har jeg i C++ ikke noget brugbart fungerende.

For een gang for alle at komme GUI diskussioner til livs har jeg tænkt mig, at grafisk præsentation skal ske fra et ioctl() kald men uden at involvere nogle af de store GUI klumper som Windows, KDE eller Gnome. 

Hvad der ser mest lovende ud lige nu er: Framebuffer UI.

Frank Nielsen:

skifte "database"

DET er rigtigt. Men:

Derfor planlægges der også en fuldautomatisk konvertering af data til og fra XML format for alt udenfor de traditionelle SQL systemer.

Der SKAL også laves en automatisk konvertering til og fra SQL database-systemer eventuelt med en on-line interface fra det nye system til et eksisterende. At gå den anden vej kan blive kompliceret og dyrt. 

Jeg har lavet et slags standardtilbud til eksempelvis Københavns Kommune, hvor jeg uden svar har tilbudt at lave en fungerende prototype erstatning af deres skandaløse Accenture/KML system for en fastpris på 2 MKR med samtlige eksisterende programfunktioner fungerende med alle relevante fejlrettelser for alle eksisterende faggrupper med databevis for at lønafregning fungerer korrekt. Denne løsning er umiddelbart brugbar derefter.

Jeg har omtalt dette i min SW-design artikel med forklaring på, hvorfor dette kan gøres og indenfor 4-9 måneder.

Frank Nielsen:

prøve den af

Det kræver bare at komme over kulturchokket først og relevante resourcer.  En presentation med bevis for effektivitet og hvordan man bygger nye programmer med indbyggede forretningsregler kan gøres på et 3 * 4 timers seminar med et tilsvarende antal timer til praktik. Nye programmører kan oplæres på 3-5 kursusdage og vil ubesværet kunne skrive hvad som helst i nye forretningsprogrammer efter en måneds systematisk arbejde under et precision time-management system MED em kompetent leder. HVIS de ellers VIL. 

Nye brugere kan bringes effektivt i gang for planlagte opgaver inden for et par timer. De vil have effektiv jobrutine inden for 2-4 dage og vil derefter kunne opdatere database information for hvem som helst uanset hvad og kunne efterspørge programmodifikationer, som typisk kan leveres inden for et par times. Typiske modifikationer tager 5-15 minutter.

---------------------------------------------------------------------------

Det er min opfattelse, at total og nødvendig restrukturering af eksisterende kendte IT-systemer kan gå hen og blive en kolossal forretning.

Jeg har research-materiale om database-teknologi og de overvejelser, som foregår internationalt og som også uafhængigt af mine egne arbejder peger mod, at nye teknikker er nødvendige. DOD efterspørger sådanne løsninger.

Jeg har ved siden af min design artikel beskrevet en universel håndtering af database-lagring af e-mal, så spam kan automatisk klassificeres og elimineres SAMTIDIG med at købere og sælgere kan hægtes sammen som konkurrent til Google's måde at gøre det på.

Der er en artikel med 35 argumenter for hastighed, sikkerhed, fejltolerence og integration og der kan leveres uigendriveligt bevis for validiteten af hvert enkelt argument.

MVH fra Ejler 

1base:

Fra den daglige log dengang med omkring 250 on-line brugere:

tc4s: 52018, exftc: 10196, #not101: 1361    +  n1r  Klb  991007 

tc4s: 18455, exftc: 7554, #not101: 1013     +  n1r  eo  991010 

Tal 1 er records kreeret, forandret and gent denne dag. Tal 2 er netto tilgang for dagen, idet mange records behandles over flere omgange, Tal 3 er nye records dannet denne dag.

hmm har lidt svært ved at relatere til talene, 250 online brugere er jo ikke ret mange i min forstad. Omvendt har jeg også set systemer der ikke kunne klare langt minde antal.

1base:

Hertil kommer databaselæsninger på omkring 5-10 millioner recordlæsninger eller mere per dag. Det typiske er omkring 100 gange antallet af skrivninger, idet der i databasen samtidig er ekstremt mange søgninger SAMTIDIG med opdateringer.

Faktisk låses der slet ikke. Database opdateringer bliver sat i kø og afsluttes een ad gangen

Umiddelbart for mig lyder det som om du har lavet en database på MySQL niveau, fra før den tid den blev transaktionnel (med låsninger). Enten har jeg ikke forstået dig, eller også har du inkonsistent data i din database. Der SKAL være låsninger hvis du læser og skriver samtidig - som du skriver du gør. Yderlig ligger alle dine opdateringer (skrivninger) i kø, hvilket vil sige at du har serialiseret hele opdateringes processen - læs ikke skalerbart. Du kan leve med det så længe 80% er læsningen, men ellers vil det være én stor flaskehals.

Mht Frontended / klienten, er du når til at integrere imod JAVA/C# og lignende. Når du snakker "ioctl()" er der ikke nogen der ved hvad du snakker om - slet ikke dem du skal sælge til. C++ er et uddødende sprog på enterprise market, det kan simplenhen ikke betale sig i dag. De andre sprog er så meget simplere og mere fejl tolerente, måske performere de et par % mindre end C++ men skalering er endnu engang mere vigtigt end performance.

En arkitektur tegning kan måske gøre min forståelse af dit system bedre, eller har du en demo/example man kan downloade?

 Ok, indrømmer blankt at jeg er offtopic mht til din tråd - håber det er ok.

1base:

Det er vel rigtigt nok for mange systemer, men ikke det jeg arbejder med. 

Ved opdatering genlæses relevante records helt naturligt først for eventuel forandring.

For Enterprise System er det bidende nødvendigt at data er konsistente og transaktionel, men umiddelbart lyder det for mig som om at du har en form for optimistisk låsning. Du sætter et Dirty flag på det data som er opdateret?! Men det lyder dog ikke til at dit system er transaktionelt?

1base:

Disse sker lynende hurtigt og næsten altid problemfrit inklusive index-  og talopdateringer.

I denne formentlig særegne form for databasesystem er læsninger af data vel typisk 99 eller langt mere  (* skrivninger) inkluderet indexopdateringer.

Systemet er designet til samtidig at være effektivt for samtidig on-line opdateringer, brug og udnyttelse af date. Data minering sker normalt altid parallelt i de samme database filer.

Hvad mener du med "næsten altid problemfrit" ? Enterprise systemer har typisk en read/write fordeling omkrinh 50% - 50%. Mens mange web systemer har som du skriver ligger omkring 80% læsninger. 

Bom bom "være effektivt for samtidig on-line opdateringer" lyder parallelt i mine øre, var alle opdateringer ikke lagt i kø / serielt?

1base:

Det burde klart ses, at et sådant system er flere eller mange gange hurtigere til håndtering af enhver form for styklisteinformation

hhmm, ja jeg kan så ikke lige se det - men det er nok mig der er noget galt med ;) Men den hurtigeste database jeg kender til er helt klart MSAccess, problemet er bare at den ingen låsninger har eller noget form for transaktionel opdatering - hvilket gør den ubruglig hvis det ikke lige er til hobby brug. 

Men det lyder som om at du/i har tænkt i hele nye baner, og det er jo yderst interessant. Ingen tvivl og at "databaserne" har udtjent deres værnepligte i den form de har i dag. Men indtil videre er det ikke rigtig lykkes med noget andet - med undtagelse af din måske...

Hvis du har mod på det, vil jeg gerne prøve at lave en performance test med din database op imod oracle, mssql og mysql...

Held og lykke med projektet :) 

Jeg er kommet tilbage til denne traad da jeg efter mange 
obstruktioner er ved at faa styr paa vore dansk-polske forretninger
og da jeg i Polen har faaet fat i en ekstremt dygtig tekniker 
til 50 Zloty/tme. 

Bl. fik jeg mine skriverier om DKUUG op at koere igen.
Se dkuug.info 

Jeg har konference-facilititer til op til 90 mand i Borup
og vi holder formentlig et moede mandag om SAP og COBOL services.  

Det ER jo ikke om c++ og den planlagte c++ programmeringsfabrik.

Men med en samlet markedsfoering af en en raekke forskellige 
ydelser burde man kunne saelge ret meget. Ogsaa C++ services.