Bjarke Dahl Ebert wrote:
> Hvor store programmer er der her tale om?
Jeg har hørt om adskillige projekter med 300-500 forms og lige så mange
units.
> På mit arbejde har vi haft mange projekter i BCB - mest klient-GUI
> programmer som skal kommunikere med vores diverse serveresoftware udviklet
> med MSVC.
> Til klienterne har vi i tidens løb brugt både BCB3, BCB4 og BCB5. (Jeg ved
> ikke om vi har prøvet BCB6). Alle versionerne har fungeret lige ustabilt -
> det virker som om det er det samme crap under motorhjelmen, men med ny lak
> og mere krom hver gang - men vi hænger stadig fast i dem, da det ellers
> ville kræve en ret stor kodeportering til et andet GUI-toolkit.
Det er rigtigt at BCB til tider kan være lidt ustabil. Det er dog ikke
noget jeg ser som et stort problem. For mit vedkommende er Windows mere
ustabil.
> Når vi søger på nettet efter de mange fejl vi observerer, kan vi se at vi
> absolut ikke er ene om at BCB fungerer dårligt.
>
> Her er nogle af de mange problemer vi oplever:
>
> * Når projektet får for mange filer eller for mange settings, så virker
> skidtet ikke fordi IDE'en kalder visse kommandolinietools, der åbenbart har
> begrænset linielængde (1024 tegn, tror jeg). Ved at shuffle lidt rundt på de
> forskellige options, kan man sommetider få det til at virke alligevel. Måske
> fordi de ting der så ryger ud over kanten på kommandolinien nok ikke var så
> vigtige alligevel
Det problem har jeg ikke hørt om før. Men det er et kendt at linkeren
har problemer når tds-filen bliver for stor.
> * Et fil- eller directorynavn i projektet kan sjovt nok ikke indeholde et
> "-", da IDE'en kalder visse kommandolinietools der misfortolker disse som
> kommandolinie-options!
Det er rigtigt. Du får en fejl hvis du forsøger at gemme med et filnavn,
der indeholder '-'. En af grundende er at den ikke kan lave en korrekt
header guard.
> * Ofte tilføjes absolutte stier til projektet, uden at man har bedt om det.
> Det bevirker at eksporterede "Borland Make" filer ikke virker på andre
> maskiner (fx en dedikeret build-maskine). Faktisk fejler "make" bare uden at
> indikere hvad fejlen er (man må selv gætte at det er de absolutte stier) -
> tror du lige det tog os lang tid at finde ud af? Så det er blevet fast
> rutine lige at gå ind og slette disse stier før man eksporterer make-filer
Folk plejer ellers at brokke sig over det modsatte. BCB plejer at lave
alt om til relative stier. Men det er rettet i version 6.
> * Undertiden er man nødt til at vælge "Disable inline expansion" - for
> ellers crasher den producerede .exe fil. Dette er observeret i mange
> forskellige projekter, og er således ikke bare en fejl i vores program.
Jeg kan ikke finde dette rapporteret noget sted. Jeg kunne godt tænke
mig et lille eksempel der viser fejlen.
> * Der er en eller anden lille øvre grænse på antallet af virtuelle metoder
> i en klasse. Omkring 64 vil jeg tro (den grænse har vi mødt i et realistisk
> projekt). Jeg mener at det var linkeren, der så går kold.
Jeg kan ikke finde dette dokumenteret noget sted. Jeg har lige prøvet at
lave en klasse med 200 virtuelle funktioner. Det kunne compiles og
linkes uden problemer både med BCB5 og BCB6.
> * Man kan ikke gemme flere forskellige konfigurationer af builds i
> projektfilen (fx. Release og Debug mode er oplagt). Kun én ad gangen. Ellers
> må man gemme flere projektfiler, men det betyder jo at rettelser skal
> foretages i dem alle sammen.
Det er rigtigt. Det er dog ikke noget jeg ser som et problem.
> * Hvis man retter i MyProject.cpp (i USEUNIT linierne) og fx skriver
> "FooBar/baz", så vil den hver gang man har skrevet ét tegn, i sin visdom
> mene at det nok er endnu et directory der skal tilføjes til include-stien.
> Så den bliver F:Fo:Foo:FooB:FooBa:FooBar osv.
For mig i BCB5 bliver stien først tilføjet til include-stien når jeg
gemmer. I BCB6 bliver den slet ikke tilføjet, hvilket jeg heller ikke
ser nogen grund til. Det er for øvrigt slet ikke meningen at man skal
redigere i disse linier.
> Næh, den gode gamle Borland C++ 5.02 (ikke Builder) fra 1995 eller sådan
> noget, er efter min mening Borlands hidtil bedste compiler og IDE - især
> hvis man ikke skal lave GUI.
Den har jeg ikke brugt ret meget. Jeg kan rent faktisk bedre lide
Builder, men det er nok efter hvad man er vandt til.
> Hvorfor skrottede de dog den?
Det kaldes udvikling. Microsoft har også langt om længe skrottet MFC.
> Er der egentlig ikke noget med at den er blevet gratis?
Nej, det er compileren fra BCB5 der er gratis.
> Eneste problem er nok at C++ har udviklet sig noget siden da. Det har fx
> fået en standard, for lige at nævne en enkelt lille detalje
Er det et problem?
> Ikke at jeg ynder at reklamere for M$, men MSVC6.0 er altså en drøm i
> sammenligning med BCB. Den har sine småskavanker/"uhensigtsmæssigheder", som
> man kan blive lidt irriteret over, men ikke noget væsentligt.
VC6 er kendt for at have den absolut dårligste compiler. Er det ikke
væsentligt? (Jeg ved godt er den er forbedret en del i version 7)
> Den er langt den mest anvendte C++-compiler til Win32 (den har vel næsten
> monopol), og er derfor selvfølgelig ret "moden".
Så man skal bruge Microsofts compiler fordi det er den mest anvendte?
Underlig tankegang. Det minder mig er lemminger. Bare følg med flokken.
Jeg ved ikke hvad du mener med "moden", men Microsoft har altid være
bagefter med hensyn til deres compiler.
Ivan Johansen