'Volgende versie Windows Phone ondersteunt C++'

Ontwikkelaars kunnen in een volgende versie van Windows Phone mogelijk apps schrijven in C++. Dat schrijft een blog in een post die inmiddels is verwijderd. Tot nu toe kunnen Windows Phone-apps alleen in Silverlight en XNA geschreven worden.

Ontwikkeling in de gangbare programmeertaal C++ zal vermoedelijk vanaf Windows Phone 8 'Apollo' ondersteund worden, schreef Windows Phone-fansite WpSauce op basis van informatie van sprekers op een ontwikkelaarsevenement in India. De post is verwijderd, maar is nog in Googles cache te vinden. De oorspronkelijke link verwijst inmiddels naar een oud artikel over screenshots maken, vermoedelijk een aanwijzing voor bezoekers om schermafbeeldingen van de blogpost op te slaan.

Met C++ zouden veel meer ontwikkelaars apps kunnen maken voor Windows Phone. Een anderen reden voor het ondersteunen van C++ kan zijn dat Microsoft stopt met de ontwikkeling van Silverlight. Op dit moment kunnen ontwikkelaars alleen nog apps maken in Silverlight en XNA. Silverlight is Microsofts Flash-alternatief, terwijl XNA werd gemaakt voor Xbox Live en vooral bedoeld is voor games.

Ook zou de eerstvolgende versie van Windows Phone, Tango, veel meer talen ondersteunen. Dat is vermoedelijk een van de eisen van Nokia, dat nu Windows Phones kan uitbrengen in slechts 35 talen, waaronder Nederlands. Als Windows Phone de genoemde 120 talen zou ondersteunen, zou dat releases van toestellen in meer landen en regio's mogelijk maken. Tango zou bovendien integratie bieden met Google+ en Skype, meldt de Zwitserse site PocketPC.ch.

Microsoft heeft zelf het bestaan van Windows Phone Tango en Apollo nog nooit bevestigd. Het vermoeden bestaat dat Tango volgende maand op telecombeurs Mobile World Congress wordt onthuld. Tango zou vooral gericht zijn op het mogelijk maken van goedkopere toestellen met Windows Phone, door de eisen voor toestellen te verlagen. Apollo zou meer integratie moeten bieden met Windows 8, het besturingssysteem voor desktops dat op het gebied van design en typografie elementen van Windows Phone heeft overgenomen.

Reacties (90)

[Heathcliff]

Native C++ is natuurlijk al lang mogelijk op Windows Phone. Het wordt alleen nog niet ondersteund voor alle ontwikkelaars. Een aantal software producenten heeft een overeenkomst met Microsoft om apps met native code in de Marketplace te mogen publiceren. Voorbeelden daarvan zijn Adobe Reader en Navigon.

Microsoft zal in de SDK voor Windows Phone 8 ook officiele support voor native C++ toevoegen. Maar voor het maken van Homebrew apps is dat met oudere SDK's nu al mogelijk. Ik heb daar een tijd geleden al een guide voor geschreven: http://forum.xda-developers.com/showthread.php?t=1299134. Ik zelf met Platform Builder voor Windows Embedded Compact 7 een eigen SDK voor Windows Phone gemaakt.

In bovenstaande reacties wordt ook genoemd dat dit wordt gedaan voor Nokia, zodat ze hun Qt kunnen porten naar Windows Phone. Dat is dus al lang mogelijk. Ik weet niet of Nokia dit ook daadwerkelijk gaat doen, maar technisch gezien zijn daar op dit moment helemaal geen belemmeringen voor.

Voor het porten van andere apps die in C++ zijn geschreven zal waarschijnlijk nog wel gelden dat de frontend in Silverlight gemaakt zal worden. Voorbeeld hiervan is ook weer Adobe Reader. Het renderen gebeurt in native code libraries en de frontend is Silverlight (XAML + C# -> Metro-style).

Het is wel de vraag of unmanaged code de stabiliteit van de apps ten goede komt. De apps blijven in een zeer goed beveiligde sandbox draaien, dus de stabiliteit van het besturingssysteem is niet in gevaar. Aan de andere kant; een unmanaged exception zorgt voor een unexpected app exit, maar een managed exception doet hetzelfde. Alleen managed exceptions zijn voor de screening van de app voor de marketplace veel sneller te ontdekken.

[Dreamvoid]

In feite is "Silverlight" niet meer de juiste naam ervoor, aangezien dat in feite is opgegaan in WinRT. Microsoft maakt een rommeltje van de naamgeving, maar XAML en C# in Metro style is met Windows 8 en dus blijkbaar Windows Phone gewoon WinRT geworden, de nieuwe Windows API.

[Franckey]

Maar XAML en C# op de desktop is volgens mij WPF (Windows Presentation Foundation) en Silverlight is juist een losstaand framework (geen .NET) dat wat betreft architectuur heel veel lijkt op WPF. Het is een soort WPF lite.

[LCP]

Tango zou bovendien integratie bieden met Google+ en Skype, meldt de Zwitserse site PocketPC.ch.

De informatie waarop PocketPC zich berust is een screenshot die hoogstwaarschijnlijk fake is, zoals te lezen in de reacties op WPCentral.

Skype is aannemelijk, maar dat Microsoft Google+ zal integreren is verre van waarschijnlijk omdat Google behoorlijk heeft tegengewerkt in het verleden als het aankomt op Windows Phone. Denk aan YouTube, waar Microsoft niet de YouTube API's voor mocht gebruiken en de Google Calendar ondersteuning (die overigens recentelijk wel verbeterd is)

[Reactie gewijzigd door LCP op 28 juli 2024 15:51]

[Redlion]

Idd een grote Hoax!!!

Waarom, omdat Skype al een paar weken geleden op CES heeft bevestigd dat ze binnenkort met een Skype APP komen! En dat volledige integratie pas in Apollo komt!

Ik snap niet waarom alle nieuwssites zo'n hoax overnemen!!!!

En Google+ integratie....wordt ff wakker!!!!!

[pibara]

Het mooie van C++ is dat het een verbindende factor is tussen verschillende mobiele platforms. Symbian was al zinds jaar en dag een (kreupele versie van) C++. Android heeft de NDK om in C++ code te kunnen ontwikkelen waarvan de performance wel uit maakt, en ook voor IOS kun je in C++ ontwikkelen. Je zou dus als je een beetje je best doet de business logic van een cross-platform App in C++ kunnen schrijven en alleen de UI per platform regelen.

Voor UI's is er trouwens ook een mooie cross-platform oplossing: PhoneGap/jQTouch. Je kunt daar mee met HTML/Javascript/ Css en een cross-platform Javascript API cross-platform Apps bouwen.

Ik hoop dat de makers van PhoneGap eens naar de koppeling met C++ kijken. Het zou fantastisch zijn als je je cross-platform business logic in C++ zou kunnen schrijven. Rete snel en/of meer App voor minder Jouls. En dan met een cross-platform javascript/HTML GUI er op.

[South_Styler]

Goede post met een handige link!

On topic: ik zou blij dat C++ wordt toegevoegd als taal in de WP telefoons. Het is makkelijk en je kunt voor zowel de desktop als de telefoonversie dezelfde functionaliteiten ontwikkelen.

[Superstoned]

EN voor andere platformen. Nokia's Qt kan cross-platform apps schrijven voor Symbian, Android, Mac OS X, iOS, Windows, Win Phone 6.x - en hopelijk komt Win Phone 8 daar dus bij.

[Dreamvoid]

Rete snel en/of meer App voor minder Jouls.

Yay, efficiente snelle code serverside!

En dan met een cross-platform javascript/HTML GUI er op.

Uh....en dan JS/HTML bloat client side...

[pibara]

Ik heb het niet over server-side/client-side maar over business-logic-side/UI-side. Beiden draaien op het zelfde apparaat (de telefoon). Voor de business-logic is het zinnig om het zware werk te doen in de taal die snelle en/of energie zuinige code oplevert. Voor een GUI is dat meestal niet zo.

[dvz89]

Ik haat de term 'business-logic-side' of 'business layer'. Alsof er in de UI geen business rules van toepassing zijn (maxlength, valide datetime, opties alleen zichtbaar als..). Er is niet zoiets als een business layer waar alle validatie plaatsvindt, er zijn alleen specs en die moeten terugkomen in al je lagen, client-side, server-side en in je data access layer.

[Dreamvoid]

Maar waarom zou je in vetersnaam met HTML je GUI willen bouwen als je ook XAML tot je beschikking hebt? OK, als je een website naar een app om wil bouwen snap ik nog dat je code wil hergebruiken, maar voor een native app? Dat doet op Android en iOS ook niemand.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 15:51]

[pibara]

"Maar waarom zou je in vetersnaam met HTML je GUI willen bouwen als je ook XAML tot je beschikking hebt? "

Portabiliteit.

"Dat doet op Android en iOS ook niemand."

Voor het maken van cross-platform mobiele apps (android/iphone) is PhoneGap toch echt nog wel redelijk populair.

[peke]

Als dit waar is is dat een grote slag die Nokia binnenhaalt. Het Qt framework van Nokia (ondersteunt tientallen OS, zowel mobile als desktop) is namelijk gebaseerd op C++ waardoor na een hercompilatie Qt apps ook op WM phones zouden kunnen draaien.

[Anoniem: 256386]

Volgens mij word Mango juist de release voor goedkope smartphones en
Apollo voor de high end. Tango is dus een update van Mango.

[Redlion]

Onjuist!

Zoals al door Rorando wordt aangegeven, Mango is afgelopen september alreeds uitgekomen! Tango komt in 2 releases uit, Tango 1 en Tango 2 en één van deze Tango's zal verbeteringen bevatten waardoor WP oa met minder dan 512MB geheugen kan omgaan waardoor er goedkopere toestellen kunnen worden geproduceert. Maar of dit nu een voordeel is...dan krijg je dadelijk weer zo'n bagger toestellen als de Samsung Ace waar gewoon overduidelijk te weinig geheugen in zit om een fatsoenlijke user experience te krijgen!

Tevens wordt er in dit artikel ook nog een zéér grote HOAX vernoemd!!!

Tango zal namelijk GééN Skype en Google+ integratie gaan bevatten!!!

Tegelijk met Tango zal er een Skype app in de marketplace gaan verschijnen en pas met Apollo welke in Augustus gaat uitkomen komt er geïntegreerde skype ondersteuning in WP! Dit is door Skype zelf alreeds bevestigd. Het is zéér frapant dat alle nieuwssites opeens zo'n hoax gaan overnemen!

En Google+ ondersteuning...laat je nakijken! Microsoft heeft deals met Facebook niet met Google, laat Google eerst eens fatsoenlijke Youtube benadering toestaan! Waarom zou Microsoft in hemelsnaam Google+ gaan pushen / ondersteunen terwijl zij volledig hun geld op Facebook hebben gezet! Nee echt niet!

[Anoniem: 171689]

Je zegt zelf dat MS probeert om WP goed te laten draaien met minder dan 512 MB geheugen. In het geval van de Ace heeft Samsung (of Google) dat dus overduidelijk niet gedaan voor Android, met als gevolg de lag. Als MS hun OS zelf gaat verbouwen om op toestellen als die Ace te kunnen draaien, hebben ze dus een harde streep voor op Android. En aangezien IOS niet in de markt zit, valt daar veel winst te behalen.

En ik zie ook niet echt het nut van Google+ ondersteuning, terwijl Facebook een veel wijder geaccepteerd netwerk is wat men ook al in Windows Live heeft geintegreerd.

[Rorando]

Manga is al een redelijke tijd uit en had niks te maken met het zorgen van mogelijke goedkope smartphones

[Anoniem: 256386]

nee op dit moment niet.
Maar de strategie van MS is om 2 versies te hebben van WP te hebben
Eentje voor goedkope en high end smartphones. Logisch is dus om Mango voor de goedkope smartphones. Voor minimaal dual core en HD schermen ondersteuning moet je bij Apollo wezen.

[Anoniem: 441072]

Ik snap niet dat iedereen zogenaamd staan te juigen om C++ support. Er moet veel meer werk verricht worden, het is denk ik ook alleen beter voor diegenen die games ontwikkelen. Ik bedoel als ik aan MFC klassen moet denken voor Windows, dan zijn dat verschrikkelijke klassen, die zogenaam voor ons (programmeurs) het leven makkelijker zou maken. Maar nee, MFC's Socket klassen zijn waardeloos en zo kan ik nog wat gaan noemen. Wat er gebeurt, programmeurs gaan eigen klassen om native systemcalls schrijven, gebruiken klassen van BOOST, schrijven eigen threadsafe klassen enz. Wat dat betreft vind ik C++ voor WP niet echt een aanwinst als je snel een app wilt maken. Wil men in C-achtige taal schrijven, gebruik dan gewoon C#, die taal is toch gefintuned voor .NET platform om zo efficient mogelijk met geheugen om te gaan, ik bedoel je hebt zelfs micro.NET voor microcontrollers, die heel beperkt geheugen hebben waar je ook in C# kunt schrijven.

C++.NET gebruikt bijna niemand, veel ex C++ programmeurs zijn gewoon direct overgestapt naar C# ipv C++.NET.

C# lijkt veel op Java (m.i heeft M$ het concept gewoon gejat van Java), dus de overstap naar C# is helemaal niet zo moeilijk. Ik heb de omgekeerde weg genomen en ik zit nu als een gek Java te schrijven. Daarvoor was het voor mij ook geen grote stap om van C++ naar C# te stappen. De ellende van C++ is dat je verdomd goed moet opletten dat je je geheugen niet lekt. Maar aan de andere kant, moet je in C# nog steeds opletten dat je HANDLEs niet lekt. Verder moet je in C# ook zaken als threads, synchronisatie, delegates en nog wat van die toestanden opnieuw leren, dat is bij elk taal net even anders en zolang je programmeert zul je moeten bijlven leren, anders moet je maar een danser, zanger, voetballer worden of zo.

[.oisyn]

Wat een ontzettend onsamenhangend verhaal vol met offtopic gezever.

Ik bedoel als ik aan MFC klassen moet denken voor Windows, dan zijn dat verschrikkelijke klassen

Klopt, maar wat is je punt? Dat iedereen nu MFC classes moet gebruiken? MFC is dood, en echt niet dat er een MFC library gaat zijn voor WP8. Veel waarschijnlijker is dat er gewoon C++/CX gebruikt gaat worden (native C++ met extensions die lijken op die van C++/CLI om van WinRT gebruik te kunnen maken), en dus krijg je gewoon een mooi OO framework om te communiceren met het OS.

Wat dat betreft vind ik C++ voor WP niet echt een aanwinst als je snel een app wilt maken

C++ is sowieso geen aanwinst als je "even snel" iets wil maken. Maar waarom zouden mensen alleen snel een app willen maken? C++ heeft gewoon zijn plaats, met name in high performance en/of memory critical applicaties zoals bijv. navigatiesoftware en games. Daarnaast zijn er tal van 3rd party libraries waar je meteen gebruik van kan maken (zoals de webkit HTML renderer, Qt framework, Unity, etc.) maar waar geen .Net ports van bestaan.

C# lijkt veel op Java (m.i heeft M$ het concept gewoon gejat van Java)

Hoe is het relevant dat Microsoft (met een s, niet een $, veelgemaakte fout) het concept wel of niet "gejat" zou hebben van Sun? Wat mij betreft is het een goede keuze geweest, ze hebben een eigen OS met een hele rijke API, en het gebruik van Java met aanpassingen was gewoon geen optie. En de ontwikkeling van .Net en C# gaan veel sneller dan die van Java taal en platform. Daarnaast is het ook zo dat Java op zijn beurt weer bepaalde punten van C# heeft overgenomen (zoals bijv. autoboxing). Dit soort concurrentie is alleen maar goed en de programmeur plukt er de vruchten van.

De ellende van C++ is dat je verdomd goed moet opletten dat je je geheugen niet lekt.

De ellende van garbage collected omgevingen is dat je net zo goed op moet letten, maar je denkt dat dat niet hoeft omdat er toch een GC draait. Maar als je niet oppast blijft er ergens een reference hangen naar een hele instance tree die vervolgens nooit opgeruimd worden. C++ dwingt je hierover na te denken, en met paradigma's als RAII is het niet eens zo lastig (en dus hoef je amper na te denken over het opruimen van HANDLEs, zoals MSalters hierboven al uitlegde - dat doe je gewoon in de destructor). Overigens sluit standaard C++ het bestaan van een GC helemaal niet uit, en er bestaan gewoon garbage collectors voor C++ (zie bijvoorbeeld het werk van Hans Boehm)

[Reactie gewijzigd door .oisyn op 28 juli 2024 15:51]

[Anoniem: 441072]

Grappig dat jij op offtopic gezever reageert.
MFC wordt nog steeds gebruikt, zelfs in VS2008 (die wij op het werk gebruiken), al beweer je dat het dood is. Het zal vast anders zijn voor WP7, maar heb er verder geen ervaring mee, behalve de ervaring die ik heb met Windows programmeren (in C++/C#).

Verder heb ik al aangegeven dat C++ wel interessant zou kunnen zijn voor games en andere toepassinge met grafische geweld.

Dat C# gejat is van Java is wil ik alleen maar aangeven voor de lezers die het niet weten, maar dat je daarop moet reageren begrijp ik ook niet.

Ik weet niet wat jij voor problemen hebt met GC, ik heb dat in ieder geval niet. Verder heb ik ook niet gezegd dat je bij C++ niet hoeft op te passen voor handle leaks. Bij C++ moet je aan alles denken, daarom is het bij C++ een stuk moeilijker, je krijgt meer controle, duz zul je op alles moeten letten (big power, comes with big responsibility). Tuurlijk kun je van alles programmeren om je rotzooi automatisch op te ruimen, maar ja, ben je nou bezig om een app te bouwen of uitlities?

Ik wil een app maken, dan wil ik simpelweg alle middelen voor hebben, dat is met C++ voor Windows gewoon niet zo goed geregeld geweest.
Goh, wist alleen niet dat hier M$ fanboys tussen zaten (en nee, het is geen schrijffout).

[.oisyn]

MFC wordt nog steeds gebruikt, zelfs in VS2008 (die wij op het werk gebruiken), al beweer je dat het dood is.

Dat het wordt gebruikt betekent niet dat het actief door MS wordt doorontwikkeld. Natuurlijk is de ondersteuning er, anders zouden ze voor legacy applicaties nooit overstappen naar een nieuwere Visual Studio, en daarom zullen er ook updates zijn. Maar geen enkel weldenkend persoon zal een nieuwe applicatie in MFC gaan ontwikkelen, en MS zal je dat advies ook echt niet geven.

behalve de ervaring die ik heb met Windows programmeren (in C++/C#).

Indien jij voor je werk met MFC moet werken: mijn oprechte deelneming

Dat C# gejat is van Java is wil ik alleen maar aangeven voor de lezers die het niet weten

Mijn kanttekening daarbij is welk punt je daarmee probeert te maken. Het is totaal irrelevant. Het lijkt een waardeoordeel te zijn, maar in feite is dat het niet. Melden dat de driemachtswortel van 8 gelijk is aan 2 heeft net zoveel toegevoegde waarde.

Ik weet niet wat jij voor problemen hebt met GC, ik heb dat in ieder geval niet

Ik heb er geen problemen mee, je moet je alleen realiseren dat het geen heilige graal is en dat het niet zo is dat je nooit meer hoeft na te denken over object lifetime. Zolang je daar rekening mee houdt zit je goed. Maar feitelijk moet je hetzelfde doen als er geen GC aanwezig is. Natuurlijk is het iets makkelijker, maar een fout zit in een klein hoekje (zoals bijvoorbeeld een delegate die je ergens hebt geregistreerd voor een event dat nooit meer zal voorkomen, terwijl die delegate toch nog een hele rits aan class instances in leven houdt - waarom denk je dat bijvoorbeeld weak event patterns bestaan? Een GC impliceert niet dat je geen geheugen lekt, en dat beperkt zich niet tot unmanaged resources).

Ik wil een app maken, dan wil ik simpelweg alle middelen voor hebben, dat is met C++ voor Windows gewoon niet zo goed geregeld geweest.

Je begon je reactie met "Ik snap niet dat iedereen zogenaamd staan te juigen om C++ support". Vervolgens lijk je heel zwart-wit te denken en te redeneren dat je vervolgens alleen nog C++ zal gebruiken om apps te maken. Complete onzin natuurlijk - wat ik in mijn vorige post al beweerde, C++ heeft gewoon zijn plaats. Je hoeft niet je hele app in C++ te maken, je kunt het kritieke component in C++ ontwikkelen (grafische engine, high performance database, etc) en de rest van je app in C# laten. En voor de mensen die dergelijke eisen hebben is het toelaten van C++ dus een hele welkome keuze.

Daarnaast resulteert het ondersteunen van C++ gewoon in veel meer ports van apps van andere smartphones, waar de consument alleen maar vrolijker van wordt. En daarom "staat iedereen zogenaamd te juichen om C++ support".

(en nee, het is geen schrijffout).

Het is gewoon een troll. En mij fanboy noemen is een flame. Jammer dat je het over die boeg moet gooien, dat kinderachtige geneuzel doe ik niet aan mee (en quite frankly, van iemand van 36 had ik beter verwacht).

[Reactie gewijzigd door .oisyn op 28 juli 2024 15:51]

[MSalters]

Wat is je argument nu, behalve dan dat MFC slecht is? Dat weet iedereen, en de meesten weten dat het ouderdom is - MFC stamt uit circa 1994, en toen was VC++ 1.x geen geweldige compiler.

En wat betreft het lekken van HANDLES - dat is makkelijker in C++. Garbage collection in C# en Java ruimt alleen geheugen op (vervanging van malloc/free), maar niets anders - het is geen vervanging van FreeHandle. RAII in C++ ruimt alles op, dus ook HANDLES.

[Anoniem: 206724]

Waarom geen C#? Dat lijkt me een veel handigere taal om smartphoneapplicaties in te schrijven en het is ook echt typisch een Microsoft taaltje. Is ook iets minder lowlevel als C++.

Edit: pardon voor mijn onwetendheid, blijkt dus inderdaad dat WP7 dit gewoon ondersteund.

offtopic:
Koffie op de vroege morgen.

[Reactie gewijzigd door Anoniem: 206724 op 28 juli 2024 15:51]

[dcm360]

C# wordt al lang gebruikt op Windows Phone, dus dat hoeft niet bepaald meer toegevoegd te worden,

[Anoniem: 206724]

Dan snap ik de meerwaarde van het toevoegen van C++ ondersteuning aan WP niet echt... Lijkt me alleen maar problemen met de integratie van applicaties in het OS te kunnen veroorzaken doordat de taal relatief low-level is. Een iets meer "managed" taal als C# of één van de vele andere .NET-talen zijn toch al prachtig genoeg om applicaties in te schrijven?

Dat de kern van Windows Phone in C++ geschreven zou zijn, bijvoorbeeld, kan ik nog wel begrijpen maar voor applicaties lijkt .NET toch prima te voldoen?

[Superstoned]

Ik kan me voorstellen dat een belangrijke reden dat Nokia dit wil is dat Qt een C++ taal is en Nokia wil dat Qt gebruikt kan worden op Windows Phone. Dat zou zorgen dat ontwikkelaars in 1 taal (C++/QML/Qt combinatie) apps kunnen schrijven voor vrijwel alle platformen (iOS, Win Mobile, Symbian, Android, WebOS).

[Dreamvoid]

Het zal er meer mee te maken hebben dat Windows 8 ook gewoon C++ support, en het nogal onlogisch is dat je zometeen een Metro app voor een W8 tablet niet kan compilen als Metro app voor Windows Phone.

[Mathieu_Hinder]

Mensen die programmeren in C++ kunnen nu ook een applicatie schrijven, zonder eerst de veranderingen in C# te hoeven doornemen. Hoe meer talen ondersteund, hoe meer ontwikkelaars in aanmerking komen.

[Anoniem: 382732]

Als je kunt programmeren doet de taal waarin je dat doet er niet toe.... Het platform en de toepassing moet de programmeertaal bepalen, niet de ontwikkelaar.

[Mathieu_Hinder]

Enerzijds gelijk, anderzijds zijn er heel wat subtiele (en minder subtiele) verschillen in bv. C en C#. Het programmeren is meer dan wat keywords typen uiteraard, maar je kan niet zomaar in een andere taal werken dan je gewoon bent. Je hebt een opleiding ofzo gevolgd voor een bepaalde taal, en eens je die meester bent, heeft die je voorkeur.

[YopY]

maar je kan niet zomaar in een andere taal werken dan je gewoon bent.

'Tuurlijk wel, je moet het gewoon doen. Een nieuwe taal leren is heus niet zo moeilijk als je wel denkt, zeker niet als je het voor je werk doet (en dus 8 uur / dag eraan kunt besteden). Het gaat meer om instelling - d'r zijn genoeg mensen die verrekken het om een nieuwe taal te leren.

* YopY werkt tegenwoordig met Objective-C, Scala, Java en JS door elkaar, geen probleem.

[Niemand_Anders]

Het gaat niet om de taal, maar de toolset - ofwel de bibliotheken waarvan je gebruik maakt.

C# (en andere runtime talen/platformen) bieden uiteraard meer bescherming, maar aan de andere kant minder vrijheid. C++ is meer low-level, je moet dus zelf meer doen en regelen, maar je hebt wel meer vrijheid..

[blorf]

Ik zit het me af te vragen. Wat gebeurt er als je in WP met een C++ programma in kernel space probeert te rommelen zonder tussenkomst van een API? Volgens mij is MS niet zo gek dat ze dat gewoon toestaan. Straks wordt WP gekozen als standaard werk-platform voor hackers

[Dreamvoid]

En daar heb je dus een app store met ballotage voor.

[Mathieu_Hinder]

Maar als je nu zoals jij Java kent, en je krijgt de optie om in Java te programmeren of in een andere taal, dan is het toch maar zo gemakkelijk dat je die al kent? Ze kunnen alleen maar meer volk aantrekken, dus waarom niet.

[blorf]

Ik denk dat je in dit geval langer bezig bent met het leren van C++ naar het idee van MS dan de principes van de taal op zich. Een "hello world" ziet er in MS-C++ waarschijnlijk iets anders uit dan het voorbeeld in de boeken. Zoiezo kan je er waarschijnlijk alleen maar apps mee wat geen volledige programma's zijn maar stukken code die tijdens runtime afhankelijk zijn van een voorgekauwd software-land genaamd WP. Gewoon een soort .NET maar dan (nog) niet een officiele standaard.

[Reactie gewijzigd door blorf op 28 juli 2024 15:51]

[Anoniem: 37864]

@blorf:

Natuurlijk zijn apps wel volledige programma's. Volgens jouw omschrijving zijn gewone programma's ook 'maar stukken code die runtime afhankelijk zijn van een voorgekauwd software-land', alleen is dan hun runtime omgeving Win32/64 of Cocoa of POSIX of iets anders, maar net wat je OS als API aanbiedt.

[Anoniem: 295700]

Dat is onzin. Iedere taal heeft specifieke kenmerken en aanvullende libraries.

[Thomson]

Al eens gedacht aan cross-platform engines voor games bijvoorbeeld. Als een hele game herschreven zou moeten worden, enkel en alleen om op WP7 te kunnen draaien zou men daar toch twee keer over na moeten denken. Wanneer men echter de (in c++ geschreven) core kan behouden zal dit veel makkelijker gaan.

[Qreed]

Al eens gedacht aan cross-platform engines voor games bijvoorbeeld. Als een hele game herschreven zou moeten worden, enkel en alleen om op WP7 te kunnen draaien zou men daar toch twee keer over na moeten denken. Wanneer men echter de (in c++ geschreven) core kan behouden zal dit veel makkelijker gaan.

Precies! Dit is een flink probleem voor MS geweest sinds de "enkel ObjC op iOS / Flash is K" actie van Apple. Ik loop al een aantal maanden met collega's hierover te discussiëren en het toelaten van C/C++ was echt de enige optie voor MS nadat ze zelf Silverlight de nek omdraaide (-- wat vreselijk jammer is).
Voor de meeste mensen is ObjectiveC niet de meest prettige ontwikkeltaal om mee te werken en het framework eromheen is ook niet altijd even praktisch. Veel developers ontwikkelen dus gewoon in C/C++ en linken dit naar een fron-endtje in ObjC. Microsoft rook dit natuurlijk ook en ze weten zelf ook dat hun ontwikkel tooling light years voorsprongen heeft op XCode en de rest.

Vooral dit is heel belangrijk voor Microsoft want als developers cross platform code gaan schrijven onder Visual Studio is er een grote kans dat ze ook primair op WP gaan richten. In het verleden heeft dit ook al goed uitgepakt voor MS, kijk maar naar de game console markt. Ik ben zeer benieuwd hoe dit gaat uitpakken.

Natuurlijk was het velen malen beter geweest als er gewoon native C# op iOS kon draaien. Steve zag dit bovenstaande (probleem voor Apple) een jaar(?) geleden al en riep daarom een halt op alles behalve ObjC (en gaf voor het publiek Flash als zwarte schaap).

[Carbon]

Voor de meeste mensen is ObjectiveC niet de meest prettige ontwikkeltaal om mee te werken

Net als met elke overstap van programmeertaal is dat gewoon een kwestie van wennen.

en het framework eromheen is ook niet altijd even praktisch.

[OT] ik ben toch wel erg benieuwd wat er niet praktisch zou zijn aan het iOS framework.

Natuurlijk was het velen malen beter geweest als er gewoon native C# op iOS kon draaien.

Ik ben zelf geen aanhanger van bytecode georiënteerde oplossingen als Java en C#
Het grote voordeel is binaire portabiliteit maar het nadeel is dat je inlevert op performance.

Daarnaast is er de problematiek van geheugenbeheer, managed code is in veel gevallen een zegen, maar het onvoorspelbare gedrag van de garbage collector maakt het voor bepaalde toepassingen gewoon storend en in bepaalde gevallen zelfs onbruikbaar.

Steve zag dit bovenstaande (probleem voor Apple) een jaar(?) geleden al en riep daarom een halt op alles behalve ObjC

Nope, je kunt programma's schrijven in C/C++ en Objective C en dat is altijd al zo geweest. Wat ze wel hebben tegengehouden is het gebruik van Flash voor iOS apps.
Die beperking is in september 2010 opgeheven.

(en gaf voor het publiek Flash als zwarte schaap).

Kom nou toch, Apple heeft Adobe meer dan één jaar de tijd gegeven om met een versie te komen die acceptabel werkt, toen ze dat niet voor elkaar kregen heeft Apple Flash definitief uitgezwaaid. En zeg nou zelf, we zijn nu een paar jaar en 2 CPU generaties verder en nog steeds is de performance een probleem op mobile devices. Het is niet voor niets dat ook Adobe er inmiddels een punt achter heeft gezet

[Reactie gewijzigd door Carbon op 28 juli 2024 15:51]

[Dreamvoid]

Dit is een uitgekauwd verhaal en lang niet zo zwart-wit. Ik kan me heel goed voorstellen dat zowel Apple als Google als Microsoft het liefst werken met zo min mogelijk frameworks op hun OS: minder attack vectors, minder overhead, niet afhankelijk van een 3rd party voor je gebruikerservaring, en het heeft als bijkomende bonus dat je de concurrentie wat beter van je platform af kan houden: platformonafhankelijkheid, dat doe je maar in de browser. Alle platformonafhankelijke frameworks op de clients zijn dood: JVM, Silverlight, JavaFX, Flash, .NET/Mono, bedenk het maar.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 15:51]

[asx245]

Goh, ik kan dit wel begrijpen eigenlijk. Ooit al eens een spel als Modern Warfare, Battlefield... op je pc gespeeld? Dat is allemaal C++, en daar zullen wel goede redenen voor zijn. .net en java zijn hier minder voor geschikt

[Timons106]

.NET is geen taal zoals C++ hoor, .NET is een framework dat door VC++, C# en VB.NET wordt gebruikt .

Het is wel netjes dat Microsoft de mogelijkheid geeft om in C++ te programmeren voor Windows Phone, ik denk dat de applicatie markt daardoor explosief zal gaan groeien, wat natuurlijk goed is!

[.oisyn]

VC++ is geen taal zoals C# hoor, maar een IDE. De .Net variant van C++ heet C++/CLI (en idd, beide C++ als C++/CLI zijn met VC++ te gebruiken)

[Reactie gewijzigd door .oisyn op 28 juli 2024 15:51]

[Gropah]

De vraag is echter of je, als je beide talen kan, wel in C# wil schrijven. Het heeft namelijk nog wel eens de neiging om meer te geheugen te gaan gebruiken dan dat zelfde programma in C++, C of ongeveer elke andere taal (sommige daar gelaten). Op een desktop boeit het weinig, iedereen heeft wel 2GB, dus daar kun je het redelijk bont maken, terwijl op een telefoon er een (zeer) beperkte hoeveelheid geheugen is.

De consument merkt er dan weinig van, maar apps zullen meer ruimte vreten waardoor er minder apps tegelijk kunnen draaien voor het geheugen vol zit en dat terwijl het juist de trend is om zoveel mogelijk naast elkaar open te hebben

[boelleken2]

Dat dit problemen gaat geven denk ik niet, de technologische vooruitgang gaat hier voor te snel vooruit. Trouwens is windows7 veel minder resource honger dan een android platform..

[Mathieu_Hinder]

Maar een overvloed aan resources zou geen reden moeten zijn om inefficiënt te programmeren (wat het nu vaak is). Hoe snel de technologie ook wordt, er wordt ook steeds meer gevraagd ervan. Meer resources en performance is altijd welkom.

[HerrPino]

(Managed) C++ wordt net als alle andere .NET talen ook gewoon ondersteund. 90% van de code is gewoon te compileren, over het algemeen hoeven alleen front-end zaken opnieuw geschreven te worden.

[Anoniem: 131715]

Als dat een eis van Nokia is... komt Qt dan toch nog naar WP? Of misschien niet Qt proper, maar ik kan me voorstellen dat een hoop van de libraries dan toch in hoog tempo de Lumia's opsijpelen.

[Mellow Jack]

Wat voor voordeel bied QT dan in de praktijk voor ontwikkelaars? Persoonlijk denk ik dat C++ veel belangrijker zal zijn vanwege cross platform

[Anoniem: 131715]

Voor de ontwikkelaars binnen Nokia: Een hoop kennis die ze al hebben. En voor ieder ander: Een berg nuttige classes. En een scripting language voor de gui. Bovendien is Qt al verkrijgbaar voor Android (en Windows, Mac en Linux), waar het een redelijke (al is het geen perfecte) job doet om er native uit te zien, dus ik zou eigenlijk zeggen dat C++ cross platform programmeren mogelijk maakt, en Qt voor een flink gedeelte de practische problemen oplost.

[Mellow Jack]

En in hoeverre wordt het ondersteund in iOS en BBos?

Ik ben namelijk benieuwd in hoerre QT echt meerwaarde bied en of het een alternatief kan zijn voor het ontwikkelen op de mobiele platformen. Dat het werkt op Nokia is natuurlijk leuk maar boeit verder niemand (dit in de zin van je wilt 1 taal voor elk mogelijk platform)

[Reactie gewijzigd door Mellow Jack op 28 juli 2024 15:51]

[Dreamvoid]

Het is leuk dat het er is, maar wordt het ook gebruikt? Hoeveel Qt-liefhebbende Symbian developers (die zich nog niet omgeschoold hebben naar andere platforms) lopen er anno 2012 nog rond? Als ik de lijst van Qt software eens doorkijk zie ik maar weinig showcases van moderne, succesvolle programma's - heeft Qt nog wel kritische massa?

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 15:51]

[Superstoned]

Qt IS cross-platform. In combinatie met QML kun je in heel korte tijd (in developer-weken) naar een ander platform porten... Qt ondersteund weet-ik-hoeveel plaformen (incl iOS, Android, Symbian, WiMo 6.x, WebOS, ...).

[Laurens-R]

Ik zie hier in de reacties dat men vooral aanneemt dat het om native C++ gaat. Het kan natuurlijk net zo goed managed C++ zijn, wat (gezien het platform) toch ook niet geheel onwaarschijnlijk is

(Zou ik btw wel balen vinden daar niet van)

Edit: Nou zie je maar dat ik er al heel lang niet meer naar gekeken heb ... je hebt tegenwoordig C++/CLI.

Ook een interessante ontwikkeling is C++/CX, wat compleet native is (hoewel het dus wel kan samenwerken met .net):

Please note, however, that while the C++/CX syntax is very similar to C++/CLI, the underlying implementation is very different, it does not use the CLR or a garbage collector, and it generates completely native code (x64, x64, ARM depending on target).

van http://blogs.msdn.com/b/v.../2011/10/20/10228473.aspx

[Reactie gewijzigd door Laurens-R op 28 juli 2024 15:51]

[Carbon]

Het kan natuurlijk net zo goed managed C++ zijn

Wat Microsoft managed C++ noemt is niets meer dan C++ met een paar tweaks aan de compiler zodat je naast C++ objecten ook .NET managed objecten kunt gebruiken.

[Reactie gewijzigd door Carbon op 28 juli 2024 15:51]

[Wolfos]

Dat is geweldig nieuws, Unity3D (waar ik mee werk) had al aangegeven geen support naar WP7 te kunnen brengen vanwege het gebrek aan C++ support. Microsoft vergat dat ze dit keer maar een klein stukje van de markt hebben en dus niet exclusieve technologieën kunnen gaan gebruiken.