[C++] 'operator =' unavailable

[woutertjez]

Ik gebruik een class calc_date welke twee methods (waaronder local_sidereal_time) bevat die een struct als return-type hebben.

In een andere functie wil ik graag een bepaalde struct invullen door gebruik te maken van die method.

code:

loc_sidereal_time = calc_date.local_sidereal_time(utc_hour, utc_minute, utc_second, 
            date_year, date_month, date_day, 
            location_degree, location_minute, location_second);

de struct loc_sidereal_time ziet er als volgt uit:

code:

struct lst
{
long lst_hour;
long lst_minute;
float lst_second;
double lst_fractional;
};

De method geeft een struct terug van precies hetzelfde type.
Bij compilatie krijg ik echt een foutmelding:
the 'operator =' function is unavailable
In mijn class is dit wel gegeven:

code:

const calc_date_class& calc_date_class::operator= (const calc_date_class &s)
{
if (local_sidereal_time != s.local_sidereal_time)
{
lst_fractional = s.lst_fractional;
lst_hour = s.lst_hour;
lst_minute = s.lst_minute;
lst_second = s.lst_second;
}
if (day_of_week != s.day_of_week)
{
day_name = s.day_name;
dow_number = s.dow_number;
}
return *this;
}

Waarom zeurt de compiler nou nog dat er geen 'operator =' functie beschikbaar is?

[Verwijderd]

Omdat het return-type van je calc_date_class::operator= als const gedeclareerd is. Dat is zinloos en niet correct in C++.

code:

calc_date_class& calc_date_class::operator= (const calc_date_class &s)
...

<edit>
Bovendien denk ik dat hij om een operator voor de lst struct vraagt.

Je zou het het efficientste met een reference kunnen oplossen:

code:

const lst &loc_sidereal_time = calc_date.local_sidereal_time(
              utc_hour, utc_minute, utc_second, 
            date_year, date_month, date_day, 
            location_degree, location_minute, location_second);

[woutertjez]

Op maandag 03 juni 2002 14:14 schreef mietje het volgende:
Omdat het return-type van je calc_date_class::operator= als const gedeclareerd is. Dat is zinloos en niet correct in C++.

code:

calc_date_class& calc_date_class::operator= (const calc_date_class &s)
...

Nope, ik blijf nog steeds dezelfde foutmelding krijgen

[The End]

volgens mij moet het een friend functie zijn... (weet het niet meer zeker, maar probeer het eens )

[Verwijderd]

Weet ik, te snel gepost. Zie de edit van m'n vorige post.

[woutertjez]

Dit gaat dus ook niet werken mietje meneer met de ondertitel ceci n est pas une pipe.,

Ik krijg nu een redefinition of formal parameter, omdat ik die method aanroep in de volgende functie:

code:

int ns1__calc_local_sidereal_time(xsd__int date_year,
        xsd__int date_month, xsd__int date_day,
        xsd__int utc_hour, xsd__int utc_minute, xsd__float utc_second,
        xsd__int location_degree, xsd__int location_minute, 
        xsd__float location_second, struct lst &loc_sidereal_time)
{
    calc_date_class calc_date;
    loc_sidereal_time = calc_date.local_sidereal_time(utc_hour, utc_minute, utc_second,
        date_year, date_month, date_day,
        location_degree, location_minute, location_second);
    return SOAP_OK;
}

Zoals je kunt zien is de parameter loc_sidereal_time al als reference parameter meegegeven aan de functie.

Als ik de parameter nou weer als reference parameter meegeef aan de method call dan krijg ik een typeclash, omdat de struct dus tweemaal staat gedeclareerd. Een maal voor de stub (Het wordt een SOAP applicatie) die de request krijgt van de client en dus eenmaal binnen de class.
Ook al zijn de declaraties hetzelfde dan nog krijg ik het niet voor elkaar om de ene struct de waardes van de andere over te laten nemen.

[The End]

Op maandag 03 juni 2002 14:37 schreef woutertjez het volgende:
Dit gaat dus ook niet werken mietje,

Je hoeft niet meteen te gaan schelden hoor
Je zou ook gewoon een soort copy functie kunnen maken. (Dan ben je van dit hele probleem af.)
Iets van Copy(calc_date_class &s);

[woutertjez]

Op maandag 03 juni 2002 14:43 schreef The End het volgende:
Je hoeft niet meteen te gaan schelden hoor

Ok sorry, heb mn post aangepast

[Verwijderd]

Ow, in dit geval werken references niet, klopt. Je zult een operator = voor je lst struct moeten schrijven, of een boel prototypes moeten aanpassen.

code:

struct lst
{
    long lst_hour;
    long lst_minute;
    float lst_second;
    double lst_fractional;

    lst& operator = (const lst& l)
      {
        lst_hour= l.lst_hour,
        lst_minute= l.lst_minute,
        lst_second= l.lst_second,
        lst_fractional= l.lst_fractional;
        return *this;
       }
};

[MSalters]

operator= is waarschijnlijk private; net zoals alle methods wordt er ook bij een assignment een access check gedaan. Het hele verhaal over references heeft er in elk geval geen [CENSUUR] mee te maken.

[Verwijderd]

/me zucht

References was een voorstel om het snel op te lossen, maar ik geef zelf al aan dat het in dit geval niet eenvoudig gaat.

De operator = van struct lst is niet private, hij is er gewoon helemaal niet.

[woutertjez]

Nou nee, dit gaat jammergenoeg niet lukken, die struct lst aanpassen.

Die struct wordt namelijk gebruikt binnen de SOAP-message en een operator definieren dat pikt ie niet (mijn soap pre-compiler pikt dat dus niet, die de struct om moet zetten naar soap functies enzo).

[Verwijderd]

Dan blijft er niet veel anders over dan calc_date::local_sidereal_time() een reference naar een lst struct mee te geven, en binnen die methode rechtstreeks in die struct te schrijven ipv. een struct te returnen.

[MSalters]

Op maandag 03 juni 2002 15:27 schreef mietje het volgende:
/me zucht

De operator = van struct lst is niet private, hij is er gewoon helemaal niet.

Kun je iets meer informatie geven? Nu lijkt het op een errug onwaarschijnlijke compiler bug; hij zou zelfstandig die operator= moeten maken ( lst is een POD-struct ) en als de compiler dat niet kan, dan kan die ongeveer 0% van de C code in de wereld compileren.

[Verwijderd]

Op maandag 03 juni 2002 16:42 schreef MSalters het volgende:
Kun je iets meer informatie geven? Nu lijkt het op een errug onwaarschijnlijke compiler bug; hij zou zelfstandig die operator= moeten maken ( lst is een POD-struct ) en als de compiler dat niet kan, dan kan die ongeveer 0% van de C code in de wereld compileren.

Ik vroeg het me ook af, maar het is duidelijk dat de compiler zeurt over een assignment operator voor de lst struct, en die is niet private gedeclareerd, want dat de declaratie van die struct staat boven Normaal is het idd. niet, dat was het hele issue.

[MSalters]

Op maandag 03 juni 2002 18:33 schreef mietje het volgende:

[..]

Ik vroeg het me ook af, maar het is duidelijk dat de compiler zeurt over een assignment operator voor de lst struct, en die is niet private gedeclareerd, want dat de declaratie van die struct staat boven Normaal is het idd. niet, dat was het hele issue.

Maar wat is de hele foutmelding ?

[woutertjez]

Het werkt nu!!!

Het probleem zat em in het feit dat de beide structs wel precies hetzelfde waren, maar allebei via een ergens anders geplaatste omschrijving werden gedefinieerd. Dit zal wel de reden zijn dat ie niet automatisch zelf een operator = functie maakte. Ik gebruik nl VC++ 6.0 en lijkt me dat die wel iets kan....

Ik heb nu een hulpstruct gebruikt die volgens dezelfde struct is gedeclareerd als de struct die ik aan de class hoor mee te geven, dus zeuren doet ie niet. Vervolgens kopieer ik om de beurt de inhoud van de hulpstruct in de uiteindelijke struct. Niet de meest elegante oplossing waarschijnlijk, maar in mijn ogen (kennis) de enige

[MSalters]

Op dinsdag 04 juni 2002 16:38 schreef woutertjez het volgende:
Het werkt nu!!!

Het probleem zat em in het feit dat de beide structs wel precies hetzelfde waren, maar allebei via een ergens anders geplaatste omschrijving werden gedefinieerd. Dit zal wel de reden zijn dat ie niet automatisch zelf een operator = functie maakte. Ik gebruik nl VC++ 6.0 en lijkt me dat die wel iets kan....

Of de namen verschillen ( _{en dan zijn het dus niet dezelfde structs - Adres::operator=(Voornaam const& ) lijkt me geen goed idee, ook al is de inhoud "hetzelfde"} ) of de namen zijn hetzelfde ( _{en dan heb je dezelfde struct met assignment, en een ellendige bug als ooit een van de twee verandert} ). Wat was het nou?

Overigens, in het eerste geval is vast maar een van de twee structs onderhevig aan de regels van de SOAP precompiler; dan kun je de tweede een ctor en conversion operator van/naar de eerste struct geven; dan werkt de assigment wel gewoon.

Ik heb nu een hulpstruct gebruikt die volgens dezelfde struct is gedeclareerd als de struct die ik aan de class hoor mee te geven, dus zeuren doet ie niet. Vervolgens kopieer ik om de beurt de inhoud van de hulpstruct in de uiteindelijke struct. Niet de meest elegante oplossing waarschijnlijk, maar in mijn ogen (kennis) de enige