progn

Menneh... zotbar tok feil da. Det er ikke ulovlig i følge standarden å konvertere funksjonspekere til void* eller omvendt.

Hva? Leste du ikke innlegget mitt? I følge standarden så er det implementation defined. Mao., den funksjonaliteten er ikke med i standard C. zotbar har helt rett.

Det er useriøst av deg å bruke VC++ som et eksempel på en standardfølgende C-kompilator når den ikke implementerer noe annet enn det subsettet av C89 som er i C++-språket. Dette er uavhengig av om du bruker /TC-flagget eller ikke, som bare sier at "filen er en C-fil".

1989 er ganske lenge siden.

Koden jeg skrev kompilerer under både gcc og Visual C++.

Jeg må bare legge til at dette er et veldig dårlig argument siden Visual C++ er en C++-kompilator og ikke en C-kompilator.

http://c0x.coding-gu...om/6.3.2.3.html

 

"A pointer to void may be converted to or from a pointer to any incomplete or object type."

 

Det eneste det står om dette er "undefined behaviour" ikke at det er ulovlig.

 

ref. http://stackoverflow...to-another-type

Noe som er *fullstendig* uinteressant. Du spurte hvilke pekere ikke kunne konverteres. En funksjonspeker (f.eks.) ikke kan konverteres til en void*. At det tilfeldigvis virker på en, to, eller 15 kompilatorer i dag betyr ikke at en funksjonspeker kan konverteres til en void*. Klarere nå?

I følge standarden (C99) så er dette definert som en "common extension", dvs. noe en god del systemer implementerer:

J.5.7 side 513:

A pointer to an object or to void may be cast to a pointer to a function, allowing data to

be invoked as a function (6.5.4).

2 A pointer to a function may be cast to a pointer to an object or to void, allowing a

function to be inspected or modified (for example, by a debugger) (6.5.4).

Siden det ikke er et spesifikt krav av standarden så er det undefined behavior. Dette er ikke det samme som å si at det er ulovlig: å dele på 0 i er f.eks undefined i C, men helt lov og det er opp til implementasjonen om den vil kompilere det eller ikke.

@hjahre

 

Omsider en som bringer temaet videre.

 

Der skulle sikkert stått

 

Database

1. modellering
   
2. design
   

eller lignende i først post.

Jeg tror ikke at du klarer å redde ansikt denne gangen. Postene dine i denne tråden er usaklige, og innholdet av siden du lenker til gir ganske lite mening mht. emnet.

Kanskje hvis du hadde hatt den utdanningen du bruker å skryte deg på i annenhver tråd så hadde du visst forskjellen mellom datamodellering og databaseprogrammering. Dette er for all del ikke ment som et personangrep, men du hadde unngått mye motstand om du holdt deg til tema du har peiling på isteden for å mette tråder som denne med dårlige råd og lenker til siden din.

Nei.

 

Vennligst opprett en tråd.

Denne youtube-videoen er å finne direkte på siden du lenket til.

Her er der feil i Kjell Bleiviks gamle og nye videoer. Forslag til forbedringer.

Hva? Er det ikke du som er Kjell Bleivik?

Er det dette du kaller relevant, Bleivik?

Jeg vet ikke om du har prøvd å sammenlikne typingske python IDE'er (som wing, pycharm) med Visual Studio med resharper, eclipse, intelij sov, men om disse IDEene gjør det du foreslår (som jeg tviler på), klarer de fortsatt ikke deterministisk å fortelle meg typene til inputvariabler, gi meg metodedefinisjoner og å fortelle meg at et gitt uttrykk ikke gir mening utifra typen. Dette har nok noe med at selv om man kan ha en interpreter gående, så må denne ha relevante input-data for å gi mening. Statisk typede språk kan derimot bruke typedefinisjonene til å logisk sjekke om metodene gir mening (selvsagt ikke fult ut, men mye lengre enn en python IDE kan).

 

Jeg har aldri snakket om å lage en egen IDE, bare om at det ikke er mulig å lage en python IDE som er like god som eksisterende IDEer for språk som java og c#.

Det er klart at en IDE for et dynamisk typet språk ikke kan utføre type inference siden dette vil kreve at den kan vite typen på en variabel på forhånd. Noe som bryter helt med konseptet om dynamisk typing (og prinsippet om duck typing).

Jeg tør si at man ikke trenger å vite det, og om du mener at du trenger det så prøver du å programmere "statisk" i et dynamisk typet språk (i.e skrive Java i Python).

Argumentene dine er stort sett de samme som de klassiske argumentene i mot dynamisk typede programmeringsspråk. Disse har blitt diskutert til døde i de siste 50 årene.

Dette er ikke bare et problem med notepad, men også et problem mellom forskjellige python IDEer uavhengig av antallet space satt opp fordi de behandler copy og paste anderledes (eller noe slikt). Uansett trenger trenger man med en slik syntaks å bli enig om diverse ting (space vs tab, antallet spaces, osv), en kompleksitet man ikke trenger å forholde seg til språk med krøllparantes.

Ser du ikke at å miste identering ved copy/paste er det samme som at du mister en krøllparentes i et annet språk? Din favoritt C++-ide ville ikke likt ubalanserte paranteser, og det gjør ikke python-interpreteren ang. identering heller. Det er en syntaksfeil, og vil bli sjekket av interpreteren ved en av de første "passene" av kildekoden, før programmet faktisk kjøres.

Hvis editoren din klarer å rote bort space ved kopiering så er det ekvivalent med at den heller hadde rotet bort en krøllparentes.

Kompleksiteten med å bli enig om antall space i kildekoden vil vel ikke være større enn den om å bestemme seg for hvilken variant av C++ man skal bruke (dvs. hvilken kompilator man bruker)?

Du skjønner ikke hvorfor parseren får problemer dersom indenteringen blir borte, også beskylder du meg for å ikke kunne noe om parsing? Dette blir derimot aldri tvetydig med krøllparanteser fordi starten på f.eks. en metode definisjon blir ulik slutten og en parser kan dermed uten tvetydighet parse i vei.

Den forrige posten din kan tolkes som om at du mener at space som blokk-delimiter er vanskeligere å parse enn krøllparanteser.

Jeg mener at det er lett å få relativt lugubre feilmeldinger ved bruk uvettig bruk av biblioteker fra den andre standarden. Problemet er at det ikke nødvendigvis er tydelig hva som er feilen utifra exceptionen som blir kastet.

Hva har dette med Python som språk å gjøre?

Det jeg mente å si her er at man kan kompilere og kjøre c++ kode uten å f.eks. ha en klasse definisjon rundt, slik man må i java. Problemet med dette er at det legger til ekstra elementer som må forklares( eller bare godtas) før man begynner. Syntaks rundt diverse statements har jeg ikke noe problem med (en god IDE legger til slik syntaks automatisk).

Et godt språk trenger ikke hjelp av en IDE for å kunne skrives effektivt.

Tror ikke det er nødvendig å være nedlatende. Du må huske på at jeg ikke er spesielt smart, så du kan la det være implisitt.

 

Men poenget ditt.. Problemet med assembly er at det ikke er direkte nyttig som et programmeringssårk, og det inneholder ingen av syntakskonvensjonene til språk som er direkte nyttig. Det inneholder også ingen "normale" programmeringskonsepter som også er en svært naturlig del av et introduksjonskurs. C++ har alle disse. Python dekker også halvveis dette behovet, men litt av poenget var jo å argumentere for noe annet ...

Det var ikke meningen å være nedlatende, men jeg trodde faktisk at du var et troll pga. argumentene dine.

Hvilke generelle programmeringskonsepter er det Python mangler i forhold til C++?

Dynamisk typing gjør det også veldig vanskelig å lage en fornuftig IDE som typisk hjelper til med å holde styr på større prosjekter.

Virkelig? Det ville jo gjort det enklere siden en IDE kan kjøre en python-interpreter i bakgrunnen og hente ut masse metainformasjon. En IDE for et statisk språk er nødt til å parse, tyde, og i visse tilfeller kompilere kildekoden. Når har du forresten behov for å lage din egen IDE?

Problem nummer to er manglen på krøllparanteser for scope. Dette går vanligvis greit for en enkelt person, men så fort man sitter å jobber flere samtidig med forskjellige editorer kombinert med litt copy and paste ender man fort opp med indenteringsproblemer.

Muligens om man bruker Notepad.

PROTIP: Bli enig om hvor mange space dere skal bruke for å identere, og ikke miks tab og space.

I et språk med krøllparanteser kan en IDE holde styr på riktig indentering, mens man i python blir nødt til å lese igjennom koden for å se hva som skal være hvor.

Hvorfor er dette vanskeligere for et språk som bruker whitespace som identering? Det ser ikke ut som du kan noen ting om parsing, og da synes jeg ikke at du skal uttale deg om det.

Problem 4 språket er i dag fragmentert mellom versjon 2 og 3 som gir mange morsomme feil om man ikke følger med.

Hvis du definerer "å følge med" som å vite hvor man er, eller hvilket språk man programmerer i.

Jeg vil heller anbefale språk som C++, Java, Scala eller C#. Kanskje C++ siden den har minst syntaks fiksfakseri man trenger å lære for å skrive simple ikke objektbaserte programmer

C++ har minimal syntaks? luls. Python har nesten ingen syntaks hvis man bare holder seg til å kun skrive imperative programmer.

samtidig som det er relativt intuitivt å relatere det til hvordan en datamaskin fungerer (da jeg var studass i java virket det for meg som folk forstod konspeptene mye bedre hvis man gjorde et forsøk på å fjerne "magien" som ligger mellom programmeringsspråket og datamaskinen).

Var du studass i Java? Please tell me more about your expertise in teaching. Per ditt argument så burde jo assemblyspråk være enklere å programmere i siden det er nærmere hardware.

Stengt for kommentarer, da jeg driver det forumet alene og med skriver for verden mener jeg på engelsk. Åpner det om og når tiden er moden.

Ideen om et forum innebærer vel diskusjon mellom forskjellige mennesker?

Siden du påstår at du har et forum med 20000+ brukere (mennesker) og bruker det som et argument i denne tråden, har jeg et par spørsmål.

Hvordan kan det ha seg at et read-only forum om ingenting har over 20000 brukere?

Hvorfor registrerte det seg over 1200 brukere i løpet av 18. mai?

For å være litt alvorlig så er det mye som tyder på at du legger til disse brukerne automatisk.

Dette bør du ha råd til om du er en seriøs utvikler. Personlig kjenner jeg ikke til en bedre platform.

Så du mener at jeg ikke kan kalle meg en "seriøs utvikler" hvis jeg ikke bruker 900 euro på et IDE? Haha.

Men for å være litt alvorlig, hva er de gigantiske fordelene med dette IDE-et?

Alle C++ kompilatorer bruker variasjoner av C++. Ofte vil slike variasjoner bemerkes ved at de starter med to understreker, eksempelvis __fastcall for fastcall funksjonkall.

Fastcall er en kallekonvesjon, og har med hvilken maskin kompilatoren har som mål å generere programfiler for; dette har ingenting med C++ som språk å gjøre (eksempelvis så kan du lage en kompilator som oversetter C++ til C). Det finnes likevel variasjoner av C++ som språk pga. forskjellig støtte fra de forskjellige kompilatorene, men så vidt jeg vet så er det bare én organisasjon som bestemmer C++-standarden.

Spørsmålet mitt var "Hva er poenget med dynamiske datatyper"

Det var egentlig alt. Jeg har ikke kritisert Python eller noe annet språk, jeg har lurt på hvorfor de tar designvalget å ekskludere statisk typesetting, når ihvertfall ikke jeg kan se noen fordeler med dynamiske datatyper.

Poenget? Det må vel være ett siden dynamiske typede språk er så populære og mye brukt. Siden andre har prøvd gjentatte ganger og feilet med å forklare deg det så tror jeg at du er nødt til å finne ut av det selv :-)

Når det gjelder casting, så var det selve castingen som var poenget, ikke typesettingen.

Selve castingen var jo den samme mellom de to språkene du viste. Det var bare syntaksen som var forskjellig.

Jeg liker ikke dynamiske datatyper, og synes at når en lærer seg å programmere, er det lurt å få med seg datatyper også. En kommer til å dette borti det, og da er det fint og ikke sitte med et språk som nesten ser helt bortifra det.

At et språk bruker dynamiske datatyper betyr ikke at det ser bort i fra typer. Det er forskjell på statisk vs dynamisk og strong vs weak typing. Det høres ut som om du tror at dynamisk typing impliserer weak typing.

Jeg anbefaler deg å lese http://en.wikipedia.org/wiki/Strong_typing. Og kanskje du burde skaffe deg litt mer erfaring innen forskjellige programmeringsspråk før du roper ut om hvor ubrukelige dynamiske typede språk er.

En implementasjon av et dynamisk språk kan UMULIG vite hva slags datatype som egner seg, og må typisk gjøre type-sjekking run-time. Ulempen kan du regne ut, for det går sterkt utover ytelsen å gjøre type-sjekking run-time. Se .NET DLR vs .NET CLR for eksempel. Min test med Vector double vs. dynamisk vector ga en 10x bedre ytelse på CLR.

Hvorfor denne besettelsen om at ytelse er eneste måleenhet for hvor bra et programmeringsspråk er?

Ja, siden statisk typede språk har mye mer typeinformasjon tilgjengelig i kompileringstid så kan de også gjøre mer aggressiv optimalisering. Men hvis et dynamisk språk lar meg løse et (ikke tidskritisk) problem på en elegant, lettleselig, og ikke minst vedlikeholdbar måte, hva betyr det om vector-klassen din er ti ganger raskere enn min? Enlighten me.

Og før du drar frem spillkortet: Ja, ytelseskritiske rutiner og algoritmer programmeres vanligvis i statisk typede språk (rightly so), men det betyr ikke at alt må gjøres slik. Python har f.eks en god del av modulene sine implementert i C.

float value = verdi gir samme syntaktisk informasjon ja, men det var heller ikke poenget.

Hva var poenget ditt da, GeirGrusom? For å svare på spørsmålet ditt: syntaksen er slik fordi den er slik i C. C++ støtter forøvrig "konstruktør"-syntaksen, og det er nok sikkert derfor GLSL bruker den.

Casting er en bra ting. Det gjør at uttrykket er fullstendig klart.

Hvorfor må ting være fullstendig klart helt ned på laveste nivå? En del av poenget med programmering er å kunne tenke i forskjellige abstraksjonsnivå. F.eks: jeg bryr meg egentlig ikke om number er et flyttall eller en BigInt så lenge resultatet eller korrektheten av programmet avhenger av det.

Dess mer unødvendig syntaks man legger til, dess tyngre blir det å lese koden.

Selv om jeg synes castingen i C språk er litt tullete. Hvorfor ikke mer som i GLSL? Constructoren til alle datatyper burde vært casting for den datatypen.

 

var value = float(verdi)
istedet for
var value = (float)verdi;

C++, som jeg mener er mer et "C språk" [sic] enn C#, støtter denne syntaksen for typecasting.

float value = verdi;

gir forøvrig samme mengde syntaktisk informasjon om typen.

#include <stdio.h>

int main(void) {
   for (int i = 0; i < 7; i++) printf("%*c%s\n", i < 4 ? 7-i : i+1, ' ', "*************" + (i < 4 ? (12-i*2) : (i*2)));
   return 0;
}

Output:

      *
     ***
    *****
   *******
    *****
     ***
      *