datagott > comp.* > comp.programmeren

edwin ng (26.08.2008, 12:26)
Ik bedoel de taal 'D' als de opvolger van C of C++

[..]

Het lijkt me interessant, maar zijn er ervaringen dat dit ook werkt in projecten groter dan
een paar duizend regels ?
Ik vraag me ook af of het werkt voor 'Embedded' targets.

Zomaar een paar vragen, dank voor uw tijd.

Groet,
Edwin
Stefan Arentz (26.08.2008, 16:03)
edwin ng <newsgroups> writes:

> Ik bedoel de taal 'D' als de opvolger van C of C++
> [..]
> Het lijkt me interessant, maar zijn er ervaringen dat dit ook werkt in projecten groter dan
> een paar duizend regels ?
> Ik vraag me ook af of het werkt voor 'Embedded' targets.
> Zomaar een paar vragen, dank voor uw tijd.


De taal is erg interessant .. maar ..

de taal en compiler zijn proprietary .. ik heb wel interesse maar niet
voor er een open source compiler is voor de populaire platformen.

S.
edwin ng (26.08.2008, 17:45)
Stefan Arentz schreef:
> edwin ng <newsgroups> writes:
>> De taal is erg interessant .. maar ..

> de taal en compiler zijn proprietary .. ik heb wel interesse maar niet
> voor er een open source compiler is voor de populaire platformen.
> S. Er is een GNU 'D' frontend.


[..]

verandert dat iets ?

Groet,
Edwin
Leon Timmermans (26.08.2008, 22:56)
On Tue, 26 Aug 2008 12:26:36 +0200, edwin ng wrote:

> Ik bedoel de taal 'D' als de opvolger van C of C++
> [..]
> Het lijkt me interessant, maar zijn er ervaringen dat dit ook werkt in
> projecten groter dan een paar duizend regels ?
> Ik vraag me ook af of het werkt voor 'Embedded' targets.
> Zomaar een paar vragen, dank voor uw tijd.
> Groet,
> Edwin


Naar mijn mening is het meer wat Java had moeten zijn dan een opvolger
voor C of C++. De vraag of het aan te raden is is afhankelijk van je
situatie. Ik zou het persoonlijk niet direct voor embedded targets
gebruiken (maar de term embedded lijkt enigszins aan inflatie onderhevig.
wat bedoel jij er precies mee?).

Groeten,

Leon Timmermans.
Stefan Arentz (27.08.2008, 02:54)
edwin ng <newsgroups> writes:

> Stefan Arentz schreef:
> Er is een GNU 'D' frontend.
> [..]
> verandert dat iets ?


Ja, nu kan ik er eens echt mee experimenteren!

S.
Stefan Arentz (27.08.2008, 03:02)
Leon Timmermans <fawaka> writes:

> On Tue, 26 Aug 2008 12:26:36 +0200, edwin ng wrote:
>> Naar mijn mening is het meer wat Java had moeten zijn dan een opvolger

> voor C of C++. De vraag of het aan te raden is is afhankelijk van je
> situatie. Ik zou het persoonlijk niet direct voor embedded targets
> gebruiken (maar de term embedded lijkt enigszins aan inflatie onderhevig.
> wat bedoel jij er precies mee?).


Ik programmeer wat (hobby) dingen in C voor de 8-bit AVR reeks. Dat
zijn kleine controllers met een paar KB RAM en weinig flash.

Wat ik enorm mis is de mogelijkheid om heel efficient tijdens
compile-time dingen te defineren en code te genereren.

Wat ik bijvoorbeeld zou willen is een module (niet een class) om iets als dit te doen:

LED<PORTB,PIN0> led;
led.aan();
led.uit();

Of op functie nivo:

PulseOut<PORTD,PIN3,9600>(data, sizeof(data));

Het kan allemaal enigzins in C++ maar ik heb toch specifieke wensen
qua code generatie. Ook zijn C++ templates redelijk hel. Zo kan je
niet alle types gebruiken als template parameters. En zijn templated
functions lastig.

Dat zijn dingen die ik zoek in een taal voor embedded werk.

S.
Meindert Sprang (27.08.2008, 09:46)
"Stefan Arentz" <stefan> wrote in message
news:kfsf
> Wat ik enorm mis is de mogelijkheid om heel efficient tijdens
> compile-time dingen te defineren en code te genereren.
> Wat ik bijvoorbeeld zou willen is een module (niet een class) om iets als dit te doen:
> LED<PORTB,PIN0> led;
> led.aan();
> led.uit();


Wat heeft bovenstaande voor voordelen t.o.v. onderstaande "code":

#define LED_PORT PORTB
#define LED1 0
#define led.aan() LED_PORT |= (1<<LED1)
#define led.uit() LED_PORT &= ~(1<<LED1)

Meindert
edwin ng (27.08.2008, 09:56)
Leon Timmermans schreef:
> On Tue, 26 Aug 2008 12:26:36 +0200, edwin ng wrote:
>> Naar mijn mening is het meer wat Java had moeten zijn dan een opvolger

> voor C of C++. De vraag of het aan te raden is is afhankelijk van je
> situatie. Ik zou het persoonlijk niet direct voor embedded targets
> gebruiken (maar de term embedded lijkt enigszins aan inflatie onderhevig.
> wat bedoel jij er precies mee?).


Embedded is inderdaad een ruim begrip, ik maak programma's voor 'embedded linux' met 512MB en 1.5GHz C7 cpu, glibc pthreads, Ik zet daar microperl op, IO doe ik in plain 'C'. ;
en ook voor ATMEGA128 (mogelijk met NutOS) dat is inderdaad een groot verschil.

Ik vroeg me af of het voor kleine systemen (zoals AVR) bruikbaar zou zijn om beter leesbare, kortere en beter gestructureerde code te komen.

Ik begin me af te vragen of het mogelijk is, want ik lees zojuist dat je dan eerst een 'garbage collector' moet porten naar je target.
Er is dus net als bij ADA een runtime systeem nodig. (AVR-ADA bestaat trouwens)

> Groeten,
> Leon Timmermans.


Zomaar wat gedachten.
Edwin
edwin ng (27.08.2008, 10:30)
Stefan Arentz schreef:
[..]
> PulseOut<PORTD,PIN3,9600>(data, sizeof(data));
> Het kan allemaal enigzins in C++ maar ik heb toch specifieke wensen
> qua code generatie. Ook zijn C++ templates redelijk hel. Zo kan je
> niet alle types gebruiken als template parameters. En zijn templated
> functions lastig.
> Dat zijn dingen die ik zoek in een taal voor embedded werk.
> S.


Ik ben ook aan het zoeken, ik kwam ook AVR-ADA tegen.
Nog niet gebruikt maar het ziet er aardig uit.

[..]

Mogelijk is dat wat voor je.
Groet,
Edwin
Leon Timmermans (27.08.2008, 17:03)
On Wed, 27 Aug 2008 03:02:35 +0200, Stefan Arentz wrote:

> Ik programmeer wat (hobby) dingen in C voor de 8-bit AVR reeks. Dat zijn
> kleine controllers met een paar KB RAM en weinig flash.
> Wat ik enorm mis is de mogelijkheid om heel efficient tijdens
> compile-time dingen te defineren en code te genereren.
> Wat ik bijvoorbeeld zou willen is een module (niet een class) om iets
> als dit te doen:
> LED<PORTB,PIN0> led;
> led.aan();
> led.uit();


Ik zie niet in waarom dat beter zou zijn dan

LED led = {PORTB, PIN0};
led_aan(&led);
led_uit(&led);

De uiteindelijke executable is kleiner, en het is niet alsof the
assignment van twee integers je code langzamer maakt.

> Of op functie nivo:
> PulseOut<PORTD,PIN3,9600>(data, sizeof(data));


Die sizeof is niet nodig als je data een template type maakt ;-)

> Het kan allemaal enigzins in C++ maar ik heb toch specifieke wensen qua
> code generatie. Ook zijn C++ templates redelijk hel.


Hel is een groot woord. De syntax is naar, maar de semantiek ervan kan
best elegant zijn.

> Zo kan je niet alle types gebruiken als template parameters. En zijn
> templated functions lastig.


Volgens mij wil je templates gebruiken voor dingen waar ze helemaal niet
voor zijn bedoeld. Ik zie ook niet in waarom de poort een onderdeel van
het type zou moeten zijn? Dat is allemaal runtime data IMO.

> Dat zijn dingen die ik zoek in een taal voor embedded werk.


Nouja, je kan altijd een DSL maken/gebruiken.

Groeten,

Leon Timmermans
Leon Timmermans (27.08.2008, 17:15)
On Wed, 27 Aug 2008 09:56:37 +0200, edwin ng wrote:
> Ik vroeg me af of het voor kleine systemen (zoals AVR) bruikbaar zou
> zijn om beter leesbare, kortere en beter gestructureerde code te komen.
> Ik begin me af te vragen of het mogelijk is, want ik lees zojuist dat je
> dan eerst een 'garbage collector' moet porten naar je target. Er is dus
> net als bij ADA een runtime systeem nodig. (AVR-ADA bestaat trouwens)


Ik begreep dat D enigszins bruikbaar is zonder garbage collector, maar de
meeste libraries vereisen een GC. Ik vraag me ernstig af of in jouw geval
porten het werk waard it. Op dat soort kleine systemen zou ik het op C
houden, ondanks alle beperkingen van die taal.

Groeten,

Leon Timmermans
Stefan Arentz (28.08.2008, 04:26)
"Meindert Sprang" <ms> writes:

> "Stefan Arentz" <stefan> wrote in message
> news:kfsf
> dit te doen:
> Wat heeft bovenstaande voor voordelen t.o.v. onderstaande "code":
> #define LED_PORT PORTB
> #define LED1 0
> #define led.aan() LED_PORT |= (1<<LED1)
> #define led.uit() LED_PORT &= ~(1<<LED1)


Het is een one-time hack terwijl ik probeer om een goeie hoeveelheid
herbruikbare code over te houden.

In geval van een LED zou ik misschien ook zo doen. Echter, als je hebt
hebt over bijvoorbeeld een software UART, waar je er
hoogstwaarschijnlijk toch maar 1 van in je project wil hebben, dan heb
ik liever een taal die handig code kan genereren dan een zooitje
preprocessor ellende.

S.
Meindert Sprang (28.08.2008, 08:52)
"Stefan Arentz" <stefan> wrote in message
news:3fsf
> > Wat heeft bovenstaande voor voordelen t.o.v. onderstaande "code":
> > #define LED_PORT PORTB
> > #define LED1 0
> > #define led.aan() LED_PORT |= (1<<LED1)
> > #define led.uit() LED_PORT &= ~(1<<LED1)

> Het is een one-time hack terwijl ik probeer om een goeie hoeveelheid
> herbruikbare code over te houden.


Och, je zou hier een macro van kunnen maken en die zo vaak gebuiken wanneer
je wilt.

> In geval van een LED zou ik misschien ook zo doen. Echter, als je hebt
> hebt over bijvoorbeeld een software UART, waar je er
> hoogstwaarschijnlijk toch maar 1 van in je project wil hebben, dan heb
> ik liever een taal die handig code kan genereren dan een zooitje
> preprocessor ellende.


Ik heb een systeem met vier software UARTS en dat is, zo zou je kunnen
zeggen, OO geprogrammeerd in assembly. Eenmaal geschreven steeds weer te
gebruiken en te instantieren door per UART een pointer naar een
datastructuur mee te geven.

Meindert
Soortgelijke onderwerpen