Posts by Duoas

Sorry I was grouchy. :$ :)

Isn't that what I suggested in #4?

Your math is off.
http://en.wikipedia.org/wiki/Determinant#Determinants_of_3-by-3_matrices

(Watch what you do with those minus signs.)

Good luck!

I actually wrote a little program to do just that not too long ago:

strip-cr.cpp

#include <algorithm>
#include <functional>
#include <iostream>
#include <iterator>
using namespace std;

#if defined(__WIN32__) || defined(_WIN32_) || defined(__WIN32) || defined(_WIN32) || defined(WIN32)
  #include <cstdio>
  #include <fcntl.h>
  void std_binary_io()
    {
    _setmode( _fileno( stdin  ), _O_BINARY );
    _setmode( _fileno( stdout ), _O_BINARY );
    _setmode( _fileno( stderr ), _O_BINARY );
    cin.sync_with_stdio();
    }
#else
  void std_binary_io() { }
#endif

int main()
  {
  std_binary_io();
  cin >> noskipws;
  remove_copy_if(
    istream_iterator <unsigned char> ( cin ),
    istream_iterator <unsigned char> (),
    ostream_iterator <unsigned char> ( cout ),
    bind2nd( equal_to <unsigned char> (), (unsigned char)'\r' )
    );
  return 0;
  }

Works on Windows or Linux. Use it as strip-cr < old.txt > new.txt Enjoy!

Almost exactly what I was going to say. Your professor is giving you a hard time for using getch()? I would be hard-pressed to find a modern 32-bit Windows compiler that doesn't support it. And only a little less hard-pressed to find an old 16-bit DOS compiler that doesn't. It may have been a Borland invention, but its popularity and availability is undisputed.

Ask your professor, if you aren't allowed to use a common function to do unbuffered input, exactly what should you use?

Is he going home and compiling your assignments on a Linux box or something?

Use CreateToolhelp32Snapshot() with the TH32CS_SNAPPROCESS flag and Process32First() and Process32Next() to get a list of processes on the system.

For each process, create another snapshot using the TH32CS_SNAPMODULE flag and the process ID. For each module ID use GetModuleFileName(), and look for the modules whose names end in ".exe".
The MSDN toolhelp documetation gives examples like how to traverese the module list.

Don't forget to use CloseHandle() on each snapshot when you are done with it.

Hope this helps.

If you read and write your files one byte at a time, endianness is not an issue.

However, bit order is always an issue. The first bit you write should be in bit position 0 of the first byte you write. The second bit goes in bit position 1, etc. The ninth bit goes in position 0 of the second byte. Etc.

I'll use that little huffman tree from the Wikipedia.

space a     e     f     h     i     m     n      
111   010   000   1101  1010  1000  0111  0010  
s     t     l     o     p     r     u     x      
1011  0110  11001 00110 10011 11000 00111 10010

Now the thing to remember here is that each code is a list of bits. Hence you have to read the above bitstreams from left-to-right, which is opposite from our usual way of looking at numbers.

For example, the 'h' is code '1101', which we can store as the number 11 --not 13. The way we are writing it here is with the lsb on the left and the msb on the right. Hence: 1 + 2 + 0 + 8 = 11 This becomes important when we start sticking more than one code next to each other. Since the order of the bits is important (not the numbers!), we must always read left-to-right, least-significant-bit to most-significant-bit.

An example: Bitsequence of a p p l e

The bitstream a..p....p....l....e.. 010100111001111001000 Separate it into bytes byte 0 . . byte 1 . …

You caught me just before I left...

It looks like the default char type is signed. So:

unsigned char 0xBF (default windows codepage for '¿', but any binary data will do)
read as --> signed char -65
expanded to --> signed int -65 (0xFFFFFFBF)
converted to --> unsigned int 4294967231

Alas. Make sure to cast to unsigned before casting to int.

Hope this helps. (...and works)

> For slow-witted reanimators: it's impossible in C and C++ to get a size of array argument by this array parameter only.

Funny how there are all kinds of C and C++ libraries to do just that sort of thing. They are most popular for debugging and finding memory leaks. A very good library is DUMA. There are others.

The thing they typically have in common is judicious allocation of memory such that any invalid access will generate a page fault --which can be intercepted and interrogated.

WW's trick likely fails for two reasons, though neither are "obvious":

3.2 C++ exceptions != OS exceptions --but it is a common Win32 compiler option to integrate SEH into C++'s exception handling (and it can be done on other platforms too)

3.1 ...because you may very well own the memory outside of the array's bounds. This can happen 1) because the mm can divy its pool (called "the heap") any way it likes, and 2) because your object is very likely data-aligned. In WW's case, it appears to be on 32-bit boundries.

> Regrettably, starting question of this thread was incorrect and inexact...

Fortunate how forums like this exist to clarify such confusions, no?

> Please, don't waste time and traffic on idle discussions...

Please, don't waste bandwith on content-free, self-aggrandizing high-mindedness. If the topic was worth closing it would have been two years ago. Or …

What exactly do you mean by "columns"? The same as in your code?

If so, perhaps it would help to stare at the cute animation over at Wikipedia: Pascal's Triangle.

You'll notice that you don't have to complete a whole row to skirt down just one "column".

Good luck!

Unfortunately, Delphi really doesn't have very good support for Unicode. Widestrings really only exist for compatabilty with OLE objects...

Lately I've been learning a lot about using Unicode in my applications (both Delphi and C++) too, and it is a big, messy world.

MSDN Unicode and Character Sets

The Delphi I18N Cookbook

CodeGear Documentation Creating International Applications

Well, that should get you started. Good luck!

You've got waaaay too many variables swimming around in there.

That said, you've managed to do all your bit-shifting without collisions.

Big output
The reason why your output file is so big is because you switched from binary to text. Go ahead and open your output in Notepad to see a giant list of digits. ("Digits", mind you, not numbers.)

Line 7: Open your output file with ios::binary.
Line 44: Don't use << --use OutFile.write() or OutFile.put() instead.

Some other notes
Line 16: Don't use while (!InFile.eof()) --it leaves you open to a possible infinite loop. Use while (InFile.good()) instead.

Packing: you have failed to heed my advice about bit-packing order. As a result your output stream is indecipherable, since the whole point of the Huffman code-tree is to produce codes with unique prefixes. If you read the codes backwards there is no guarantee against ambiguous matches --and by packing from MSB to LSB you give the decoder no way to determine where each code begins.

Missing bits: You also didn't write any leftover bits to file before closing it, as I warned you to not do. As a result the last few code(s) of your stream will be missing in the output file.

Helpful hints
Don't try to do too many things at once. Your code tries to do everything: read, pack, and write, all at once. Break it down into smaller chunks.

If you plan to do any serious programming in C++ you absolutely must have a good reference.

How did you learn about the function to begin with if it wasn't with an example or reference?

AD Check your PMs

For everyone else...

is it just a question?
or is it nothing at all?

maybe we can help
for just a little more info

:-/ :twisted:

...which is the correct solution for Linux.

On Windows, register a new window message (specific to your application) and broadcast it when your program is considering starting up.

Any existing instance should respond that it already exists. The new instance can then terminate. If there isn't any response, then there is no other instance.

There are various ways to do this involving mutexes and the like... but just sticking to a window message won't lock.

It also gives the new instance a way of communicating extra information (like files to open, or "focus yourself", etc) to the existing instance.

There isn't any good way to do this "cross-platform". Some people will suggest playing with map files, but they aren't infallable and doing it is platform-specific anyway... so you should heed twomers advice. Be sure to check through the Pre-defined C/C++ Compiler Macros pages to make sure your code will compile with different compilers and OSes.

Good luck!

[edit] All the above is according to memory --I could be wrong on some small account. There are some very good pages on the net about bullet-proof application mutexing, but I don't remember where they are ... alas.

maybe:

:twisted: (Google "haskell maybe" if you are confused.)

/me runs away

Good grief, why the plethora of new threads?

Hmm, I just replied to your last post...

Huffman only works if the tree is properly formed. If you are getting a larger output file then your tree is malformed.

You are accounting for the difference in what it takes to actually store the tree in the output, right? If you are testing on a really small input then the file could grow just because of the space necessary to store the tree...

You need to keep track of how many bits you have "output" so far. When you get eight or more, output a byte.

unsigned char bits = 0;  // the unwritten bits
int count = 0;  // the number of unwritten bits

// write_bit()
//    Write a single bit to the output stream
//
void write_bit( ostream& outs, bool bit )
  {
  // Add the latest bit into our "to-output" bits
  bits |= bit << count;

  // Track how many we have "output" so far
  if (++count < 8) return;

  // If we have "output" a whole byte, then
  // actually write it to the output stream
  outs.put( bits );

  // And reset
  bits  = 0;
  count = 0;
  }

// flush_bits()
//   Write any left-over bits --filling
//   with zeros to the even byte.
//
void flush_bits( ostream& outs )
  {
  if (count) outs.put( bits );
  bits  = 0;
  count = 0;
  }

I'm not sure how exactly you plan to avoid the STL in C++. The solution would be much nicer if you were to use it... but the above demonstrates the basics.

Notice how since we are dealing with a bit-stream, we must output bits in the same order as we get them -- meaning:

bit #   byte 1    byte 2
  1       .......@  ........
  2       ......@x  ........    These bytes are DISPLAYED
  3       .....@xx  ........    in the way that we humans
  4       ....@xxx  ........    like to read them, but what
  5       ...@xxxx  ........    is really …

Huffman codes are all variable-length --don't tack-on extra zeros (that would change the code).

Your tree should be organized top-down with branch 0 having a summed-weight <= branch 1. (Note: the tree will have a "random" balance.) The huffman code is just a list of branches taken in the path from root (MSB) to leaf (LSB).

To decode: starting at the root node, just peel one bit at a time from the input and follow that branch until you hit a leaf node, then emit the leaf's value. The next input bit will again be from the root node.

To encode is just a tad-bit trickier: for each leaf, collect all bits back to the root, then emit them in reverse order (without adding any other bits into the output stream).

For simple bit-packing and unpacking, use a bitvector (vector<bool>). You can then push and read individual bits easily enough...

Hope this helps.

You'll need an index or pointer to the last character in the string, and an index or pointer to the first character in the string, and a temporary char. Then swap values, dec( last ), inc( first ) and repeat until last <= first.

Do the same thing for each word.

Good luck!

Complain to your vendor. If their DLL is broken they are obligated to fix it.

Otherwise, read on:

For some oddball reason the C++ design doesn't think that system exceptions belong as part of the exception-handling structure. (Nevermind that every computer hardware has access interrupts, div-by-zero interrupts, etc.)

You need to either:

1. Compile using VC++ using exception extentions
2. Roll your own SEH block

If you go for number 2, a good place to start is
A Crash Course on the Depths of Win32™ Structured Exception Handling

You will also need the reference.

Good luck!

Reminds me of the grandaddy of all screensavers. Something like

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

int main()
  {
  srand( time( NULL ) );
  while (1) printf( "%*c", rand() % 15, '*' );
  return 0;
  }

(This, of course, is just the simplest possible version...)

What version of TP are you using? My TP4 wouldn't get past the 8+ letter filename.

First, you are forbidden to use reserved words as identifiers. That means unit and in are off-limits.

You must then go through and fix all the syntax errors. (Watch the ',' in your write statements, and only the last end should be followed by a '.'.)

Lastly, if you are planning to do what I think you are with that label, don't. Use a loop.

program unitconv;
uses Crt;

procedure do_a_conversion;
  var
    unit_name: string;
    inches, inches_in_feet: real;
    ...
  begin
  ...
  end;

begin
  writeln( 'Lytre''s unit converter' );
  writeln;
  repeat
    do_a_conversion;
    write( 'Would you like to do another (Y/N)? ' )
  until upcase( readkey ) <> 'Y'
end.

Hope this helps.

An exception is a way of handling runtime errors (like stack overflow or page faults). Read more here:
http://www.freepascal.org/docs-html/ref/refch14.html#x167-17400014

Enjoy!

Google "mingw sdl" and take a look through the first few links.

If you haven't already, make sure to upgrade to the latest version of MinGW (Dev-C++ comes with a pretty old one).

Good luck!

With Windows, there is no such thing as 'identical systems', alas.

Because of its age GW-BASIC has some difficulties handling the hardware/software changes that have occurred beneath it. XP's DOS emulator is actually rather weak, and is known to goof in weird spots.

A good spot to start when dealing with Windows directly is this page: Running GW-BASIC under Windows. (The whole site is actually pretty good.) The recommendation is to have your GW-BASIC programs set up to start by turning off as much as the new-fangled Windows stuff as possible, and open directly in a full-screen mode. (Of course, Vista will not play fair no matter what you do to the Windows environment.)

There is also a known bug with Compaq systems that needs to be patched. (But I don't know if this applies --it has been years since I have had to mess with a Compaq PC.) Enable Compaq PCs to Run QBASIC Programs

The other option is to run it under a good DOS emulator. (That is, not the one that comes with Windows.) I recommend DOSBox. There are others.

Good luck!

Take it one step at a time with car and cdr:

define xs (((GOOD))((NIGHT)))

car xs --> ((GOOD))
cdr xs --> ((NIGHT))

car (car xs) --> (GOOD)
cdr (car xs) --> ()

etc.

FPC will generate exceptions for them. Check FPC's documentation for runtime errors.

Good luck!

You will need to provide a default constructor. Then you can use konto in arrays and other containers.

...
#include <vector>
using namespace std;

...

class konto
{
public:
    konto( char* name = 0, int nomer = 0, double saldo = 0.0, float renta = 0.0 );
    ...
};

konto::konto( char* name, int nomer, double saldo, float renta )
{
    if (name) strcpy( this->name, name );
    else this->name[ 0 ] = '\0';
    this->nomer = nomer;
    this->saldo = saldo;
    this->renta = renta;
}

...

int main()
{
    vector <konto> konten;
    ...
}

Hope this helps.

Argh! I'm so sorry! (Recent med changes have made my brain work worse than usual...)

I forgot a couple of things:

1. force proper type comparison
2. non-ASCII characters

This will work. (I tested it to be sure!)

#include <algorithm>
#include <ciso646>
#include <functional>
#include <string>

struct UTF8_ischar
  {
  bool operator () ( unsigned char c ) const 
    {
    return (c < 0x80) or (c >= 0xC0);
    }
  };

std::size_t UTF8_length( const std::string& s )
  {
  return std::count_if( s.begin(), s.end(), UTF8_ischar() );
  }

The above is an optimized version of

std::size_t UTF8_length( const std::string& s )
  {
  return std::count_if(
           s.begin(),
           s.end(),
           std::bind2nd( std::less <unsigned char> (), 0x80 )
           )
       + std::count_if(
	   s.begin(),
           s.end(),
           std::bind2nd( std::greater_equal <unsigned char> (), 0xC0 )
           );
  }

Don't worry too much about the weird stuff. You'll learn about it soon enough. It is just C++'s way of giving the user simple lambda s.

Essentially it says "count every character that has the msb == 0 or the two msbs == 11", which are the UTF-8 prefix codes for individual character sequences [ 1 ].

Sorry again! :$
Have fun now!

Argh, I couldn't find a simple example on the web. So, without further ado:

hello.dpr

program hello;
{$apptype console}
uses greet;

var
  index: cardinal;
  name:  string;
begin
if ParamCount > 0
  then for index := 1 to ParamCount do
         Salute( ParamStr( index ) )
  else begin
       Write( 'What is your name? ' );
       ReadLn( name );
       Salute( name )
       end
end.

greet.pas

unit greet;

interface
procedure Salute( name: string );

implementation
procedure Salute;
  begin
  WriteLn( 'Hello ', name, '!' )
  end;

end.

Hope this helps. :)

[edit]
Example use: D:\prog\delphi\hello> [b]hello[/b] What is your name? [b]Johnny Five[/b] Hello Johnny Five! D:\prog\delphi\hello> [b]hello Jacob "Mary Ann"[/b] Hello Jacob! Hello Mary Ann!

Yes, it is an encoding issue. I suspect that it comes from the way your editor is saving the text file.

There are several ways to 'encode', or store, character data.

There is the old char-sized ASCII encoding, but that is limited to only 7-bit ASCII characters and any system dependant character codes above 127. Microsoft calls this "ANSI" and the exact selection of extended characters depends on your output code page. Obviously, this is not very convenient for languages using anything but straight-up Roman characters.

Then came (eventually) Unicode, which handles all language graphemes. (This doesn't mean it is complete --additions are still being made, but most industrialized nations can express their native language[s] with Unicode.)

There are several ways to store Unicode: three of which are of interest to us.

UTF-8 uses our venerable char. Only those graphemes that need more than one byte use more than one byte.

UTF-16/UCS-2 variable-width characters, like UTF-8, but where the smallest element is a 16-bit word instead of a byte. This format is considered deprecated, but it is still very much in use.

UTF-32/UCS-4 simply stores every character in a 32-bit word. This is how the GCC treats Unicode (wchar_t) values. As such, modern Linux systems in general are moving toward the exclusive use of this encoding.

So, now that you've had the lecture, on to the point: your text editor is using UTF-8, which you will recall is variable-width. I …

No, it is the same as all the files having a #define GRAPHICS To have a value: g++ -DGRAPHICS=1 --> #define GRAPHICS 1 if (GRAPHICS) will work if and only if GRAPHICS is always defined to have some value (such as 0 or 1). That is typically a wasteful way to do it though, because you add time used and space occupied for every test. It is best to stick with the #ifdef GRAPHICS so that only the code you need gets compiled into the executable.

[edit]
You can still test for different values though:

#if GRAPHICS == 1
  do_x();
#elif GRAPHICS == 2
  do_y();
#else
  do_z();
#endif

Hope this helps.

That is typically something handled by the build process.

If you want to have the #defines in every file, you can specify the flag, or not, in your Makefile(s).

Here's an example makefile that builds a program "foo" from the following files:
foo.cpp
baz.h
baz.cpp
quux.h
quux.cpp

If compiling on Windows, it will automatically #define GRAPHICS for every source file and link the executable with the Windows GDI library.

#----------------------------------------
# Common stuff
#
CC     = g++
CFLAGS = -Wall
LFLAGS = 

#----------------------------------------
# Windows-specific nonsense
#
Windows = $(if $(COMSPEC)$(ComSpec),1,)

ifeq ($(Windows),1)
CFLAGS = $(CFLAGS) -DGRAPHICS
LFLAGS = $(LFLAGS) -lgdi32
endif

#----------------------------------------
# Main target rule
#
foo: foo.o baz.o quux.o
	$(CC) -o foo $^ $(LFLAGS)

#----------------------------------------
# Individual object files rule
#
%.o: %.cpp %.h
	$(CC) $(CFLAGS) -c $<

Another common option is to have a file (often named something like "machine.cpp") for each type of architecture that actually implements the OS-dependant code, and a common "machine.h" file which prototypes the routines implemented by the machine files. That way your program can use the machine.h API to do OS-dependant stuff. And again, the build system will compile and link with the appropriate version of the "machine.cpp" file.

Hope this helps get you going.

> can you elaborate on why your code is more efficient?
Sorry, my wording tripped you up. What I meant by that is that my code is not efficient, but it is descriptive.

> and can you tell me why you choose to use %1d at line 22
You want to see binary bit patterns, right? "00", "01", "10", and "11"? Neither printf() nor cout can print binary. What you would get is "00", "01", "02", and "03". So I just explicitly specify that I want to print one digit at a time.

You cannot avoid shifting once for each bit you want to display. That's eight shifts per byte. Fortunately, the overhead is very small for that. Here is the most efficient way you can get your output (without dropping down to x86 assembly):

#include <stdio.h>

char* to_binary( unsigned value, char* s, unsigned digitcount )
  {
  s[ digitcount ] = '\0';
  for (; digitcount > 0; value >>= 1)
    s[ --digitcount ] = (value &1) ? '1' : '0';
  return s;
  }

void print_bit_array( unsigned char bytes[], unsigned count )
  {
  unsigned byte_index;
  char     s[ 9 ];

  for (byte_index = 0; byte_index < count; byte_index++)
    {
    to_binary( bytes[ byte_index ], s, 8 );
    printf( "%s%.4s-%.4s", byte_index ? " " : "", s, s+4 );
    }
  }

int main()
  {
  unsigned char bits[] = { 0xAF, 0x57, 0x3C };
  /* bits = 1010-1111 0101-0111 0011-1100 */
  /* again, the bytes are ordered here MSB to …

In terms of how we humans view it, bits are treated the same way as we do any other number: most significant to least significant: 1010 binary Which reads as, left to right,
{1}\times{2^3} + {0}\times{2^2} + {1}\times{2^1} + {0}\times{2^0}

The shift operations assume this point of view. Hence, shift-left is "the same" as multiply by two, and shift-right is "the same" as divide by two. (There are some differences when it comes to overflow and storage, but ignore that for now.)

So 1010 binary << 2 becomes 101000 binary .
And 1010 binary >> 2 becomes 10 binary .

Now, the convenient thing is this multiply/divide relationship. Use a divide and a modulo to get every two digits out of every byte of the array:

#include <stdio.h>

int main()
  {
  unsigned char bits[] = { 0xAF, 0x57, 0x3C };
  /* bits = 10 10 11 11 01 01 01 11 00 11 11 00 */
  /* the bytes are ordered here MSB to LSB */

  int byte_index, pair_index, bit_index;
  unsigned char twobits;

  /* for every byte (MSB to LSB): */
  for (byte_index = 0; byte_index < 3; byte_index++)
    {
    /* for every bitpair (MS pair to LS pair) */
    for (pair_index = 3; pair_index >= 0; pair_index--)
      {
      /* get the two bits of interest */
      twobits = (bits[ byte_index ] >> (pair_index *2)) & 0x03;
      /* print them (msb to lsb) */
      for (bit_index = 1; bit_index >= 0; bit_index--)
        printf( "%1d", …

Its full path is given as the first command-line argument. So you will want to add code to check to see if an mp3 file was supplied and autoplay it. How exactly you do it is up to you, but I recommend you read the documentation for TApplication.Initialize.

The following is an example, assuming you have an object named 'MyPlayer' with a method 'PlayFile', etc.

if ParamCount > 0
  then MyPlayer.PlayFile( ParamStr( 1 ) );

Hope this helps.

You do know that this is a year-old thread in a C++ forum?

If you want to contribute, please use C++ (for those who don't understand PHP), and please don't repeat information already presented.

For C++, I usually just forget the c-string stuff:

#include <ciso646>    // operator synonyms
#include <iostream>
#include <limits>     // numeric_limits
#include <string>
#include <vector>
#include <windows.h>  // to play with the console (system() is evil)
using namespace std;

void easteregg()
{
    ...
}

int main( int argc, char** argv )
{
    vector <string> args( argv, argv+argc );

    if ((args.size() > 1) and (args[ 1 ] == "/e")) easteregg();

    SetConsoleTitle( "I am lost" );
    SetConsoleTextAttribute( 0xF0 );
    cout << "\a";
    cout << string( 9, '\n' );
    ...

    cout << "Press ENTER to continue...";
    cin.ignore( numeric_limits <streamsize> ::max(), '\n' );

    return 0;
}

Enjoy!

> Maybe even scan the image and set the region pixel by pixel, so we will have a long list of vectorial "lines".
That is actually non-trivial to implement. But there do exist algorithms to do it. I have never had the need (or desire) to try it, so I can't really point you anywhere useful other than Google. (Sorry.)

For simple bitmapped buttons, I will often just use a TImage and the transparent color of the bitmap. If hit-testing is required, the OnMouseDown event can be used to see whether pixel[ X, Y ] is the transparent color or not. That really is the simplest way to do it.

Good luck! :)

You aren't talking about sofic shifts, are you? If so, how are you representing your graphs?

I think I understand. You want the actual button itself to have the same shape as the polygon?

You'll have to create a region and assign it to your button.
See the MS Regions documentation.
It isn't particularly hard or even complex, but the trick is knowing how to create the region to begin with.

A GIF or other image is a raster-format: a bunch of lines of pixels.
A region is a vector-format: a list of points that connect lines.

So the trick will be knowing what list of points to use to create the region for each image. You will probably have to spend some time with an image editor to draw lines as an outline around your image and take note of the pixel coordinates of each end of a line. Don't save the changes to the image, but take that list of points and use it to create the regions for each button.

Sorry there isn't a simpler way to do this. The only two options are to have a square button that ignores clicks outside a specific area, or to reshape the button with a region.

Hmm, of course, you could just forget the buttons and use a TPaintBox on the form. Draw all your 'buttons' in the paint box, and when the user gives an OnMouseDown on the form decide whether or not the X,Y coordinate is in any one of the …

I would suspect all that debug code in the VC++ options, and it doesn't look like you have many optimizations enabled either...

Go to your project options and disable debug info and enable all the optimizations you can, and see if that doesn't make a difference.

(I still can't get VC++ to install on my machine... so I can't help more... I just updated to SP3 so maybe I'll get that pesky .NET 3 to work now.)

Good luck!

Take a look in the documentation for the TCanvas.Pixels property. (Your button has a canvas). Also look at the OnMouseDown event.

That depends entirely on the OS and the compiler vendor.

I'm pretty sure that old Turbo Pascals will properly crash if you try to overflow the heap. Delphi will raise an exception. For other vendors, particularly on OSes other than Windows, your results may vary.

Hope this helps.

BTW, please don't shout.

Nice start.

The main cause of problems is one of types on lines 14 and 15 in main().

A template type is an incomplete type. It cannot be instantiated into an actual variable type without further information: the template arguments.

Hence, you cannot declare a variable as vector <T> v; , since T is not a valid type. You must decide what type you wish to use. Since you are reading ints from the user (as per line 19) you might as well have a vector of them. Get rid of line 14 and change line 15 to read vector <int> v; If you try compiling again you'll notice that your list of errors has shortened considerably. :)

Next, line 57 (swapValues()) does not declare a template function. So two things are wrong with it: 1) it does not satisfy the prototype on lines 9 and 10, and 2) the compiler will barf on the unknown type T. Fix it by adding the line template <class T> in front of the swapValues() definition.

There is one other thing you need to notice. Line 46 assumes that T is an alias for int when you declare your indexOfMax variable. That's bad. What if it were string? or bool? Change it to T max = v[startIndex]; int indexOfMax = startIndex; Hmm, I think that's it. I hope I got the line numbering right...
Have fun!

Empty files will never do anything except exist. ("Existing is basically all I do!" --Fry)

It also sounds like there is something misconfigured with your Code::Blocks IDE. Have you been able to compile other projects? Are you using a compiler other than MinGW?

If no to one or both of those:

1. From the main menu select Settings|Compiler and debugger...
2. Make sure your Selected compiler is the compiler you plan to use.
   Mine is the "GNU GCC Compiler" option.
3. Click the Toolchain executables tab.
4. Make sure the Compiler's installation directory is correct.
   I keep my MinGW in C:\Program Files\MinGW , but most users will have it in the default installation path: C:\MinGW If you are using another compiler, for example, CodeGear Turbo C++ Explorer, make sure you've got its installation directory listed C:\Program Files\Borland\BDS\4.0
5. In the Program Files tab, make sure each item correctly identifies the executable. Mine uses all the default stuff for GCC:

   C Compiler:			mingw32-gcc.exe
   C++ Compiler:			mingw32-g++.exe
   Linker for dynamic libs:	mingw32-g++.exe
   Linker for static libs:		ar.exe
   Debugger:			gdb.exe
   Resource compiler:		windres.exe
   Make program:			mingw32-make.exe

   Again, if you are using something different, make sure you've got the correct executables. For TC++Explorer you'll want to make sure you've got something like:

   C++ Compiler:			bcc32.exe
   Linker for static libs:		ilink32.exe
   Resource compiler:		brcc32.exe
   Make program:			make.exe

   Et cetera.
   If you aren't using the GCC you'll also want to make sure you've got the proper global variables set up. See here for more.

…

Wait... this is marked as solved?

Console programs can have any and all of the same resources as Window GUI programs, but they typically aren't built with them. On Windows, EXE, DLL, OBJ, and a few other files are all the PE32 file format.

For MinGW users in general, you need to create an RC file, like:

MAINICON ICON "foo.ico"

Then use windres to compile it to a linkable object file: C:\prog\foo> windres fooicon.rc fooicon.o When you compile, just link it into the exe as usual: C:\prog\foo> g++ foo.cpp fooicon.o For Code::Blocks users, you only need to go so far as to create the RC file and add it to your project. The IDE can handle compiling it correctly.

Have fun!

If I understand you correctly, you need to look in your documentation at SetWindowPos() for the SWP_FOO flags.

Hope this helps.