[Putty client]

cygwin + ssh = win

[MyspaceJuke Myspace Music Downloader!]

Disclaimer: First part of the post on the previous page, or here

C++ is very strict with syntax while assembly is not... So type casting must be used frequently, And I'm fine with that. But I like being able to relax with ASM and just deal with DWORDS! :)

I don't see what this has to do with the subject, but ok, I will answer.

C++, and C alike, is extremely lax when it comes to syntax. Way more than assembly. You obviously have no idea how many implicit conversions your compiler does for you, without even warning you. And yes, sometimes you have to do an explicit conversion, but in no way is this a very cumbersome task.

Standard conversions are used for integral promotions (e.g., enum to int), integral conversions (e.g., int to unsigned int), floating point conversions (e.g., float to double), floating-integral conversions (e.g., int to float), arithmetic conversions (e.g., converting operands to the type of the widest operand before evaluation), pointer conversions (e.g., derived class pointer to base class pointer), reference conversions (e.g., derived class reference to base class reference), and pointer-to-member conversions.

And I suppose that you do casts like:

foo = (bar *) foobar;

In which case I suggest you pick up a copy of the new C++ standard, and read up about the C++ cast operators. Because, yes, again: if you are using the line above, you are using old C-style coding. Not C++. I suggest you read up about static_cast, const_cast, dynamic_cast, and reinterpret_cast.

I guess it just depends on if you like manually handling memory allocation for your strings yourself...

Manually allocating strings is stupid. It's the best way to get a buffer overflow. It's the best way to start writing over your own variables, or worse yet, write on memory that the running user owns, and you start corrupting the data allocated to other programs. char* is archaic, and should not be used in C++.

I am starting to see the goodness of using std::string though, and I will definitely start using that instead of char*

You don't have to, but if you don't, don't use C++.

the header files to put classes and functions in, I will (for the most part) stop putting functions and classes in header files, only because of the "inline" issue which you mentioned, that's something I wasn't aware of thanks for letting me know that...

Also I won't ever put a ton of shit in a few files... But I also wont put a little code in a million files! I'll find somewhere in the middle and stay there ;)

Small example:

Nokia-N810-23-14:~# ls /root/liqbase_www_jpeg/

APP_VER_BUILD liqbook.c liqgraffiti.c mk_micro.c

APP_VER_MAJOR liqbook.h liqgraffiti.o mk_style.c

APP_VER_MINOR liqbook.o liqgraffiti_details.c mk_style.o

COPYING liqbookprogress.c liqimage.c mkfileselect.c

Maemo.org.jpg liqbookprogress.o liqimage.h mkfileselect.o

Makefile liqbrain liqimage.o mkproject.c

NCI_bacon_alpha_small.png liqbrain.c liqkeyboard.c mkproject.o

NCI_bacon_small.png liqcamera.c liqkeyboard.o mkrun.sh

NCI_bacon_tiny.png liqcamera.h liqmenu.c mkrun.sh_inner.sh

berlin-map-metro-big.png liqcamera.o liqmenu.o mksketch.c

cancel.png liqcanvas.c liqreader.c mksketch.o

car.jpg liqcanvas.h liqreader.o n810.jpg

catshower.jpg liqcanvas.o liqreader_readme.txt ok.png

data liqcanvas_xv.c liqscroll.c plane.png

debian liqcanvas_xv.o liqscroll.o pybook

description liqcliprect.c liqspeedtest.c q.c

dictnode.c liqcliprect.h liqspeedtest.o q.h

dictnode.h liqcliprect.o liqstars.c q.o

errs.txt liqdialog.c liqstars.h qcard.c

filebuf.c liqdialog.h liqstars.o qcard.h

filebuf.h liqdialog.o liqtextbuffer.c qcard.o

filebuf.o liqdoc.c liqtextbuffer.h qcell.c

kcup.sh liqdoc.h liqtextbuffer.o qcell.h

killbadapps.sh liqdoc.o liqtile.c qcell.o

liq_xsurface.c liqdraw.c liqtile.h qfontlibrary.c

liq_xsurface.h liqdraw.h liqtile.o qfontlibrary.h

liq_xsurface.o liqdraw.o liqtile_easyrun.c qfontlibrary.o

liq_xsurface_stable.c liqdrawframe.c liqtile_easyrun.o qstyle.c

liqapp.c liqdrawframe.h liqui2.c qstyle.h

liqapp.h liqdrawframe.o liqui2.o qstyle.o

liqapp.o liqed.c liquidesign.c qstylelibrary.c

liqart.c liqed.o liquidesign.o qstylelibrary.h

liqart.o liqed_rotate.c liqwww.c qstylelibrary.o

liqart2.c liqfloat.c liqwww.o qtile.c

liqart2.o liqfloat.o liqx.c qtile.h

liqbase liqfloatgallery.c lucon.ttf qtile.o

liqbase-example.txt liqfloatgallery.o makefile-orig qtilemedia.c

liqbase.c liqfloatpic.c marble_800_480.jpg qtilemedia.h

liqbase.o liqfloatpic.o marble_dark_200_120.jpg rounded.png

liqbase_bookhistory.dat liqfont.c marble_dark_400_240.jpg sun.png

liqbase_readme.txt liqfont.h marble_dark_800_480.jpg yuv.png

liqbase_run.sh liqfont.o mk_core.c

liqbirds.c liqgame.c mk_core.h

liqbirds.o liqgame.o mk_core.o

Nokia-N810-23-14:~#

Do you honestly believe this would be manageable if it wasn't very strictly categorised? And this is a tiny project.

As for picking up C++? Try to remake the project as a straight C project, naming the files .c instead of .cpp I really doubt it will compile without modifications. That's how I know its C++!

I don't need to prove to myself that it's not C++. I know that much. It might be something that you like to call C++, but it definitely isn't C++. In C++, like TomB said, you'd have inheritance, polymorphism, abstraction, and data encapsulation. You don't provide a whole lot of those. Don't mentally masturbate yourself into thinking you're writing awesome C++ code. It's just bastardised rubbish code.

std::string I'm starting to like it!

It's an awesome class and is really an excellent way to go, it does solve a huge number of problems that C should never have brought upon us in the first place.

[MyspaceJuke Myspace Music Downloader!]

Disclaimer: Had to cut the post in two, too many quotes

I advertise it as C++, because I never started with C... I went str8 to C++. Even thought they are similar, they are different still...

The problem is, it's not real C++. Is it? You can't say you use a certain language, but use everything that defines another language. That's what I'm trying to say when I say "pick one and stick with it". This project doesn't need C++. Regular C would have been more than enough.

Object Oriented Programming? I don't think you've looked at the code enough... Well my Winsock CLASSES are in there in EasySockets.h and in my code I create xClient objects... I can create a client object or a server object and use them...

In this app I only need to use the client object... Maybe you missed the parts which contained this line?

Maybe you haven't read my answer enough. I said I hadn't looked at your code. I said I was making wild assumptions. But one class in a whole project is hardly OOP. Really. I didn't miss anything.

xClient* cli = new xClient;

that creates a new xClient object, and also a pointer to it...

then it can be used like so:

cli->ConnectToServer("hak5.org", 80);
sendx(cli->serversock, buffertosend, sendbuffersize);
recvx(cli->serversock, recvbuffer, numberofbytestorecieve);

//if done close connection or do more sending and receiving first
cli->Close();

//clean up
delete cli;

Excepted this isn't Object Oriented Programming. You're just using it as a struct to hold a bit of data. If you honestly believe this is OOP, you're way off. Sorry to have to be the one to break it to you.[1]

I created the xClient + xServer classes as I started using winsock in a lot of my apps, and I disliked repeatedly having the same code everywhere. I mean that's why we create functions right? Make functions which do all the dirty work, then you can just call them. Which in turn makes your code look more neat. So I created a simple class for client and server communication which works very well ;)

Bla bla bla, you reinvented the wheel, good for you. There's just one problem. You say "I dislike having the same code everywhere". But you still do. You still copy those same sources around to all your projects. You still have the same code in a shitload of places. And no, we don't create functions which do all the dirty work. We create functions, member functions, methods, or whatever you want to call them because some action is redundant. If it happens once, you don't create a function. If it happens twice, you consider it. The third time, you create the function. Code is about structure. Not about hiding stuff.

Well your not always going to be allocating memory for an 'object'. I always use new for creating class objects, but for raw memory, where a buffer will be, or some other kind of data which is just data and does not include functions, Allocating memory is allocating memory. How you do it shouldn't matter, as long as the memory is allocated I don't see a problem with it... That being said as long as your not allocating the memory on the STACK, your fine... As stack memory is limited and shouldn't be used for large buffers...

I think you're just talking bull right there. I think everything we talk about, you google it up and find something to answer. You don't have to do that.

How you allocate memory doesn't matter? Does it fuck! new/delete are what give C++ the concept of objects. Without those the whole language wouldn't exist. And yes, you can implement basic OO features into a C project, but the reason people adopt C++, is that it already has everything. You don't need to reinvent the wheel.

The reason C was such an amazing hit, was that before C, most languages did memory management. They had garbage collectors, they'd do everything. But they wouldn't allow you to fiddle with the memory directly. Then C came around, and said "hey, I'll do your memory allocation, but you can still play with my privates if you want to". And that was that. Going against how a given language handles memory allocation is like going against everything it is good for, because in essence, that's what it comes down to. We don't care about the syntax. But the way it plays with our variables? That's still what is bloody important.

So like I said, pick one, and stick with it. You took C++ because it sounded nice, and because everyone was talking about it, but you're not using half what it's good for. You'll have to make a decision at some point, you can't keep bastardising both languages.

as for the char*

yes char* is a pointer to a single character, but there isn't a way to make something point to many characters at once... and it wouldn't make sense either...

What I mean is, even though its a pointer to 1 character, what comes after it? usually another character, and another and another, until a NULL terminating character is reached. null terminator is binary 0

Now this was epic. What the fuck are you on about? Nothing comes behind a char*. A char* contains the address to a spot of memory that supposedly contains one single char. It is only by convention that we accept other characters behind that one, and that we keep reading them until we encounter 0-valued char. Stop trying to bullshit your way out of this. We don't give a rat's ass about the "NULL is binary 0". Of course it is. Has this become "name the greatest obviousnesses ?" NULL is hex 0. NULL is octal 0. NULL doesn't exist in Klingon.

<snip random BS>

So you see what I'm getting at?

No.

(Continued on the following page)

[1]: But don't worry, you're not really an idiot. You were just taught the wrong stuff. Or you didn't bother understanding what you were being taught, but in any case, a lot of developers think they understand OOP, when really, they're just being cocky and are completely oblivious to the whole package. "Sticking feathers up your butt does not make you a chicken".

[MyspaceJuke Myspace Music Downloader!]

In C++, new and delete is used. Do not use malloc() or free() unless you know what you are doing, and if you do, do not mix malloc()/free() with new/delete.

The reason behind this, is that simply put, new/delete call the constructors/destructors of an object. malloc()/free() won't. Indeed, you can use new to allocate raw memory, but this is not its main usage. Use one, and stick with it. Want to keep using malloc/free? Go back to C.

From what I can see, you're just coding C, so don't advertise it like C++. I don't see classes, I don't see any heritage, I don't see any kind of OO programming.

In C++, we don't use char *. char* is a pointer to a char. char* to string literal is deprecated in C++. See ISO 14882:2003 Annex C Subclause _lex.string. Use char const* to point at the first character of a string literal. Use std::string::c_str() to get a char const* to a c string from std::string. For old C functions that accept char* and promise not to alter the string, you may use const_cast.

The reason why people actually use a different file for headers and code, is that they're two distinct things. I haven't looked at your code, so I'm just assuming a few things, but this is what you should know:

It is "ok" to put member functions of an object in the header if it is a one liner (e.g: int getX() { return x; }). It is not OK to put whole functions in the header file. Yes "it works", but it's wrong.

Want an argument about that? Sure:

The first reason one could use, is that it's just easier to maintain. Having correctly organised files is a huge time-saver, and allows for anyone new to the project to get a sense of direction fairly quickly. Having a ton of different shit in a few files is the best way to confuse the shit out of everyone.

The second point is the whole inline mess.

If you declare a function in a header, it must be inline. In any case, then it will appear in every .o that includes the header. Marked inline won't give collisions because it will be put in a special 'link once' section. The implication is thus: longer compile times and link times, more diskspace etc etc... You should only inline functions that are small and need it for run time speed.

You may feel these are little cons, but trust me, it's poor practise, and poor coding style. You'll get slammed for it if you do something like that at work or in any kind of official (read collaborative) coding project.

I think as a whole, you should probably try to pick up C++ as a language; cuz you're just coding C. None of what I've seen is C++. Oh yeah. You use std::string. At least you don't abuse using namespaces.