kjetil7

Har i dag en kommersiell onlineløsning, men det kommer til å bli for kostbart i lengden.

Derfor jobber jeg med å få på plass en onlineløsning som sender dataene mine til en Netgear ReadyNAS som jeg plasserer hos mine foreldre. Synes det blir en rimelig, fleksibel og ikke minst helautmatisk løsning.

Er det noen som har gode erfaringer med synkroniseringsløsninger som gjerne støtter FTP? Skal sjekke ut SyncBack.

Hyggelige priser fra Play for tiden. La inn bestilling på Tomb Raider Underworld og Singstar 3 i går. I dag bestilte jeg GTA IV og TopSpin 3. Alle spillene kostet 17,99

Fikk min 80 GB X25-M mandag og må si at den lever opp til alle forventningene og vel så det. Den er rett og slett helt rå!

Jeg bruker den i jobbmaskinen min (laptop). Jobber som systemutvikler og det betyr mange småfiler (typisk 200-300,000 filer kildekodetreet) og da kommer den virkelig til sin rett. Det er en helt ny verden i forhold til min gamle 250 GB Samsung. Der jeg før kunne sitte og vente flere titalls sekunder spretter ting nå rett opp. Eneste problemet nå er at CPU'en nå stadig oftere jobber for fullt. Men det tyder jo hvert fall på at jeg har fått fjernet en stor flaskehals i systemet : )

Ja jeg betalte 5500, men var verdt hver eneste krone (selv om jeg riktignok får tilbake moms + kan trekke fra på skatten : )

Anbefales på det varmeste.

Hvis Windows er platformen din kan du like godt gjøre det enkelt å bruke GDI+. Da kan du klare deg med noen få linjer kode. Det finnes massevis av dokumentasjon og eksempler for hvordan du bruker GDI+.

Et lite eksempel (hadde ikke kompilator tilgjengelig når jeg skrev dette...):

#include <gdiplus.h>
#include <memory>

int main()
{
 ULONG_PTR gdiplusToken;

 // init
 Gdiplus::GdiplusStartupInput gdiplusStartup;
 Gdiplus::GdiplusStartup(&gdiplusToken, &gdiplusStartup, NULL);

 // load bitmap
 std::auto_ptr<Gdiplus::Bitmap> bitmap(Gdiplus::Bitmap::FromFile( L"bitmap.jpg" ) );

 // do something with bitmap ...
 

 // cleanup
 Gdiplus::GdiplusShutdown(m_gdiplusToken);

}

Det er mulig med bat-script også.

Start cmd.exe med /V:ON switchen for å aktivere delayed environment expansion:

cmd /V:ON

Kjør følgende script på en en text.txt fil med ca 10 linjer:

set maxLines=4

for /f "delims= skip=3" %%i in (text.txt) do (
   if !maxLines!==0 (
     rem
   ) else (
     set /A maxLines-=1
     echo %%i
   )
 )

Linje 4-8 vil da skrives ut. Pent er det kanskje ikke, men det er mulig. Og kanskje noen har en bedre og enklere løsning?

Alt du trenger er å lagre filen med "c" extension istedenfor "cpp". Visual Studio vil da automatisk bruke C-kompilatoren hvis du ikke overstyrer det manuelt i etterkant.

For å teste det kan du prøve å kompilere følgende:

main.c

#include <string>

int main()
{
  std::string str;
}

Dette vil feile siden det blir kompilert med C-kompilatoren.

Har prøvd å rename filene til .c istedenfor .cpp , men da får jeg bare "fatal error: .pch" (et eller annet, har ikke mulighet til å se feilmeldingen akkurat nå)

Har du prøvd å legge inn #include <stdafx.h> øverst i c-fila?

Fikk prøve N95 for første gang på jobben i dag. Var bare en liten 5-minutters test, men rakk å få et solid inntrykk av telefonen. Den virket svært rask og var rett og slett rå-lekker.

Var såvidt inne i GPS-programmet, men fikk ikke GSP-mottakeren til å fungere i bygningen jeg satt (muligens mange støykilder der jeg satt).

Som sagt; fikk ikke testet den så mye og har ikke så mye fornuftig å komme med. Men det lille jeg testet var i hvert fall stort sett positivt.

Siden bedriften jeg jobber for nå har fått testeksemplarer regner jeg med at den snart vil dukke opp andre steder også! Og det er kanskje interessant i seg selv... ?

Synes du virkelig det er rart at folk uten erfaring har vanskeligheter med å forstå regular expressions? En ganske unødvendig kommentar var det uansett.

Nok om det. En god side for å lære litt om emnet: http://regular-expressions.info/

Redd du har misforstått litt. Dette har i grunn ikke så mye med kontroller og web-applikasjoner å gjøre (hvert fall ikke i utgangspunktet).

Jeg tenkte først og fremst på enterprise-systemer basert på SOA. Store kompliserte systemer med køer og workflows. Dette er jo noe av det store nye med .NET 3.0. Og det er veldig lovende, men har fortsatt mange barnesykdommer og trenger absolutt oppdateringer før det blir veldig bra.

Mange trekker nok frem WPF som det den store nyheten i .NET 3.0, men i de mer "profesjonelle kretser" er det i grunn WCF og Windows Workflow Foundation som vekker mest interesse.

Med tanke på hva Java tilbyr så er det ikke unaturlig at Microsoft ønsket at WCF og Windows Workflow Foundation kom inn under .NET Framework. Dette er funksjonalitet som Javaplatformen har vært total overlegen på i mange år nå. Først nå kommer Microsoft for alvor på banen, og det var kanskje på høy tid?

Vi (der jeg jobber) har kjørt et prosjekt som tar i bruk den nye funksjonaliteten (ikke WPF). Liker absolutt det jeg ser, men teknologien har en del barnesykdommer enda. Dessuten er du mer eller mindre avhengig av Windows Vista (MSMQ 4.0 støttes f.eks. ikke i XP eller 2003 server). Men på sikt blir dette sannsynligvis veldig, veldig bra.

Jo, .NET 3.0 er en veldig stor oppdatering og fortjener versjonsnummeret etter mitt syn. Men min spådom er at det ikke vil gå alt for lang tid før .NET 3.1 ser dagens lys ...

Du trenger også .NET Framework 2.0.

Hvorfor det egentlig? Hva gjør det og hvorfor kan ikke programmet kjøre uten det?

 

For å kjøre programmet trenger du Microsoft Windows Server 2003 (SP1), XP (SP2) eller Vista.

I likhet med efikkan tenkte jeg også på å anbefale GIMP, som tross alt ikke krever at man kjøper Windows. Futten går litt ut av ordet "Gratis" når det innebærer et krav om kjøp (et dyrt kjøp også etter min mening og sammenlignet med alternativene).

 

GIMP kan forsåvidt lastes ned i varianten GIMPshop for de som foretrekker utseendet til Photoshop. Disse fungerer både under Windows, Linux og OSX.

7949170[/snapback]

Vel, hva er definisjonen av gratis da? GIMP er heller ikke gratis siden det innebærer et krav om kjøp av datamaskin... Ja, de fleste har datamaskin. Men de fleste har Windows også.

Isolert sett er selvfølgelig Paint.NET gratis. Like gratis som GIMP. At enkelte entusiaster tydeligvis blir bitre av at et program ikke kjører på deres "sære" operativsystem som gjør den almenne brukeropplevelsen dårligere, gjør det ikke mindre gratis.

Og at programmet krever .NET Framework 2.0 betyr ganske enkelt at det var programmert med hjelp av dette rammeverket. Vet ikke om du prøver å trolle eller at det er ren uvitenhet, men imponert blir en hvert fall ikke...

(Og ja, dette er langt fra første gangen MS har gitt ut komponenter i åpen kildekode uten at det har så mye med saken å gjøre. .NET er også en åpen standard. Hvem som helst kan implementere C# og .NET Framework hvis de ønsker og har kompetansen til det. Jeg har begge standardene liggende på hardisken min, inkludert C# 3.0 som enda ikke er gitt ut av MS. Den er med andre ord ikke lukket som det feilaktig ble antydet i en post ovenfor).

Forøvrig tyder ingenting på at kameraet har autofokus. De ofisielle spesifikasjonene til Apple sier bare 2.0 MegaPixels og det er veldig sannsynlig at de hadde nevnt dette hvis kameraet hadde det. Men det er selvsagt bare velbegrunnede spekulasjoner

Multitouchscreen kan jo bli bra, men det gjenstår å se hvordan det virkelig fungerer i praksis. F.eks. om skjermen blir ripete og møkkete. Men dette er utvilsomt det mest spennende med telefonen.

Men alt i alt synes jeg ikke iPhone innfrir med tanke på prisen. Ja, den har pent design selv om jeg selv foretrekker et mer tradisjonelt design som Nokia N95.

Angående kameraet; jeg brukte min første kameratelefon (T610) et par ganger den første uken. Det var fullstendig ubrukelig! Men med K800i ble saken en helt annen. Da går det faktisk an å ta bilder som er helt brukbare. Mobilene, eller skal vi si "mobilene", kommer utvilsomt til å ta over kompaktkameraenes rolle om få år. Så vil heller de av oss som krever litt mer ha et speilrefleks i tillegg.

Slik jeg ser det gir ikke iPhone meg noe funksjonalitet som ikke f.eks. N95 gir meg (minus multitouchscreen). Dessuten kan det godt vise seg at iPhone mangler mye funksjonalitet som regnes som standard i dag (f.eks. SyncML). Og den har hverken radio eller GPS!

Synes det var mange ukritiske røster her...

Ikke har den 3G, ikke radio, den er stor, forferdelig dyr, dårlig kamera og kort batteritid.

Nokia N95 ble lansert i fjor og kommer snart med EDGE, 3G, 5 MP kamera, GPS, radio, musikkavspiller, Symbian og mye mer til en lavere pris. Dessuten har den et lekrere design (etter min mening) og tar mye mindre plass. Eneste fordelen til iPhone er hardiskstørrelsen (kan sikkert kjøpes rimelig til Nokia også) samt den store skjermen som dog gjør telefonen for stor.

Og enda har SE tid til å komme med sitt motsvar til Nokias N95.

Nei, kan ikke se at denne telefonen skal være konkurransedyktig med den prisen om nesten et år når den kommer til Europa. Noen fanboys og andre som ønsker å skille seg ut med en "Mac" kommer sikkert til å kjøpe den dog...

iPhone, nei takk!

Den riktige måten å gjøre dette på er å bruke API-funksjonen CharToOem som vist over. Det du gjør kan betraktes som et hack.

Koden fungerer fint og kompilerer i både Visual C++ og GCC. Siden det her var et C-program regner jeg med at du lagrer kildekodefilen med *.c -endelse. Du trenger heller ikke en typecast fra malloc siden dette er C, og ikke C++.

Eksempel på kompilering av CharToOem.c med GCC:

gcc -Wall CharToOem.c -o CharToOem

Output:

ansi: µ, °, Õ, ã, Ï ┼
oem:  æ, ø, å, Æ, Ø Å

Hvis det hjelper er det en tommerfingerregel som sier at du alltid skal bruke delete på objekter du bruker new på. Ellers skal du ikke bruke delete.

Det meste sagt allerede, men jeg kaster meg på anbefalingene om bruk av auto_ptr og standardbiblioteket. De er laget for å hjelpe deg. De kan dessuten brukes til å gjøre koden mer lesbar. Eks:

class foo
{
public:
   
   void take_ownership(std::auto_ptr<std::string> str);
   
   std::auto_ptr<std::string> release_ownership();
};

Ved å bruke auto_ptr på denne måten vil det ikke være tvil om at den første metoden tar eierskap og den andre gir fra seg eierskap selv uten noe dokumentasjon. Hvis du kun sendte inn en peker ville brukeren av koden vært avhengig av å lese dokumentasjonen og/eller kildekoden for å være helt sikker på hva som skjer med objektet. I mine C++ prosjekter bruker jeg alltid auto_ptr på denne måten. Unntaket er når du er avhengig av "covariant return types" som f.eks. polymorfiske copy-c'tors (Clone). Da må det dokumenteres!

Ganske sikker på at du må bruke OTA. Firmaet som jeg jobber for implementerte i hvert fall det på den måten nylig. Enkelte nyere terminaler støtter det muligens gjennom klientkode, men det vil garantert ikke fungere på de litt eldre.

Det er som nevnt tegnsettet som er feil:

#include <windows.h>
#include <stdio.h>


int main(int argc, char *argv[], char *envp[] )
{
   const char* ansi = "æ, ø, å, Æ, Ø Å";
   char* oemStr = malloc(strlen(ansi) + 1);

   printf("ansi: %s\n", ansi);
   
   CharToOemA(ansi, oemStr);
   printf("oem:  %s\n", oemStr);
   fflush(stdout);

   free(oemStr);
}

Edit: eksemplet er for Windows

Ser ut som at siden char er signed i VC++ så skaper dette problemer.

Du kan caste den til en unsigned char:

if(isspace((unsigned char)str[i]))

Konstanten du skrev inn på linje 28 er for stor for datatypen du spesifiserte.

Prøv å lage en long long eller en unsigned type som unsigned long. De fleste kompilatorer bruker også en ymse postfiks på store konstanter.

Eks.

long long myBigInt = 36245564177LL;

Du kan ikke skrive hele vector-objektet rett til fil slik du gjør (Giddion påpekte vel også dette). Grunnen er at vector inneholder interne pekere som ikke vil være gyldige neste gang du leser de inn.

Det er generelt fy fy og ris på det ene og det andre m.m. for å skrive/lese hele klasseobjekter slik du gjør.

Men du kan derimot skrive en array vector holder direkte. std::vector er den eneste containeren som elementene er garantert å ligge etterhverandre. Men det hjelper ikke hvis vectoren i seg selv holder pekere. Hvis den hadde inneholdt char hadde det vært noe annet, f.eks:

std::vector<char> myVec;
//... add some elements to myVec
output.write(&myVec[0], myVec.size() );

Koden over er helt ok.

Da kan du bruke wcstombs hvis det er ok å bruke programmets locale (se setlocale).

Hvis du er avhengig av å ikke bruke programmets locale må du ta i bruk standardbiblioteket til C++. Klassen du skal kikke på heter std::codecvt sammen med std::use_facet. Sjekk ut dokumentasjonen og eventuelt Google for mer info rundt de. De kan være litt vanskelige å forstå for et utrent øye. wcstombs vil nok i det fleste tilfeller være mer enn bra nok.

Det her kommer litt an på hvordan Unicodebokstavene er formatert. Du har kanskje hørt om UTF-8, UTF-16, UTF-32, UCS-32 osv?

Dette er forskjellige måter å formatere Unicodetegn på. UTF-8 består av bytesekvenser, UTF-16 av 2-bytesekvenser og UTF-32 er alltid 4 bytes (fordi 4 bytes er nok til å representere alle Unicodetegn).

I Unicodeverden har alle tegn en unik ID fra 0x00 til 0x10FFFF. ASCII-verdiene er de første og er dermed kompatibelt med ASCII (den er faktisk også kompatibel med Latin-1 eller ISO-8859-1 som det mer presist heter). Dette er grunnen til at UTF-8 blir identisk med ASCII. UTF-8 kan derimot ikke representere Latin1-supplementet som har verdiene 0xA0 - 0xFF med 1 byte. Disse tegnene blir representert med 2 bytes i UTF-8. Byteverdiene bestemmes ut fra en spesfisert bitdistribusjonsmodell (sjekk Google).

Så svaret er egentlig enkelt. Siden vi snakker om ASCII (som er tegnene 0x00 - 0x7F) kan du bare caste tegnene til en char hvis det er snakk om UTF-8, UTF-16, UTF-32 eller lignende (som det "alltid" er). Hvis du skal støtte Latin1 fra UTF-8 blir det litt mer komplisert (ikke veldig) siden de vil være representert med 2 bytes. Men du bør uansett ta høyde for lengre bytesekvenser hvis du jobber med UTF-8. Det finnes masse dokumentasjon om dette via Google så jeg anbefaler den veien. Men jeg svarer mer en gjerne hvis du har noen konkrete spørsmål.

Til slutt vil jeg nevne at wchar_t i Windows er UTF-16 og Linuxsystemene som regel bruker UTF-32.

Edit: glemte å nevne at hvis du leser fra en fil må du ta hensyn til byterekkefølge (eng. byte order) hvis det er noe annet enn UTF-8. Dette gjøres ved å lese BOM i begynnelsen av fila (igjen sjekk Google). UTF-8 har ikke denne problematikken siden den består av bytesekvenser.

Har heller ikke hørt om mange (ikke noen faktisk) som ønsker å bruke ASP i dag. Men ASP.NET er veldig i vinden om dagen.

Og det er forståelig etter mitt syn. Ingen tvil om at utviklerne blir *mye* mer produktive med ASP.NET kontra f.eks. tradisjonell ASP og PHP. Ikke fordi PHP er dårlig, men ASP.NET er så ufattelig mye mer enn et språk. PHP kombinert med andre teknologier kan helt sikkert være konkurransedyktige. Men ASP.NET er som sagt ikke noe språk slik som PHP, men heller en samling webutviklingsverktøy basert på .NET-platformen. Derfor kan du bruke et hvilket som helst .NET-språk, som f.eks. C#, VB.NET, Python, Perl, C++/CLI m.fl. når du utvikler med ASP.NET. Og ja; du har .NET Framework tilgjengelig...

Så det blir litt feil å sammenligne etter min mening. ASP.NET mot språket PHP blir nok litt rått parti.

#include <iostream>

// win32
#include <windows.h>
#include <tchar.h>

// glib
#include <glib.h>


// linker glib (kan også gjøres i prosjektoppsettet)
// (husk å ha libglib-2.0-0.dll tilgjengelig)
#pragma comment(lib, "glib-2.0.lib")


// vi definerer tcout for bruk med TCHAR
// (TCHAR er wchar_t når UNICODE er definert, ellers char)
#if defined(UNICODE)
   #define tcout std::wcout
#else
   #define tcout std::cout
#endif

// win32 implementasjon
void findfile_win32()
{
   WIN32_FIND_DATA fd;
   HANDLE findHandle = FindFirstFile(_T("c:\\*.*"), &fd );

   if(findHandle != INVALID_HANDLE_VALUE)
   {
       do
       {
           // du kan bruke fd til å sjekke hva slags
           // filobjekt som er funnet. eks:
           // if(fd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) { }

           tcout << fd.cFileName << std::endl;
       }
       while(FindNextFile(findHandle, &fd));
   }

   CloseHandle(findHandle);
}


// glib implementasjon
void findfile_glib()
{
   GDir* dir = g_dir_open("c:\\", 0, 0);

   if(dir)
   {
       while(const gchar* fname = g_dir_read_name(dir) )
       {
           // før du skriver ut strengen må du strengt tatt
           // konvertere den fra UTF-8.

           std::cout << fname << std::endl;
       }
   }

   g_dir_close(dir);
}


int main()
{
   findfile_win32();

   tcout << _T("\n\n----------------\n\n");

   findfile_glib();

   tcout << std::flush;
}