[Ervaringen] Visual Studio 2010

[Olaf van der Spek]

.oisyn schreef op woensdag 01 juli 2009 @ 17:40:
Ach, met lambdas wordt std::for_each zowaar nuttig

Ja, maar for_each(range, ...) kan ook niet toch? Er blijven twee iterators nodig.

[.oisyn]

C++:

// voor containers
template<class C, class F>
void for_each(C && cont, F && f)
{
    for (auto it = cont.begin(); it != cont.end(); ++it)
        f(*it);
}

// voor arrays
template<class T, size_t N, class F>
void for_each(T (&array)[N], F && f)
{
    for (size_t i = 0; i < N; i++)
        f(array[i]);
}

Nu kan het wel.

Range-based for is gestoeld op concepts, en concepts zitten niet in VS 2010. Sterker nog, concepts vertragen heel C++0x en het is sowieso de vraag wat ze er nou mee gaan doen... (al denk ik niet dat ze het eruit gaan halen)

[ Voor 65% gewijzigd door .oisyn op 10-07-2009 17:48 . Reden: const C & -> C && ]

[Olaf van der Spek]

.oisyn schreef op woensdag 01 juli 2009 @ 21:02:
[code=c++]// voor containers
Range-based for is gestoeld op concepts, en concepts zitten niet in VS 2010. Sterker nog, concepts vertragen heel C++0x en het is sowieso de vraag wat ze er nou mee gaan doen... (al denk ik niet dat ze het eruit gaan halen)

Ah, gaat lekker. Erin laten zitten klinkt ook niet zo heel handig.

[Data-base]

Woy schreef op woensdag 01 juli 2009 @ 11:30:
dat ik dat nooit geprobeerd heb

Ik werk nu altijd met van die losse floating windowtjes. Dit is wel een stuk beter, nog een maximaliseer knop erbij en het is precies wat ik wil

Maximaliseer knop is er al!

Kijk!



Of begrijp ik je verkeerd

[.oisyn]

Is dat 2010? Voorheen zat dat er nog niet in.

[Data-base]

.oisyn schreef op donderdag 02 juli 2009 @ 01:09:
Is dat 2010? Voorheen zat dat er nog niet in.

Ja is 2010 beta zoveel.

[Woy]

Data-base schreef op donderdag 02 juli 2009 @ 01:06:
[...]


Maximaliseer knop is er al!

Kijk!

[afbeelding]

Of begrijp ik je verkeerd

Ja ik wou het thuis al controrleren, want dacht dat het er idd inzat. Maar had gisteren geen tijd om te testen. Maar blijkbaar werkt het nu in VS.NET 2010 zoals ik zou willen.

[D-Raven]

RobIII schreef op woensdag 01 juli 2009 @ 16:29:
[...]

Goed; dat de IDE('s) wat mankeert is nog tot daar aan toe, maar wat voor monster van een project is dat dan?

Dat heet zogenaamde "enterprise" development . Tis een project wat begonnen is in 2003 en waarvan we ondertussen mee in 2008 zitten. Zegt wat over hoe lang het al loopt.
Het is een intranet applicatie waar een bedrijf zogoed als al zijn core bedrijfsprocessen in kan managen en beheren. Vanaf de bestelling bij de klant tot aan een order bij de leverancier en alles wat daar tussen zit en meer.
In de loop der tijden is er constant op voortgeborduurd en onderontwikkeld
Er zit dus behoorlijk veel in .

Maargoed de markup editor is daar iig erg traag. Had wat dingen gelezen en blijkbaar is Javascript intellisense een van de boosdoeners.
Vroeg me af wat de ervaringen zijn met dat soort dingen in VS2010.

[Data-base]

D-Raven schreef op donderdag 02 juli 2009 @ 09:37:
[...]


Dat heet zogenaamde "enterprise" development . Tis een project wat begonnen is in 2003 en waarvan we ondertussen mee in 2008 zitten. Zegt wat over hoe lang het al loopt.
Het is een intranet applicatie waar een bedrijf zogoed als al zijn core bedrijfsprocessen in kan managen en beheren. Vanaf de bestelling bij de klant tot aan een order bij de leverancier en alles wat daar tussen zit en meer.
In de loop der tijden is er constant op voortgeborduurd en onderontwikkeld
Er zit dus behoorlijk veel in .

Maargoed de markup editor is daar iig erg traag. Had wat dingen gelezen en blijkbaar is Javascript intellisense een van de boosdoeners.
Vroeg me af wat de ervaringen zijn met dat soort dingen in VS2010.

Ik vind vs2010 stuk trager dan vs2008.

Maar misschien komt dat ook wel omdat ik zo'n extension heb geinstalleerd voor intellisense in wpf.

[Snake]

Data-base schreef op donderdag 02 juli 2009 @ 12:56:
[...]


Ik vind vs2010 stuk trager dan vs2008.

Maar misschien komt dat ook wel omdat ik zo'n extension heb geinstalleerd voor intellisense in wpf.

Welke plugin is dat?

[Verwijderd]

Data-base schreef op donderdag 02 juli 2009 @ 12:56:
[...]


Ik vind vs2010 stuk trager dan vs2008.

Maar misschien komt dat ook wel omdat ik zo'n extension heb geinstalleerd voor intellisense in wpf.

Wat is er mis met de standaard intellisense? Ik mag toch aannemen dat ze dat er niet uitgehaald hebben tussen VS2008 en 2010

[dj_vibri]

Nog niet kunnen testen maar wat ik me wel afvroeg is het volgende: Waarom brengt Microsoft in godsnaam geen Visual Studio x64 editie uit?!? Heb zitten zoeken naar VS 2008 x64 en VS 2010 x64 maar blijkbaar draait vs 2010 nog steeds enkel op 32-bits......

Vermits dit mijn primaire werktaak op de pc is, vraag ik me dus ook af of het überhaupt dan wel nodig is om te 'investeren' in 64-bits systeem?

Anybody got some thoughts?

ps: hetzelfde is trouwens ook geldig ivm Office 2007/2010..... Net gevonden dat Office 2010 wel degelijk 64-bits aangeboden zal worden....

[ Voor 14% gewijzigd door dj_vibri op 03-07-2009 07:53 ]

[OMX2000]

dj_vibri schreef op vrijdag 03 juli 2009 @ 07:49:
Nog niet kunnen testen maar wat ik me wel afvroeg is het volgende: Waarom brengt Microsoft in godsnaam geen Visual Studio x64 editie uit?!? Heb zitten zoeken naar VS 2008 x64 en VS 2010 x64 maar blijkbaar draait vs 2010 nog steeds enkel op 32-bits......

Vermits dit mijn primaire werktaak op de pc is, vraag ik me dus ook af of het überhaupt dan wel nodig is om te 'investeren' in 64-bits systeem?

Anybody got some thoughts?

ps: hetzelfde is trouwens ook geldig ivm Office 2007/2010..... Net gevonden dat Office 2010 wel degelijk 64-bits aangeboden zal worden....

Microsoft, ik weet niet meer waar ik dat gehoord/gelezen heb, heeft aangegeven dat het niet zoveel voordelen heeft en dat het meer loont om VS 32 bits op een 64 bits platform te draaien. Memory management van je OS is met 64 bits een stuk beter. Ik denk dat het ook wel waar is. Het gaat dus niet om de compiler en het framework zelf.

Found the article : http://news.softpedia.com...isual-Studio-113943.shtml

Als ik het nu nog eens lees is het met name de kosten die Microsoft ervan weerhoudt om het te gaan porten naar x64.

[dj_vibri]

Maar gaat je applicatie dan bv. niet sneller compilen op een x64-systeem? Meer memory om te gebruiken bv. Weliswaar op voorwaarde dat Microsoft zijn code aanpast naar x64

Ze zetten alles om naar x64 behalve Visual Studio....zonde.... *denk ik dan weer*

[.oisyn]

Dat VS niet in 64 bits is wil niet zeggen dat de compilers dat ook niet zijn. Als ik kijk naar m'n VC++ 2005 directory, dan staat er in VC/bin/amd64 gewoon een 64 bits compiler (dwz, het is een 64 bits executable, ik bedoel niet dat ie 64 bits executables produceert )

[OMX2000]

dj_vibri schreef op vrijdag 03 juli 2009 @ 10:32:
Maar gaat je applicatie dan bv. niet sneller compilen op een x64-systeem? Meer memory om te gebruiken bv. Weliswaar op voorwaarde dat Microsoft zijn code aanpast naar x64

Ze zetten alles om naar x64 behalve Visual Studio....zonde.... *denk ik dan weer*

Nou ja zonde... Visual Studio is best wel een grooot beest. Ze gaan denk ik stapje voor stapje. Door nu bijv. de code-editor te porten naar WPF/Managed code. Hoewel VS een hele belangrijke tool is voor MS maken ze er lang niet zoveel winst op als Office. Dus logisch dat ze het daar kunnen veroorloven om in een keer te porten naar x64.

Ik ben het ook met MS eens. Je zult het alleen merken bij extreem grote solutions. En daar heb ik zoieso mijn twijfels bij, ophakken die hap. Niemand kan mij vertellen dat hij/zij overzicht heeft of houdt doordat alles in een solution zit. En het is ook niet goed als een persoon op een moment zoveel projecten tegelijk open moet hebben om makkelijk te debuggen.

[Woy]

offtopic:
Ben ik een beetje aan het spelen met mijn nieuw verworven docking kunsten , loop ik meteen tegen deze bug aan FIX: When you undock some windows or change the window layout in the Visual Studio 2008 Service Pack 1 IDE, the IDE crashes

[Olaf van der Spek]

dj_vibri schreef op vrijdag 03 juli 2009 @ 10:32:
Maar gaat je applicatie dan bv. niet sneller compilen op een x64-systeem? Meer memory om te gebruiken bv. Weliswaar op voorwaarde dat Microsoft zijn code aanpast naar x64

2, 3 of 4 gbyte geheugen is aardig wat hoor, het zou toch absurd zijn als het IDE of compiler/linker proces nog meer geheugen nodig had?

MS heeft aangegeven dat de beschikbaarheid van meer geheugen wel verleidelijk is, maar dat ze liever optimaliseren om meer met minder geheugen te doen.

[ Voor 15% gewijzigd door Olaf van der Spek op 03-07-2009 12:13 ]

[Snake]

Woy schreef op vrijdag 03 juli 2009 @ 11:43:

offtopic:
Ben ik een beetje aan het spelen met mijn nieuw verworven docking kunsten , loop ik meteen tegen deze bug aan FIX: When you undock some windows or change the window layout in the Visual Studio 2008 Service Pack 1 IDE, the IDE crashes

Ni moeilijk doen e de hotfix kan je gratis downloaden.

[.oisyn]

Grapjas. Het nadeel van die hotfixes is dat ze doorgaans niet compatible zijn met de Xbox SDK . Wel moeilijk doen dus. 't Grappige is overigens dat wij net deze week overgaan op 2008

[ Voor 32% gewijzigd door .oisyn op 03-07-2009 12:56 ]

[Snake]

.oisyn schreef op vrijdag 03 juli 2009 @ 12:55:
Grapjas. Het nadeel van die hotfixes is dat ze doorgaans niet compatible zijn met de Xbox SDK . Wel moeilijk doen dus. 't Grappige is overigens dat wij net deze week overgaan op 2008

Geen ervaring mee Mea culpa!

Maar moet je die installeren gelijk bvb de Azure SDK? Of is dat een volledig pakket geintegreerd in VS.NET?

Of mag je hierover niet praten?

[Olaf van der Spek]

Als ik Step Into gebruik tijdens debuggen, kom ik vaak terecht in functies als std::string::c_str(). Is dit automatisch te voorkomen zonder Step Into Target te gebruiken of Step Into uit te schakelen voor class/functie templates? Ik heb er in 2010 nog niks op gevonden.

[ Voor 8% gewijzigd door Olaf van der Spek op 05-07-2009 16:26 ]

[.Gertjan.]

Olaf van der Spek schreef op zondag 05 juli 2009 @ 16:25:
Als ik Step Into gebruik tijdens debuggen, kom ik vaak terecht in functies als std::string::c_str(). Is dit automatisch te voorkomen zonder Step Into Target te gebruiken of Step Into uit te schakelen voor class/functie templates? Ik heb er in 2010 nog niks op gevonden.

Ik weet niet of je er iets aan hebt, maar binnen 2008 was er volgens mij een optie waarmee je kon aangeven dat je alleen je "eigen code" wilde debuggen. Ik kan zo niet op de exacte naam komen, maar volgens mij zat hij er wel in. Je kreeg dan alleen je eigen code en libraries te zien als je step into deed.

[.oisyn]

Just My Code™, maar da's managed only

[TaraWij]

Olaf van der Spek schreef op zondag 05 juli 2009 @ 16:25:
Als ik Step Into gebruik tijdens debuggen, kom ik vaak terecht in functies als std::string::c_str(). Is dit automatisch te voorkomen zonder Step Into Target te gebruiken of Step Into uit te schakelen voor class/functie templates? Ik heb er in 2010 nog niks op gevonden.

The functionality you are requesting is a feature that is currently in the product called "Step Into Specific" and was introduced with Visual Studio 2008 SP1. When the current line has multiple method calls right click the mouse in the editor, and choose "Step Into Specific ->" from the context menu. A list will then pop out of methods that you can step into.

As for the Global exclude/include lists, this functionality can be achieved through adding a "StepOver" registry entry as detailed here: http://blogs.msdn.com/hab...sual-studio-debugger.aspx

Bron van bovenstaande quote

Werking en voorbeelden van de boven vermelde registry key

[Olaf van der Spek]

TaraWij schreef op maandag 06 juli 2009 @ 10:32:
Bron van bovenstaande quote

Werking en voorbeelden van de boven vermelde registry key

Heel toevallig had ik dat al gelezen...
Daarom vroeg ik expliciet om een andere optie:

Is dit automatisch te voorkomen zonder Step Into Target te gebruiken of Step Into uit te schakelen voor class/functie templates?

Class/functie templates worden namelijk zoveel gebruikt dat het niet handig is Step Into er totaal voor uit te schakelen.

[ Voor 8% gewijzigd door Olaf van der Spek op 06-07-2009 11:42 ]

[EfBe]

Er wordt al jaren om die optie grvraagd, maar MS' debugger team is er gewoon doof voor. Die hack die in Sp1 zat werkt wel 'aardig' maar nog steeds niet top, zoals je zelf ook al aangeeft. Ik geloof niet dat ze dit ooit nog gaan oplossen op een manier die beter werkt.

[TaraWij]

Olaf van der Spek schreef op maandag 06 juli 2009 @ 11:42:
[...]

Class/functie templates worden namelijk zoveel gebruikt dat het niet handig is Step Into er totaal voor uit te schakelen.

Volgens mij heb je die links dan niet volledig gelezen, er staat uitleg en voorbeelden in de tweede link waarmee je dus door even enkele waarden aan te maken in het register zulke specifieke dingen als c_str, de + operator en meer automatisch kan laten overslaan, hierbij functioneert Step Into dan vervolgens zoals jij het wilt. Het enigste nadeel is hier dat er geen GUI functionaliteit is, maar voor een enkele keer dat jij in het register daarvoor moet zijn is dat nu ook niet zo'n probleem.

Het kan natuurlijk zijn dat ik fout ben en het niet mogelijk is te specifieren dat je bij de + operator wel wil inspringen voor jouw eigen dingen, maar in die mate heb ik die tweede link niet gelezen, in dat geval is het inderdaad wel weer ambetant. Als dat het geval is raad ik jullie aan gezamelijk op connect.microsoft.com dat als een bug/feature in te dienen onder Visual Studio 2010, als je het hier linkt krijg je van mij ook een up-vote.

[ Voor 23% gewijzigd door TaraWij op 06-07-2009 17:06 ]

[Olaf van der Spek]

TaraWij schreef op maandag 06 juli 2009 @ 16:58:
Volgens mij heb je die links dan niet volledig gelezen, er staat uitleg en voorbeelden in de tweede link waarmee je dus door even enkele waarden aan te maken in het register zulke specifieke dingen als c_str, de + operator en meer automatisch kan laten overslaan, hierbij functioneert Step Into dan vervolgens zoals jij het wilt. Het enigste nadeel is hier dat er geen GUI functionaliteit is, maar voor een enkele keer dat jij in het register daarvoor moet zijn is dat nu ook niet zo'n probleem.

Ah, die tweede link had ik inderdaad nog niet gelezen.
Maar met een hele lijst regexen klooien lijkt me ook niet zo handig. c_str() was maar een voorbeeld, ik wil in niks van boost en std steppen eigenlijk. Behalve dan misschien een paar uitzonderingen. Mogelijk is die hack dan toch bruikbaar, ik zal er eens naar kijken.

Het kan natuurlijk zijn dat ik fout ben en het niet mogelijk is te specifieren dat je bij de + operator wel wil inspringen voor jouw eigen dingen, maar in die mate heb ik die tweede link niet gelezen, in dat geval is het inderdaad wel weer ambetant. Als dat het geval is raad ik jullie aan gezamelijk op connect.microsoft.com dat als een bug/feature in te dienen onder Visual Studio 2010, als je het hier linkt krijg je van mij ook een up-vote.

Mijn poging dus: https://connect.microsoft...ckID=469061&wa=wsignin1.0

Zo'n optie moet gewoon in de GUI zitten.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 95% gewijzigd door Ruudjah op 01-12-2009 21:52 ]

[EfBe]

Ruudjah schreef op dinsdag 07 juli 2009 @ 17:50:
Wat ik nog niet zo goed begrijp (en jammer vind) is dat ze die ribbon interface niet hebben gebruikt in de nieuwste VS telg. Je zou zeggen dat het ook op VS een waardevolle verbetering is, juist omdat je zo belachelijk veel functionaliteit in een IDE hebt tegenwoordig.

Ik denk omdat de ribbon gewoon een debiel idee is. Immers, het is niets anders dan menu items over een dikkere bar uitgesmeerd, zodat je meer screen estate kwijt bent aan dingen die ook in menus zitten. Na een tijdje de ribbon te hebben gebruikt in word snap ik werkelijk niet waarom het zo'n goed idee is, zeker gezien het feit dat het screenestate opslokt VERTIKAAL terwijl de editing richting ook vertikaal is.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 97% gewijzigd door Ruudjah op 01-12-2009 21:52 ]

[Olaf van der Spek]

Ruudjah schreef op dinsdag 07 juli 2009 @ 18:13:
Al die bars horizontaal onder elkaar slurpen meer screen estate op dan één ribbon. Vergeet niet het textuele menu hier ook bij te rekenen, dan kom je al snel op 1,5 meer hoogte.

Welke bars? Aan een of twee bars heb je toch wel genoeg? Ik gebruik geen toolbars en het menu bedien ik vooral met het toetsenbord. Je hebt wel gelijk, liefst zou ik zien dat ze het menu en de titelbalk samenvoegen ofzo.
De status bar is eigenlijk ook best nutteloos. Enige info van waarde daar is het regelnummer.

Het mooie is juist dat je alle functionaliteit op een éénduidige manier toegankelijk maakt, zonder 10x te moeten klikken in louter textuele sub-sub-submenu's. En kan zien wát je nu eigenlijk allemaal kan.

Zoveel lagen heb je toch niet? Als de menu bar laag een is, heb je maar drie lagen.

[ Voor 6% gewijzigd door Olaf van der Spek op 07-07-2009 23:00 ]

[Rhapsody]

Ruudjah schreef op dinsdag 07 juli 2009 @ 18:13:
Al die bars horizontaal onder elkaar slurpen meer screen estate op dan één ribbon. Vergeet niet het textuele menu hier ook bij te rekenen, dan kom je al snel op 1,5 meer hoogte. Als je de gehele breedte meerekent, afhankelijk van de schermresolutie, kan het inderdaad groter uitvallen (die dunne 16x16 px iconenbars stoppen ergens). Door de tabs (ribbons) kan je juist meer icoontjes/woorden uitsmeren over dezelfde ruimte als een conventionele iconenbar. Je offert hier wel één klik voor op als je niet in de juiste ribbon zit, maar dat is nog altijd meer dan het gebruik van het textuele menu, wat minimaal één klik vereist. Voor sommige functies zelfs rond de 8-10.

Het mooie is juist dat je alle functionaliteit op een éénduidige manier toegankelijk maakt, zonder 10x te moeten klikken in louter textuele sub-sub-submenu's. En kan zien wát je nu eigenlijk allemaal kan.

De ribbon is niet voor elke applicatie een verbetering. Visual Studio heeft zoveel functies, ik denk dat die simpelweg niet makkelijk in de ribbon te stoppen zijn zonder dat het extra werk kost om een bepaalde functie te gebruiken.
Iedereen heeft Visual Studio ingericht zoals hij/zij wil.

Dus ergens kan ik het wel begrijpen. Ik denk dat de ribbon niet geschikt is voor Visual Studio.

[.oisyn]

Zo, ik heb 'm net ook maar geïnstalled.
Wat me vooral opvalt is dat de C++ intellisense parser de nieuwe C++0x constructies nog niet snapt

[Phyxion]

.oisyn schreef op vrijdag 10 juli 2009 @ 17:32:
Zo, ik heb 'm net ook maar geïnstalled.
Wat me vooral opvalt is dat de C++ intellisense parser de nieuwe C++0x constructies nog niet snapt

Ach, het is nog niet final natuurlijk. Sowieso vind ik de C++ IS lang niet zo goed als die van C#. Zal in de final vast wel werken

[.oisyn]

Phyxion schreef op vrijdag 10 juli 2009 @ 19:18:
[...]

Ach, het is nog niet final natuurlijk

Oh ik heb er helemaal vertrouwen in dat dat in het eindproduct gefixed gaat zijn idd, maar vond het toch een beetje vreemd. Dan introduceer je nieuwe features, maar dan snapt de IDE die niet

Sowieso vind ik de C++ IS lang niet zo goed als die van C#

Nogal wiedes, C++ is vele malen complexer om te parsen , en is veel te ambigu als je niet exact de juiste context kent (vooral de preprocessor kan roet in het eten gooien). En die context is in elke sourcefile weer anders, ookal gebruiken ze dezelfde types. Talen als C# en Java hebben daar een stuk minder last van.

[Sebazzz]

Phyxion schreef op vrijdag 10 juli 2009 @ 19:18:
[...]
Sowieso vind ik de C++ IS lang niet zo goed als die van C#.

Je mist natuurlijk ook de XML documentation, dat scheelt wel

[Phyxion]

.oisyn schreef op vrijdag 10 juli 2009 @ 19:29:
[...]

Oh ik heb er helemaal vertrouwen in dat dat in het eindproduct gefixed gaat zijn idd, maar vond het toch een beetje vreemd. Dan introduceer je nieuwe features, maar dan snapt de IDE die niet


[...]

Nogal wiedes, C++ is vele malen complexer om te parsen , en is veel te ambigu als je niet exact de juiste context kent (vooral de preprocessor kan roet in het eten gooien). En die context is in elke sourcefile weer anders, ookal gebruiken ze dezelfde types. Talen als C# en Java hebben daar een stuk minder last van.

Uiteraard, maar je zou zeggen dat na al die jaar dat Microsoft nu aan VS aan het sleutelen is het toch wel wat beter zou kunnen zijn. Ik heb nog regelmatig dat IS gewoon helemaal niks doet (In VS2005 en VS2008), en dan na een tijdje weer tijdelijk een aantal dingen pakt en vervolgens weer helemaal niks. Je hoeft maar een klein tikfoutje te maken en het ligt hier compleet op z'n gat.

[Olaf van der Spek]

Phyxion schreef op zaterdag 11 juli 2009 @ 08:14:
Uiteraard, maar je zou zeggen dat na al die jaar dat Microsoft nu aan VS aan het sleutelen is het toch wel wat beter zou kunnen zijn.

In 2010 schijnt IS dus wel sterk verbeterd te zijn.

[.oisyn]

Hmz, block selection met alt werkt niet meer . Hopelijk blijft dat niet zo.

.edit: wheee, internal compiler error

C++:

template<class F, class P>
auto call(F && f, P && p) -> decltype(f(std::forward<P>(p)))
{
    return f(std::forward<P>(p));
}

void bar(int i)
{
}

int wmain()
{
    int i = 34;
    call(bar, i);
}

[ Voor 86% gewijzigd door .oisyn op 12-07-2009 16:38 ]

[farlane]

.oisyn schreef op zondag 12 juli 2009 @ 16:33:

C++:

template<class F, class P>
auto call(F && f, P && p) -> decltype(f(std::forward<P>(p)))
{
    return f(std::forward<P>(p));
}

void bar(int i)
{
}

int wmain()
{
    int i = 34;
    call(bar, i);
}

Tjee, ik moet me weer wat gaan verdiepen geloof ik, decltype == typeof ?

[.oisyn]

Yup, en de auto foo() -> returntype is de nieuwe functiedeclaratiesyntax, die nodig is omdat anders het returntype voor de parameters komt en je die parameters op dat moment dus nog niet kunt gebruiken in een eventuele decltype

leesvoer (da's deel 3, maar die bevat ook de linkjes naar deel 1 en 2)

[ Voor 26% gewijzigd door .oisyn op 12-07-2009 21:53 ]

[farlane]

.oisyn schreef op zondag 12 juli 2009 @ 21:24:
Yup, en de auto foo() -> returntype is de nieuwe functiedeclaratiesyntax, die nodig is omdat anders het returntype voor de parameters komt en je die parameters op dat moment dus nog niet kunt gebruiken in een eventuele decltype

leesvoer (da's deel 3, maar die bevat ook de linkjes naar deel 1 en 2)

Ah dank. Nuttig leesvoer

[Verwijderd]

weet iemand of de c++ Concurrency Runtime ook onder windows XP gaat werken of alleen vista/7? Ik kan het nergens echt expliciet vinden.

[farlane]

Verwijderd schreef op maandag 13 juli 2009 @ 14:12:
weet iemand of de c++ Concurrency Runtime ook onder windows XP gaat werken of alleen vista/7? Ik kan het nergens echt expliciet vinden.

Volgens mij is het onderdeel van de CRT, dat zou betekenen dat het ook op XP draait. Kan me eigenlijk ook niet voorstellen waarom het niet op XP zou werken eigenlijk.

[.oisyn]

Zijn er mensen hier die de laatste build van Visual Assist (1727) hebben draaien én de beta 1 van VS 2010? Is VAX bij jullie dan ook in 2010 geïntegreerd? Want bij mij is dat dus wel het geval, en de mensen van WholeTomato geloven me niet

[Phyxion]

.oisyn schreef op woensdag 15 juli 2009 @ 12:32:
Zijn er mensen hier die de laatste build van Visual Assist (1727) hebben draaien én de beta 1 van VS 2010? Is VAX bij jullie dan ook in 2010 geïntegreerd? Want bij mij is dat dus wel het geval, en de mensen van WholeTomato geloven me niet

offtopic:
Bevalt Visual Assist wat? Ik gebruik zelf ReSharper en Refactor.

[.oisyn]

.oisyn schreef op woensdag 01 juli 2009 @ 15:34:
Ik code alleen C++, dus ik heb niets aan Resharper

[Woy]

Voor C# is Resharper IMHO gewoon de tool om te gebruiken.

[.oisyn]

En voor C++ is dat Visual Assist. Het was ook altijd al C++ only (en het bestaat al sinds Visual Studio 5). Later zijn er wat .Net talen aan toegevoegd (maar volgens mij ook pas rond 2005 oid), maar voor mij blijft het een pure C++ tool. Adviesen over VA icm .Net zijn bij mij dus ook aan het verkeerde adres

[whoami]

Heeft er iemand al eens TestDriven.NET (2.22 geloof ik), aan de praat gekregen binnen VS.NET 2010 ?

Die versie zou VS.NET 2010 moeten supporteren; ik heb het geinstalleerd, ik zie het verschijnen in de AddIn manager, ik vink het aan, maar ik zie toch geen 'run tests' menuitem in het contextmenu als ik rechtsklik op een project.

[ Voor 13% gewijzigd door whoami op 17-07-2009 11:45 ]

[Sebazzz]

Woy schreef op woensdag 15 juli 2009 @ 13:13:
Voor C# is Resharper IMHO gewoon de tool om te gebruiken.

Yep, precies. Natuurlijk blijven het hulpmiddelen, je zal altijd zelf nog je variabelen en methodes goed moeten benoemen.

[Phyxion]

Sebazzz schreef op vrijdag 17 juli 2009 @ 21:57:
[...]
Yep, precies. Natuurlijk blijven het hulpmiddelen, je zal altijd zelf nog je variabelen en methodes goed moeten benoemen.

De namen wel qua wat het is maar in de laatste Resharper kan je ook al naming rules instellen, werkt best handig (camelcase ed).

[Olaf van der Spek]

.oisyn schreef op woensdag 01 juli 2009 @ 21:02:
[code=c++]// voor containers
Range-based for is gestoeld op concepts, en concepts zitten niet in VS 2010. Sterker nog, concepts vertragen heel C++0x en het is sowieso de vraag wat ze er nou mee gaan doen... (al denk ik niet dat ze het eruit gaan halen)

Het is toch exit concepts zo te lezen...

[.oisyn]

Waar lees je dat dan?

[Olaf van der Spek]

In een bericht op de Boost mailing list:

The C++ standards committee met in Frankfurt, Germany, last week. Key
actions:

* Concepts have been removed from C++0x.

The committee is very much in favor of Concepts. But Concepts are seen as so
important that they have to be right. And the strong consensus was that
getting Concepts right, for any reasonable definition of "right", would add
several years to the schedule. There was also a consensus that an
implementation of a compiler that could compile the entire standard library
is part of the definition of "right". While ConceptGCC has been a great
help, it isn't there as far as validating "right". Personally, I think Clang
may end up being the compiler that eventually validates Concepts.

* The range-based for loop and some other library features that were
dependent on Concepts will be retained by recasting them to no longer depend
on Concepts. See a paper in the upcoming post-meeting mailing to see how
range-based for loops will work.

* A second Committee Draft (CD2) will need go out for public comment in the
Spring or Summer 2010, given the amount of change required to remove
Concepts. The C++0x final schedule will thus slip about one year.

* No committee action was taken as to how Concepts will eventually make it
into C++. While there was a bit of discussion about doing a Concepts
Technical Report (TR), there was no such proposal made. Committee members
seem to lean toward letting the two rival Concept teams go back to work
outside of the committee process. The expectation being they will come back
to the committee when they are ready to restart the standardization process.
Hopefully the lessons learned about Concepts during the committee process
will be taken advantage of, so future standardization of Concepts will be
smoother.

My personal opinion is that removing Concepts will speed the arrival of
conforming C++0x compilers. GCC, for example, has already implemented much
of C++0x, so their key developers are no longer faced with the difficult
task of turning ConceptGCC into a production compiler, and can concentrate
on remaining major features like lambdas.

Although Concepts would have added a lot to C++ and Boost, Concepts would
also have presented major migration challenges. I'm thinking that for most
Boost libraries, migration to C++0x will now be easier and less disruptive.
We need to focus on the bright side.

--Beman

[.oisyn]

Jammer, maar wel de betere keuze denk ik.

[.oisyn]

Hier staat ook nog wat interessant leesvoer over het verwijderen van concepts: http://www.informit.com/g...px?g=cplusplus&seqNum=441

.edit: trouwens wel interessant, het verwijderen van concepts maakt de implementatia van range-based for ook makkelijker. Wellicht eindigt dat dan toch in VS 2010

[ Voor 36% gewijzigd door .oisyn op 22-07-2009 15:09 ]

[Cavalera125]

Ik heb even door het topic gezocht, volgens mij is het hier nog niet vermeldt. Voor zover ik heb kunnen zien biedt deze beta geen ondersteuning voor ontwikkelen voor het Windows Mobile platform! Indien je hiervoor wil ontwikkelen kun je de lange installatie van VS 2010 voorlopig aan je voorbij laten gaan. Het schijnt overigens wel in de final release te zitten, kan natuurlijk ook haast niet anders.

[Niemand_Anders]

Cavalera125 schreef op donderdag 23 juli 2009 @ 23:09:
Ik heb even door het topic gezocht, volgens mij is het hier nog niet vermeldt. Voor zover ik heb kunnen zien biedt deze beta geen ondersteuning voor ontwikkelen voor het Windows Mobile platform! Indien je hiervoor wil ontwikkelen kun je de lange installatie van VS 2010 voorlopig aan je voorbij laten gaan. Het schijnt overigens wel in de final release te zitten, kan natuurlijk ook haast niet anders.

Je kunt met beta1 wel ontwikkelen voor Windows Mobile, er is alleen geen project template. Zelf start ik het project in VS2008 en daarna open en importeer ik hem in VS2010.

De reden dat WM momenteel niet 'actief' wordt ondersteund komt omdat zij in de final release WM7 willen ondersteunen. WM7 applicaties lijken meer op WPF dan WinForms. Met WM7 komt ook Silverlight eindelijk beschikbaar voor mobieltjes. Een feature welke microsoft sinds MIX '07 elk jaar aankondigd.

Omdat Microsoft wil dat VS2010 developers straks masaal WM7 apps gaan schrijven, hebben ze momenteel de project templates voor WM6.5 eruit gelaten. Dit was overigens uitgelegd op de MIX in maart. Ik heb nog even snel gezocht naar de presentatie, maar kon hem niet zo snel vinden. Vorige week liet Scott Guthrie in Londen een zeer vroege alpha van WM7 zien met daarop Silverlight. Scott was daar voor de presentatie van Silverlight 3. Ook daar werd nogmaals benadrukt dat beta1 vooral bedoeld is om een idee te krijgen wat er veranderd is ten opzichte van VS2008 (zoals het WPF start screen).

[Olaf van der Spek]

Kan VC al meerdere cores gebruiken om een project te compileren? VC9 kan dat niet (AFAIK) en in VC10 heb ik het ook nog niet gezien.

[Verwijderd]

Olaf van der Spek schreef op zaterdag 25 juli 2009 @ 20:26:
Kan VC al meerdere cores gebruiken om een project te compileren? VC9 kan dat niet (AFAIK) en in VC10 heb ik het ook nog niet gezien.

Dit was toch wel al onder VC9 mogelijk. Met de /MP switch.

[ Voor 10% gewijzigd door Verwijderd op 26-07-2009 12:51 ]

[Olaf van der Spek]

Verwijderd schreef op zondag 26 juli 2009 @ 12:38:
[...]


Dit was toch wel al onder VC9 mogelijk. Met de /MP switch.

Ah, helaas niet echt bruikbaar:

The /Gm Compiler Option

By default, a project build enables the /Gm compiler option (incremental builds) for debug builds, and disables it for release builds. Therefore, the /MP compiler option is automatically disabled in debug builds because it conflicts with the default /Gm compiler option.

[.oisyn]

Alsof de /Gm optie zoveel boeit. Die kun je net zo goed uitzetten. Overigens zou je ook iets als Incredibuild kunnen gebruiken, dan is het nog distributed ook

[ Voor 41% gewijzigd door .oisyn op 26-07-2009 18:45 ]

[Olaf van der Spek]

.oisyn schreef op zondag 26 juli 2009 @ 18:45:
Alsof de /Gm optie zoveel boeit. Die kun je net zo goed uitzetten.

Is de performancewinst zo laag daarvan?

Overigens zou je ook iets als Incredibuil kunnen gebruiken, dan is het nog distributed ook

Hehe, leuk als je een groot LAN hebt inderdaad.

[.oisyn]

Olaf van der Spek schreef op zondag 26 juli 2009 @ 20:52:
[...]

Is de performancewinst zo laag daarvan?

In mijn ervaring wel. Zeker als het betekent dat je ipv 1 file 4 files tegelijk kunt compilen, en je er in je sourcecode voor zorgt dat je veel gebruik maakt van forward declares en dus alleen include als je een definitie echt nodig hebt, wat sowieso good practice is.

Hehe, leuk als je een groot LAN hebt inderdaad.

Het werkt echt fantastisch. Wij zijn dan niet zo'n heel groot bedrijf (12 werknemers), maar dat zijn dus al 12 quadcores, en daarnaast hebben we nog twee dedicated quadcore build machines, en een full rebuild van een game gaat terug van ongeveer 20 minuten naar iets van 2 minuten.

[Olaf van der Spek]

.oisyn schreef op zondag 26 juli 2009 @ 21:05:
In mijn ervaring wel. Zeker als het betekent dat je ipv 1 file 4 files tegelijk kunt compilen, en je er in je sourcecode voor zorgt dat je veel gebruik maakt van forward declares en dus alleen include als je een definitie echt nodig hebt, wat sowieso good practice is.

Er is geen IDE optie voor die /mp switch toch? Is er een manier om die globaal aan te zetten of moet dat voor elk project afzonderlijk?

Forward declaraties zijn inderdaad handig.

[.oisyn]

Volgens mij niet. Je kunt er evt een property sheet van maken, zodat je die gemakkelijk aan alle projects kunt adden met de property manager.

[Olaf van der Spek]

Dat is niet echt handig. Een manier om globaal crap als _CRT_NONSTDC_NO_DEPRECATE en _CRT_SECURE_NO_DEPRECATE uit te schakelen zoek ik ook nog.

[.oisyn]

Daar gebruik ik dus ook property sheets voor. Dat adden is echt simpelweg alle projects tegelijk selecten in de property manager, right click, add property sheet, en klaar.

[RobIII]

Olaf van der Spek schreef op maandag 27 juli 2009 @ 10:03:
[...]

Er is geen IDE optie voor die /mp switch toch? Is er een manier om die globaal aan te zetten of moet dat voor elk project afzonderlijk?

Even een shot in the dark; maar doet dit niet wat je wil?


[edit]
Nevermind

[ Voor 8% gewijzigd door RobIII op 27-07-2009 14:15 ]

[.oisyn]

Nee, daar staat "project builds", niet "file builds"

[RobIII]

Vandaar mijn nevermind

[jip_86]

Gisteren Scott Guthrie gehoord bij een dotNed event. Beta 2 van visual studio 2010 komt 'hopefully in a not to distant future'. Hij liet half doorschemeren dat daar gisteren een deadline/beslismoment over was.

[Snake]

jip_86 schreef op zaterdag 26 september 2009 @ 17:22:
Gisteren Scott Guthrie gehoord bij een dotNed event. Beta 2 van visual studio 2010 komt 'hopefully in a not to distant future'. Hij liet half doorschemeren dat daar gisteren een deadline/beslismoment over was.

Ik heb bij MVPs al de Beta 2 al zien draaien. Dus ik begrijp niet waarom ze 'm niet gewoon uitbrengen.

[Olaf van der Spek]

Snake schreef op zaterdag 26 september 2009 @ 18:23:
Ik heb bij MVPs al de Beta 2 al zien draaien. Dus ik begrijp niet waarom ze 'm niet gewoon uitbrengen.

Eh, pre-public testing?

[Snake]

Olaf van der Spek schreef op zaterdag 26 september 2009 @ 18:52:
[...]

Eh, pre-public testing?

Het is een Beta, dus ik zie er het nut niet van in. Laat ons toch testen? Kunnen we impesant genieten van de nieuwe features?

[jip_86]

Snake schreef op zaterdag 26 september 2009 @ 18:23:
[...]

Ik heb bij MVPs al de Beta 2 al zien draaien. Dus ik begrijp niet waarom ze 'm niet gewoon uitbrengen.

Hij had het ook over de freeze waarin alleen nog gezocht word naar fouten. Kan best dat dat die versie is.
Scott had ook dingen van ASP.NET MVC preview 2 laten zien. maar dat is een ander onderwerp.

[Olaf van der Spek]

Snake schreef op zaterdag 26 september 2009 @ 19:04:
Het is een Beta, dus ik zie er het nut niet van in. Laat ons toch testen? Kunnen we impesant genieten van de nieuwe features?

Bij grote releases (beta of niet) wil je geen blunders begaan, dus daarom kun je het beter eest releasen binnen een kleinere groep.

[beany]

En Beta 2 is uit!

http://blogs.msdn.com/jas...net-framework-beta-2.aspx

edit: volgens mij alleen voor MSDN abonnee's...
edit2: volgens Scott gaat de beta 2 open voor iedereen komende woensdag

[ Voor 36% gewijzigd door beany op 20-10-2009 10:36 ]

[.oisyn]

Woei, nullptr in C++ \o/

[Laurens-R]

Heb er via MSDN al mee kunnen spelen

Veel beter t.o.v. beta1, mooier uiterlijk (de WPF IDE heeft wederom wat veranderingen ondergaan) en niet al te onbelangrijk ook VEEEEL sneller dan beta1.

C++ ontwikkeling is nu super! Zeer goede snelle intellisense en idd leuke zaken zoals nullptr.

Het buildproces verloopt nu ook veel vlotter t.o.v. beta1. (Dat was in beta 1 bij mij soms behoorlijk wachten)

m.a.w. het is gewoon meer af.

[ Voor 30% gewijzigd door Laurens-R op 20-10-2009 11:38 ]

[MLM]

Ik kijk door de SKUs en sommige toch wel handige features (profiling, testing) ziten niet in de pro editie (welke degene is die ik gratis krijg via DreamSpark waarschijnlijk ), dus dat is wel een beetje jammer.

Gelukkig heb ik een 2008 pro + intel profiler die nog wel even mee kan

[Olaf van der Spek]

Is nullptr zo leuk / belangrijk?

[.oisyn]

Wel als je pointers wilt forwarden, omdat een 0 als argument naar een template functie gededuceerd wordt als int, en een int kun je niet doorgeven aan een functie die een pointer verwacht.

C++:

int main()
{
    std::pair<int, const char*> p1 = std::make_pair(4, NULL); // bummer
    std::pair<int, const char*> p2 = std::make_pair(4, nullptr); // woei \o/
}

Misschien een beetje een lame voorbeeld, maar het wordt vooral van belang bij r-value references die perfect forwarding zou moeten geven. Het is natuurlijk een beetje suf dat die zogenaamd perfecte forwarding alsnog niet goed gaat omdat je geen (ongetypeerde) null pointers door kan geven.

Of bij function overloads, die zowel een int als een pointer accepteren, en dat je dan NULL passt en dat dan ineens de int-versie wordt aangeroepen.

[ Voor 42% gewijzigd door .oisyn op 20-10-2009 14:18 ]

[labee]

VS 2010 beta 2 nu ook te testen voor de mensen zonder MSDN
http://www.microsoft.com/visualstudio/en-us/try/default.mspx

[OMX2000]

Is er al een VPC te vinden op de MS site?

[MTWZZ]

Ben nu bezig om TFS 2010 te installeren, straks eens even kijken of het lekker werkt

[Snake]

OMX2000 schreef op donderdag 22 oktober 2009 @ 00:38:
Is er al een VPC te vinden op de MS site?

Zelf eentje maken? Virtual PC is gratis, en Server 2008 R2 kan je van MSDN halen.

[OMX2000]

Snake schreef op donderdag 22 oktober 2009 @ 10:43:
[...]

Zelf eentje maken? Virtual PC is gratis, en Server 2008 R2 kan je van MSDN halen.

Da's waar... maar liever lui dan moe. Maar klopt ik kan er ook zelf ff eentje maken.

[.oisyn]

Goddomme

[farlane]

.oisyn schreef op vrijdag 23 oktober 2009 @ 02:20:
Goddomme

Ligt het aan mij of is dat een beetje een knullige bug?

[Alex]

Microsoft heeft aangegeven dat ze voor C++ een geheel nieuw compiler model aan het bouwen zijn. Dit model moet straks ingezet worden voor alle talen, maar C++ is het begin. De volledige MSBuild(waar C++ toch al geen gebruik van maakte) gaat op de schop. C++ vooraan in de rij. Jammer dat dit soort bugs nu optreden, maar liever nu dan na de RTM....

[Olaf van der Spek]

In VS 2010 gaat C++ toch juist ook naar MSBuild?

[.oisyn]

Alex schreef op vrijdag 23 oktober 2009 @ 09:25:
Microsoft heeft aangegeven dat ze voor C++ een geheel nieuw compiler model aan het bouwen zijn. Dit model moet straks ingezet worden voor alle talen, maar C++ is het begin.

Dit strookt in z'n geheel niet met het commentaar dat de STL developer bij MS gaf in z'n videoblog over nullptr, die juist zei dat ze niet zomaar nieuwe features konden toevoegen omdat dat impact heeft op de rest van de codebase en ze dus ontzettend moeten uitkijken voor nieuwe bugs in dingen die altijd al werkten. Als dat zo is, ga je ook niet de hele compiler opnieuw bouwen. Heb je hier een link van oid?

[Olaf van der Spek]

Ik kan me er ook niks van herinneren. Ik weet wel dat ze IntelliSense helemaal opnieuw hebben gedaan. Het zat gehacked in de compiler, nu is het eruit.

[.oisyn]

Het VCCodeModel is ook geoverhauld, maar dat is de automation interface die plugins en macro's gebruiken voor refactoring en dat soort dingen. Wellicht dat dat bedoeld wordt?

[MTWZZ]

bummer
Migreren van een Visual Source Safe database lukt niet TFS staat nu niet op http://ts01:8080/ maar op http://ts01:8080/tfs en VSSConverter snapt dat niet

[Laurens-R]

De volledige MSBuild(waar C++ toch al geen gebruik van maakte) gaat op de schop.

Niet bepaald. C++ is juist nu helemaal geintegreerd met MS Build -> ze promoten het notabena als een feature.. http://blogs.msdn.com/vcb...io-2010-ctp-released.aspx (eerste punt in de lijst).

MSBuild is er juist om voorlopig nog even te blijven!

[ Voor 7% gewijzigd door Laurens-R op 23-10-2009 21:26 ]