dev-cpp-users — Dev-C++ users discussion list

Re: [Dev-C++] about replies

[<or...@vp...>]

Mats Lidstrom wrote:
> The purpose of a mailing list is that everybody else can gain from the
> input. The thing that irritates me with this list is that when I click
> "reply" it defaults to the person instead of the list.

I completely agree.
If anyone here doesn't want his/her mailbox full of mails, then get off=20
this list. THAT's the best solution.

For that reply thing: a "Reply To:" field, with=20
"dev...@li..." would be REALLY useful.
Any of the "moderators" listening?

--
Greets,
   Bal=E1zs

[Dev-C++] other programs through our program...

[Siva C. <siv...@ya...>]

hello,

this is might be an easy one(and could be out of
place!)...

How do we run the standard windows programs through
our application. for example clicking the help menu
starts the IE!!

TIA

Siva Chandra

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

RE: [Dev-C++] Re: Design decision in C++

[P.D. v. Z. <pd...@xs...>]

Eek!
You still seem to be having a bad implementation of Singleton. My Singleton
classes are derived from a Singleton utility class template as well, but I
have none of that ugliness in my code. I do need a different bit of ugly
though, a friend declaration, but that seems a lot better than pointer
offsets and the like.
The only extra thing I need to do in the derived classes is declare my
constructor, destructor, copy constructor and assignment operator as
something non-public (along with not implementing the copy constructor and
assignment operator, to catch attempted accidental copying).

Regards,


Paul

P.S.: I didn't actually write the Singleton class template I use myself, I
found it on the internet somewhere a while ago. Later I found an apparently
much better implementation, but I still don't understand the bulk of the
code involved in that one, let alone how to use it.

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Doug
MacDonald
Sent: Friday, March 12, 2004 6:06 AM
To: dev...@li...
Subject: Re: [Dev-C++] Re: Design decision in C++

Per,

I understand now.  You all have been talking about taking a regular 
class and adding code to it to make it a singleton.  My expressed 
ambivalence is toward something a bit different - it's a Singleton 
utility, so to speak.  Below is what I am referring to.  The idea is 
that you implement the Singleton behavior once and for all, as a 
template, then any class can become a singleton by inheriting from it as

class Klass : public Singleton<Klass> {
...
}

It's in making it work in general, through inheritance, that the 
ugliness I spoke of is introduced.

--Doug

#ifndef __SINGLETON_H__INCLUDED__
#define __SINGLETON_H__INCLUDED__

#include <assert.h>

template <typename Type>
class Singleton
{
	protected:
		static Type * ms_pInstance;
		
	public:
	// Constructor
	// The Singleton construct takes care of assinging a
	// value to the
	// instance pointer.  Since this class' child may have
	// more than one
	// parent, we have to do some pointer math to figure out
	// the correct
	// address for the child class
	Singleton ()
	{
		assert (!ms_pInstance);
		int iOffset = (int)(Type *)1 -
			(int)(Singleton<Type> *)(Type *)1;
		ms_pInstance = (Type *)((int)this + iOffset);
	}
		
	// Destructor
	virtual ~Singleton ()
	{
		assert (ms_pInstance);
		ms_pInstance = 0;
	}
		
	// Instance
	// Returns a reference to the singleton
	static Type & Instance ()
	{
		assert (ms_pInstance);
		return (*ms_pInstance);
	}
		
	// InstancePtr
	// Returns a pointer to the singleton
	static Type * InstancePtr ()
	{
		assert (ms_pInstance);
		return ms_pInstance;
	}

         // HasBeenInstantiated
         // Returns true if the class has been instantiated
         static bool HasBeenInstantiated ()
         {
             return (NULL != ms_pInstance);
         }
};

template <typename Type> Type * Singleton<Type>::ms_pInstance = 0;

#endif // __SINGLETON_H__INCLUDED__

> I haven't looked at any Singleton<DataType> class doing any instance 
> pointer offset hack.
> 
> The sample code I sent for a singleton object was just a very fiew
> lines of manually added code to the class in question. 100% valid C++
> without any typecasts.
> 
> /Per W
> 
> On Thu, 11 Mar 2004, Doug MacDonald wrote:
> 
> 
>>> Per and Kevin,
>>> 
>>> Thanks for your advice.
>>> 
>>> My ambivalence wrt the Singleton<DataType> class is in part due
>>> to the instance pointer offset hack, which seems to introduce a
>>> risk of implementation dependency: are base and derived classes
>>> always included in a standard order with offsets that never vary
>>> from compiler to compiler?.  Further, the instance pointer
>>> adjustment involves pointer <-> int casts that are a bit ugly,
>>> despite the elegance of Singleton as seen from the outside.
>>> 
>>> But I take your points as to the limited desirability of fully
>>> static classes.
>>> 
>>> (I guess declaring a top-level static _instance_ of a class is a 
>>> different matter, and is useful, e.g., when there is no C++ main 
>>> routine, as was the case in a former project of mine at my last
>>> employer.)
>>> 
>>> --Doug





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] Re: Design decision in C++

[Doug M. <dou...@al...>]

Per,

I understand now.  You all have been talking about taking a regular 
class and adding code to it to make it a singleton.  My expressed 
ambivalence is toward something a bit different - it's a Singleton 
utility, so to speak.  Below is what I am referring to.  The idea is 
that you implement the Singleton behavior once and for all, as a 
template, then any class can become a singleton by inheriting from it as

class Klass : public Singleton<Klass> {
...
}

It's in making it work in general, through inheritance, that the 
ugliness I spoke of is introduced.

--Doug

#ifndef __SINGLETON_H__INCLUDED__
#define __SINGLETON_H__INCLUDED__

#include <assert.h>

template <typename Type>
class Singleton
{
	protected:
		static Type * ms_pInstance;
		
	public:
	// Constructor
	// The Singleton construct takes care of assinging a
	// value to the
	// instance pointer.  Since this class' child may have
	// more than one
	// parent, we have to do some pointer math to figure out
	// the correct
	// address for the child class
	Singleton ()
	{
		assert (!ms_pInstance);
		int iOffset = (int)(Type *)1 -
			(int)(Singleton<Type> *)(Type *)1;
		ms_pInstance = (Type *)((int)this + iOffset);
	}
		
	// Destructor
	virtual ~Singleton ()
	{
		assert (ms_pInstance);
		ms_pInstance = 0;
	}
		
	// Instance
	// Returns a reference to the singleton
	static Type & Instance ()
	{
		assert (ms_pInstance);
		return (*ms_pInstance);
	}
		
	// InstancePtr
	// Returns a pointer to the singleton
	static Type * InstancePtr ()
	{
		assert (ms_pInstance);
		return ms_pInstance;
	}

         // HasBeenInstantiated
         // Returns true if the class has been instantiated
         static bool HasBeenInstantiated ()
         {
             return (NULL != ms_pInstance);
         }
};

template <typename Type> Type * Singleton<Type>::ms_pInstance = 0;

#endif // __SINGLETON_H__INCLUDED__

> I haven't looked at any Singleton<DataType> class doing any instance 
> pointer offset hack.
> 
> The sample code I sent for a singleton object was just a very fiew
> lines of manually added code to the class in question. 100% valid C++
> without any typecasts.
> 
> /Per W
> 
> On Thu, 11 Mar 2004, Doug MacDonald wrote:
> 
> 
>>> Per and Kevin,
>>> 
>>> Thanks for your advice.
>>> 
>>> My ambivalence wrt the Singleton<DataType> class is in part due
>>> to the instance pointer offset hack, which seems to introduce a
>>> risk of implementation dependency: are base and derived classes
>>> always included in a standard order with offsets that never vary
>>> from compiler to compiler?.  Further, the instance pointer
>>> adjustment involves pointer <-> int casts that are a bit ugly,
>>> despite the elegance of Singleton as seen from the outside.
>>> 
>>> But I take your points as to the limited desirability of fully
>>> static classes.
>>> 
>>> (I guess declaring a top-level static _instance_ of a class is a 
>>> different matter, and is useful, e.g., when there is no C++ main 
>>> routine, as was the case in a former project of mine at my last
>>> employer.)
>>> 
>>> --Doug

Re: [Dev-C++] connect to a database via odbc

[Per W. <pw...@ia...>]

Will take some time to get my fingers to write wxWidgets ;)

/Per W

On Fri, 12 Mar 2004, Oliver Brandt wrote:

> Per Westermark schrieb:
>
>  > Another alternative is to look at the database classes in wxWindows.
>
> Right! I just forgot it. wxwindows (now wxwidgets) has a
> support for ODBC. Look here: http://www.wxwidgets.org/
>
> Regards Olli

Re: [Dev-C++] connect to a database via odbc

[Oliver B. <the...@gm...>]

Per Westermark schrieb:

 > Another alternative is to look at the database classes in wxWindows.

Right! I just forgot it. wxwindows (now wxwidgets) has a
support for ODBC. Look here: http://www.wxwidgets.org/

Regards Olli



-- 
  /"\		mailto:the...@gm...
  \ /		http://www.the-unchallenged.de
   X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
  / \		

Re: [Dev-C++] connect to a database via odbc

[Per W. <pw...@ia...>]

Another alternative is to look at the database classes in wxWindows.

/Per W

On Fri, 12 Mar 2004, Oliver Brandt wrote:

> Oliver Rogasch schrieb:
> > Can anyone give me an advice, how to connect to a database via odbc?
>
> try this:
> http://otl.sourceforge.net/
> http://dtemplatelib.sourceforge.net/index.htm
>
> Regards Oliver
>
> --
>   /"\		mailto:the...@gm...
>   \ /		http://www.the-unchallenged.de
>    X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
>   / \
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] connect to a database via odbc

[Oliver B. <the...@gm...>]

Oliver Rogasch schrieb:
> Can anyone give me an advice, how to connect to a database via odbc?

try this:
http://otl.sourceforge.net/
http://dtemplatelib.sourceforge.net/index.htm

Regards Oliver

-- 
  /"\		mailto:the...@gm...
  \ /		http://www.the-unchallenged.de
   X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
  / \		

[Dev-C++] connect to a database via odbc

[Oliver R. <o.r...@gm...>]

Can anyone give me an advice, how to connect to a database via odbc?

Greetings

Oliver

Re: [Dev-C++] Design decision in C++

[<de...@ci...>]

If you want to use any objects within your class that just uses static 
methods you end up having to instantiate them as singletons in a 
non-standard construction method that you then have to document.

Far simpler to design a conventional class that you then use as a 
singleton.

In article <404...@al...>, dou...@al... 
(Doug MacDonald) wrote:

> This is thread is especially interesting to me, as I'm working on a 
> project that uses Singleton for a number of its classes, and I'm not 
> sure it is warranted.  No one has addressed Michael's original 
> question: what are the tradeoffs between using Singleton and just 
> making the class (or all of its members) static?  I'd like to know 
> about others' experiences with Singleton, in case it's advisable to 
> move from Singleton-based classes to static classes in my project.
> 
> Doug

Re: [Dev-C++] about replies

[Alvin T. <al...@th...>]

yup. it would be better if the 'reply to' address was the list.

-alvin


Daniel Glenfield wrote:
> Exactly. I enjoy seeing what other ppl have to say - I just delete those 
> with subject lines I am not interested in.
> 
> 
>> From: "Mats Lidstrom" <mat...@to...>
>> To: <dev...@li...>
>> Subject: Re: [Dev-C++] about replies
>> Date: Thu, 11 Mar 2004 00:12:20 +0100
>>
>> From: "Scott Simontis" <age...@co...>
>> > How about we all only reply to people who need to hear the results? I
>> > think this would help clear all of our inboxes.
>> > Tim Schumacher wrote:
>>
>> The purpose of a mailing list is that everybody else can gain from the
>> input. The thing that irritates me with this list is that when I click
>> "reply" it defaults to the person instead of the list.
>>
>> Just my 2 cents.
>>
>> /M
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Dev-cpp-users mailing list
>> Dev...@li...
>> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
>> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 
> 
> _________________________________________________________________
> Express yourself with cool emoticons - download MSN Messenger today! 
> http://www.msn.co.uk/messenger
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

-- 
Alvin Thompson

Navy: 34
Army: 6

[Dev-C++] Subject : Virus Detected in "Re: Your music"

[<pos...@po...>]

A mail message with subject "Re: Your music" has been found containing
a virus.
The message was sent from  dev...@li...  to the following:
sa...@po...

The email has been Deleted.
For more information contact su...@po...
The description of the Virus is shown below:
Scenarios/PPL Sales/PPL Sales Deliver: 'Selected'.
Scenarios/G.Virus: Threat: 'W32/Netsky-D' detected by 'Sophos AV Interface for MIMEsweeper'.
Scenarios/G.Exe: 'ItemLength.GE.0'.

Re: [Dev-C++] Re: Design decision in C++

[Per W. <pw...@ia...>]

I haven't looked at any Singleton<DataType> class doing any instance
pointer offset hack.

The sample code I sent for a singleton object was just a very fiew lines
of manually added code to the class in question. 100% valid C++ without
any typecasts.

/Per W

On Thu, 11 Mar 2004, Doug MacDonald wrote:

> Per and Kevin,
>
> Thanks for your advice.
>
> My ambivalence wrt the Singleton<DataType> class is in part due to the
> instance pointer offset hack, which seems to introduce a risk of
> implementation dependency: are base and derived classes always included
> in a standard order with offsets that never vary from compiler to
> compiler?.  Further, the instance pointer adjustment involves pointer
> <-> int casts that are a bit ugly, despite the elegance of Singleton as
> seen from the outside.
>
> But I take your points as to the limited desirability of fully static
> classes.
>
> (I guess declaring a top-level static _instance_ of a class is a
> different matter, and is useful, e.g., when there is no C++ main
> routine, as was the case in a former project of mine at my last employer.)
>
> --Doug
>
>
>
>

Re: [Dev-C++] Re: Design decision in C++

[Doug M. <dou...@al...>]

Per and Kevin,

Thanks for your advice.

My ambivalence wrt the Singleton<DataType> class is in part due to the 
instance pointer offset hack, which seems to introduce a risk of 
implementation dependency: are base and derived classes always included 
in a standard order with offsets that never vary from compiler to 
compiler?.  Further, the instance pointer adjustment involves pointer 
<-> int casts that are a bit ugly, despite the elegance of Singleton as 
seen from the outside.

But I take your points as to the limited desirability of fully static 
classes.

(I guess declaring a top-level static _instance_ of a class is a 
different matter, and is useful, e.g., when there is no C++ main 
routine, as was the case in a former project of mine at my last employer.)

--Doug

Re: [Dev-C++] problem with Irrlicht

[Mats L. <mat...@to...>]

When it comes to graphic cards I think you have to count the Matrox =
Millenium G450 as an old card. You really should try another card. But =
if your computer is about 5 years old as the card you might have to =
upgrade that too since new graphic cards need a faster computer.

/M

  ----- Original Message -----=20
  From: michele=20
  To: Mats Lidstrom=20
  Cc: dev-cpp-users=20
  Sent: Thursday, March 11, 2004 10:10 AM
  Subject: Re: [Dev-C++] problem with Irrlicht


  thanks... even I  think so,
  (even if my graph. card isn't very old)
  (I have a Matrox=20
  millennium G450 16MB).

  p.s. excuse me all if only I make questions... but I'm not very =
expert...

Re: [Dev-C++] about replies

[Mats L. <mat...@to...>]

From: "Siva Chandra" <siv...@ya...>

> > > > Tim Schumacher wrote:
> > >
> > >The purpose of a mailing list is that everybody
> > else can gain from the
> > >input. 

I think that was me actually :)

Re: [Dev-C++] about replies

[Siva C. <siv...@ya...>]

hello,

I do exactly what Dan' does.
But how do we know who all are willing to listen to
our replies if we are going to follow Scott??
And anyway, as Tim puts it, mailing list is that
everybody else can gain from the input. 

Hence from my side: We should be stripping of
un-neccassry junk from the text in the replies.

Siva Chandra

> Daniel Glenfield <sp...@ho...> wrote:
> I just delete those 
> with subject lines I am not interested in.
 
> >From: "Scott Simontis" <age...@co...>
> > > How about we all only reply to people who need
> to hear the results? .

> > > Tim Schumacher wrote:
> >
> >The purpose of a mailing list is that everybody
> else can gain from the
> >input. 


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

to mats Lid...Fw: [Dev-C++] problem with Irrlicht

[michele <mic...@li...>]

----- Original Message -----=20
From: michele=20
To: Mats Lidstrom=20
Cc: dev-cpp-users=20
Sent: Thursday, March 11, 2004 10:10 AM
Subject: Re: [Dev-C++] problem with Irrlicht


thanks... even I  think so,
(even if my graph. card isn't very old)
(I have a Matrox=20
millennium G450 16MB).

p.s. excuse me all if only I make questions... but I'm not very =
expert...


    ----- Original Message -----=20
    From: Mats Lidstrom=20
    To: dev...@li...=20
    Sent: Tuesday, March 09, 2004 12:24 PM
    Subject: Re: [Dev-C++] problem with Irrlicht


    The "OpenGL device" is your graphics card. What model and make is =
it? Could it be that it's an older one?
    =20
    /M

      ----- Original Message -----=20
      From: michele=20
      To: dev-cpp-users=20
      Sent: Tuesday, March 09, 2004 11:18 AM
      Subject: [Dev-C++] problem with Irrlicht
      =20
      ...but even when opengl works there is some problem... Could it =
concerns with my dll or with my graphic-card-driver?  (Sometimes it =
causes bad loop.console: "OpenGL device only has one texture unit. =
Disable multitexturing.").
      =20

Re: [Dev-C++] problem with Irrlicht

[michele <mic...@li...>]

thanks... even I  think so,
(even if my graph. card isn't very old)
(I have a Matrox=20
millennium G450 16MB).

p.s. excuse me all if only I make questions... but I'm not very =
expert...


    ----- Original Message -----=20
    From: Mats Lidstrom=20
    To: dev...@li...=20
    Sent: Tuesday, March 09, 2004 12:24 PM
    Subject: Re: [Dev-C++] problem with Irrlicht


    The "OpenGL device" is your graphics card. What model and make is =
it? Could it be that it's an older one?
    =20
    /M

      ----- Original Message -----=20
      From: michele=20
      To: dev-cpp-users=20
      Sent: Tuesday, March 09, 2004 11:18 AM
      Subject: [Dev-C++] problem with Irrlicht
      =20
      ...but even when opengl works there is some problem... Could it =
concerns with my dll or with my graphic-card-driver?  (Sometimes it =
causes bad loop.console: "OpenGL device only has one texture unit. =
Disable multitexturing.").
      =20

Re: [Dev-C++] about replies

[Daniel G. <sp...@ho...>]

Exactly. I enjoy seeing what other ppl have to say - I just delete those 
with subject lines I am not interested in.


>From: "Mats Lidstrom" <mat...@to...>
>To: <dev...@li...>
>Subject: Re: [Dev-C++] about replies
>Date: Thu, 11 Mar 2004 00:12:20 +0100
>
>From: "Scott Simontis" <age...@co...>
> > How about we all only reply to people who need to hear the results? I
> > think this would help clear all of our inboxes.
> > Tim Schumacher wrote:
>
>The purpose of a mailing list is that everybody else can gain from the
>input. The thing that irritates me with this list is that when I click
>"reply" it defaults to the person instead of the list.
>
>Just my 2 cents.
>
>/M
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

Re: [Dev-C++] about replies

[Mats L. <mat...@to...>]

From: "Scott Simontis" <age...@co...>
> How about we all only reply to people who need to hear the results? I
> think this would help clear all of our inboxes.
> Tim Schumacher wrote:

The purpose of a mailing list is that everybody else can gain from the
input. The thing that irritates me with this list is that when I click
"reply" it defaults to the person instead of the list.

Just my 2 cents.

/M

Re: [Dev-C++] about replies

[Scott S. <age...@co...>]

How about we all only reply to people who need to hear the results? I 
think this would help clear all of our inboxes.
Tim Schumacher wrote:

>Hi Oladipo,
>
>You wrote:
>
>  
>
>>when replying posts, could you pls help out those of us with
>>space-limited mail accounts to strip out whatever isn't important in
>>the post? 
>>    
>>
>
>Btw, you don't need to save the mails, there is a archive on Sourceforge
>of the mailinglist:
>
>http://sourceforge.net/mailarchive/forum.php?forum_id=6572
>
>  
>
>>for instance, the 'this mail is sponsored by SF.net..' thing. please,
>>just help us out, okay. some of these things get very long and very
>>large. 
>>    
>>
>
>I think it would even help if most people would quote right like
>described on http://www.netmeister.org/news/learn2quote.html
>
>greetings
>
>Tim
>
>  
>

[Dev-C++] Re: Design decision in C++

[Kevin B. <kev...@ma...>]

The main advantage to the static idea, of course, is that there will be no 
"this" pointer passed to all your calls, which will make them slightly more 
efficient.
The disadvantages are that the class will be very difficult to generalize 
and reuse, and that the syntax will seem "weird" and probably a bit 
difficult to understand for anybody else who ever needs to maintain this class.

Personally, I would disregard the "efficiency advantage", since it will 
likely be utterly insignificant. You should consider an "optimization" like 
this only when you have clear evidence from performance profiling of a 
working program that it will make some difference. The key is objective 
evidence; developers are notoriously bad at guessing where their 
performance bottlenecks lie. Resist the temptation to over-optimize before 
you know what the bottlenecks are, and especially before you even have a 
working design. The rule is, first make it correct, then make it fast.

If you're going to make all the class members static, you might as well 
just forget the class and define plain old variables and functions in a 
namespace. That would be syntactically almost identical, and conceptually 
cleaner. This all-static idea is *not* the same as a singleton pattern. A 
singleton class in general has no more than one instance at a time. With an 
all-static class, by contrast, there's no point having any instance at all. 
There's nothing for the "this" pointer to point to, so why bother? Ergo, if 
you're going to go this route, you might as well just use a namespace 
instead and avoid confusing future maintainers (and maybe even yourself) 
with a pointless class declaration.

--- Kevin

[Dev-C++] (no subject)

[mikro <mi...@te...>]

[Dev-C++] Re: embedded mysql

[Josep S. <sub...@ar...>]

Hi Frederick and Oliver,

If you downloaded embedded.zip to test the embedded mysql server, you might
want to add the following modified code to the test_dll.cpp file. Originally
the programme had to be run with the following parameters for main():
test.exe c++ -datadir:c:\mysql\data <--or whatever directory your "data"
directory (that contains the mysql,test,paro and other databases you create
with mysql) is in.
I added some code that passes where this data directory is and other
arguments in form of the array "arg" to mysql_server_init(). But this code
is based on the *WORKING DIRECTORY* (getcwd() function) instead of the
directory where test.exe lies (windows API GetModuleFileName() function ).
It is better to part from the directory where test.exe resides instead of
the working directory, to define where the data directory is located... I
use now the windows API GetModuleFileName() function instead of getcwd()
function. You might one to replace this code too...

Attached to this email is the newest test_dll.cpp file, and below the new
code that passes the directory where "data" resides to the
mysql_server_init() function.

Regards,
Josep

P.S. >Per, maybe you want to take alook at this code and produce a more
elegant version ;-)


#include <windows.h>  //win32 API: see GetModuleFileName()



int main(int argc, char* argv[])
{

  //CODE ADDED BY JOSEP TO AVOID HAVING TO PASS PARAMETERS TO main(). 9-3-04
  // builds something like --datadir=E:\dev-c++_projects\myproject\data
  //it's presupossed that the mysql "data" directory will be always located
in the same directory as the .exe executable

  long size = 2000L;
  char flag[size];
  char *buf;

  strcpy(flag,"--datadir=");

  GetModuleFileName(NULL, buf, size);

  char *basename;
  basename = strrchr(buf, '\\') + 1;  //last ocurrence of '\' --> name of
the exe file (=basename)

  strncat(flag, buf, strlen(buf)-strlen(basename));

  if (strlen(flag) < size-4)         //check for too small buffer.
        strcat(flag,"data");

  int argn = 3;
  char *arg[] = {
    argv[0], "c++", flag  //argv[0] is the name of the executable and on
ocassions also the path.
  };
  //---   END OF ADDED CODE ---

  MYSQL *one, *two;
  mysql_server_init(argn, arg, (char **)server_groups);